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

[Jen Linkova <[e-mail]>]

On Fri, Oct 9, 2020 at 9:01 AM Ole Troan <[e-mail]> wrote:
> > On 8 Oct 2020, at 23:55, Templin (US), Fred L <[e-mail]> wrote:
> >
> > Now, client B sends packets destined to an address in A to R, and R forwards the
> > packets to client A since it still has a route for A. When the packets arrive at A,
> > however, A forwards them back to R since it has "forgotten" that it holds the
> > prefix A. When R receives the packets from A with destination address also
> > from prefix A, it must drop them instead of forwarding them back to A to
> > avoid looping.
>
> This is indeed what the requirement in the draft says.

Well, then I should say that the requirement is not clear and open to
misinterpretation. I read it as:
- the client B sends a packet with the destination address in A to R.
When R receives it, it finds out that the both conditions from R4 are
met:
1) a route for a delegated prefix points to this interface
2) the receives traffic (from the device B) on this interface with a
destination address within the delegated prefix.
So the traffic will be dropped right away, not after it went to the
client A (and back, if A forgot about the delegation).

I read Ian's response as he confirmed my interpretation and the
traffic will be dropped.
It looks to me like R4  assumes that all links are p2p, and 'receiving
a traffic from an interface the client is connected to' == 'receiving
a traffic from the client'.

> This isn’t quite obvious how to implement, which why I brought up the question if anyone had implemented this. And if it’s supported in hw etc.

What you and Fred described does look like a hard thing to implement,
while the way I read R4 seems to be very easy to do (kind of URPF,
basically) but, as discussed, might break working scenarios.


-- 
SY, Jen Linkova aka Furry