Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020

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

Hi.

See below (BV2>).


  *   Bernie

From: [e-mail] <[e-mail]>
Sent: Monday, September 14, 2020 7:41 AM
To: Bernie Volz (volz) <[e-mail]>
Cc: Ole Troan <[e-mail]>; [e-mail]
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020

Hi Bernie,

Thanks for your response. Please see inline below.

Thanks,
Ian




On 19. Aug 2020, at 00:15, Bernie Volz (volz) <volz=[e-mail]<mailto:volz=[e-mail]>> wrote:

Thanks Ole ... I had also flagged that requirement as an issue in my shepherd review as it is not very clear.

I think the not configured on the relay means that the destination address hasn't been assigned as an address on one of the relay's interfaces.

I do wonder though what the "normal" router behavior would be - would it not just send the packet back and also send an ICMP redirect? And, why does this needs to be called out specially isn't clear?

[if - Yes,

The requirement is intended to hand the case where, for whatever reason, the client’s routing traffic towards the delegating relay with a destination in the prefix that it’s been delegated. i.e. something’s wrong with the client’s routing. The obvious exception to this is if the link between the client and delegating relay has a prefix that is part of the delegation (e.g. the PD exclude case).

The current wording is pretty unclear. How about:

old:
If the relay has an existing route for a delegated prefix via  an interface, and receives ingress traffic on this interface  with a destination address from the delegated prefix (not configured on the relay), then it MUST be dropped.

new:
If the relay has learned a route for a delegated prefix via a given interface, and receives traffic on this interface with a destination address within the delegated prefix (but not directly connected to the relay), then it MUST be dropped.  This is to prevent routing loops.

BV> "(but not directly connected to the relay)" is a bit odd ... perhaps "where this address is not assigned to the relay" (remove the parentheses).

[if - I wondered about using something like this, but it only really makes sense if the client / relay are on a p-t-p link. If it’s a shared / NBMA link then other devices could be attached to segment and addressed from this prefix. Really, it’s an on-link prefix, so what about:

"and receives traffic on this interface with a destination address within the delegated prefix (that is not an on-link prefix for the relay), then it MUST be dropped."

BV2> Hum … Perhaps Ole has some thought. Not sure that really covers it.


BV> Additional question ... RFC7084 has WPD-5 and they added an (a) about ICMPv6 Destination Unreachable ... do you want to say anything about whether to send ICMPv6 or not (probably not)?

[if - I think it makes sense. I’ve added the following to R-4:

An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject
route to destination) error message MAY be sent back to
the client.  The ICMP policy SHOULD be configurable.]

BV2> OK!
----






And, "time synchronization between DHCP functional elements" is really not covered much - it translate into O-3 as best I can gather? Just wondering if it is really worth mentioning in the abstract - but that leaves just "rejection of client's messages and other problems". Perhaps reworking this to provide a list of the main problems is worth considering? FYI  - you could add some kind of data recovery/persistence in case of 'crash'/restart?

[if - It did read ’timer syncronization’ - i.e. related to the times present in DHCP messages, but this text is no longer present.]

BV> So, I'm not sure what the plan is with respect to this text? DHCP has a generic time synchronization problem in that everything is relative to when received (not necessarily transmitted) and resolution is seconds and no strong requirement for clocks to tic consistently. This is often why grace periods are applied to lease expiration times (though in most cases, this is probably also not necessary given that the client is probably not there as otherwise it would have renewed).

[if - I’m a little confused as to which text you’re referring to now. The original comment was related to the ‘..issues such as timer synchronization between..’ wording in the abstract. The abstract text has now been replaced using Ted’s suggested wording and does not mention timers at all. This is the current abstract wording:

    This memo describes operational problems that are known to
    occur when using DHCPv6 relays with Prefix Delegation. These
    problems can prevent successful delegation and result in routing
    failures. To address these problems, this memo provides necessary
    functional requirements for operating DHCPv6 relays with Prefix
    Delegation.

   It is recommended that any network operator that is using DHCPv6
    prefix delegation with relays should ensure that these requirements
    are followed on their networks.

Req G-8 is for DHCP lease timer synchronisation:

    G-8: The delegating relay MUST update the lease
    lifetimes based on the Client Reply messages it forwards to the
    client and only expire the delegated prefixes when the valid
    lifetime has elapsed.]

BV2> OK … Just wanted to make sure the ‘timer synchronization’ bit earlier in the document was either removed or expanded upon; removed is fine.