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

["Bound, Jim" <Jim.Bound@hp.com>]

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