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

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Feb 2003 08:24:24 -0500

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

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 17 Feb 2003 19:49:40 -0500

Tony,

Your not getting it at all.  Let me try another way and I think the
tunnel broker may work.  But that is the solution discussion.  Others
get it and others don't and I am trying to determine what those not
getting it are missing.

The idea is to simply get an IPv6 packet to the POP without any
mechanism except a tunnel.

Home user BOX address 10.1.2.3 

To

NAT Box 18.1.4.6 (global address)

To Tunnel point at POP

POP Tunnel End point 128.3.6.8

Two ways this can work.

#1 Home user encaps as follows:

Src 10.1.2.3
DST 128.3.6.8
IPv6 encap packet in protocol ID 41

THis means the home node has to encap its IPv6 address inside IPv4.

#2 Better Edgev6 solution  would be as follows:

Home user box just sends IPv6 packet (no messing around on the home
node) and the NAT box has been upgraded to encap to the tunnel broker or
POP tunnel using config tunnels. This means upgrade to home NAT boxes
though for simple encap and understanding tunnel end points.

#3 Once IPv6 is native the IPv6 packet goes directly to the POP.

THe solution change for #2 is the NAT Home Router.

This is not done today.

As far as the previous architecture point you missed that too.  What I
believe is that no box on a network should have to look past the header
to do perform its function. So looking at port numbers is
architecturally impure from my view to be kind.

I have enough information to attempt execution now though.

Thanks for your time

Regards,
/jim

> -----Original Message-----
> From: Tony Hain [mailto:[email-masked]] 
> Sent: Thursday, February 13, 2003 5:14 PM
> To: Bound, Jim; [email-masked]
> Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT
> 
> 
> 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
> 
> > 
> > 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: "Bound, Jim" <[email-masked]>
Date: Mon, 17 Feb 2003 19:54:37 -0500

Tony,

> Bound, Jim wrote:
> > ...
> > I will build different solution other than Teredo.  Teredo is
> > to complex and breaks a 2 rules for me I use as network 
> > engineer/architect for v6ops solutions. 1) We should NEVER 
> > use or access port numbers to get things done but only use 
> > the IP header whereever possible. 
> 
> Well it is arguable that teredo violates this rule, since the 
> origin application port is not referenced. The fact that it 
> uses the available port id bits in the IPv4-UDP encapsulation 
> header to construct the IPv6 address is really a function of 
> the application in the encapsulating endpoint. 

It has to work with more than the IP header.

> 
> > 2)Client/Server protocol
> > soulutions should only be developed for v6ops solutions, 
> > where the client and server are in the same network domain. 
> 
> While this may be a reasonable restriction for a corporate 
> marketing decision, it makes no sense for a standards effort. 
> The whole point for people to move to IPv6 is so that there 
> are no topological restrictions placed on nodes, particularly 
> servers. If one required all servers to live in the same 
> domain as their clients, all web access would require a 
> proxy. v6ops needs to be about building the infrastructure 
> tools and configurations so that IPv6 applications are 
> unaware of the activities going on at the packet handling level.

I am fine with client/server apps that run across many nets.  I am not
fine with transition solutions that try to attempt work around NAT.
 
> 
> 
> > Teredo breaks both of these principles for me.
> > 
> > ISATAP is to robust for home use and I do not see it being
> > used there at this time. I do see it in other environments 
> > for sure (e.g. Military, Manufacturing, Robotics, and a few 
> > others I know interested in ISATAP).
> > 
> > The home user scenario is clear and well understood.
> > 
> > The solution I will proprose will cause NO changes to the
> > client code and will exist in the NAT and POP.  The idea is 
> > to view it as NAT+IPV6 not working around NAT.  This has been 
> > an error in our thinking model (mine included). 
> 
> Well, it is exactly the model of 6to4. You are adding the 
> wrinkle of the home edge being behind a nat, which tunnel 
> broker deals with.

I believe so except for how to get the packet to the broker.

