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

[Timothy Winters <[e-mail]>]

Hi Ian,

I've read this draft including Bernie comments and think it will be ready
for the last call.

I did have one extra thought about IA_PD and forwarding loops.   In the
case where the delegating router has a route to the CPE for a delegated
prefix and the CPE loses that prefix (reboot, loses sense of time/space,
etc).  The Router will continue to send traffic to the CPE for that
prefix.  While the CPE waits for DHCP it will typically get a route with
RAs and send the traffic back to the router, making a loop until DHCPv6
happens.  If the loop has lots of IPv6 traffic sometimes DHCPv6 is dropped
so you have to wait until the traffic dies down to get the CPE and prefix
again.  Is this something that we think we should try to solve in this
document?

~Tim

On Wed, Apr 1, 2020 at 2:43 PM Bernie Volz (volz) <volz=
[e-mail]> wrote:

> Hi:
>
>
>
> For G-5:  OK … so G-4 says to do it for a single interface, G-5 says to do
> it across multiple interfaces (of the relay).
>
>
>
> And looks good for other issues.
>
>
>
> Thanks!
>
>
>
>    - Bernie
>
>
>
> *From:* [e-mail] <[e-mail]>
> *Sent:* Wednesday, April 1, 2020 2:29 PM
> *To:* Bernie Volz (volz) <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [dhcwg] I-D Action:
> draft-ietf-dhc-dhcpv6-pd-relay-requirements-00.txt
>
>
>
> Hi Bernie,
>
>
>
> Please see inline below.
>
>
>
> Thanks,
>
> Ian
>
>
>
>
>
>
>
>    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?
>
>
>
> [if - Good point. This is intended to cover deployment scenario where a
> single L3 router has many customer facing interfaces each with a relay
> function. So, to clarify this:
>
>
>
> If a device has multiple interfaces that implement a delegating relay
> function, the device 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.
>
>
>
> ]
>
>
>
>
>
>    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.
>
>
>
> [if - I’ll go with 8 for now and hopefully we’ll get some more feedback
> during last call. For the wording:
>
>
>
>           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 MUST be configurable.
>
>
>
>           G-8: It is RECOMMENDED that delegating relays support
>
>             at least 8 active delegated leases per client device and use
> this
>
>             as the default limit.
>
>
>
> I don’t think that we need the ‘fully configurable line’ in G-8 as it’s
> covered in G7 (I’ve changed the old SHOULD to a MUST for the configurable
> statement in G7]
>
>
>
>
>
>    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?
>
>
>
> [if - OK]
>
>
>
> 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.
>
>
>
> [if - This could actually be a problem for e.g. a user is being DoS’d.
> Even if they were to release their current lease, change their DUID and get
> new leases the relay would continue to forward the DoS traffic to the old
> prefix until it aged out.
>
>
>
> The 0 lifetime in the server response seems like a neater solution to me,
> but it sounds like that ship has sailed. What about adding the following in
> general requirements?:
>
>
>
> G-10: On receipt of a Release message from the client, the delegating
> relay MUST expire the active leases for each of the IA_PDs in the message.]
>
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>