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

From: "Bound, Jim" <[email-masked]>
Date: Wed, 12 Feb 2003 12:21:37 -0500

Folks,
 
I am hearing an need for home users for transition.  It could be this is
ipv6 wg work but will bounce it off here first.
 
Assume dominant NAT/VPN/Firewall routers in most homes for Internet
access.
 
Assume an upstream provider obtains IPv6 prefix to give to subscribers.
 
Assume home routers want to support IPv6 and will eventually but won't
move until they believe it can be used over provider networks.
 
Assume there is not enough Ipv4 address space for providers to give out
to all subscribers or cannot at reasonable cost.  But they can give the
subscriber an IPv6 prefix.  This means 6to4 or ISATAP won't work in this
scenario in the users home.
 
A solution (more on Teredo below) would be to figure a method for an
IPv6 on the homelan to be encaped in the NAT packet to the provider who
will decap that packet and send to the IPv6 destination and recall the
state to the NAT user upon receiving packets back so the session can be
established with the home user over the net.
 
This is quick for now as a thought.
 
The home user network encaps the IPv6 packet at NAT with Protocol ID
equivalent to "6".  The provider then takes that packet and decaps at
their edge and uses native IPv6 or 6to4 to encap that packet to where
the IPv6 service is located.  I realize this has many assumptions and I
would work on those with some other folks interested in this problem.  
 
I am re-reading Teredo now and working to see if it is addendum to
Teredo or completely different solution.  I think it is a different
solution and possibly much simpler.  I also believe this solution we are
looking at can do e2e IPsec over the IPv4-NAT.
 
This would be a minor initial update for the home router vendors and
basic IPv6 edge tunneling for the Provider.  Also I think a
tunnel-broker could be used by the Provider to help set this up for
users too.  The code for the home router on my first analysis could also
be a firmware upgrade that is down loadable.
 
Could I get others opinions and thoughts on this before I and some
others jump in here.
 
thanks
/jim

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 12 Feb 2003 19:06:43 +0100

Bound, Jim wrote:

>  
> I am hearing an need for home users for transition.  It could 
> be this is ipv6 wg work but will bounce it off here first.

<SNIP>

> Could I get others opinions and thoughts on this before I and 
> some others jump in here.

Based on your assumptions you would have something similar too:

{ Internet } - { ISP } - <NAT> - { many endusers }

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

First of all the ISP could choose to simply have all its routers
understand native IPv6. But ofcourse this is a nogo with most
hardware, and as apparently the ISP can't get IPv4 space it prolly
won't have enough cash to get new hardware too.

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.

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.

Greets,
 Jeroen

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 12 Feb 2003 10:55:14 -0800

Maybe I misunderstood the scenario, but it looks like you are describing
a case where teredo is the appropriate choice. To restate; the ISP is
offering support for IPv6, including a tunnel endpoint to transit any
non-upgradable PE/CPE gear, though there is a nat in the path, so simple
IPv4 encaps using 6to4 or isatap will fail. If the nat can be upgraded,
it should become a 6to4 router. If not, it doesn't make sense to insert
yet another device to do tunneling, because the end nodes are capable of
doing it just as well.
 
Tony

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bound, Jim
Sent: Wednesday, February 12, 2003 9:22 AM
To: [email-masked]
Subject: IPv6 Home Use to stimulate deployment over IPv4-NAT

Folks,

 

 

 

 
thanks
/jim

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 13 Feb 2003 11:30:15 +0100

> Assume there is not enough Ipv4 address space for providers to give 
> out to all subscribers or cannot at reasonable cost.  But they can 
> give the subscriber an IPv6 prefix.  This means 6to4 or ISATAP won't 
> work in this scenario in the users home.
>

Are you saying this as an alternative to IPv4 NAT or as a complement? 
(I assume the latter)

> the IPv6 service is located.  I realize this has many assumptions and 
> I would work on those with some other folks interested in this 
> problem. 

If you mean the first of what I wrote above, I could finally see 
something that could  make consumer oriented operators look at IPv6. 
There are a number of questions still though, as cost and stability of 
equipment as well as application impact. But the two last doesn't 
appear to have bothered this type of operators before....

> solution and possibly much simpler.  I also believe this solution we 
> are looking at can do e2e IPsec over the IPv4-NAT.

That would be a useful application in a way. But I am worried about the 
poor performance of IPsec in combination with IPv6 code.

- kurtis -

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Feb 2003 13:55:49 +0100 (CET)

> scenario in the users home.

I think what is needed are four things:
1. A method for the actual encapsulation
   IPv6 over UDP over IPv4 might be the easiest
2. A method to keep the NAT state up to date
   ICMPv6 echo's over the tunnel can do that
3. A method to detect when the NAT state has been lost or changed
   so that it can be restored (perhaps using the same mechanism in #4)
4. A mechanism to determine the tunnel endpoint (IP address and port)

Note that draft-ietf-mobileip-nat-traversal-07.txt specifies how
to do this when #4 is the Mobile IPv4 registration protocol.

I think much of that draft can be used, and for #4 we can use either
 - TSP as for tunnel broker (makes sense when some authentication of
   the client is needed)
 - a DHCPv4 option (makes sense when DHCPv4 is already used by the ISP
   and no special authentication is needed for the tunnel)

> would work on those with some other folks interested in this problem.  

Using a separate protocol ID implies that the NAT box has the functionality.
Using UDP tunneling provides more flexibility since one can run tunneling
across a NAT box one can't modify/control (like the one I have at home).

Thus until the home router has been modified one could do this
tunneling from the host at home.

  Erik