Hi, Suresh, Comments inline. 2012-12-21 à 23:09, Suresh Krishnan <[email protected]> :
> Hi Remi/Ole/Bob, > Speaking as the author of RFC5453, I am afraid that this will not > work. The allocation policy for this registry is *Standards Action* and > hence requires a Standards track RFC. Bad news, but an indisputable fact! Thank you for signaling it. > This was done to keep the bar high > to minimize disruption to existing implementations as they do not check > against this registry. If 6man will propose this as the way forward, > then we need to change the IANA policy for the registry. Because the proposed range is disjoint from any IID values that are currently permitted by RFC 4291, no disruption of any existing implementation that complies with this RFC can be caused by this new range being used for 4rd. Some seem to still have doubts about this so. Of course, if it would be proven to be false, this approach should be abandoned, but I am confident that sooner or later it will be understood as being a fact. To proceed, yes, an update of RFC 5453 happens to be needed. It could add permission to include,in this registry, experimental-track protocols that are understood to not disrupt any implementation that complies with existing RFCs. Regards, RD > Thanks > Suresh > > On 12/20/2012 05:07 AM, Rémi Després wrote: >> Hello, chairs, >> >> - First a great thank you Jouni for for the reference to RFC 5453, which is >> perfectly relevant but had been ignored in this discussion. >> The good news is that, since an IANA registry for IID ranges has already >> been created, no new registry is needed for any new IID type, and in >> particular for 4rd. >> >> - Small problem: at http://www.iana.org/protocols, a registry for "Reserved >> Internet Protocol version 6 (IPv6) Interface Identifiers" is listed but, >> when clicking to open it, the page that comes is that of "Instant Message >> Disposition Notification (IMDN) Headers". This should be easy to fix I >> suppose. >> >> - For 4rd, it is then sufficient that the table of >> http://tools.ietf.org/html/rfc5453#section-3 (to be reflected in the IANA >> registry), becomes: >> >> +-----------------------------------------+-------------------------+ >> | Interface Identifier Range | Description | >> +-----------------------------------------+-------------------------+ >> | 0000:0000:0000:0000 | Subnet-Router Anycast | >> | | [RFC4291] | >> | | | >> | 0300:0000:0000:0000-03FF:FFFF:FFFF:FFFF | Reserved 4rd Unicast | >> | | Addresses [RFCxxxx] | >> | | | >> | FDFF:FFFF:FFFF:FF80-FDFF:FFFF:FFFF:FFFF | Reserved Subnet Anycast | >> | | Addresses[RFC2526] | >> +-----------------------------------------+-------------------------+ >> >> A possible answer from 6man to Softwire is then a request to modify the IANA >> section of the 4rd draft to reflect the above. >> >> >> Regards, >> RD >> >> >> >> >> 2012-12-19 à 22:19, Jouni Korhonen <[email protected]> : >> ... >>> Hmm.. how would this work with RFC5453 reserved IID space we already >>> have for anycast addresses? >> -------------------------------------------------------------------- >> 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 --------------------------------------------------------------------
