Rémi, Like Brian, I am also trying to understand this.
My initial personal conclusion to answer Suresh's question, I don't think this is compatible with the IPv6 address architecture. It proposes to change how interface IDs are constructed (the use of the "g" and "i" bits in the modified EUI-64) and sets up a new IANA registry (it's not clear to me what else would need to be registered). This like a very large change for a document that is intended for Experimental status. Making these changes would seem to me more reasonable after the experiment is completed. Given this is a tunneling based solution, why not just add a destination header that includes the information you need to make this approach stateless? Then you wouldn't have to change the way IPv6 interface identifiers are created and avoid any unintended consequenses. Further, I thought we already had solutions to providing IPv4 connectivity over IPv6 (there are some large operators doing this today). The rhetorical question is why do we need more? Thanks, Bob On Dec 11, 2012, at 6:35 AM, Rémi Després wrote: > Hi Brian, > > Thank you for the quick comments on this issue. > Let me explain more below. > > 2012-12-11 11:55, Brian E Carpenter <brian.e.carpen...@gmail.com>: > >> Hi Suresh, >> >>> The 4rd draft (http://tools.ietf.org/html/draft-ietf-softwire-4rd-04) >>> describes a solution for providing IPv4 connectivity over IPv6. The >>> draft describes the method for mapping 4rd IPv4 addresses to 4rd IPv6 >>> Addresses. It uses a 4rd specific mark called the V octet in the first 8 >>> bits of the Interface Identifier. There were some concerns raised in >>> softwire about whether such addresses are actually compatible with the >>> IPv6 addressing architecture. Whether this is actually compatible with >>> the IPv6 addressing architecture is outside the scope of the softwire >>> wg. Hence we would like to hear the 6man wg's perspective on this. I >>> would like to request the wg to please go over the NOTE in Section 4.5 >>> page 18, which explains the issue, and over IANA Considerations Section >>> 6, and chime in on whether this is acceptable from a 6man perspective. >> >> It certainly makes me nervous. The proposed format misuses the "g" bit, >> which is supposed to flag multicast. > >> Can it be proved beyond doubt that >> such an address will never escape a context in which the V octet will >> only be interpreted 4rd-style? > > No, but this is AFAIK acceptable: > - If a 4rd packet enters, in a 4rd domain, a customer site that has no 4rd CE > will be routed in this site like any other IPv6 packet, based on its IPv6 > prefix. > - It is guaranteed, however, that no properly configured interface will ever > be reached at this address. Reason is precisely that no properly configured > host may have an interface ID starting with the 4rd exclusive /8 prefix. > > This prefix is so far called the V octet, for historical reasons, but could > IMHO be advantageously renamed to be more intuitive (e.g. 4rd IID prefix). > >> This is not clear to me from the draft. >> >> I would be less nervous if you could also set the OUI bits to a reserved >> value for this purpose. > > Unfortunately, it proved to be impossible: this wouldn't have left 48 bits > for the IPv4 address and the 16-bit checksum-neutrality preserver. Both have > to fit in the IID. > >> For this, the V octet has its "u" and "g" bits of >> [RFC4291] both set to 1, so that they differ from "u" = >> 0, reserved for Interface IDs that have local-scope, and >> also differs from "u" = 1 and "g"= 0, reserved for >> unicast Interface IDs using the EUI-64 format. Bits >> >> That should be "modified EUI-64 format" > > The proposed 4rd address format introduces, for unicast IPv6 addresses, a new > variant of the "modified EUI-64" IID format > It comes in addition to variants so far defined, namely: > - One with u = 0, for the IID privacy option (RFC 4941). > - One with u = 1, for universal IIDs that embed IEEE OUIs and have g = 0 or > unicast addresses (Appendix A of RFC 4291). > > This proposal is expected to be fully in line with the openness expressed in > RFC 4291 by saying "the use of the universal/local bit in the Modified EUI-64 > format identifier is to allow development of future technology that can take > advantage of interface identifiers with universal scope". > While reserved OUIs is one way to use this openness, reserved IID prefixes > having u=g=1 is another. > > >> >> other than "u" and "g", are proposed to be 0, giving V = >> 0x03. 4rd is thus the first "future technology that can >> take advantage of interface identifiers with universal >> scope" [RFC4291]. >> >> I find that sentence hard to swallow. It's recycling the u and g bits >> but I don't see how it takes advantage of universal scope. I would >> just delete the sentence. > > OK. > Deleting the sentence in the draft shouldn't be a problem at all. > It was intended as a clarification for 6man, but doesn't add any technical > content. > >> >> As such, it needs to be endorsed by >> the 6man working group and IANA (Section 6). >> >> This sentence too can be deleted before RFC publication. > > OK. > >> >> o An IPv6 Interface-ID type reserved for 4rd (the V octet of >> Section 4.5). For this creation of new registry is suggested for >> Interface-ID types of unicast addresses that have neither local >> scope nor the universal scope of Modified EUI-64 format >> [RFC4291]). This registry is intended to be used for new >> Interface-ID types that may be useful in the future. >> >> I don't get this. The possible ug combinations are all theoretically >> valid today, aren't they? 11 means globally unique multicast. The only >> way you can protect them as a 4rd flag is by using a dummy OUI value, >> as far as I can see. I think that is what you should ask for (from >> IEEE, not IANA). > > As explained above, "globally unique multicast" isn't suitable for a globally > unique _unicast_ address. > > If I may add a detail: the proposed new IANA registry would contain IID > prefixes that, in the context of IETF modified EUI-64, have universal scope > and don't embed IEEE OUIs. The first one would be the 4rd mark 0300::/8. > Others to come may have different lengths (but at least 8 to include u and g > bits) > > Best regards, > RD > > > > >> >> Regards >> Brian Carpenter >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
