Subject: Re: [MBONED] Multicast question for IPv6

From: Toerless Eckert <[email-masked]>
Date: Mon, 4 Dec 2006 00:43:51 -0800

AFAIK, the idea to use TTL=255 came up with VRRP and it was primarily
meant as a mean to identify potential intruders - eg: remote senders -
because their TTL would be less than 255 upon receipt. It's like an
inverted form of ttl-threshold that IP multicast liked to use last
century.

I think all forms of ttl-scoping are hacks. Especially in IPv6 where
multicast addresses have clearly identified scopes there's no need one
way or the other to overload the ttl field with scope semantics.

Cheers
    Toerless

reverse ttl-threashold IP multicast liked to use in the last century

On Mon, Dec 04, 2006 at 12:19:31AM -0500, Marshall Eubanks wrote:
> Dear John;
> 
> On Dec 4, 2006, at 12:01 AM, John Zwiebel wrote:
> 
> >
> > 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
> >> 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.
> >>
> >
> > Actually, for security reasons don't you want these to have a TTL  
> > of 255?
> > This requirement seems to pop up quite a bit. :-)
> 
> For high bit rate streams ? In any case, I think this also requires  
> CPU cycles, maybe more than TTL=1.
> 
> Regards
> Marshall
> 
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mboned

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

---

From: Beau Williamson <[email-masked]>
Date: Mon, 04 Dec 2006 11:50:56 -0600

>way or the other to overload the ttl field with scope semantics.

Marshall et al,

I agree with Toerless.  If you want to scope multicast to Link Local, do it 
with the built in scoping mechanisms and not by defaulting the TTL=1 by the 
application which is a know problem for routers.

BTW, I don't think there is any easy way to handle TTL=1 packets for 
routers. They pretty much all have to be punted to the main CPU for 
handling when TTL=1.  The only way to get around that is to add special 
TTL=1 handling in the hardware for multicast packets.  From what I 
understand, this is non-trivial and therefore expensive. (I could be wrong 
about this.)

My biggest issue is stating that the default = 1 which will no doubt be 
picked up by application developers.  We've been down this path before and 
had to explain why TTL=1 defaults for applications is a bad thing.  I'd 
rather not see us start down this path again by documenting TTL=1 is a 
standard.

Beau

---

From: Beau Williamson <[email-masked]>
Date: Mon, 04 Dec 2006 11:50:56 -0600

Marshall et al,

Beau

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 4 Dec 2006 10:11:11 -0800

>> handling when TTL=1.  The only way to get around that is to add special 

    They don't have to. What would a control CPU want to do with a TTL-
    exceeded multicast packet? Surely not send an ICMP Unreachable. So these
    types of packets could be dropped in hardware.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 4 Dec 2006 10:11:11 -0800

Dino

---

From: Stig Venaas <[email-masked]>
Date: Sun, 03 Dec 2006 19:15:22 +0100

Beau Williamson wrote:
> I agree with Toerless.  If you want to scope multicast to Link Local, do 
> it with the built in scoping mechanisms and not by defaulting the TTL=1 
> by the application which is a know problem for routers.

Agree

> understand, this is non-trivial and therefore expensive. (I could be 
> wrong about this.)
> 
> picked up by application developers.  We've been down this path before 
> and had to explain why TTL=1 defaults for applications is a bad thing.  
> I'd rather not see us start down this path again by documenting TTL=1 is 
> a standard.

There is nothing saying that the default for applications should be 1.
That the stack/socket API by default uses TTL 1 means that applications
will typically need to specify the desired value. One advantage of the
default of 1 is that unicast applications that accidentally send to a
multicast address won't disturb anyone but those on the link.

I wouldn't mind too much if default was different, but I'm against
making changes when progressing the current RFCs unless there are good
reasons. I don't see a sufficiently good reason here.

Also, having different defaults for IPv4 and IPv6 might lead to mistakes
by users or programmers.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Sun, 03 Dec 2006 19:15:22 +0100

Agree

Stig