2012-12-12 17:06, RJ Atkinson <[email protected]> : > All, > > I fully agree with Brian Carpenter's note of Tuesday, > December 11th at 10:55:05 +0000. I support his > perspective as expressed in that note. > > I have read, but am NOT persuaded by, the responses > from Remi Despres to Brian's notes.
Brian suggested an alternative based on a reserved OUI, but I explained why it wouldn't be sufficient. Explaining technical objections you may have, beyond what follows, would be appreciated. > Further, I note that the combination ( U==1 a&& G==1) > already has a well defined meaning -- namely a > global-scope multicast identifier. These are not > widely deployed today, but there are various folks looking > into using precisely those identifiers for global-scope > multicasting -- in a way compatible with IEEE 802 > definitions of the EUI-64 with (U==1 && G==1). Is there any particular IETF reference that you could suggest to read? In any case, IIDs for multicast addresses are out of scope for the IPv6 addressing architecture of RFC 4291. > > Also, I'll note that the IID portion of an IPv6 address > is carefully designed to be algorithmically translatable, > from an IEEE 802 standard EUI-64 identifier. That algorithm > is trivial, and is universally deployed today, in a > wide range of devices. The definitions of U and G bits > do NOT derive ab initio from IETF documents, but instead > are fundamental parts of the IEEE 802 EUI-64 architecture. > The IETF architectural choice to use a (trivially-modified) > EUI-64 in the IETF's IPv6 addressing formats was foundational, > correct, and ought not be changed at this point. Same view. An important point to be noted is that, in the translation direction from EUI-64 of IEEE to modified EUI-64 of IETF, the proposed format implies no change at all. Also, multicast addresses being recognizable by their binary prefix 1110, they can use IIDs of their own, based on IEEE formats or not, without conflict with RFC 4291 in which the only specified IIDs are those of unicast addresses. In other words, reserving a /8 IID prefix for 4rd (and possibly some others for new types of unicast addresses) won't prevent from using IEEE-based IIDs with u=g=1 for multicast. > > Last, according to the IANA web site (URL below), > the IETF *already* has several different ways of > mapping IPv4 addresses into IPv6 addresses. The > 4rd folks need to show that none of these could be > used for their purposes, and also need to show > that none of the mapping techniques already used > could work. Neither of these have been shown so far. > If the 4rd advocates can't make an existing mapping > (between IPv4 and IPv6) work, they ought to define > a new mapping that does NOT modify the semantics of > either the U or G bits. Reasons why a new format is used for 4rd have been extensively discussed in Softwire. If you are really interested , we can continue, but offline. Where 6man has to be involved is to conclude whether the new IID format is an acceptable new usage of the openness of RFC 4291 to new unicast-address technologies, and if not to explain why. Regards, RD > > Yours, > > Ran Atkinson > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