> 
> >  The solution
> > will drive as the underlying end mechanisms to either be 
> > Native IPv6 or 6to4 which are cohesive also with v6ops 
> > direction and current work.  Note Teredo and ISATAP are not 
> > at this time.  I will suggest it and bring it as idea and 
> > solution IETF can reject it if it is not good, whether it is 
> > used is another matter. I only say that because this is a 
> > real deployment problem for home use.  
> 
> Yes and no. Yes the case exists where a home edge nat/router 
> is behind a nat, and we need a solution, but no we can't 
> assume that even the home edge nat is upgradable, as in 
> docsis cable modems. 

I don't agree and will get it from the answer from those suppliers to be
sure.

>The fact that v6ops is too highly 
> focused on router upgrade solutions is due to the lack of 
> appreciation for the breadth of the problem space. The whole 
> point of the scenario design teams was to provide descriptive 
> documents to help educate about this breadth, but several 
> vocal participants have chosen to dismiss them as out of line 
> with a directive that all deployments must fit a single mold. 

Don't discount the importance of the v6ops scenarios but deployment may
not wait.

> 
> > 
> > I am now going to propose to a few providers to get feedback
> > (my own included in NH) and a few home router vendors that we 
> > are building connections to via the IPv6 Forum. This will 
> > take me some time.
> 
> I am not going to discourage new concepts, but take a hard 
> look at the identity/allocation issues that are solved in 
> tunnel broker, and make sure any new approach works at least 
> that well.

Of course.

/jim
> 
> Tony
> 
> 
> > 
> > P.S. If anyone here on the list is interested in working on
> > this let me know and there are others not on this list.  thanks
> > 
> > Regards,
> > /jim
> > 
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 17 Feb 2003 19:57:02 -0500

Alain,

I am on the exact same page as you today.

I also believe this is imperative for IPv6 deployment.

Thanks
/jim

> From: Alain Durand [mailto:[email-masked]] 
> Sent: Friday, February 14, 2003 7:48 PM
> To: Bound, Jim
> Cc: [email-masked]; [email-masked]
> Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT
> 
> 
> Jim,
> 
> I like your idea. A lot.
> the issue I have with solution like teredo is that they are 
> initiated by the end nodes. The implications are:
> 1- all end node needs to understand this protocol
> 2- it becomes difficult for the acess router/firewall
>    to enfore any kind of policy on what traffic is acceptable
>    A knob that says 'enable IPv6' is just not enough.
>    We need solutions that enable the user to express easily the same
>    security policy in v4 and v6.
> 
> Those are the reasons why I think that 'IPv6 connectivity' is
> a functionality that has to be provided by an access router
> and not by the end hosts.
> .
> The nice thing about this is that it would work
> the same way in case of simple NAT (the exit router
> is given a public IPv4 address) and double NAT
> (the exit router is given a private address)
> but tunneling over UDP.
> 
>                     v4 Internet
>                         |
>                         |
>                         |
>  
>                        CPE           <--- v4 external address 
> can be either
>                  v4 acces router          global or private 
> (double NAT)
>                      v4 NAT
>                  v6 access router
>               (Tunnel Broker client)
>                         |
>                         |
>           ------------------------------------------   Home lan
>                                |           |
>                              Host1       Host2
>                
> Even better, this could be implemented on a different
> box than the actual v4 exit router!
> The connection scenario would then be the following:
> 
>                     v4 Internet
>                         |
>                         |
>                         |
> 
>                        CPE
>                  v4 acces router
>                      v4 NAT
>                         |
>                         |
>           ------------------------------------------   Home lan
>               |                |           |
>            v6 access         Host1       Host2
>              router
>       (Tunnel Broker client)
> 
> 
> That way folks who do not want to (or can not)replace their 
> CPE just have to add another box in the home network to 
> provide v6 connectivity to the entire home lan.
> 
> Now, as it has been pointed out, this is a typical case
> where the access router is a client to a tunnel broker.
> The question is what can we do to simplify the tunnel
> set-up from the router to the tunnel broker.
> If we decide to go that route, a tunnel set up protocol
> like the one Marc Blanchet was suggesting now become
> a interesting solution
> 
> The configuration of the v6 access router would require:
> - providing the IPv4 address (or name) of the IPS Tunnel Broker
> - providing the credentials negatiated out of band with the ISP (e.g. 
> username/passwd)
> - specifying the encapsulation mode: IPv6/IPv4 or IPv6/UDP/IPv4 or 
> IPv6/PPP/IPv4
> - specifying the IPv6 security policy
> 
> Yes, there is manual configuration involved, but I think it 
> is minimal and not too different to what home users do today 
> to configure their DSL router.
> 
>     - Alain.
> 
> 
> 
> 
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 17 Feb 2003 20:02:03 -0500

