Hi, Bob, Please see inline further explanations, and answers to your questions.
2012-12-12 01:18, Bob Hinden <[email protected]>: > 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). Note that it is just a backward-compatible extension, not a change that would imply on anything existing today. It takes advantage of an unused combination of bits to introduce a specific way "to allow development of future technology that can take advantage of interface identifiers with universal scope", as envisaged in RFC 4291 itself. Appendix A of RFC 4291 "provides examples on the creation of Modified EUI-64 format-based interface identifiers". The two of them that apply to links having universal scope IIDs (i.e. having u = 1) are based on IEEE EUI-64 and IEEE EUI-48 at link layer. Both have g=0 (unicast addresses) so that u=g=1 remains as an escape pattern for new universal-scope formats. Advantage of this escape pattern over using a reserved OUI in the IEEE EUI-64 format, a technique mentioned by Brian in his las t mil, is that it leaves 62 free bits instead of 40. As 4rd needs 48 bits for its own use (an IPv4 address and a 16-bit checksum neutrality preserver), it is the first design that needs the escape pattern. It leaves plenty of space for other uses of this pattern. > 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. No change of RFC 41 is AFAIK needed: (a) RFC 5214, and RFC 4214 before it, already specify an IID format that, being a backward-compatible use of RFC-4291 format, didn't lead to a modification of RFC 4291. (b) IANA does list in its registries assigned numbers of experimental RFCs. > 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. All of this has been carefully reviewed in Softwire, and even more so by the six co-authors of widely different origins. No alternative has been found with the same desired combination of functional properties. > 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? The need for a _stateless_ solution to assign _public_ IPv4 addresses across IPv6-only domains, including shared IPv4 addresses, has been abundantly discussed and approved in Softwire. While MAP-E is now the path chosen for standard track, the WG has found enough complementary functional properties in two other solutions to proceed with them on experimental track, 4rd and MAP-T. Hoping to have given the expected clarifications and answers, Best regards, RD > > 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 <[email protected]>: >> >>> 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 >>> [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 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
