Re: RFC4291bis

[Mark Smith <[e-mail]>]

On Wed., 8 Aug. 2018, 09:39 Brian E Carpenter, <[e-mail]>
wrote:

> Hi,
>
> Assuming that we adopt draft-farmer-6man-exceptions-64
> for the standards track or BCP, I suggest that we should
> also update draft-ietf-6man-rfc4291bis as proposed below,
> and plan for the two documents to be published as RFCs
> simultaneously:
>
> OLD:
>    Interface Identifiers are 64 bit long except if the first three bits
>    of the address are 000, or when the addresses are manually
>    configured, or by exceptions defined in standards track documents.
>    The rationale for using 64 bit Interface Identifiers can be found in
>    [RFC7421].  An example of a standards track exception is [RFC6164]
>    that standardises 127 bit prefixes on inter-router point-to-point
>    links.
>
>       Note: In the case of manual configuration, the Prefix and
>       Interface Identifier can be any length as long as they add up to
>       128.
>
> NEW:
>    Interface Identifiers for stateless address autoconfiguration
>    are 64 bits long except if the first three bits
>    of the address are 000,




or when the addresses are manually
>    configured,


So this reads as though manually configured addresses will never have 64
bit IIDs, as it is stating it is an exception to the 64 bit IID part of the
sentence.

Actually, reference to manually configured addresses doesn't seem relevant
at all, because presumably "stateless address autoconfiguration" is
referring to SLAAC, and SLAAC is an automated address configuration method,
not a manual one.

There seems to be a bit of conflating address configuration methods and
address properties.

In some cases the address properties are specified by the address
configuration method so that an automated address configuration method has
default address properties it can assume out of the box, and will work for
common and ideally all cases without requiring a network operator to
bootstrap the network i.e. SLAAC.

(With a large enough IID space, the constraint on the number if nodes that
can be attached to a link is shifted from being the available and
affordable layer 3 addresses to the underlying link layer constraints.)

In the case of stateful DHCPv6, an assumed default prefix size/IID size is
also useful to minimise the operator effort to configure it. The operator
however has decided to accept the expense of setting up a stateful DHCPv6
infrastructure. The cost of overriding defaults is incremental.

Manual addresses are totally manual, so the operator is required to decide
an address structure. There is no opportunity to reduce operator effort
through reasonable defaults, and going without the benefits of reasonable
defaults is the choice the operator has made by going with manual
configuration.


Regards,
Mark.





or by exceptions defined in standards track documents.
>    The rationale for using 64 bit Interface Identifiers can be found in
>    [RFC7421].  An example of a standards track exception is [RFC6164]
>    that standardises 127 bit prefixes on inter-router point-to-point
>    links. The relationship between prefix length and Interface Identifier
>    length is discussed in [I-D.farmer-6man-exceptions-64].
>
>       Note: In the case of manual configuration, the Prefix and
>       Interface Identifier can be any length as long as they add up to
>       128. In all cases, routing and forwarding processes must be
>       designed to process prefixes of any length up to /128 [BCP198].
>
> Comments:
>
> 1. This change makes it clear that the 64-bit IID length is for SLAAC.
> 2. It specifically send the reader to draft-farmer for details.
> 3. It underlines that routing must work for any length prefix.
>
>     Brian
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>