Subject: [MBONED] Multicast question for IPv6

From: Thomas Narten <[email-masked]>
Date: Fri, 01 Dec 2006 08:37:32 -0500

Asking here, as this is where the experts are...

This came up during a review of draft-ietf-ipv6-2461bis-09.txt.

Erik Nordmark <[email-masked]> writes:

> Thomas Narten wrote:

>  >>         CurHopLimit    The default hop limit to be used when sending
>  >>                        (unicast) IP packets.
>  >
>  > why only unicast? seems like this should also apply to multicast.  Are
>  > the default values for multicast different  than unicast? (I think the
>  > answer is yes for IPv4, but I'm not sure that applies to IPv6. IPv6
>  > multicast addresses have explicit scoping, whereas IPv4 multicast used
>  > the TTL for that...)

> I don't know how much we've discussed it, but I think IPv6 needs to have 
> a default hoplimit for multicast of 1, just like IPv4. Applications can 
> use IPV6_MULTICAST_HOPLIMIT etc to set a different value.

Does this make sense? I.e., what is the current recommendations for
setting the Hop Limit/TTL for normal applications that use multicast?

What should it be for IPv6?

Thomas

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

---

From: Stig Venaas <[email-masked]>
Date: Fri, 01 Dec 2006 15:24:53 +0100

> What should it be for IPv6?

All implementations I've seen use 1 as default. Also RFC 2553 and the
new revision RFC 3493 says:

             If IPV6_MULTICAST_HOPS is not set, the default is 1
             (same as IPv4 today)

So I think we should stick with this.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Fri, 01 Dec 2006 15:24:53 +0100

Stig

---

From: Tim Chown <[email-masked]>
Date: Fri, 1 Dec 2006 15:00:02 +0000

> So I think we should stick with this.

I agree with Stig.   Our internal IPv6 multicast is scoped to organisational
via the explicit scope bits, and our external content is scoped globally
using Embedded RP.   In both cases the TTL is set high, and is, in practice,
not something used in IPv6.   Organisations wanting finer granularity
for scoping internally have extra scoping bits to define and use as they
please, no need to even try to rely on TTLs.   

-- 
Tim

---

From: Tim Chown <[email-masked]>
Date: Fri, 1 Dec 2006 15:00:02 +0000

-- 
Tim

---

From: Bill Fenner <[email-masked]>
Date: Fri, 1 Dec 2006 07:20:46 -0800

The discussion to have here is: if you want to scope to the link,
you can use a link-scoped address, so why default the TTL to
link-scoped?

IMO, the original design decision holds: multicast is funadmentally
different from unicast; if a misbehaving application sends to a
multicast address by mistake, and doesn't know what it's doing, it
shouldn't be permitted to do much damage.  This is the same reasoning
behind some versions of the BSD socket API requiring a socket option
be set before allowing outgoing broadcasts - not that it wants to
prevent you from sending a broadcast, it just wants you to know
what you're doing.  Similarly, if you know what you're doing sending
multicasts, you can set IP[V6]_MULTICAST_TTL.

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Fri, 1 Dec 2006 07:20:46 -0800

Bill

---

From: Beau Williamson <[email-masked]>
Date: Fri, 01 Dec 2006 12:37:36 -0600

>So I think we should stick with this.

Hmmm. I think this might be a bad idea.

Haven't we run into problems in the past with TTL= 1 Multicast packets 
impacting routers because they have to drop the packets (after the 
obligatory decrement) and this generally requires processing in the 
software path.  This means that if you are sending a high-rate multicast 
stream with a TTL=1, the multicast routers on the wire are going to be 
negatively impacted by the stream.

Maybe someone else will add to this and either confirm or deny.

Beau Williamson

---

From: Beau Williamson <[email-masked]>
Date: Fri, 01 Dec 2006 12:37:36 -0600

Beau Williamson

---

From: Stig Venaas <[email-masked]>
Date: Fri, 01 Dec 2006 23:13:19 +0000

> At 12/1/2006 08:24 AM, Stig Venaas wrote:
[...]
> Maybe someone else will add to this and either confirm or deny.

Yes, I've seen issues with this on several routers. For link-local I
would hope that routers will ignore it since they are not forwarding
packet anyway. For other scopes you would usually use a higher value,
this is just the default. I have seen cases where people by accident
send at high rates with ttl 1 though. Several times I've seen people
use tools that can do both unicast and multicast udp streaming, and
accidentally told the tool to send "unicast udp" to a multicast
address. Then if the tool doesn't check that the destination address
is unicast and relies on the default ttl, you end up sending multicast
with ttl 1.

Anyway, there might be issues with this default, but I feel it's wrong
to change it now. A change would require stacks to be changed, and
possibly also applications if they rely on the default being 1.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Fri, 01 Dec 2006 23:13:19 +0000

[...]

Stig

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 3 Dec 2006 10:22:50 -0500

On Dec 1, 2006, at 1:37 PM, Beau Williamson wrote:

>>>> I don't know how much we've discussed it, but I think IPv6 needs  
>>>> to have a default hoplimit for multicast of 1, just like IPv4.  
>>>> Applications can use IPV6_MULTICAST_HOPLIMIT etc to set a  
>>>> different value.
>>>
> Haven't we run into problems in the past with TTL= 1 Multicast  
> packets impacting routers because they have to drop the packets  
> (after the obligatory decrement) and this generally requires  
> processing in the software path.  This means that if you are  
> sending a high-rate multicast stream with a TTL=1, the multicast  
> routers on the wire are going to be negatively impacted by the stream.
>

Dear Beau;

If you are sending high rate multicast with TTL=1, but you intend for  
them to get somewhere, then that is
a configuration bug, which presumably the operator or sender will  
fix. (In other words, in this case your
negative impact is because of an error; fix the error, fix the impact.)

If, on the other hand, you _intend_ for your high bit rate multicast  
to be link
local, it seems to me that you will and should send them TTL=1  
regardless of the default. If there is
a negative impact, change what you or doing or take it up with your  
FH router vendor, not the IETF.

It seems to me that in neither case is the negative impact _because  
of the default_.

The danger of link-local multicasts escaping is real, and so I would  
still vote for TTL=1 as a default.

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 3 Dec 2006 10:22:50 -0500

Dear Beau;

Regards
Marshall

---

From: John Zwiebel <[email-masked]>
Date: Sun, 3 Dec 2006 21:01:49 -0800

On Dec 3, 2006, at 7:22 AM, Marshall Eubanks wrote:

>
> If, on the other hand, you _intend_ for your high bit rate  
> multicast to be link

Actually, for security reasons don't you want these to have a TTL of  
255?
This requirement seems to pop up quite a bit. :-)

---

From: John Zwiebel <[email-masked]>
Date: Sun, 3 Dec 2006 21:01:49 -0800

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 4 Dec 2006 00:19:31 -0500

Dear John;

On Dec 4, 2006, at 12:01 AM, John Zwiebel wrote:

>> a negative impact, change what you or doing or take it up with  
>> your FH router vendor, not the IETF.
>>
>
> Actually, for security reasons don't you want these to have a TTL  
> of 255?

For high bit rate streams ? In any case, I think this also requires  
CPU cycles, maybe more than TTL=1.

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 4 Dec 2006 00:19:31 -0500

Dear John;

Regards
Marshall