> Despite its completeness in terms of different (IPv4) address resolution > protocols, the primary purpose of the ARP mediation draft is to enable > migration from frame relay to ethernet, specifically for customers with > IP traffic. IP traffic is not limited to IPv4. > The engineering decision here is to determine if we are going to make > this draft more complete for the future (IPv6) or not. That wasn't a > pressing stated need at the time of the creation of the work. That would appear to indicate a flaw in the process you used. If the technology you are developing is inherently one that only needs to be used only in legacy situations (e.g. use of ARP for election of v4 linklocal address, when v6 already has linklocal addresses), or one that should never be used except in legacy situations (e.g. NAT as a workaround for v4 address space shortages), then it makes sense to only consider v4. Or if you're only trying to document a deployed protocol for a very rare occasion where someone needs to implement it to talk to legacy devices, or for purely academic purposes, then you should document the actual use of the protocol and refrain from trying to define how it should work. In such cases it would be silly to document use of the protocol on IPv6 if it was never actually used with IPv6. But if you're trying to standardize a protocol that tends to imply that you believe it will be useful in the future. And unless you believe that the protocol has a very limited future, or unless the facility you are trying to build is inherently IPv4-specific, it's hard to justify limiting the protocol to IPv4. Offhand I don't see anything IPv4-specific about bridiging between two dissimilar link layers. On the contrary, it seems to me that the use of the technology you are defining by an IPv4 network would be an impediment to allowing that network to support IPv6. I think this is called "built-in obsolescence" as well as a "known technical omission". > If there > is even a small handful of people who say that IPv6 is required, we'll > do it. I think you have it backwards. The burden should be on the WG to explain why IPv6 support should not be a "MUST implement" part of the technology. Of course, if the WG can come up with a defensible reason to not require IPv6, IESG should consider that reason. But "we didn't want to work that hard" is not a defensible reason. > Since you aren't part of that history, it is easy for you to say you > want an "IPv6 inside" label on everything. Unfortunately, that's what > the IPv6 line of thinking has been reduced to: if you mandate (from the > IESG, no less), that IPv6 be forced into every IETF activity, then we > will finally have IPv6. IETF develops protocols that run on the Internet. IPv6 is the community consensus and industry accepted direction for the Internet to overcome the address space limtiations of IPv4. It's ridiculous to expect IETF to standardize a new link layer technology that doesn't support IPv6. At best, it's out of scope for IETF to do so; at worst, it's expecting IETF to favor one working group's whims over a community consensus that took many years to forge. > We'll have IPX tunneled over IPv6, we'll have > SNA 3270 not just over IPv4, but also over IPv6, we'll have ... Not necessarily, because IETF doesn't burden itself with taking on useless work. (well, not as a matter of institutional scope anyway...) But if there's a need to define a standard for tunneling (say) IPX over IPv4, there's probably a need to define a standard for tunneling it over IPv6 also. > > I know Mark is going to intervene at this point ... :-) > > Going back to another point of yours, I find it deplorable (especially > given the amount of MPLS deployed and to be deployed) how little other > working groups know about MPLS. If MPLS touched every host and application in the Internet, I'd agree with you. Of course the reason we have separation of function between protocols and layers is so that everyone doesn't have to concern himself with every protocol used in the Internet. But IP is the common protocol - the thing that all Internet hosts, routers, apps, and intermediaries have in common. It's the waist of the hourglass, part of the fundamental core. So the comparison with MPLS is bogus. And I would submit to you that your goal in defining L2VPN is to create a technology that people - other than its implementors and the network admins whose networks use it directly - _don't_ have to be concerned with. Which implies that it needs to work as transparently as possible and that it should not be a barrier to those networks supporting IPv6. Keith _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf