At Sat, 27 May 2017 08:24:39 +1200,
Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> 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