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

On Wed, Oct 14, 2020 at 12:16 AM <ianfarrer@gmx.com> wrote:
> Thanks for all of the discussion on this. We’ve reworked the requirement as follows:
>
> R-4
> To prevent routing loops, the relay SHOULD implement a configurable policy to
> drop client traffic as follows:

I agree with Bernie's comment that 'client traffic' is a bit unclear.
Is it traffic from the client? Or to the client?
Maybe 'traffic with the destination address in a prefix delegated to a client'?

>For point-to-point links, when the packet's
> ingress and egress interfaces match. For multi-access links, when the packet's
> ingress and egress interface match, and the source MAC and next-hop MAC addresses
> match. 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.
>
> Thanks,
> Ian
>
> > On 9. Oct 2020, at 17:41, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> >
> >
> > Jen Linkova <furry13@gmail.com> wrote:
> >> I think there is confusion re: the scenario we are talking about. I've
> >> attached the diagram for the case which concerns me.
> >> So:
> >> - The Relay R has an interface eth0 connected to a switch S.
> >> - Devices A and B are connected to the same switch and using R as a
> >> default gateway.
> >> - The prefix 2001:db8::/56 was delegated to a client A via the relay R.
> >
> > a friendly amendment to your example to aid in human comprehension:
> >     } - The prefix 2001:db8:0000:0123:/64 was delegated to a client A via the relay R.
> >     }  - R installs a route for 2001:db8:0000:0123:/64 towards A via eth0.
> >
> >> - The device B (which has an address NOT from the delegated prefix,
> >> but from another /64 assigned to that common link, let's sat
> >> 2001:db8:cafe::/64) sends a packet to an address from the delegated
> >
> > now, my brain can more clearly see that 2001:db8:cafe::/64 is not
> > within 2001:db8:0000:0123:/64, while I had to use a few extra brain cells to
> > see that it wasn't in that ::/56 :-)
> >
> >> What I'd expect to happen (with DHCP-PD or without - e.g. if R has a
> >> static route towards A, not a dynamic route produced by PD):
> >> - the packet is sent to A. Well, if A does not have a route to
> >> 2001:db8::42 then indeed a routing loop might happen. But if A does
> >> have a route, the packet will be delivered.
> >
> >> What seems to be required by R4:
> >> - R detects that the packet is received via eth0 and needs to be sent
> >> back to eth0. R4 seems to require such packets to be dropped.
> >> So if B would never be able to communicate to any address in the
> >> delegated prefix, right?
> >
> >> Am I missing anything?
> >
> > I think that you got it right.
> >
> >>> Perhaps the missing piece of the rule is don’t send it back to where it came from, based on link layer addresses (or link if point-to-point).
> >
> >> Yes. If R4 was saying 'drop the packet if it comes from the same
> >> link-layer address you are going to send it back' - it would make
> >> total sense. But I don't think routers do *that*.
> >
> > Yes, if we made the check on L2 address, then it would work.
> > And I agree that routers are exactly doing that.
> >
> > I think that it also works if B is a router with additional interfaces
> > downstream, unless there are multiple paths.
> >
> > --
> > Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
> >           Sandelman Software Works Inc, Ottawa and Worldwide
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>

-- 
SY, Jen Linkova aka Furry