Subject: [Dhcpv6bis] [dhcpv6bis] #143 (XML 3315): Is it ok for daisy-chain relays to use multicast?

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Mon, 12 Jan 2015 14:46:14 -0000

#143: Is it ok for daisy-chain relays to use multicast?

 Consider the following case:

 client---relay1---relay2---relay3---server

 In context of multiple relays, is it allowed for relay agents to use
 multicast when sending traffic towards the server? I thought that "yes" is
 the obvious answer, but I was surprised to discover that the text forbids
 that. Sure, using multicast is maybe not optimal, but there may be valid
 use cases when it is useful. For example if youre relay network is very
 dynamic and you frequently change it. So I think it definitely should be
 allowed.

 The text in Section 20 says:
 {{{
    If the relay agent has not been explicitly
    configured, it MUST use the All_DHCP_Servers multicast address as the
    default. If the relay agent relays messages to the All_DHCP_Servers
 multicast
    address or other multicast addresses, it sets the Hop Limit field to
    32.
 }}}
 That means that in the example given above, the relay1 would forward the
 packet, but would set Hop Limit to 32. That would cause the relay2 to drop
 the packet.

 I have two suggestions here, either of them will fix the issue:

 1. Change the text to "If the relay agent relays messages to the
 All_DHCP_Servers multicast
    address, it sets the Hop Limit field to 32.
 2. Change the text to "If the relay agent relays messages to the
 All_DHCP_Servers multicast
    address  or other multicast addresses other than
 All_DHCP_Relay_Agents_and_Servers, it sets
    the Hop Limit field to 32."

 I would prefer option 1 as it gives more flexibility (sysadmins may use
 different multicast groups if they want to).

-- 
----------------------------------------+-----------------
 Reporter:  [email-masked]  |      Owner:
     Type:  task                        |     Status:  new
 Priority:  P1 blocker                  |  Milestone:
Component:  XML 3315                    |   Keywords:
 Due Date:                              |
----------------------------------------+-----------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/143>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Jan 2015 09:00:32 -0800

> dynamic and you frequently change it. So I think it definitely should be

It doesn't make sense to do this.   We use multicast differently for clients than for servers.   Clients do not yet have a network configuration, and can't participate meaningfully in multicast routing, so their multicast has to reach something on the local network.   Relay agents can participate in multicast routing, so they can multicast to all DHCP servers in a site.   So it doesn't make a lot of sense to do multi-hop multicast relay.   Also, if you did do multi-hop multicast, you'd be at risk of creating loops, and there'd really be no operational way to correct for it, since the loops would likely go undetected: since you are multicasting, if there is one valid path to the server, the transaction will succeed, so you won't see a failure.   Consequently, the loop could go undetected indefinitely, until someone notices the traffic and figures out that it's DHCP.   I don't think that's a desirable failure mode.

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 12 Jan 2015 18:29:32 +0100

On 12.01.2015 18:00, Ted Lemon wrote:
>> In context of multiple relays, is it allowed for relay agents to
>> use multicast when sending traffic towards the server? I thought
>> that "yes" is the obvious answer, but I was surprised to discover
>> that the text forbids that. Sure, using multicast is maybe not
>> optimal, but there may be valid use cases when it is useful. For
>> example if youre relay network is very dynamic and you frequently
>> change it. So I think it definitely should be allowed.
> 
> It doesn't make sense to do this.   We use multicast differently for
> clients than for servers.   Clients do not yet have a network
> configuration, and can't participate meaningfully in multicast
> routing, so their multicast has to reach something on the local
> network.   Relay agents can participate in multicast routing, so they
> can multicast to all DHCP servers in a site.   So it doesn't make a
> lot of sense to do multi-hop multicast relay.   Also, if you did do
> multi-hop multicast, you'd be at risk of creating loops, and there'd
> really be no operational way to correct for it, since the loops would
> likely go undetected: since you are multicasting, if there is one
> valid path to the server, the transaction will succeed, so you won't
> see a failure.   Consequently, the loop could go undetected
> indefinitely, until someone notices the traffic and figures out that
> it's DHCP.   I don't think that's a desirable failure mode.
Ok, I agree with this explanation. It doesn't make sense for a multi-hop
multicasts, so HopLimit=32 for All_DHCP_Servers is fine.
But what about single-hop (link-local) multicasts? In particular, I'm
thinking about All_DHCP_Relay_Agents_and_Servers, which is link-scoped,
single-hop multicast.

