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

[Erik Nordmark <Erik.Nordmark@sun.com>]

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

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)

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

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