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

Hi,

Just to be clear, are we talking about Michael’s proposed rewording/restructuring of the requirement text (here with Bernie’s link-layer wording change):

   R-4
   To prevent routing loops, the relay SHOULD implement a configurable
   policy to drop potential looping packets received on any DHCP-PD client
   facing interfaces.
   The policy SHOULD be configurable on a per-client or per-destination basis.

   Looping packets are those with a destination address in a prefix
   delegated to a client connected to that interface, as follows:

        1) For point-to-point links (e.g., PPPoE), when the packet’s ingress and egress
           interfaces match.

        2) For multi-access links (e.g., ethernet), when the packet’s
           ingress and egress interface match, and the source link-layer and next-hop 
           link-layer  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 4. Nov 2020, at 14:01, Timothy Winters <tim@qacafe.com> wrote:
> 
> 
> 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 <mailto: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 <mailto:ianfarrer@gmx.com>" <ianfarrer@gmx.com <mailto: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 <mailto:furry13@gmail.com>> wrote:
>>> 
>>> On Wed, Oct 14, 2020 at 12:44 AM Bernie Volz (volz) <volz@cisco.com <mailto: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 <mailto:ianfarrer@gmx.com> <ianfarrer@gmx.com <mailto:ianfarrer@gmx.com>>
>>>> Sent: Tuesday, October 13, 2020 9:16 AM
>>>> To: Michael Richardson <mcr+ietf@sandelman.ca <mailto:mcr+ietf@sandelman.ca>>; Jen Linkova <furry13@gmail.com <mailto:furry13@gmail.com>>
>>>> Cc: Bernie Volz (volz) <volz@cisco.com <mailto:volz@cisco.com>>; dhcwg <dhcwg@ietf.org <mailto:dhcwg@ietf.org>>; 6man <ipv6@ietf.org <mailto:ipv6@ietf.org>>; v6ops list <v6ops@ietf.org <mailto: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 <mailto:mcr+ietf@sandelman.ca>> wrote:
>>>>> 
>>>>> 
>>>>> Jen Linkova <furry13@gmail.com <mailto: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 <mailto: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 <mailto:ipv6@ietf.org>
>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>>>>> --------------------------------------------------------------------
>>>> 
>>> 
>>> 
>>> -- 
>>> SY, Jen Linkova aka Furry
>> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org <mailto:v6ops@ietf.org>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>