So this is method 1 and working.
/jim

> From: JORDI PALET MARTINEZ [mailto:[email-masked]] 
> Sent: Sunday, February 16, 2003 1:55 PM
> To: Jeroen Massar; [email-masked]
> Cc: 'Alain Durand'; Bound, Jim; [email-masked]
> I've observed, that in most of the cases, a NAT box forwards 
> proto-41 as any other UPD or TCP traffic, so I can use my 
> IPv6 elsewhere ... In my home, hotels, conferences, ...
> 
> In my case never requires changing my DSL router 
> configuration, but I agree that if the hotel is filtering 
> proto-41, I will not be able to change it either ;-)
> 
> Regards,
> Jordi
> 
> ----- Original Message -----
> From: "Tim Chown" <[email-masked]>
> To: "Jeroen Massar" <[email-masked]>
> Cc: "'Alain Durand'" <[email-masked]>; "'Bound, Jim'" 
> <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Sunday, February 16, 2003 6:58 PM
> > On Sun, Feb 16, 2003 at 03:18:28PM +0100, Jeroen Massar wrote:
> > >
> > > Which one can do now by simply installing eg the freenet6 client 
> > > onto one of the existing windows/*nix boxes which will 
> advertise the 
> > > IPv6 prefix onto the local subnet. The only trick here is to have 
> > > the CPE forward proto-41 to your v6-gate or using Teredo. 
> Btw 'just 
> > > have to add' is sometimes expensive for some people.
> >
> > This is what our IPv6 students tend to do in their homes.  It works 
> > nicely, but still requires a tweak in the DSL router.
> >
> > Tim
> >
> 
> *********************************
> Madrid 2003 Global IPv6 Summit
> 12-14 May 2003 - Pre-register at:
> http://www.ipv6-es.com
> Interested in participating or sponsoring ?
> Contact us at [email-masked]
> 
> 
>

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 17 Feb 2003 17:59:06 -0800

> It has to work with more than the IP header.

Uh? The Teredo routing works strictly with the IPv6 header. If you send
a packet to a Teredo relay, the relay will not look at anything besides
that header. The encapsulation runs over UDP, but you may observe that
many encapsulation protocol run with "more than IP" -- L2TP, for
example, runs over UDP.

> fine with transition solutions that try to attempt work around NAT.

Whether you cross the NAT using Teredo or using a tunnel does not change
anything to the fact that you "working around the NAT".

-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 17 Feb 2003 18:05:10 -0800

> If we have tunnel brokers we don't need teredo right?  That's my take
> now.

We have debated that many times. The issue is economics, and more
precisely the trade-off between how much software you write and how much
bandwidth you require from the tunnel server. A Teredo host only uses
the Internet bandwidth that was already paid by its owner to the local
ISP; a tunnel host uses that bandwidth, plus an equal amount at the end
of the tunnel. That may be OK if the tunnel is provided by the same ISP
that provides the user connection; but in all other cases, the user ends
up with having the equivalent of two ISP subscriptions.

-- Christian Huitema

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 17 Feb 2003 21:48:51 -0500

> Uh? The Teredo routing works strictly with the IPv6 header. 
> If you send a packet to a Teredo relay, the relay will not 
> look at anything besides that header. The encapsulation runs 
> over UDP, but you may observe that many encapsulation 
> protocol run with "more than IP" -- L2TP, for example, runs over UDP.

There are many parts to Teredo that are not just a simple ecap (e.g.
bubbles, udp refresh to NAT).  I am not against Teredo and I believe it
has its case and use.

From -08.

----------------------------------------------
3.2.1	When to use Teredo?

Teredo is designed to robustly enable IPv6 traffic through NATs, and
the price of robustness is a reasonable amount of overhead, due to
UDP encapsulation and transmission of bubbles. Nodes that want to
connect to the IPv6 Internet SHOULD only use the Teredo service as a
"last resort" option: they SHOULD prefer using direct IPv6
connectivity if it is locally available or if it is provided by a
6to4 router co-located with the local NAT, and they SHOULD prefer
using the less onerous "6to4" encapsulation if they can use a global
IPv4 address.
-------------------------------------------------

It does have overhead.

I would just add that in addition to 6to4 Tunnel Brokers should be
listed above too.  Then the market will decide which one to use.

But to compare Teredo with a simple encap at a DSL router of an IPv6
packet to get it to a Tunnel broker that was established is no way the
overhead of Teredo.
What I say also should not discount Teredo and I supported and still
support it as a standards track document.  I believe it will take to
long and too complex for initial IPv6 deployment and looking for a more
simple solution.  You sent me mail that we care about deployment.  I say
exactly.
I read ahead and will respond to your economic case in that mail.

> Whether you cross the NAT using Teredo or using a tunnel does 
> not change anything to the fact that you "working around the NAT".

I was referring to the cost and single point of failure in depending on
a client server model.  Not working around only NAT.  Bad prefix to may
last statement.
I don't like ALGs either.  But willing now to compromise for Tunnel
Brokers for IPv6 deployment.

My main thinking is that the client simply sends IPv6 packets after
setting up its tunnel end points to communicate with IPv6 either at the
DSL router or the POP.  I want to see a fix suggestion for the DSL
router and POP.  

/jim

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 17 Feb 2003 18:55:34 -0800

> listed above too.  Then the market will decide which one to use.

In fact, we can probably adapt the Teredo spec so the same code can be
used for configured tunnels and for dynamic Teredo behavior.

> packet to get it to a Tunnel broker that was established is no way the

I was only referring to the point that not all encapsulations are
directly over IP. 

> simple solution.  You sent me mail that we care about deployment.  I
say

In the IETF, we used to deal with arguments of complexity by considering
running code, rather than by theoretical debates. We have running code
for Teredo. I have used the code myself. I guess this meet at least 1/2
of the requirements -- the other 1/2 would be to prove Interop with an
independent implementation.

-- Christian Huitema

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 17 Feb 2003 22:08:09 -0500

> > If we have tunnel brokers we don't need teredo right?  

Clarification.  I mean't for initial deployment jump start.  Which was
the context of my whole thread here.  I can envision many reasons for
Teredo.

> 
> We have debated that many times. The issue is economics, and 
> more precisely the trade-off between how much software you 
> write and how much bandwidth you require from the tunnel 
> server. A Teredo host only uses the Internet bandwidth that 
> was already paid by its owner to the local ISP; a tunnel host 
> uses that bandwidth, plus an equal amount at the end of the 
> tunnel. That may be OK if the tunnel is provided by the same 
> ISP that provides the user connection; but in all other 
> cases, the user ends up with having the equivalent of two ISP 
> subscriptions.

As far as debating issues many times.  That means nothing to me.  We
have debated so many issues so many times on so many topics in the IETF.
Are you watching the multi6 email exchange, as one of many examples
:--).    

I agree with your trade off logic for engineering above.

On Teredo bandwidth.  But each ISP would have to have a Teredo Server?

--------------------------------------------------
2.3	Teredo Server

A node that has access to the IPv4 Internet through a globally
routable address, and that is used as a helper to provide IPv6
connectivity to Teredo clients.
---------------------------------------------------------------

So each ISP would need one?

And:

---------------------------------------------------------------
3.2.3	Minimal load on servers

During the peak of the transition, there will be a requirement to
deploy a large number of servers throughout the Internet. Minimizing
the load on the server is a good way to facilitate this deployment.
To achieve this goal, servers should be as stateless as possible,
and they should also not be required to carry any more traffic than
necessary. To achieve this objective, we request that servers only
enable the packet exchange between clients, but do not carry the
actual data packets: these packets will have to be exchanged
directly between the Teredo clients, or through a destination-
selected relay for exchanges between Teredo clients and other IPv6
clients.
----------------------------------------------------------------------

Seems like it will require a lot of servers too during peak.  What I am
driving is lets do it without all these servers before the "peak"
(defined as in the above from Teredo).  Not that Teredo does not have
purpose.

Contrary to many opinions most average home users do have one ISP and
many new users are going be in an economic condition that does not
warrant support for two ISPs.  Most non technical/computer professionals
I know do not have two ISPs so I question this fact stated and have to
see real polls and analysis.  But even if true the Tunnel Broker is cost
effective for that case. Regarding use of the end tunnel I am not sure I
agree with this cost metric, but the point is if it works then use it,
and it harms nothing.  What I believe is that a Tunnel Broker strategy
can assist to get IPv6 deployed for home use far faster than use of
Teredo for initial deployment and use.

That in turn gives the ISP and other Providers a means to request their
IPv6 prefixes and use their entrepreneurial skills with IPv6 for their
end users. If they all have to deploy Teredo and other complex schemes
they will wait longer to get started.

Now I envision Teredo use in IPv4 and IPv6 coexistence for Savy Home
Users, Small Businesses, Enterprise Intranets that are NAT'd, and a dual
stack path around IPv4 NAT in some mission critical environments where
as the Teredo draft states there is no other choice.  It is an important
tool for IPv4 and IPv6 coexistence.

I believe for Home Use we need something very simple that is a no
brainer to understand and very simple for operations at the ISP and
operations by the Home User.

Regards,
/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 17 Feb 2003 22:12:01 -0500

> In fact, we can probably adapt the Teredo spec so the same 
> code can be used for configured tunnels and for dynamic 
> Teredo behavior.

I am thinking like that too but have not broken tbrough it this is
clearly an idea I think worth pursuing.

> I was only referring to the point that not all encapsulations 
> are directly over IP. 

ACK.

> In the IETF, we used to deal with arguments of complexity by 
> considering running code, rather than by theoretical debates. 
> We have running code for Teredo. I have used the code myself. 
> I guess this meet at least 1/2 of the requirements -- the 
> other 1/2 would be to prove Interop with an independent 
> implementation.

I agree this is a very very good argument.  I want to do the same but I
need find DSL Router folks to make it work.  We both have done manual
config and 6to4.  But I am wondering if some kind of very very simple
code patch can make it so the DSL router can assist with the process.

/jim

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 18 Feb 2003 08:47:26 -0800

> code patch can make it so the DSL router can assist with the process.

Teredo is not meant to be implemented in the DSL router: it is a single
host solution. The only requirement of the DSL router is that it
provides "reasonable" support for UDP-IPv4; our tests show that this is
the case for the overwhelming majority of the small routers available on
the US market. The correction needed by the other routers mostly amount
to bug fixes: a slight modification of the "5-tuple" mapping algorithm,
and a requirement to not do anything stupid after receiving an ICMP
"unreachable" error message. The same fixes are also needed to enable
the STUN scenarios that are used by IPv4/VoIP, so I expect market
pressure will lead the home router manufacturers to "do the right
thing."

If these home router manufacturers want to help deploy IPv6, then the
obvious requirement is to support 6to4, to allow configured tunnels, and
to also allow relaying of an ISP native IPv6 service. This is very much
what we are describing in the "unmanaged networks" scenarios.

-- Christian Huitema

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 21 Feb 2003 12:50:44 -0500

I agree Christian.
/jim

> From: Christian Huitema [mailto:[email-masked]] 
> Sent: Tuesday, February 18, 2003 11:47 AM
> To: Bound, Jim
> Cc: [email-masked]
> > > considering running code, rather than by theoretical debates. We 
> > > have running code for Teredo. I have used the code 
> myself. I guess 
> > > this meet at least 1/2 of the requirements -- the other 
> 1/2 would be 
> > > to prove Interop with an independent implementation.
> > 
> > I agree this is a very very good argument.  I want to do 
> the same but
> I
> Teredo is not meant to be implemented in the DSL router: it 
> is a single host solution. The only requirement of the DSL 
> router is that it provides "reasonable" support for UDP-IPv4; 
> our tests show that this is the case for the overwhelming 
> majority of the small routers available on the US market. The 
> correction needed by the other routers mostly amount to bug 
> fixes: a slight modification of the "5-tuple" mapping 
> algorithm, and a requirement to not do anything stupid after 
> receiving an ICMP "unreachable" error message. The same fixes 
> are also needed to enable the STUN scenarios that are used by 
> IPv4/VoIP, so I expect market pressure will lead the home 
> router manufacturers to "do the right thing."
> 
> If these home router manufacturers want to help deploy IPv6, 
> then the obvious requirement is to support 6to4, to allow 
> configured tunnels, and to also allow relaying of an ISP 
> native IPv6 service. This is very much what we are describing 
> in the "unmanaged networks" scenarios.
> 
> -- Christian Huitema
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 21 Feb 2003 12:53:29 -0500

OK.  I have offline come up with code algorithm for DSL/NAT boxes who
don't have an IPv6 stack to do config tunnels.  I am trying to get
people to talk to me in that platform world now.  So the tweak can be a
patch.
Thanks
/jim

> From: Tim Chown [mailto:[email-masked]] 
> Sent: Tuesday, February 18, 2003 5:28 PM
> To: [email-masked]
> Just the protocol 41 forwarding destination on the internal 
> network from
> the NAT box.  So like Jordi but some config needed.   They 
> also wrote their
> own tunnel broker s/w using FreeBSD, ssh and OpenLDAP (all v6).
> 
> Tim
> 
> On Mon, Feb 17, 2003 at 08:00:58PM -0500, Bound, Jim wrote:
> > What are they tweaking?
> > 
> > Thanks
> > /jim
> > 
> >  
> > 
> > 
> > > From: Tim Chown [mailto:[email-masked]]
> > > Sent: Sunday, February 16, 2003 12:59 PM
> > > To: Jeroen Massar
> > > Cc: 'Alain Durand'; Bound, Jim; [email-masked]; 
> [email-masked]
> > > > Which one can do now by simply installing eg the freenet6
> > > client onto
> > > > one of the existing windows/*nix boxes which will advertise
> > > the IPv6
> > > > prefix onto the local subnet. The only trick here is to
> > > have the CPE
> > > > forward proto-41 to your v6-gate or using Teredo. Btw 
> 'just have 
> > > > to
> > > > add' is sometimes expensive for some people.
> > > 
> > > This is what our IPv6 students tend to do in their homes.  It
> > > works nicely, 
> > > but still requires a tweak in the DSL router.
> > > 
> > > Tim
> > > 
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 21 Feb 2003 12:56:29 -0500

Erik,

Good thing to parse and the traversal draft thanks.

Forget the odd proto-id that was bug in my busy processes below :--)

Thanks
/jim

> From: Erik Nordmark [mailto:[email-masked]] 
> Sent: Friday, February 21, 2003 7:56 AM
> To: Bound, Jim
> Cc: [email-masked]
> > 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)
> 
> 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
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 21 Feb 2003 12:59:36 -0500

I caught that in the rfc too.  Yes we need an updated tunnel rfc or
draft.
Would that be valid work here ?  Chairs ?
My only concern about dhcpv4 is that is more work and process.  Which is
fine but we can use vendor class for now?  But I agree dhcpv4 is a good
mechanism.
But we could have something in interim.  Some I know would like to see
this working in 2004 and deployed.
/jim

> Sent: Friday, February 21, 2003 8:42 AM
> To: Bound, Jim
> Cc: Jeroen Massar; JORDI PALET MARTINEZ; [email-masked]; 
> Alain Durand; [email-masked]
> > If we have tunnel brokers we don 't need teredo right?  
> That's my take 
> > now.
> 
> Agreed in principle.
> 
> Two things though:
> Firstly, for the access router to ISP tunnel config
> something simpler (like a DHCPv4 option) might make sense - 
> depends on what type of authentication the ISP wants to do 
> specifically for the IPv6 tunnel. If it is sufficient for the 
> ISP to check that the IPv4 source is one of its customers 
> then the TSP authentication features and flexibility isn't needed.
> 
> Secondly, 
> I've been told that tunnel broker can work trough NAT but the 
> RFC (RFC 3053) says: 3. Known limitations
> 
>    This mechanism may not work if the user is using private IPv4
>    addresses behind a NAT box.
> 
> Thus I think it would be useful to have a specification on 
> how tunnel broker works across a NAT.
> 
>   Erik
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 21 Feb 2003 13:02:29 -0500

I thought I had same problem as Erik but I just got proto 41 through.
But I put a box in front of the cable dsl router. As note.  But it
breaks still :--)
/jim

> From: Paul Timmins [mailto:[email-masked]] 
> Sent: Friday, February 21, 2003 10:56 AM
> To: Erik Nordmark
> Cc: Jeroen Massar; Bound, Jim; 'JORDI PALET MARTINEZ'; 
> [email-masked]; 'Alain Durand'; [email-masked]
> On Fri, 2003-02-21 at 10:29, Erik Nordmark wrote:
> > That's nice for those that have control of the NAT box.
> > The Telco that provides me service at home provides me with 
> a NAT box 
> > that they control - and they are uninterested in doing anything 
> > special. I can't bypass/replace the NAT box because it 
> speaks some odd 
> > and probably proprietary stuff on the other side (it's an 
> ISDN line).
> > 
> > So I prefer solutions that don't have to rely on 
> configuration in the 
> > NAT box yet are simpler than Teredo.
> 
> I agree here as well. I've seen -alot- of firewalls that 
> either block, or don't statefully forward proto-41. Even if 
> they did, that limits IPv6 to one end user behind the NAT. If 
> I was using this at a Mariott for example, they NAT the users 
> of their in room ethernet. I'd be disappointed if someone 
> else was using v6 tunneling in the hotel, because it means I 
> couldn't (Assuming they forward proto-41 to begin with). With 
> UDP tunneling, we could both have our own tunnels. I think a 
> limitation on how many machines behind a NAT can have a 
> tunnel would slow transition in places like this, because if 
> I were offering enterprise services over v6, and had my 
> employees tunneling back to the office, I'd be pretty upset 
> if they couldn't get their job done because another employee 
> (or just another user, depending on the proto-41 forwarding 
> implementation) has a tunnel open at the hotel at the same time.
> 
> My 0.02.
> -Paul
> 
> -- 
> Paul Timmins
> [email-masked] / http://www.timmins.net/
> H: 313-586-9514 / C: 248-379-7826 / DC: 130*116*24495
> AIM: noweb4u / Callsign: KC8QAY
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 21 Feb 2003 13:03:26 -0500

It sounds like getting providers to support TB is a mission? As initial
step?
/jim

> From: Jeroen Massar [mailto:[email-masked]] 
> Sent: Friday, February 21, 2003 11:07 AM
> To: 'Erik Nordmark'
> Cc: 'Marc Blanchet'; [email-masked]
> Erik Nordmark wrote:
> > > The only thing is that the NAT box needs to know where to
> > send incoming
> > > proto-41 packets to.
> > > 
> > > - Some NAT boxes can be configured with a 'default'.
> > >   Those boxes will then forward any unrelated traffic to
> > that default
> > > IP.
> > 
> Make a ssh/pptp/vtund/<fill in>/* tunnel to the outside and 
> route your packets over there. These mechanisms then ofcourse 
> should be supplied and supported by the Tunnel Broker in 
> question. So if we want a good deployment we need to support 
> all of these options (unfortunatly). Marc can you create such 
> TSP drafts ?
> 
> Eg: draft-parent-blanchet-ngtrans-tsp-<application>-00.txt
> 
> Which means that an external application is needed for 
> tunneling the packets to the tunnel broker.
> 
> application ::= ssh|pptp|vtund|httptunnel|<fill in>
> 
> Some networks unfortunatly will want to avoid the possibility 
> of using them as a 'transit' service only, eg tunneling to a 
> friendly AS and then routing a own prefix over that, 
> basically only using the ISP's IP for the tunnel.
> 
> Sidenote:
> IMHO you don't have a complete IPv4 internet connection
> either as with your current setup you can't do most thing 
> that have an embedded IP in the packets (read: Netmeeting). 
> Also setting up your own SSH, apache, gameserver etc will not 
> work :( If I had a chance of ISP's in your situation I would 
> surely not go for them, I hate NAT's and I require at least 
> one public IPv4 thats completely unfiltered. In your current 
> situation they could have put you all their customers behind 
> a big rfc1918 subnet and NAT there too and that is what I 
> call localnet access (with an internet gate) and not internet access.
> 
> Greets,
>  Jeroen
> 
> 
>