> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Rémi Després > Sent: Monday, January 21, 2013 8:20 AM > To: Bob Hinden > Cc: 6man 6man-wg > Subject: 4rd IID range & IPv6 addressing architecture > > Hi, Bob, > > The discussion on whether the proposed 4rd IID range is "compatible with > the IPv6 addressing architecture" has apparently come to a standstill. > Yet an answer of 6man to Softwire is expected. > > A. To help making a WG decision, here are key points that, in my > understanding, emerged from the discussion. > > (a) Ray Hunter has provided a reference to RFC5342 which confirms that, > in RFC 4291 compliant addresses, u=g=1 is "currently unused" > (www.ietf.org/mail-archive/web/ipv6/current/msg16890.html). 4rd > addresses, which have u=g=1, therefore cannot conflict with current > addresses of the IPv6 addressing architecture. (In particular, they > don't conflict with those of RFC6740 ILNP.) > > (b) Brian Carpenter pointed out that a 16-bit prefix would be sufficient > for 4rd, taking less IID space than the currently proposed 8-bit prefix. > This being acknowledged, the 0x0300 prefix can without problem replace > the 0x03 prefix. (This doesn't change the 4rd specification which > already has a 0x00 after 0x03.) With this prefix, the reserved range > uses only 1/2^14 of the unused set of IIDs having u=g=1 is reserved. > This leaves plenty of space for future uses of IIDs having u=1 (future > uses explicitly envisaged in RFC 4291). > > (c) Jouni Korhonen pointed out that there is already an IANA registry > for reserved IID ranges, and Simon Perreault gave the correct pointer to > it (http://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface- > ids.xml). > > (d) Suresh Krishnan pointed out that, according to RFC 5453, this > registry is so far reserved for standard-track RFCs, the reason being > "to minimize disruption to existing implementations". Although 4rd has > been purposely designed so that it cannot disturb any existing > implementation (precisely by using a currently unused IID range), the > proposed 4rd range can be endorsed by IANA only if an RFC updates RFC > 5453, explaining why a 4rd IID range can be safely assigned despite its > experimental status. > - If agreed on the principle, and if no one else volunteers, I can be > available to propose a draft to this effect.
Seems reasonable. > (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of > IIDs having u=g=1 is reserved. This leaves plenty of space for future > uses of IIDs having u=1, as explicitly expected in RFC 4291. That goes to the argument of (d), that it isn't harmful to assign some space to 4rd. -d > With this, 6man can IMHO answer that Softwire can proceed with 4rd, > provided: > - the 16-bit IID prefix 0x0300 replaces the current 0x03 > - it is understood that IANA won't register this IID range before a 6man > RFC permits it for this experimental-track RFC. > > No technically founded objection remains AFAIK, but if any one still > holds it has of course to be expressed and discussed. > > > > B. For those who are interested in a detailed summary of objections that > were made, and have been answered, here is what I noted: > > (i) If IETF uses u=g=1 in some unicast addresses, IEEE would have to be > involved. > - Because 4rd IIDs are never to be used in any MAC-layer addresses. IEEE > isn't concerned. > > (j) 4rd could work without a reserved range. > - As discussed in Softwire, reserving an IID range is key to satisfy the > objective that "4rd IPv6 addresses are recognizable by CEs without any > interference with the choice of subnet prefixes in CE sites". > > (k) An IID range using the IANA OUI with u=1 and g=0 would have been > sufficient. > - As discussed in Softwire, this wouldn't have left enough IID bits to > contain the IPv4 address and the 16-bit CNP, which are both needed in > 4rd. > > (l) A 4rd-specific destination header could have been used instead of an > IID-range. > - An extra header would have defeated the 4rd objective that its > "tunnel packets are valid IPv6 packets for all layer-4 protocols that > use the same checksum algorithm as TCP". > > (m) With a "reserved /64 on the customers delegated prefix for the sole > use of 4rd",and 4rd nodes protecting "all possible 4rd interface-ids > using DAD", a reserved range could have been avoided. > - This wouldn't work for IID assignments made before 4rd activation, > while 4rd is designed to cover this case too. (Note also that 4rd > implementations can add, on their LAN sides, exclusion of all addresses > having the 4rd IID prefix. Although this isn't strictly needed, this can > permit early detection of some erroneous manual configurations, and is > easy to do due to the 4rd IID prefix being a constant. > > (n) 4rd would fail if a customer link has two 4rd CEs. > - After discussion, no issue on this has been kept in Softwire. > > > > Best regards, > RD > > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
