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

[Michael Richardson <[e-mail]>]

[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.

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

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