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

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Feb 2003 01:18:40 -0500

Tony,

You are missing my point for the solution.  But yes it could be double
NAT too.
The solution I am looking for requires no intelligence for any mechanism
on the home node except to send IPv6 packets.  That is not the case for
ISATAP.  Or administration of the IPv6 nodes for mechanisms.  It is all
done by the home nat router.  So Microsoft XP, Linux, Freebsd, Symbian,
Vxworks, and other home embedded OS system nodes would not have had to
implement any of the previous ngtrans mechanisms.  It is all
accomplished at the home "edge" to the provider or at the apartment
complex "edge" to the box for fibre at the curb, etc. etc.

If the home nodes can get a public address for their network then yes
the previous ngtrans mechanism become usable.  What I am discussing is a
different case.

I believe the home routers can build this and if we can define and
specify it.

Regards,
/jim 

> -----Original Message-----
> From: Tony Hain [mailto:[email-masked]] 
> Sent: Wednesday, February 12, 2003 4:08 PM
> To: Bound, Jim; [email-masked]
> Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT
> 
> 
> So the case is a double nat? If it is just that the 'public' 
> side of the nat has a private address and needs to tunnel 
> over IPv4 infrastructure, isatap is the appropriate tool. 
> 
> 
> -----Original Message-----
> From: Bound, Jim [mailto:[email-masked]] 
> Sent: Wednesday, February 12, 2003 11:15 AM
> To: [email-masked]; [email-masked]
> Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT
> 
> 
> Tony,
> 
> I may suggest alternative to Teredo but looking at that now 
> technically. But if Teredo works that is fine but many have 
> issues with the complexity.  So I will reserve comment on 
> Teredo for now OK.  Not sure I support it now.  We will see.
> 
> The home router cannot become a 6to4 router because the 
> public address may not be available or duplicated in practice 
> is my assumption?  But more than that an ecap of the packet 
> with 6 proto-id is a simple software engineering upgrade for 
> very low end home routers and field deliverable with a patch 
> on the web is my belief, and 6to4 is far more complex and may 
> require an entire release. So the work we do here may be two 
> steps 1) first do simple encap, 2) eventually deploy 6to4 
> given the home router can use the public address.  I am also 
> worried of duplicate public address for the home router for 
> the nat which I have seen at home and in hotels enough and in 
> enough locations that I just have to look further into it.  I 
> am speaking with multiple providers now that do this function 
> to get the issues from the horses mouth not second hand.  I 
> will also speak with 2 well known home router vendors on my 
> assumptions for patches for upgrades.
> 
> Regards,
> /jim
> 
> 
> 
> -----Original Message-----
> From: Tony Hain [mailto:[email-masked]] 
> Sent: Wednesday, February 12, 2003 1:55 PM
> To: Bound, Jim; [email-masked]
> Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT
> 
> 
> 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,
> 
> 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: "Tony Hain" <[email-masked]>
Date: Thu, 13 Feb 2003 14:14:04 -0800

Bound, Jim wrote:
> Tony,
> 
> You are missing my point for the solution.  But yes it could 
> be double NAT too. The solution I am looking for requires no 
> intelligence for any mechanism on the home node except to 
> send IPv6 packets.  That is not the case for ISATAP.  Or 
> administration of the IPv6 nodes for mechanisms.  It is all 
> done by the home nat router.  So Microsoft XP, Linux, 
> Freebsd, Symbian, Vxworks, and other home embedded OS system 
> nodes would not have had to implement any of the previous 
> ngtrans mechanisms.  It is all accomplished at the home 
> "edge" to the provider or at the apartment complex "edge" to 
> the box for fibre at the curb, etc. etc.
> 
> If the home nodes can get a public address for their network 
> then yes the previous ngtrans mechanism become usable.  What 
> I am discussing is a different case.
> 

I will admit I am having a hard time finding the point. For this case
the home router may or may not be a nat, but it is downstream from a nat
which prevents 6to4 from working. It sounds like that if it weren't for
the private addressing on the upstream side, the solution you are
looking for would be solved by 6to4. If that is the case, you are
looking to define an IPv6 router that can automatically build a tunnel
over IPv4 to get out. 

> I believe the home routers can build this and if we can 
> define and specify it.

Well it would already be specified as the client router to a tunnel
broker. If what you are trying to do is establish an anycast model for
finding a tunnel broker, you will find it challenging to deal with the
identity issue when the upstream nat mangles the header. This is a case
where tunnel broker is the right tool, because it already has the
mechanism to handle identity and prefix allocation.

Tony