Let me clarify my question. The scenario is as described, but relays
forward to All_DHCP_Relay_Agents_and_Servers (link-local, single hop
multicast). The rationale to do this is to simplify relay agent
configuration. The only thing a relay agent needs to know is which
interface is up (towards the server) and which is down (towards the
clients). When forwarding to a single-hop multicast, relays would
increase hop-limit by 1, not immediately to 32. Does that make sense?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Jan 2015 09:33:57 -0800

On Jan 12, 2015, at 9:29 AM, Tomek Mrugalski <[email-masked]> wrote:
> The only thing a relay agent needs to know is which

Sounds like a multicast routing protocol.

:)

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 12 Jan 2015 18:40:47 +0000

Be careful here ... Hop-limit refers to the ipv6 header, not the hop-count.

Hop-count is the field in the relay agent packet header.

I don't see where the next relay would drop the packet if the hop-limit is set to 32. Please explain?

- Bernie (from iPad)

>> On Jan 12, 2015, at 12:34 PM, Ted Lemon <[email-masked]> wrote:
>> 
> _______________________________________________
> Dhcpv6bis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcpv6bis

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 12 Jan 2015 19:48:59 +0100

> I don't see where the next relay would drop the packet if the hop-limit is set to 32. Please explain?
I misspoke. I meant hop-count, the field in relay-forward message. The
relay agent would follow the rule from Section 20.1.2 of RFC3315, which
says to drop the packet if the hop-count is greater or equal to 32.

I don't see it as a multicast protocol. This is merely a way to make a
single hop without explicitly knowing the next recipient's (be it the
server or the next relay) address.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Jan 2015 10:54:08 -0800

> server or the next relay) address.

Do a little graph theory on your proposal.   I think you mean that the relay does a link-local multicast to all DHCP servers and/or relay agents, but if it's a relay agent that receives the multicast, not a server, then what's the next hop, and the hop after that?   How do you ensure that there is not a loop?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Jan 2015 14:30:11 -0500

> multicast when sending traffic towards the server? I thought that "yes"

Would a site-local anycast work?
is that permitted?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Jan 2015 11:34:22 -0800

> Would a site-local anycast work?

It's unprecedented.  I suppose we could do something like that, but it would probably involve a spin through 6man, and might see a lot of pushback, so it would be nice if there were a strong reason for doing it.   Although now that I think about it, it doesn't really work, because anycast addresses are single addresses, and presumably we want to reach multiple servers, for redundancy.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Jan 2015 17:38:20 -0500

> It's unprecedented.  I suppose we could do something like that, but it
    > would probably involve a spin through 6man, and might see a lot of
    > pushback, so it would be nice if there were a strong reason for doing
    > it.   Although now that I think about it, it doesn't really work,
    > because anycast addresses are single addresses, and presumably we want
    > to reach multiple servers, for redundancy.

My impression is that each servers wants to reach at least *one* upward
server, and that's enough.  Some (out of scope for us) routing fabric would
take care of deliverying the packet.
I don't know why 6man would be involved: it's a *site-local* anycast.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Jan 2015 15:00:39 -0800

> I don't know why 6man would be involved: it's a *site-local* anycast.

There are no IANA-allocated site-local anycast addresses that I can find anyway.   There are well-defined _link-local_ anycast addresses, but those wouldn't do.   And no, sending to just one server isn't adequate.   E.g., consider what happens without failover if you have a stateless load-balancer splitting the traffic.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 12 Jan 2015 23:50:58 +0000

Is there really a need for this in the first place? Does someone have a use case?

Ideally relays should be design to support sending packets to multiple (unicast) destination addresses (as they were for v4).

- Bernie (from iPad)

> On Jan 12, 2015, at 6:00 PM, Ted Lemon <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Jan 2015 16:07:28 -0800

> Is there really a need for this in the first place? Does someone have a use case?

Exactly the right question to be asking, Bernie--thanks!