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

[Philip Homburg <[e-mail]>]

> [if - Theres a couple of problems that this requirement is trying
> to address:
> 
> 1, A misbehaving client (accidentally or otherwise) 2, The volume
> of traffic being forwarded by the relay consumes the available
> bandwidth meaning that DHCP configuration cant complete
> 
> In both cases, the client cant be relied on to solve the problem]

I wonder if the problem can be stated in a more general way.

It seems to me that router should only forward a packet back to the link it
came from when it got the packet directly from a host.

I.e., a host may send a packet to a default router when the best next hop
happens to be different router on the same link. A host may also send a
packet to a default router when the host doesn't know that the destination
is on-link (on NBMA links for example).

In contrast, routers can be relied on to send packet to the correct next hop.
If they don't, then there is something inconsistent in the routing information.
Routers don't react to redirect ICMPs, so this inconsistency could waste a
lot of bandwidth.

One option is to only forward a packet back to the same link if we can also
send a redirect ICMP (ignoring rate limiting). I.e., Section 8.2 of RFC 4861
(Neighbor Discovery) describes that a redirect ICMP can be send if
"the Source Address field of the packet identifies a neighbor"

This could be implemented both in the downstream router and in the upstream
router.

I can see two cases where this could go wrong:
1) multi-homed hosts doing something weird. In that case the host should be
   fixed.
2) Multiple downstream routers on a single link where the downstream routers
   also do not speak a routing protocol. I doubt that we need to support 
   this configuration.