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

[[e-mail]]

Hi Michael,

Thanks for the comments. Pleased see inline below.

Ian

> On 7. Oct 2020, at 20:24, Michael Richardson <[e-mail]> wrote:
> 
> 
> [e-mail] wrote:
>> 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.  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 (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 browsed through pd-relay-requirements, but I didn't know it was being
> worked on.  (Did I fall off the dhc list again due to outsourced spam filter? Probably)
> 
> The document was seemed clear and direct.
> It may be that it could explain more about the consequences of failing to
> take some of the advice.
> 
>> 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.
> 
> My BMS implementation (2014-ish) had a DHCPv6 server listening per PPPoE connection.
> BMS/PPPoE operators often don't have DHCPv6 servers, and adding one isn't
> something they want to do.  Making Radius run is hard enough....
> In that context, the client can't drop without killing the PPPoE interface,
> which drops the route, removing it from the IGP, etc.  So despite having
> implemented, my experience is not particularly useful for you.
> 
> But, I'm very enthusiastic to have DHCPv6-PD be incorporated into hypervisors
> and LXD and Docker, so I hope the problem you describe will be "common”.
> 
> If a client goes way and does not properly restart, then the NCE entries
> associated with the routes will be invalid, and the traffic will be dropped.
> While the client is starting, the NCE entries will become valid, but the
> client won't have the state.  The traffic will loop.
> This could become a serious problems, particularly if the traffic loops at
> very high speed, worse case, causing the client to fail again.
> 
> Best case, it goes on for a few seconds, then the client perhaps a DHCPv6-PD,
> gets delegated the same prefix and everything is normal again.
> Perhaps for this reason alone, delegated prefixes need to be stable across
> their lifetime.   Perhaps that is obvious, but there are many flash
> renumbering discussions...
> 
> The concerning case is, I think, that the client comes up fine, but declines
> to do a DHCPv6-PD for some reason.  Maybe the option was turned off and the
> CPE device rebooted.   Or maybe it won't do the PD until some event occurs,
> like some VM gets started.

[if - We didn’t consider this scenario but it could certainly be a problem here. 
Do you think that the current problem description text and requirement 
adequately cover this case?]

> 
> It seems to me that we need some additional protocol where the relay can be
> informed to blackhole the traffic by the DHCP server.

[if - I’m not sure how that could work. if the relay isn’t aware that the client’s DHCP
state is out of sync with its own, how can the server know this to tell the relay to
blackhole?]

> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
>