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

Actually it looks like this requirement is another piece of the
'renumbering from one PD prefix to another' puzzle.
SLAAC renumbering drafts are solving the issue of 'a DHCP-PD client
forgot about the prefix but connected downstream hosts are not aware
the prefix is not in use'.
This requirement is about 'a DHCP-PD client forgot about the prefix
and the upstream router/relay is not aware the prefix is not in use'.

Maybe it's dumb idea but is there any way DHCP-PD can be improved to
help 'amnesiac' clients with 'total recall'(c) and signal the prefix
disappearance both downstream (via prefix deprecation) and upstream
(sonehow)?

On Wed, Oct 7, 2020 at 9:25 PM <ianfarrer@gmx.com> wrote:
>
> 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.  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.
>
> 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.
>
> Thanks,
> Ian
>
> Current draft version: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-pd-relay-requirements/
>
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

-- 
SY, Jen Linkova aka Furry