[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Bound, Jim wrote:

> Thanks for using ascii text as mail interface or rule of convesion to
> text from html or rtf.

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

> Bound, Jim wrote:
> > 

<SNIP>

> > 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.

<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.

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.

> > 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.

Greets,
 Jeroen