RE: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: ipv6 [mailto:ipv6-bounces@xxxxxxxx] On Behalf Of Lorenzo Colitti

> Help he understand, then. There is widely-deployed code that assumes
> that the interface ID is 64 and does not work on anything other than
> 64 bit prefix lengths. Currently that code is correct on all unicast
> space. If you change RFC 4291, won't that code be incorrect?

This shows precisely why it is urgent to update RFC 4291, to correct that notion of a fixed IID, before it's too late to set things straight again.

RFC 4291 describes any number of address prefixes that are not /64. For example:

   IPv6 unicast addresses are aggregatable with prefixes of arbitrary
   bit-length, similar to IPv4 addresses under Classless Inter-Domain
   Routing.

Important point. Arbitrary length. That does not mean 64 bits.

And

   |          n bits               |           128-n bits            |
   +-------------------------------+---------------------------------+
   |       subnet prefix           |           interface ID          |
   +-------------------------------+---------------------------------+

This next needs to be clarified/corrected, as it should only apply to the 2000::/3 space:

   All Global Unicast addresses other than those that start with binary
   000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
   described in Section 2.5.1.  Global Unicast addresses that start with
   binary 000 have no such constraint on the size or structure of the
   interface ID field.

Bert





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]