Subject: [v6ops] comments on draft-templin-v6ops-pdhost-13

From: 神明達哉 <[email-masked]>
Date: Sat, 17 Mar 2018 14:47:55 -0700

I've read draft-templin-v6ops-pdhost-13.  I found it generally well
written.  I have a couple of quick comments:

- Section 1

   'R' could instead function under the strong end system (aka "strong
   host") model [RFC1122][RFC8028] by assigning IPv6 addresses taken
   from 'P' to an upstream interface as shown in Figure 3:

  I think this usage should clarify its relationship with the
  following part of RFC3633:

   [...] the requesting router MUST
   NOT assign any delegated prefixes or subnets from the delegated
   prefix(es) to the link through which it received the DHCP message
   from the delegating router.

  Perhaps the implicit assumption is that the "prefix" itself is
  assigned to a different interface than the upstream interface and
  should be justified.  But (even if so) I believe it should be at
  least explained explicitly, and I guess it could be controversial
  and should better reach an explicit consensus.

- Section 3

   In contrast, a node that configures addresses from a delegated prefix
   can assign them without invoking MLD/DAD on an upstream interface,
   since the prefix has been delegated to the node for its own exclusive
   use and is not shared with any other nodes.

  I personally think it still technically violates RFC4862 Section
  5.4:

   Duplicate Address Detection MUST be performed on all unicast
   addresses prior to assigning them to an interface, regardless of
   whether they are obtained through stateless autoconfiguration,
   DHCPv6, or manual configuration, with the following exceptions:

  These exceptions don't include "when the prefix is delegated to the
  host".  In fact, my understanding is that the sense of RFC4862 is
  quite strongly err on the side of caution and try to catch a
  situation of configuration errors - in the context of the draft,
  including cases where the upstream router accidentally assigns an
  address from the prefix.

  With some more discussion it may be justified, but I personally
  don't think the current brief description is enough.  Also, for this
  reason this document should be a standard track document updating
  RFC4862.

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 19 Mar 2018 19:44:31 +0000

Hi, see below for responses:

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of ????
> Sent: Saturday, March 17, 2018 2:48 PM
> To: [email-masked]
> Subject: [v6ops] comments on draft-templin-v6ops-pdhost-13
> 

Thanks for taking the time to read and comment.

>    from the delegating router.

Yes, you are correct per RFC3633 and this document intends to honor
the requirement. The difference is that this document only permits the
assignment of *addresses* to the upstream interfaces - not prefixes
or subnets. Can this be addressed by the addition of a single sentence
such as:

"While addresses taken from the delegated prefix can be assigned to
the upstream interface, the prefix itself (nor any subnets taken from
the prefix) cannot be assigned to the upstream interface (see: RFC3633)."

>   and should better reach an explicit consensus.

I think the terminology says that prefixes are added to an interface's
prefix list (i.e., they are not "assigned" to an interface per se). But,
the assumption in this document is that the prefix would be added
to the prefix list of some downstream interface (e.g., a loopback) or
not added to any interface prefix list at all.

>    DHCPv6, or manual configuration, with the following exceptions:

One of the exceptions is:

   -  An interface whose DupAddrDetectTransmits variable is set to zero
      does not perform Duplicate Address Detection.

So, if delegated prefixes are the only autoconfiguration parameters that will
ever be received over the upstream interface then it should be OK to set
DupAddrDetectTransmits to 0.

But, maybe you are thinking of some kind of mixed mode of operation
where the node may receive both delegated prefixes and on-link
prefixes over the upstream interface. In that case, there would need
to be a provision for avoiding DAD only for the delegated prefixes and
honoring DAD for the on-link prefixes. Is this getting to the point you
are making?

>   host".

This may in fact be a new exception to be added to the list if we
want to support "mixed mode".

> In fact, my understanding is that the sense of RFC4862 is

We want to avoid unnecessary DAD to avoid unnecessarily disturbing other
nodes on the link. I think the case of the upstream router assigning an
address from the delegated prefix is a bug like any other, and going out
of our way to test for this particular bug seems unnecessary. (For example,
in another bug a node with a duplicate address could be misconfigured to
ignore the NS messages sent by DAD.)

>   don't think the current brief description is enough.

Please feel free to suggest text.

>   Also, for this

I see your point about updating RFC4862, but that pertains only to
the desire to avoid DAD on upstream interfaces that may receive
a mix of delegated prefixes and on-link prefixes. The rest of the
document is operational and not a protocol standard.

So, how would it be if we split into two documents. The main
document would be operational-only and would retain about
80% of the text of the current document. The other 20% would
be used to form a new standards-track document with the
intention of updating RFC4862.

What do you think?

Thanks - Fred

> --
> JINMEI, Tatuya
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops