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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf