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. (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. 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 ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
