RJ Atkinson wrote: > A) MEASUREMENTS > > First, I've done some measurements. MUCH MUCH less than 1% of > IPv6 traffic in real enterprise deployments contain ANY > optional header.
How is that relevant when we're talking about an architectural issue? We're seeing only the very earliest of IPv6 deployment. Surely we can't expect observed traffic to be any indicator of future use. >> and we would need to make >> sure that a NAT66 device can handle arbitrary extension headers. > > The IPv6 community's plan has been (and still seems to be) that > additional "extension headers" would not exist, but instead that > any additional IPv6 "options" would be placed either inside the > "Hop-by-Hop Header" or the "Destination Options Header". Good point. So the only new extension headers we can expect to be added to IPv6 are those for which neither hop-by-hop nor destination-only seem appropriate. That's probably not the null set, but it probably does mean that NATs will be able to deal with most new IPv6 extensions. > Over time, IPv4 NAT devices have been updated to support various > extensions to TCP/UDP over IPv4 deployments, so there is good reason > to believe that NAT66 devices also could be enhanced over time. It's not a black-or-white situation. We've also observed that the failure of IPv4 NATs to be updated has caused problems for IPv4 hosts and applications, and we can expect the same situation to apply to IPv6 NATs. > In the case of the residential/SOHO implementation of NAT66, > a purely software implementation is likely to be common. Various > software loads, including some 3rd party software loads, exist > for at least some of the existing very-low-cost IPv4 NAT devices > (e.g. Linksys boxen). Yes, but it's hard to expect users to consistently maintain those boxes. Users want to believe (and vendors want users to believe) that they're maintenance free. It's also hard to expect vendors to keep updating the software for those (commodity) boxes without being paid to do so. My guess is that users replace those boxes more often than they update their firmware, if for no other reason than to get the latest wired and/or wireless LAN technology that's bundled into them. (Who knows, maybe they'll buy new boxes for IPv6 too.) > Separately, what kind of IP option could one imagine that has > neither a "hop-by-hop" nature nor an "end-to-end" nature ? I don't have a firm idea myself, but I know better than to assume that we'll never have reason to define an option that doesn't fit one of these categories. e.g. Maybe an option to make some out-of-band request to a NAT? Keith _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
