Subject: [dhcwg] RFC3315 relay agent behavior question...

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Dec 2007 10:00:00 -0800

I can't remember if this ever came up, but I was just reading section  
20 of RFC3315, and I noticed what seems like an omission in the spec.

The spec currently says that if the relay agent has not been  
configured with any DHCP server IP addresses, it forwards packets to  
the All_DHCP_Servers multicast address.   However, it omits mention of  
one situation that can occur: where a relay agent is connected to a  
particular link, and a DHCP server is connected to that same link.

In this case, a DHCP client that multicasts on that link to the all  
relay agents and servers multicast address will be immediately heard  
by the DHCP server.   But a relay agent that follows RFC3315 will  
still forward the packet to the DHCP server, meaning that the DHCP  
server will receive the packet twice.

Do we think that this is a problem, or is the fact that DHCP handles  
duplicate packets correctly sufficient to deal with this issue?

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Damien Neil <[email-masked]>
Date: Thu, 6 Dec 2007 11:56:01 -0800

On Dec 6, 2007, at 10:00 AM, Ted Lemon wrote:
> the All_DHCP_Servers multicast address.   However, it omits mention  
> of one situation that can occur: where a relay agent is connected to  
> a particular link, and a DHCP server is connected to that same link.

I would consider this to be a error in the site configuration.  I  
don't see any change that can be made to the specification in RFC 3315  
that would eliminate the possibility of such errors.

As you point out, DHCP already robustly deals with misconfigurations  
like this.  I think 3315 is fine as it stands.

                    - Damien

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 6 Dec 2007 12:09:35 -0800

I think there's at least an implicit requirement that relaying be
between different (virtual) interfaces, at the express direction of
an operator.

If making that implicit requirement (more?) explicit is considered
helpful, then it is at least safe to say so.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Dec 2007 12:33:07 -0800

On Dec 6, 2007, at 11:56 AM, Damien Neil wrote:
> don't see any change that can be made to the specification in RFC  
> 3315 that would eliminate the possibility of such errors.

I would expect the proximity of servers to relay agents to be quite  
common, actually.   Any small-ish corporate network is probably going  
to have a central DHCP server and a single set of spoke routers, each  
running a relay agent.   If a DHCPv6 client broadcasts on the central  
subnet, it's going to hit both the relay and the server.

> between different (virtual) interfaces, at the express direction of

This is actually hard to do - you would have to learn a lot more about  
your low-level network configuration than I think is reasonable.

However, there's a much easier solution - say that DHCPv6 relay agents  
SHOULD NOT listen on networks to which DHCPv6 servers are attached.    
This way the relay doesn't happen because the relay agent doesn't hear  
the packet (easy), rather than because it notices that it's sending it  
out the same network interface it arrived on (hard).

Making this a soft requirement is probably sufficient - it's enough to  
tell a responsible network administrator what to do, and as Damien  
says, if they get it wrong, the only downside is that it increases the  
load on the DHCP server to some degree.   In networks where this might  
be common, that's probably not a serious problem.

---

From: Evan Hunt <[email-masked]>
Date: Thu, 6 Dec 2007 21:57:15 +0000

I believe this (or a closely related) issue came up at the interop bakeoff
in Amsterdam last March, and we may see more of it this weekend.  From
Alain's report:

  * RFC3315 reserved multicast addresses are not useable for
    inter-relay multicasting:
      - The link local "all relays and servers" multicast address cannot be
        used between relays that are not on the same link.
      - The site local "all servers" multicast address can not be used
        between relays
  * Suggested fix:
      - Clarify the spec about this.

> SHOULD NOT listen on networks to which DHCPv6 servers are attached.    

It seems to me that a client multicasting to "all relays and servers"
would reasonably expect to reach, you know, all relays and servers.  So I
can't really support this. Maybe a better solution is to say a DHCPv6
relay agent SHOULD NOT retransmit a request onto the interface from which
that request was received, unless it's transmitting to a configured server
address (i.e., something other than the "all {relays and,} servers"
multicast addresses).

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: John Jason Brzozowski <[email-masked]>
Date: Thu, 06 Dec 2007 15:59:45 -0800

I agree with David that the requirement is implicit.

> helpful, then it is at least safe to say so.

