Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-pd-relay-requirements-00.txt

["Bernie Volz (volz)" <[e-mail]>]

Hi:

Please see additional comments below (BV>).


  *   Bernie

From: Ian Farrer <[e-mail]>
Date: Thursday, March 26, 2020 at 1:12 PM
To: Bernie Volz <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-pd-relay-requirements-00.txt

Hi Bernie,

Many thanks for your review. I’ve prepared an update which incorporates most of your suggestions (and I’ve removed them from the email below). For the remaining questions, please see inline below.

I’ve also replaced the reference to the obsoleted RFC7283 (handling unknown message types) and replaced with a ref. to RFC8415 Sec 19.
BV> Yes, good catch!!

Thanks,
Ian

3.4<https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-00#section-3.4>.  Dropping Messages from Devices with Duplicate MAC addresses and
      DUIDs
   It is an unfortunate operational reality that client devices with
   duplicate MAC addresses and/or DUIDs exist and have been deployed.
   In this situation, the operational costs of locating and swapping out
   such devices are prohibitive.

   Delegating relays have been observed to restrict forwarding client
   messages originating from one client DUID to a single interface.  In
   this case if the same client DUID appears from a second client on
   another interface while there is already an active lease, messages
   originating from the second client are dropped causing the second
   client to be unable to obtain a prefix delegation.
- We need to be a bit careful in this section and not sure exactly how to fix it. But in DOCSIS, for Cable Modems, often these restrictions exist to prevent theft of service (as there have been cloned devices). I think this document means the devices behind the CMs (in the case of DOCSIS) and perhaps similar environments. The complexity here is that “delegating relays” are the devices passing DHCPv6 packets and so could be interpreted to include all devices. Perhaps this will require some further discussions.
…

[if - What about adding the following sentence:

It should be noted that in some access networks, the MAC address and/or DUID are used as part of device identification and authentication. In such networks, enforcing MAC address/DUID uniqueness is a necessary function and not considered a problem.
]
BV> That sounds reasonable.

   G-5:    The relay MUST allow the same client identifier (DUID) to
           have active delegated prefix leases on more than one
           interface simultaneously.  This is to allow client devices
           with duplicate DUIDs to function on separate broadcast
           domains.
- See earlier my points in section 3.4; not sure how best to “modify” this item.

[if - What about changing to:

The relay SHOULD allow the same client identifier (DUID) to have active delegated prefix leases on more than one
interface simultaneously, unless client DUID uniqueness is necessary for the functioning or security of the network.
This is to allow client devices with duplicate DUIDs to function on separate broadcast domains.
]
BV> OK, but I guess I should have raised this earlier but what is meant by Interface? Who’s interface? Do we need “on more than one interface” in this sentence?

   G-6:    The maximum number of simultaneous prefixes delegated to a
           single client MUST be configurable.

   G-7:    The relay MUST implement a mechanism to limit the maximum
           number of active prefix delegations on a single port for all
           client identifiers and IA_PDs.  This value SHOULD be
           configurable.
- For G-6 ad G-7, are there some recommendations about what (a) a reasonable number to support is and (b) what the default should be? While it would be great to have this be “unlimited”, likely equipment manufacturers might like some guidance. For example we could say that “While allowing this to be fully configurable, delegating relays should support at least 8 per client device and use this as the default limit.” That’s just an example.

[if - This is a good question. We could add another requirement here recommending that the delegating relay supports at least X prefixes per client. The question is what value? I’ve seen 4-8 in SP edge routers, so I think 8 is a reasonable value, but I’m not sure whether this is reasonable for CMTS/BNG etc. Any insight would be appreciated here.
]
BV> Yeah – I don’t have any direct insight. I agree that 8 is a reasonable value as I would hope it would never be that many to start with.

   G-8:    The delegating relay MUST synchronize the lifetimes of active
           prefix delegation leases with server.
- I’m not sure I completely understand what this requirement means. Are you suggesting NTP or similar time synchronization be used? As lifetimes are relative (seconds remaining, not absolute time stamps) in DHCP messages, I’m not sure why NTP would be that critical. As there are 3 places lifetimes would be stored (server, delegating relay, client), unless all of these clocks were synchronized, some drift should be tolerated (i.e., not all clocks will tick at the same rate).

[if - The important thing here is the lease lifetime synchronisation between the server, delegating relay and client from the timers in the Reply messages. No suggestion that NTP should be used for that as it’s the DHCP lifetimes that matter. As this is a requirements document, we didn’t want to define how the delegating relay performs this synchronisation (like with SAVI), just that this needs to happen. Do you think that this is the wrong approach, or is the requirement text not clear as to the intention?
]
BV> I think perhaps this could be worded in a different way? Perhaps something like “The delegating relay MUST update the lifetimes based on the Client Reply messages it forwards to the client and only expire the delegated prefixes when the valid lifetime has elapsed.” Isn’t that really what you are after?
BV> I also wonder whether there is some value in pointing out that “snooping” Client Reply Messages cannot capture which delegated prefixes have been released; Client Release messages must be monitored instead. (While it was something I had noted but for some reason failed to bring up during the RFC8415 discussion, it would have been a nice change to allow a Server to send back the “released” leases in the Reply to the respond with the IA_*/IA* options containing 0 lifetimes. This would have made snooping a bit simpler as I think then it would have been possible to just snoop the Reply messages.