RJ Atkinson wrote: > > On 3 Apr 2009, at 16:51, Keith Moore wrote: >> RJ Atkinson wrote: >>> >>> 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? > > Very relevant. Options that are not in use today are unlikely > to become very frequently used in the foreseeable future.
To me it seems way too early in IPv6 deployment to tell. Of course, yours could turn out to be a self-fulfilling prophecy. If this kind of argument were used to justify v6 NAT, and v6 NATs were deployed such that they broke new or existing options (as has happened in the v4 world) that would certainly discourage further deployment of those options - making your prediction true. But from an architectural point of view it makes sense to leave some wiggle room for future needs. Though it might be the case that existing "generic" IPv6 extensions are sufficient. Thinking about it now I realize that the purpose of the hop-by-hop vs. destination distinction is to specify the handling of this extension by boxes that don't recognize the option, not to specify the handling of the extension of those that do. And if a router doesn't recognize a specific option, drop and forward are about the only two choices it has. The only real question is whether there are cases where IPv6 NATs need to behave differently than routers with respect to some option that they don't understand. > And to be clear, my thread is quite clearly focused on > *engineering* details for the specific case where a longer > IPv6 prefix might be allocated to an end user. > > I haven't made any *architectural* postings in this thread, > at least so far. Its all been engineering. Well, the choice of whether to essentially preclude deployment of new options is an architectural choice. >> We're seeing only the very earliest of IPv6 deployment. Surely we can't >> expect observed traffic to be any indicator of future use. > > Surely we can and should. It won't be a perfect indicator, > since those don't exist, but it is certainly an informative > guide for what we might reasonably expect in future. Completely disagree. Assuming IPv6 ever succeeds in any terms that we'd recognize, you're extrapolating far beyond any data that exists so far. That's not sound analysis for either engineering or architecture. Keith _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
