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

I agree with Bernie, link-layer address would be an improvement to the
Mac Address.

~Tim

On Wed, Nov 4, 2020 at 7:15 AM Bernie Volz (volz) <volz=
40cisco.com@dmarc.ietf.org> wrote:

> Hi ... looks good but perhaps MAC address is too Ethernet specific and
> just link-layer address would be better?
>
> - Bernie
>
> On Oct 29, 2020, at 12:24 PM, "ianfarrer@gmx.com" <ianfarrer@gmx.com>
> wrote:
>
> 
> Hi,
>
> Sorry for the delay in reply, I’ve been out of the office for the last few
> weeks for various reasons.
>
> Here’s a new wording proposal incorporating Jen & Bernie’s suggestions:
>
> R-4
> To prevent routing loops, the relay SHOULD implement a configurable policy
> to drop packets
> received on a DHCP-PD client facing interface with a destination address
> in a prefix delegated
> to a client connected to that interface, as follows:  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 as per [RFC4443], section 3.1.  The ICMP policy SHOULD be
> configurable.
>
> Thanks,
> Ian
>
> On 15. Oct 2020, at 03:51, Jen Linkova <furry13@gmail.com> wrote:
>
> On Wed, Oct 14, 2020 at 12:44 AM Bernie Volz (volz) <volz@cisco.com>
> wrote:
>
> If not, perhaps we just say:
>
> R-4
> To prevent routing loops, the relay SHOULD implement a configurable policy
> to drop traffic received from an uplink interface as follows:
>
>
> I'm not sure 'from an uplink interface' makes sense. In the case of a
> routing loop caused by an amnesiac DHCP-PD client it would be a
> downstream interface.
> The scenario when such traffic arrives from an uplink interface is
> 'the uplink router believes the prefix is delegated to the client but
> the relay does not have a route pointing to the client so it sends
> traffic back' - so more likely 'an amnesiac relay' case.
>
> 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 as per [RFC4443], section 3.1.  The
> ICMP policy SHOULD be configurable.
>
> - Bernie
>
> -----Original Message-----
> From: ianfarrer@gmx.com <ianfarrer@gmx.com>
> Sent: Tuesday, October 13, 2020 9:16 AM
> To: Michael Richardson <mcr+ietf@sandelman.ca>; Jen Linkova <
> furry13@gmail.com>
> Cc: Bernie Volz (volz) <volz@cisco.com>; dhcwg <dhcwg@ietf.org>; 6man <
> ipv6@ietf.org>; v6ops list <v6ops@ietf.org>
> Subject: Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay
> Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
>
> Hi,
>
> 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:  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
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>