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

Hi all,
I believe that the current text behind requirement "R-4" is not accurate.
it is not possible to install the route to just multi-access interface (Ethernet). Any vendor software would refuse to do it for the good reason.
In that case, it should be not interface, but "next hop" (MAC address should be included).
IMHO: requirement should be improved: "Interface" should be replaced by "next-hop"

Then it would be the real challenge to check that traffic has been received from specific MAC.
It is not uRPF check, because RFP is about IP addresses only.
Moreover, filtering should be done on the "destination IP" & "source MAC" (logical "AND")
I did google a little - I have found no vendors implemented RPF check at MAC layer.
Hence, this requirement is the strong new feature request.
Probably, it would be ignored by vendors anyway.
IMHO: if you could correct it to "nex-hop" then you would keep this "good wish" in the document. Just change "MUST" to "MAY".

PS: Yea, DHCP is not routing protocol:-(
Eduard
> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jen Linkova
> Sent: 8 октября 2020 г. 4:25
> 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
> 
> On Wed, Oct 7, 2020 at 9:25 PM <ianfarrer@gmx.com> wrote:
> > 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
> 
> I might be missing smth but...
> Let's say I have a relay and it's 'south' (client-facing) interface is connected to a
> switch. The client AND second device (another router or a host) are connected
> to the same segment.
> The client gets a prefix, the relay 'learned' (or shall we call it
> 'install'?) the route for the delegated prefix pointing to its 'south'
> interface with the client address as a next-hop.
> What would happen if the *second* device sends traffic towards the delegated
> prefix? As that device is usig the relay as its default gateway, the traffic would
> be sent there.
> If I read the draft correctly, instead of forwarding the traffic and maybe sending
> the redirect, the relay is expected to drop it?
> 
> --
> SY, Jen Linkova aka Furry
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------