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

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

Ole,

> I can tell you how we will do it in AERO/OMNI. R will have an OMNI interface
> neighbor cache entry (NCE) for A that links the prefix A with the link-layer
> address of A. Then, when R receives a packet from A's link-layer address it
> consults its NCE to see that A is the holder of prefix A and therefore not a
> valid source of packets with destination address in A. We will have this in
> our code soon - thanks for the catch!

On further thought, this is complicated by the multilink nature of OMNI since the
OMNI neighbor could have multiple link-layer addresses. R would then have to
very carefully check that, if a packet with IPv6 destination address 'A' arrived
from link-layer address 'a1', that it not be forwarded back via link-layer address
'a1' nor any other link-layer addresses 'a2', 'a3', 'a4', etc. It gets messy quickly.

So, why not fix the problem at the client instead of at the relay? The client could
have a simple check to make sure it does not forward a packet out the same
interface that it arrived on due to a default route. That way, the relay would
never see a packet originating from node A with a destination address A.
(BTW, it should be OK for the client to forward a packet out the same interface
it arrived on due to  a more-specific route - but not due to a default route.)

Fred