Re: A proposal for draft-ietf-6man-rfc4291bis-07

[james woodyatt <[e-mail]>]

On Mar 2, 2017, at 17:55, David Farmer <[e-mail]> wrote:
> On Thu, Mar 2, 2017 at 7:29 PM, Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
> On 03/03/2017 13:34, Manfredi, Albert E wrote:
> > From: ipv6 [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of David Farmer
> >
> >> 3. IIDs are REQUIRED to be 64 bits
> >
> > I think that RFC 4291 bis should not retain a constraint that has been applied so far, out of convenience, in the earliest stages of IPv6 deployment.
> 
> Agreed. And I think there are actually two things to say here:
> 
> 3.1. Any IPv6-over-foo spec must specify a recommended IID length.
> 3.2. In the absence of such a spec, the recommended IID length is 64 bits.
> 
> Again, that breaks no running code, and it respects the architectural
> statement that prefix_length + IID_length == 128, and the use of CIDR
> routing and variable-length subnet masks.
> 
>     Brian
> 
> I'd be fine with that, but others seem to feel otherwise. Lorenzo and James?

I’m not sure my response to this is necessary, but since it was invited…

p1. For consistency with IPv6 Stateless Address Autoconfiguration [RFC 4862], I don’t think it’s a good idea to require IPv6-over-foo documents to specify IID length. Okay to state that they MAY do so, but not that they MUST do so, and if they don’t then the length is 64 bits, citing [RFC 7421]. [*]

p2. Section 5.5.3 Router Advertisement Processing in RFC 4862 discusses at length how to process the Prefix Information Option (PIO) in Router Advertisement (RA) messages. Some details relevant to this discussion:

  A. "If the sum of the prefix length and interface identifier length
      does not equal 128 bits, the Prefix Information option MUST be
      ignored."

  B. "The length of the interface identifier is
      defined in a separate link-type specific document, which should
      also be consistent with the address architecture [RFC4291] (see Section 2).

  C. "It is the responsibility of the system administrator to ensure
      that the lengths of prefixes contained in Router Advertisements
      are consistent with the length of interface identifiers for that
      link type. It should be noted, however, that this does not mean
      the advertised prefix length is meaningless.  […]
      [It] should be safe to validate the advertised prefix length here, in
      order to detect and avoid a configuration error specifying an
      invalid prefix length in the context of address autoconfiguration.”

p3. There is another relevant point observed in Section 3 Design Goals of RFC 4862:

  A. "A large site with multiple networks and routers should not require
      the presence of a DHCPv6 server for address configuration.  In
      order to generate global addresses, hosts must determine the
      prefixes that identify the subnets to which they attach.  Routers
      generate periodic Router Advertisements that include options
      listing the set of active prefixes on a link."

I think this is a pretty clear statement to general purpose host operating system developers that Prefix Length advertised in PIO options, even those with zero for both A and L flags, are required to be 64 bits on all the typical link types in general use today and for the foreseeable future, because the IID for those links is specified to be 64 bits. Give us a new link type with a 32 bit IID, and we would then require all the PIO to have plen=96.

At the risk of being excessively repetitive, I will again say that I think it’s important to say that subnet prefixes for networks intended to connect general purpose hosts to the Internet are always 64 bits in length, and they should be 64 bits in length for all other subnets except where expressly recommended otherwise by IETF standards actions (including IPv6-over-foo specifications). I think that’s a shorter way of expressing all that stuff above.

—

[*] As an example, consider the case of IPv6 Over IEEE 802.15.4 [RFC4944]. For some reason, it was carefully written not to specify a limitation on the length of the IID except for use with stateless autoconfiguration, which expressly limits the IID to exactly 64 bits. It then proceeds to define the LOWPAN_HC1 common compressed header encoding, which allows for address compression provided that either A) the IID is derived accordingly from one of the two possible forms of IEEE 802.15.4 address it recognizes, or B) the subnet prefix is exactly 64 bits. These compression methods apply regardless of whether SLAAC is used or not. This gets even more squirrelly in [RFC6282] where LOWPAN_IPHC provides compression for addresses with a 64-bit IID derived from either the EUI-64 address or the IEEE 802.15.4 “short” 16-bit address.

--james woodyatt <[e-mail] <mailto:[e-mail]>>