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

Well, the root cause is the same.
But this is not related to current "renumbering", because current draft is concentrated on ND fixes (1st hop).
We have the discussion here about challenges in converting DHCP into routing protocol. Prefix distribution on the wide scale was always "the routing".
Different network layers, different purpose, different protocols - it should be discussed in different standards, despite the common root cause.
Ed/
> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jen Linkova
> Sent: 9 октября 2020 г. 4:50
> To: ianfarrer@gmx.com
> Cc: dhcwg <dhcwg@ietf.org>; v6ops list <v6ops@ietf.org>; 6man
> <ipv6@ietf.org>
> Subject: 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-requir
> > ements/
> >
> >
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg@ietf.org
> > https://www.ietf.org/mailman/listinfo/dhcwg
> 
> 
> 
> --
> SY, Jen Linkova aka Furry
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------