Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis - subnet

[Alexandre Petrescu <[e-mail]>]

Hi,

I will read in detail the proposal later, but for now I would like to 
point out one thing in particular that pops up every time I read this 
4291 text.

Le 09/03/2017 à 09:19, james woodyatt a écrit :
[...]
> Proposed (conservative):
>> A slightly sophisticated node (e.g. one capable of neighbor discovery) may additionally be aware of subnet prefix(es) for the link(s) to which it attaches, where the length (n) of the interface ID field may vary with different types of link:
>>
>>    |       128-n bits              |           n bits                |
>>    +-------------------------------+---------------------------------+
>>    |       subnet prefix           |           interface ID          |
>>    +-------------------------------+---------------------------------+
>>

>> Note: according to the reasoning presented in Analysis of the 64-bit Boundary in IPv6 Addressing [RFC7421], the length of the Interface ID field in all unicast IPv6 addresses is 64 bits, except for addresses beginning with binary value 000 and except in cases where otherwise specified in future IETF standard actions.

That 'subnet prefix' looks very much like a 64bit-or-so subnet.

[...]
>>    |         n bits         |   m bits  |       128-n-m bits         |
>>    +------------------------+-----------+----------------------------+
>>    | global routing prefix  | subnet ID |       interface ID         |
>>    +------------------------+-----------+----------------------------+
>>
>> where the global routing prefix is a (typically hierarchically-structured) value assigned to a site (a cluster of subnets/links), the subnet ID is an identifier of a link within the site, and the interface ID is as defined in Section 2.4.1.

This 'subnet ID' looks like something shorter than a 64bit-or-so length.

I think we should be consistent in the use of this subnet word.

Alex
[...]