Re: [v6ops] Last Call: <draft-ietf-v6ops-unique-ipv6-prefix-per-host-03.txt> (Unique IPv6 Prefix Per Host) to Best Current Practice

[神明達哉 <[e-mail]>]

At Sat, 27 May 2017 08:24:39 +1200,
Brian E Carpenter <[e-mail]> wrote:

> This draft cites RFC4862 (SLAAC) and mentions Router Advertisements
> (without also citing RFC4861, which is possibly a mistake). Those
> documents do not specify the subnet prefix length. So the draft
> shouldn't assume a particular prefix length either. We all know that
> it's usually 64 today, but that doesn't affect the argument made by
> the draft. We need consistency with RFC 7608 (BCP 198).

It looks like this draft has the commonly seen confusion I tried to
clarify in my own draft: draft-jinmei-6man-prefix-clarify-00

Specifically, in Section 4 v6ops-unique-ipv6-prefix-per-host-03
states:

   This
   RA contains two important parameters for the EU/subscriber to
   consume: (1) a /64 prefix and (2) flags.
[...]
   o  A-flag = 1 (The UE/subscriber can configure itself using SLAAC)
[...]
   o  L-flag = 0 (The UE/subscriber is off-link, which means that the
      UE/subscriber will ALWAYS send packets to its default gateway,
      even if the destination is within the range of the /64 prefix)

Since A-flag=1 and L-flag=0, this /64 prefix is an "SLAAC subnet
prefix" but not an "on-link prefix" (using the terminology introduced
in draft-jinmei-6man-prefix-clarify-00).  And, in that sense, the
"which means..." part could even be misleading in that it might read
as if this (SLAAC subnet) prefix were somehow related to an on-link
prefix.

I'd also note that "The UE/subscriber is off-link" is not accurate.
When L=0 "the advertisement makes no statement about on-link or
off-link properties of the prefix" (RFC4861 Section 4.6.2).  See below
for a specific suggestion to fix it.

As for the reference to the specific number of 64, I think it's okay
with this clarification, the fact that that's the only possible SLAAC
subnet prefix length today in practice, and the intended status of
this document (BCP).

But I also tend to agree with Brian in that this document could be
more clarified to avoid confusing and/or misleading readers.  My high
level suggestion is:

- clearly state that the prefix in this document is a kind of "SLAAC
  subnet prefix" but not an "on-link prefix".  I understand "SLAAC
  subnet prefix" may not be the best choice since this document
  doesn't limit the address configuration method to SLAAC - hence "a
  kind of".  But the main point is that it's better to explicitly
  clarify the prefix is one and the only one of the two kinds of
  prefixes advertised via RA PIO.  With this clarification, and fixing
  the error I pointed out above, the description for the L-flag would
  look something like this:

   o  L-flag = 0 (the prefix is not an on-link prefix, which means
      that the UE/subscriber will NEVER assume destination addresses
      that match the prefix are on-link and will ALWAYS send packets
      to those addresses to its default gateway.)

- if it refers to a specific (SLAAC subnet) prefix length of 64,
  explain that it's the SLAAC subnet prefix length derived from the
  current addressing architecture for unicast IPv6 addresses starting
  with the binary value 000 (and those are only addresses used in
  production today).  It might also note that future specification may
  or may not introduce a different prefix length for different ranges
  of addresses, but that's out of scope of the document as a BCP.

--
JINMEI, Tatuya