ietf
[Top] [All Lists]

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

2017-02-22 22:39:58
From: ipv6 [mailto:ipv6-bounces(_at_)ietf(_dot_)org] 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


<Prev in Thread] Current Thread [Next in Thread>