Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements

[[e-mail]]

Hi Alexandre,

Thanks for your comments, please see inline.

Ian

> On 7. Oct 2020, at 12:38, Alexandre Petrescu <[e-mail]> wrote:
> 
> There are few things I could comment on here...
> 
> Le 07/10/2020 à 12:25, [e-mail] a écrit :
>> Hi,
>> We are currently finishing WGLC for this draft. It describes requirements for a 'DHCPv6 Delegating Relay' - this is a router functioning as the L3 edge and DHCPv6 relay (only) with prefix delegation. This is a common deployment scenario, but RFC3633/8415 only really describes PD using a Delegating Router - i.e the L3 edge also functions as a DHCPv6 server with no relay. When the relay and server functions are performed by separate devices a number of problems with how relays behave have
>> been observed, so this document addresses them.
>> During WGLC for this, Ole raised a comment related to one of the routing requirements:
>> R-4:    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 (that is
>>            not an on-link prefix for the relay), then it MUST be
>>            dropped.
> 
> 'within' the delegated prefix?  How is the operation of finding whether an address is within a prefix implemented?  REmember the 64bit limit is not frozen and as such a longest prefix match operation might be the only possible; such an operation is however not offering the result one might expect.  Lpm is good for matching an address among a few prefixes, but is not good for deciding whether an address is 'within' a given prefix.
> 
> 2. there is a new RFC now that suggests addition of an NC entry in router's table such that incoming packets to that Host dont get dropped.  Such an operation would contradict R-4.

[if - The operation would be via normal destination route lookup - if the dest address egress interface matches the ingress interface.

Do you have a number for the RFC that you mention?]

> 
>   This is to prevent routing loops.  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.
>> The problem that this is trying to solve is:
>> 3.5.  Forwarding Loops between Client and Relay
>>    If the client loses information about a prefix that it is delegated
>>    while the lease entry and associated route is still active in the
>>    delegating relay, then the relay will forward traffic to the client
>>    which the client will return to the relay
> 
> Will a client return a packet to relay?  Or will it generate an ICMP error carrying the packet?

[if - In the case described, yes. The client has a default route via the relay (learned via RA) so it will send it back to the relay.]

> 
> (which is the client's
>>    default gateway (learnt via an RA).  The loop will continue until
>>    either the client is successfully reprovisioned via DHCP, or the lease
>>    ages out in the relay.
> 
> I would dare to wonder whether such loop has been seen with a packet capture tool such as wireshark?  Or is it that we worry that such a loop might appear?  Both are valid points to consider.

[if - I’ve seen this in lab conditions a while ago due to a DHCP client bug]

> 
>> Ole’s comment: "And I would also be happy if we could have some implementors chime in with a "we are happy and able to implement this requirement”.”
>> We would appreciate any feedback on this, especially from anyone with experience implementing DHCPv6 relays with PD.
> 
> I do have some experience implementing relays and server doing PD, but it was some years ago.  The server was doing PD and the relay  just adding a route.  I dont remember having seen loops, but I have not tried the scenario described above (expiration of prefix lease).
> 
> Alex
> 
>> Thanks,
>> Ian
>> Current draft version: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-pd-relay-requirements/ <https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-pd-relay-requirements/>
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg