Subject: Re: [v6ops] Call for Adoption: draft-templin-v6ops-pdhost

From: 神明達哉 <[email-masked]>
Date: Fri, 17 Aug 2018 11:56:48 -0700

On Thu, Jul 26, 2018 at 10:25 AM Ron Bonica <[email-masked]> wrote:

>    This draft initiates a two week call for adoption on
>    draft-templin-v6ops-pdhost. Please respond by August 9, 2018.

Belated, but as chairs seem to seek more input, I've read
draft-templin-v6ops-pdhost-21.

I don't have a strong opinion on whether to adopt it at v6ops.  But I
have some general observations:

- On one hand, applying prefix delegation to a "host" type of node
  seems to be a straightforward extension to the original usage
  described in Section 5 of RFC3633.  In that sense the need for
  having a separate document is not so clear to me (but I'm not saying
  this as an objection to the adoption - as I noted above I don't have
  a strong opinion on that decision).

- On the other hand, this document seems to introduce new protocol
  behaviors without saying it's updating the corresponding existing
  standard (see specific cases below).  These could be considered
  non-trivial protocol updates and it may make this document worth
  publication.  But in that case I'd wonder whether this should rather
  belong to 6man and rather aim to be a standards track document.

- It assumes nearly silently that a requesting node can skip DAD in
  the upstream link if the prefix is "delegated":

   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.

  Although this logic may be justifiable, I believe this should
  actually be specified as an update to RFC4862.  In my interpretation
  RFC4862 requires nodes to perform DAD quite strongly even when it's
  operationally reasonable to assume duplicates are less likely to
  happen.  If we want to override it, IMO we should specify it as a
  standard protocol behavior, e.g., as defined in Section 5.1 of
  RFC4862:

      Default: 1, but may be overridden by a link-type specific value in
      the document that covers issues related to the transmission of IP
      over a particular link type (e.g., [RFC2464]).

- In Section 8, it talks about somewhat awkward behavior of the
  requesting node:
  + it sends NS to the upstream link (not prohibited by RFC4861 but
    a bit awkward for a "router)
  + it sets the router flag to true in NA (btw I don't see why it
    needs to do it)
  + it receives a redirect and updates its neighbor cache.  This may
    be in a gray zone, but I'd consider it a possible violation of the
    following part of RFC4861:

      A router MUST NOT update its routing tables upon receipt of a
      Redirect.

- This document describes the model where addresses are assigned to
  the upstream interface (Figure 3).  I would suggest clarifying how
  it's not considered a violation of 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.

- Now that this document talks about various ways of delegating a
  prefix, I guess the term "prefix delegation" might be confusing,
  since it would be easy to assume RFC3633 is used.  Maybe we should
  use a different term, e.g., "prefix assignment".

- In Section 12, the definition of "trusted/untrusted networks" and
  how a node determines it are not clear to me:

   In all cases, the node must decide whether or not to send DUs
   according to the specific operational scenario.  In trusted networks,
   the node should send DU messages to provide useful information to
   potential correspondents.  In untrusted networks, the node can
   refrain from sending DU messages to avoid providing sensitive
   information to potential attackers.

--
JINMEI, Tatuya

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 20 Aug 2018 16:02:28 +0000

See below for follow-ups to the points you have raised.

Fred

From: v6ops [mailto:[email-masked]] On Behalf Of ????
Sent: Friday, August 17, 2018 11:57 AM
To: Ronald Bonica <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] Call for Adoption: draft-templin-v6ops-pdhost

  Although this logic may be justifiable, I believe this should
  actually be specified as an update to RFC4862.

>> The purpose of this document is not to update RFC4862. If the delegated
>> prefix and/or addresses derived from the prefix are to be assigned to
>> interfaces other than the upstream interface (i.e., the interface over
>> which the prefix was received) then it is a fact that no DAD is needed
>> on the upstream interface. So, your point would seem to be limited to
>> the case where the node assigns addresses to the upstream interface.
>>
>> In that case, however, I believe that RFC4862 is incorrect in saying
>> that DAD must be used for all address assignments to an interface
>> because it has an unspoken assumption that the prefixes from which
>> the addresses are derived are on-link (or possibly on-link). In the case
>> of address assignment from a delegated prefix, the prefix is known
>> to be off-link and hence DAD is unnecessary.
>>
>> I believe this point can be addressed in two complimentary actions:
>>
>> 1) In this document, make it clear that DAD avoidance is for assignment
>>    of addresses to interfaces other than the upstream interface and remain
>>    silent on DAD avoidance for assignment to the upstream interface.
>>
>> 2) Publish an erratum for RFC4862 to say that the DAD procedures
>>     apply only for addresses derived from prefixes that are known
>>     to be on-link or could possibly be on-link.
>>
>> Note that action 1) does not depend on action 2), and the two actions
>> could go forward independently.

In my interpretation

>> This document does not need to discuss DupAddrDetectTransmits.

- This document describes the model where addresses are assigned to
  the upstream interface (Figure 3)..  I would suggest clarifying how
  it's not considered a violation of the following part of RFC3633:

>> This can be clarified by citing the text you have quoted to state that
>> only addresses are assigned and not prefixes or subnets. Therefore,
>> it is not a violation of RFC3633.

>> The term prefix delegation has been used in the discussions of this
>> document since the first version was published 3 years ago. No one
>> else has expressed confusion, and IMHO “prefix delegation” is more
>> correct and less confusing than “prefix assignment”.

   potential correspondents..  In untrusted networks, the node can

>> I don’t mind deleting that paragraph. Would that address the concern?

--
JINMEI, Tatuya