Hi, Bob and 6man, We do need an answer from 6man to move forward. So far, in my understanding, 6man has not answered the requirement/question raised by softwire chair.
Personally, I support the proposal to reserve a 4rd IID range (we can have max 16 fixed bit in order to reduce the reserved range). For this we need to update RFC 5453 to enable IID reservation for experimental RFCs. The value of reserved 4rd IID range can be discussed. The only requirement is the uniqueness. Best regards, Sheng >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of R >émi Després >Sent: Tuesday, January 22, 2013 12: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. > >(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 >[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 --------------------------------------------------------------------
