RE: IPv6 Home Use to stimulate deployment over IPv4-NAT

["Bound, Jim" <Jim.Bound@hp.com>]

Jeroen,

> google "outlook readasplain" does the trick for all outlook 
> fans ;) I dislike HTML/RTF etc as a mail format too...

Thanks I will go look at this to learn more .....................

> > > The NAT-box/router will have both have a public IPv4 and
> > > IPv6:  internet side IPv4: 1.2.3.4
> > >  user     side IPv4: 10.0.0.1
> > >  internet side IPv6: 2001:db8::0:1
> > >  user     side IPv6: 2001:db8::1:2
> > 
> > Yes but also I am concerned about the persistance of the NAT
> > box address
> > which affects 6to4 performance. But checking.  Also I assume 6to4
> > 2002::/ can be used too at the ISP too in your diagram.
> 
> If the infrastructure behind the NAT box supports Native IPv6 
> all becomes much easier ofcourse and then one could even use 
> the NAT box as 6to4 relay as the IPv6 prefix would then be 
> 2002:0102:0304::/48 But in that case the ISP could better go 
> for native IPv6 deployment.

I agree 100% but as other mail stated getting the home router industry
to do IPv6 requires a baby step for the business case.  Ergo a technical
solution that is not painful, robust, and will scale.  I am not clear we
have developed that here in v60ps or ngtrans.

> 
> <SNIP>
> 
> > > Thus the cheap alternative: Fix up a Tunnelbroker on the NAT
> > > box (or on a second machine) which can be connected to the 
> > > public internet giving it the above 2 IPv6 addresses and one 
> > > private / 'userside' IPv4 address. The endusers can the build 
> > > a tunnel from their 10.0.0.0/24 IPv4 address to the 10.0.0.1 
> > > IPv4 address and route their IPv6 traffic over that.
> > 
> > Yes but the IPv6 packet will have to be encaped at the home
> > nat router.
> > That is what I am saying is a cheap and expedient solution 
> and longer
> > solution is 6to4 at the home nat router.  
> > 
> > I am still thinking about the tunnel broker angle. For 
> example why not 
> > the ISP provide this via the web interface to the user that is 
> > downloadable.  The first and quick deployment strategy should be to 
> > reduce the amount of effort the home nat box has to do for initial 
> > deployment.  So if the tunnel broker can be a service at the ISP to 
> > the home net that reduces what is required "initially" for the home 
> > nat box.
> 
> One doesn't want a webinterface. Though MSN, Outlook, ICQ and 
> many other sites requiring authentication have shown that the 
> signup process can be done over the web, the user shouldn't 
> have to configure a thing on their machine. Currently a 
> 'apt-get install freenet6' on a debian machine will get you 
> connected over Freenet6 The ISP could provide it's users to 
> a, modified, binary of this tool which connects the user to 
> it's local POP. They could even use a connection to their 
> RADIUS accounting machine to give the user a persistent IPv6 
> prefix for the tunnel and subnet provided over it. The user 
> should only have to: download + run the tool, maybe give some 
> login information and be done with it.

This is a good point and idea.  If this flys and a few of us believe it
worth while we should document the above in the spec as appendice.

Also using POP is more appropriate for discussion too.

> 
> Unfortunatly most homeusers will be running Windows 9x thus 
> unless they install Trumpet's Winsock they can't use IPv6 at 
> all. NT4/Windows 2000 IPv6 requires a somewhat difficult (for 
> endusers mind
> you)
> installation and has some problems with newer versions of IE. 
> Windows XP users are best of ofcourse in this row as they can 
> with "ipv6 install". And for all the people running 
> Linux/*BSD they can probably also manage installing an IPv6 
> stack. There are also quite a number of easy scripts and 
> autoconfig tools for the "free" OS's. All OS's not in the 
> list above are not in the 'enduser' segment IMHO and usually 
> the people using those know what they are doing.

We need to be vendor neutral here though I think trumpet is good
comment.
My view is if the home box supports IPv6 and sends packets with IPv6 the
home router box and possibly the cable modem will simply take care of
the coexistence issues to the POP.  If it is that simply it will be
deployed and it gives a cheap ROI business case to the home routers and
the providers.



> 
> > > Ofcourse this would require something automatic for the
> > > enduser as not every enduser is a computer guru. The Freenet6 
> > > TSP protocol and others could be used to complement this. I 
> > > am currently in the process of finishing up the autoconfig 
> > > tool for the SixXS project which allows a similar concept to 
> > > work without any user intervention.
> > 
> > This is why I am thinking the TSP be at the ISP and yes 
> Freenet6 could 
> > be used by the ISPs pretty "cheap".
> 
> The "POP" as I like to call it, or tunnelbroker as per TSP 
> drafts, should ofcourse be on the NAT box or next to it 
> inside the ISP's network which would save quite some latency 
> and the big problem that the endusers are all NAT'ed and thus 
> can't use any other 'public' POP.

I agree 100%.

/jim

> 
> Greets,
>  Jeroen
> 
>