=========================================
John Jason Brzozowski (CISSP, RHCT)
Comcast Corporation
e) mailto:[email-masked]
m) 609-377-6594
p) 856-324-2671
=========================================

---

From: John Jason Brzozowski <[email-masked]>
Date: Thu, 06 Dec 2007 16:12:50 -0800

Inline.

John

> subnet, it's going to hit both the relay and the server.
[jjmb] So even if the relay gets the DHCP multicast on the interface that is
on the same link as the client and server the server will get two SOLICITs.
As Damien suggested DHCPv6 should handle this adequately.  In this case I
would expect two ADVERTISEMENTs from the server leaving the client to decide
based on attributes of the ADVERTISEMENTs which to select.
> your low-level network configuration than I think is reasonable.
[jjmb] I would expect the relay to handle this minimally based on its
configuration.
> out the same network interface it arrived on (hard).
[jjmb] How does the relay detect the absence or presence of a server?

---

From: John Jason Brzozowski <[email-masked]>
Date: Thu, 06 Dec 2007 16:16:33 -0800

Evan I thought the item that was reported essentially resulted in a
multicast storm.  Further, would this not be classified as configuration
issue?

> address (i.e., something other than the "all {relays and,} servers"
[jjmb] What you are recommending seems reasonable.  Perhaps to my fault I
would have assumes this to be the case already.  As someone suggests maybe
some clarification would be good.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Dec 2007 16:20:06 -0800

On Dec 6, 2007, at 4:12 PM, John Jason Brzozowski wrote:
(referring to which interface a forwarded packet is being sent across)
> [jjmb] I would expect the relay to handle this minimally based on its

I suppose my naivete is showing here - I don't know if, when you send  
a single multicast, it is delivered to all interfaces, or whether if  
you want it delivered to all interfaces you have to iterate across  
each interface.   If it's the latter, then you're right - it's easy to  
just skip the interface on which the packet arrived.

> [jjmb] How does the relay detect the absence or presence of a server?

The network administrator configures it to not listen on that  
particular interface.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Dec 2007 16:21:44 -0800

On Dec 6, 2007, at 1:57 PM, Evan Hunt wrote:
> Maybe a better solution is to say a DHCPv6

Except that that's the thing I was trying to avoid.   Being able to  
configure on which interfaces a relay agent listens, and disable  
listening on the network interface that's attached to the network to  
which the DHCP server is also attached, seems like a useful thing to  
be able to do.

---

From: Evan Hunt <[email-masked]>
Date: Fri, 7 Dec 2007 01:48:29 +0000

> Except that that's the thing I was trying to avoid.

I guess I'm not clear why you want to avoid it.

> Being able to  configure on which interfaces a relay agent listens, and
> disable  listening on the network interface that's attached to the
> network to  which the DHCP server is also attached, seems like a useful
> thing to  be able to do.

Being able to configure which interfaces the relay will monitor does indeed
seem like a good idea (and I hope all existing relays support it), and
configuring the relay not to listen on a link that's shared with a server
may be good general practice... but I see those as implementational and
operational details, not properly part of the protocol.

A statement that relays shouldn't multicast packets on links that have
already seen them, however, does seem appropriate.  I don't know if it's
necessary; I agree with David that it's implicit in the spec.  But I
wouldn't oppose making it explicit.

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 18 Dec 2007 13:03:02 -0800

> multicast storm.  Further, would this not be classified as configuration

I think the bulletpoint Evan quoted was resulting from discussion
after one of the test events, some scenario whiteboarding, not any
test event in Amsterdam.

I think in the test event you're thinking of, the server(s) observed a
relay-forward packet storm, but this was not due to multicast issues,
my (squishy, human) memory is that we were using unicast addresses for
the relays to forward to.

---

From: John Jason Brzozowski <[email-masked]>
Date: Tue, 18 Dec 2007 23:25:44 -0500

If unicast forwarding was used and relay forward storms resulted I think I
would classify this as a misconfiguration since unicast forwarding is
something very deliberate and controlled in most cases.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 26 Dec 2007 13:38:47 -0800

> something very deliberate and controlled in most cases.

Sort of.

It was one of our clarification findings that I think 3315 tries to
mention that "most relays are routers", but it doesn't mean that all
relays need to toggle their ip forwarding bits when asked to relay.