Hi Hemant, On Mon, 8 Nov 2010 19:11:17 -0600 "Hemant Singh (shemant)" <shem...@cisco.com> wrote:
> Mark, > > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Mark Smith > Sent: Monday, November 08, 2010 5:12 AM > To: Thomas Narten > Cc: ipv6@ietf.org > Subject: Re: draft-ietf-6man-prefixlen-p2p-00.txt > > > >I think the Addressing Architecture RFC would need to be changed, as it > >stipulates 64 bit interface ids, which I think implies a maximum of 64 > >bit prefix lengths, unless these /127s were only permitted within 0::/3 > >- the impacted text is in 2.5.1 of RFC4291 - > > >"For all unicast addresses, except those that start with the binary > > value 000, Interface IDs are required to be 64 bits long and to be > > constructed in Modified EUI-64 format." > > Why should any text in RFC 4291 change? The IID for /127 starts with > binary 000 and only the Modified EUI-64 format has got to deal with the > u/g bits. > I'm pretty sure the leading three 000s referred to are at the start of the unicast IPv6 address, not at the start of the IID portion. My assumption has been that this 000s exception is what has allowed allowed unicast ::1 to be a /128. I think ::1/64 would comply with the Modified EUI-64 requirement, so the only reason for the exception that I can think of is to allow the prefix length of ::1 to be /128 instead of /64. (In the past I've had some uses for multiple loopback addresses within IPv4 127/8, so I actually wouldn't have minded ::/64 being a loopback network/subnet, with ::1 the first default IID value for loopback, but other loopback IIDs allowed. IIRC, ntpd also uses addresses within IPv4 127/4 to represent different local time sources on the local host) Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
