Re: [IPv6] Second Working Group Last Call for <draft-ietf-6man-rfc6724-update>

[Ted Lemon <[e-mail]>]

Thanks, Bob. A few comments.

First, the abstract is too long, and contains a document reference.
Document references are (IIRC) not allowed in abstracts. The abstract
should tell us why to read the document, rather than briefly recapitulating
the introduction. I would suggest:

This document updates RFC6724 (default address selection for IPv6) based on
experiences with IPv6 deployment since RFC6724 was published. It makes
changes to the priority of various address types in default address
selection: ULA priority is increased, and 6to4 address priority is
decreased, for example. This document  also makes some behaviors, e.g.
"rule 5.5" mandatory rather than optional. With these changes, hosts are
more able to operate correctly in multi-homed networks and networks where a
ULA address can be expected to be more stable than a GUA address for
intra-site communication.

I continue to think that section 3,  "Operational Issues Regarding
Preference for IPv4 addresses over ULAs," should make the new proposed ULA
behavior mandatory rather than optional. I don't see a downside to making
it mandatory. Hosts will come into compliance when they can; older
implementations will not implement this new behavior, but I don't see any
point in perpetuating that.

Section 5 illustrates this well: it changes "MAY" to "SHOULD" but doesn't
explain why an implementation might not do this. "SHOULD" is not for
situations where we think some implementor might prefer not to implement
the recommended behavior out of expedience—it's for cases where we think
there's a reason that in some cases an implementation SHOULD NOT do it.
Since we have not documented any such cases, we should not say SHOULD here,
but rather "MUST."

Section 5.3 seems to suggest that if there are no "known-local" ULAs, all
ULAs should have the "known local" priority. I don't see any reason for
doing this. Is this what was actually intended? Is the notion that some
node might not be able to keep a full list of known-locals, and that in
that case it would be better to treat all ULAs as known-local rather than
none? If nothing else, this should be explained.

This text is a bit hard to follow:

   Such known-local ULA prefixes include /48 prefixes containing a ULA
   address assigned to any interface via manual configuration, DHCPv6
   NA_IA, or SLAAC or learned from a PIO received on any interface,
   regardless of how the PIO flags are set.  Additionally, type C hosts,
   as defined in [RFC4191] section 3, include any ULA prefixes learned
   from RIOs as known-local ULAs.

I would suggest something like:

A known-local ULA prefix is the /48 ULA prefix that contains an address or
prefix known to be local by the host. Such addresses and prefixes are known
to be local because they appear either in addresses offered for local use
by DHCP (e.g. delegated prefixes and allocated addresses) or in router
advertisement PIO and RIO options.

This paragraph could also use some work, in particular the use of "should"
is confusing:

   Any such inserted "known local" ULA entries should also have a
   different, but common, label, rather than the default ULA label, 13.
   This document defines a label of 14 for such inserted known-local ULA
   prefixes.

How about:

Known-local ULAs have a policy table label of 14; other ULAs have a policy
table label of 13.

I also don't love that we are proposing to just put all these prefixes in
the policy table. It might be worth emphasizing that this is how we are
explaining it, but there is no requirement that the internal data
representation be a table exactly as described here. But maybe that's
obvious and doesn't need to be stated.

I'm trying and failing in section 8 to see what changed in rule 5, but a
difference is highlighted. Maybe it's just line breaking?

So, I think the document is in pretty good shape modulo the above comments,
but would like us to change the SHOULD to MUST for known-ULA support.
However, I support this document either way—I just think it would be a
missed opportunity to leave known-ULA support at "SHOULD."