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

["Templin (US), Fred L" <[e-mail]>]

Michael, what I was referring to below as "failure" is the proxy case when
there is an L2 proxy P between the client and relay (e.g., RFC489). There
could be many clients A, B, C, D, etc. on downstream link segments of
the proxy, with the relay R on an upstream link segment. The relay would
then not see the individual client MAC addresses A, B, C, D, etc. - it would
see only the proxy MAC address P in all cases. So, it is true that an RPF
check in the relay would drop a packet from client A addressed to itself,
but it would also drop any of client A's packets addressed to clients B,
C, D, etc. That is what I meant by "failure" in this context.

Fred

> -----Original Message-----
> From: Michael Richardson [mailto:[e-mail]]
> Sent: Tuesday, October 13, 2020 10:03 AM
> To: Templin (US), Fred L <[e-mail]>; [e-mail]; Jen Linkova <[e-mail]>; dhcwg
> <[e-mail]>; v6ops list <[e-mail]>; 6man <[e-mail]>
> Subject: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> requirements
> 
> 
> Templin (US), Fred L <[e-mail]> wrote:
>     >> For multi-access links, when the packet's
>     >> ingress and egress interface match, and the source MAC and next-hop MAC addresses
>     >> match.
> 
>     > As I said, this gets very tricky if the client has multiple MACs. If Client A has MAC addresses
>     > a1, a2, a3, a4, etc. it becomes very difficult for the relay to know that a packet received
>     > from one of the MAC addresses (e.g., a1) must not be sent back to another of the MAC
>     > addresses (e.g., a3). I think another failure case is if there is a proxy between the client
>     > and relay. In that case, the relay will see the MAC address of the proxy and not the
>     > MAC address of client A. And, if there were multiple additional clients B, C, D, etc.
>     > sharing the same proxy then the proposed check could block legitimate
>     > traffic.
> 
> okay, but let's be clear about what "failure" here means.
> If the client has multiple MAC addresses, then the router *fails* to
> eliminate the loop.  It does not drop traffic it shouldn't.
> So this policy doesn't make the situation worse.
> 
> I don't know what kind of relay you are talking about.
> If it's a L2 switching fabric, and it rewrites mac addressess, then there is
> a problem.
> 
> If it's an L3 router, then yes, the MAC address will change.
> But, that L3 router will *also* need a route to the client.
> That first L3 router should be the one dropping the traffic.
> 
>     > As I said before, I think the better fix is to instrument the client. If the client receives
>     > a packet on its relay-facing interface, and the routing system determines that the
>     > packet should be forwarded out the same interface via a default route, the client
>     > must drop the packet. That way, the relay never sees a looped packet, and there
>     > is no extraneous traffic on the client/relay interface.
> 
> I agree that it should *also* be fixed on the client.
> 
> 1) The client will never do any forwarding if the the client has forwarding
>    turned off.
> 
> 2) There are many cases where there are legitimate reasons to have an
>    one-armed router like this.  So, whatever text you right must be sure that
>    the client is looking at the same packet, and not the IPsec transformed one.
>    (The Linux kernel does not make this trivial to get right, for instance)
> 
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
>