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

["Bernie Volz (volz)" <[e-mail]>]

Hi:

Do we know that this is "client" traffic? And what is the "client" - especially given in the case that Jen showed.

For a RFC4443 Destination Unreachable address, the IPv6 destination address field is as follows:

   IPv6 Fields:

   Destination Address

                  Copied from the Source Address field of the invoking
                  packet.

So, are you changing this?

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:  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: [e-mail] <[e-mail]> 
Sent: Tuesday, October 13, 2020 9:16 AM
To: Michael Richardson <[e-mail]>; Jen Linkova <[e-mail]>
Cc: Bernie Volz (volz) <[e-mail]>; dhcwg <[e-mail]>; 6man <[e-mail]>; v6ops list <[e-mail]>
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 <[e-mail]> wrote:
> 
> 
> Jen Linkova <[e-mail]> 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 <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------