Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020

[[e-mail]]

Hi Ole,

Please see inline below.

Thanks,
Ian

> On 15. Sep 2020, at 09:32, [e-mail] wrote:
> 
>> 
>> The requirement is intended to hand the case where, for whatever reason, the client’s routing traffic towards the delegating relay with a destination in the prefix that it’s been delegated. i.e. something’s wrong with the client’s routing. The obvious exception to this is if the link between the client and delegating relay has a prefix that is part of the delegation (e.g. the PD exclude case). 
>> 
>> The current wording is pretty unclear. How about:
>> 
>> old:
>> If the relay has an existing route for a delegated prefix via  an interface, and receives ingress traffic on this interface  with a destination address from the delegated prefix (not configured on the relay), then it MUST be dropped.
>> 
>> new:
>> 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 (but not directly connected to the relay), then it MUST be dropped.  This is to prevent routing loops.
>> 
>> BV> "(but not directly connected to the relay)" is a bit odd ... perhaps "where this address is not assigned to the relay" (remove the parentheses).
>> 
>> [if - I wondered about using something like this, but it only really makes sense if the client / relay are on a p-t-p link. If it’s a shared / NBMA link then other devices could be attached to segment and addressed from this prefix. Really, it’s an on-link prefix, so what about:
>> 
>> "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."
>> 
>> BV2> Hum … Perhaps Ole has some thought. Not sure that really covers it.
> 
> 
> OK, so here is the text again:
> 
> R-4:    If the relay has an existing route for a delegated prefix via
>           an interface, and receives ingress traffic on this interface
>           with a destination address from the delegated prefix (not
>           configured on the relay), then it MUST be dropped.

[if - There’s been quite a lot of iterations on this since -01. The current working version is:

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.]

> 
> 
> Two questions:
> 
> 1) What is the case where this would triggered? That wouldn't be caught by uRPF (R-2)?

[if - The traffic is originated from a valid source prefix so uRPF (R-2) doesn't cover it. This requirement is concerned with the destination.]

> 2) On a multi-access link, how should this even be implemented?
>   drop if rx-interface == tx-interface and packet source mac == next-hop mac?

[if - That sounds like it would cover it.]

> 
> - Is it supposed to be a silent discard or should you send a destination unreachable?

[if - Please see current text above.]

> 
> Depending on the answers to the above I do wonder if this requirement is needed or not.
> 
> Cheers,
> Ole