Subject: [BEHAVE] Re: multicast-08

From: Toerless Eckert <[email-masked]>
Date: Mon, 9 Jul 2007 17:42:17 -0700

TTL scoping, aka: the use of small TTL to determine the reach
of a particular multicast group or channel was deprecated by
the IETF about 8 years ago. There should really be no mentioning
of TTL scoping in an IETF document other than saying not to do it.
If you do not believe me, ask the mboned working group. 

A NAT device needs to handle TTL for multicast as it handles
TTL for unicast, which means that all the NAT that i think is
considered in the draft must decrement TTL of IP multicast
packets forwarded. If a NAT was acting as a bridge, rather than
a router, then it would of course not decrementing TTL neither
for unicast nor multicast packets, but i thought we do not
consider that case at all.

IGMP packets are not logically forwarded by a NAT acting as a
router, instead they are logically always logically generated,
whether the IGMP proxying is working transparently or not. That's
why there is no arguing "Oh, but we receive IGMP packets with
TTL=1 and we send out IGMP packets with TTL=1, so we do not
decrement TTL". I thought the indented paragraph in section 3.
explains this sufficiently.

Cheers
    Toerless

On Mon, Jul 09, 2007 at 06:53:24PM -0400, Manfredi, Albert E wrote:
> > -----Original Message-----
> > From: Dan Wing [mailto:[email-masked]] 
> 
> > > In some cases of which I am aware, the scope of the multicast 
> > > is in part
> > > controlled through use of low values of TTL. Routers are 
> > considered in
> > > determining that value, but the NAT firewalls are not, in 
> > part because
> > > these firewall requirements seem to emerge later in the 
> > design. So it
> > > would be nice if the TTL were not decremented.
> > 
> > It is my understanding that IGMPv3 doesn't discuss TTL because the
> > consensus is that TTL isn't a good way to scope multicast 
> > traffic.  That's
> > why in draft-ietf-behave-multicast-08 we specified administratively-
> > scoped addresses:
> > 
> >   REQ-6:  A NAT MUST NOT forward administratively scoped 
> >           IP multicast traffic (239.0.0.0/8) [RFC2365] from its 
> >           'inside' interface(s) to its 'outside' interface, 
> >           unless the NAT has been configured to do so.
> > 
> > 
> > However, this does leave me wondering what we can or should say about
> > NATs decrementing the TTL of multicast data traffic if the host is
> > receiving multicast via IGMPv1/v2, or if the host is sending multicast
> > (and not listening, in which case the NAT can't decide if the host
> > might be IGMPv1/v2/v3-aware).
> > 
> > I'm open to suggestions.
> 
> I would just make that a configurable item. I agree that using TTL to
> limit multicast scope is discouraged. However, it is still a technique
> used as a fail safe measure.
> 
> Thanks, Dan
> 
> Bert

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

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 10 Jul 2007 09:58:10 -0400

> From: Toerless Eckert [mailto:[email-masked]] 
> 

I have no problem with words to explain that the NAT may also "act as a
bridge," then. Unless I missed the words in the current draft.

As a matter of fact, if the NAT is a 1:1 NAT, I see no reason why it
can't also relay IGMP messages in IGMPv3 just as it is allowed to do in
IGMPv2. In IGMPv3, there is the group-and-source-specific query that
should prevent the NAT from "blackholing."

Bert

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 10 Jul 2007 08:42:31 -0700

> bridge," then. Unless I missed the words in the current draft.

I'd be very surprised if any NAT used in home gateways would do that.

> should prevent the NAT from "blackholing."

Problem is if the upstream router wants to support explicit tracking
for immediate channel changing, then it would require to really
have the NAT be compliant to an IGMPv3 reporter that represents the
aggregate joined state of multiple STBs.

Cheers
    Toerless

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 10 Jul 2007 21:22:54 +0530

One question in line.

Thanks,
Bharat

> aggregate joined state of multiple STBs.

Will it not be the same for IGMPv2 as well?

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

---

From: Rodney Dunn <[email-masked]>
Date: Tue, 10 Jul 2007 11:58:49 -0400

> I'd be very surprised if any NAT used in home gateways would do that.

I agree. I didn't understand that part either. 
What deployment model is suggested there?

Rodney

---

From: "'Toerless Eckert'" <[email-masked]>
Date: Tue, 10 Jul 2007 09:10:09 -0700

> Will it not be the same for IGMPv2 as well?

You can not do explicit tracking in IGMPv2 without making 
implicit assumptions and in addition the reports in IGMPv2,
so, unless you do those non-standards-compliant assumptions
you're fine. In addition, i think it's also a question of
whether or not you could see on the upstream router behavior
of the NAT that would be incompliant to the IGMP reporter side,
and because IGMPv2 reports are more atomic i think you would
be able to do so with IGMPv2 when using such a shortcut, but
you would in IGMPv3. I thought this was all written out in the
draft appropriately.

Cheers
    Toerless

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 10 Jul 2007 12:13:19 -0400

> From: Rodney Dunn [mailto:[email-masked]] 

> What deployment model is suggested there?

Not the IPTV model.

Consider transferring, for example, navigation data to hosts behind a
1:1 NAT firewall. You want to keep that firewall as dumb as possible,
its designers concerned primarily with implementing an acceptable set of
packet filters.

IGMP aggregation is not an issue here. Best for the multicast router
outside the NAT to behave just as it would if there were no NAT
involved. The firewall's filters would probably be identical whether
unicast or multicasts are transitting. In this case, it would be best to
keep the details of IP multicast routing from impacting this firewall
design. 

Bert

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 10 Jul 2007 09:32:56 -0700

> keep the details of IP multicast routing from impacting this firewall

I think i will fail to provide a short reply here, sorry ;-))

In my experience there are lots of other usage cases for NAT with
multicast, and i have been trying to understand what scope we intend
to have for the draft. Best i could come up with was to make it specific
to IGMP proxy-routing, but exclude PIM for example. The second limitation
is - and that's as well explicitly shown in the drafts picture, is
that you have really NAT between the IGMP proxy-routing and the 
upstream interface. The key thing with the upstream interface is that
it's not directly connected to hosts but with a router behind it.

Now if i look into generic cases where i would have static
manually configured 1:1 NATing, then this would often typically
include connecting of eg: multiple LANs with sources and receivers,
and that's the case that can not represented by the NAT box model
used in the draft but would rather be a picture where you had
NAT between multiple different downstream interfaces in the IGMP
proxying device.

The case which i think you are describing could be within scope, but
i would like to resist to even further differentiate the conditions
under which you could hack in a shortcut IGMP proxying implementation
for such cases i would consider to be borderline for the scope of this
draft (and as said above: i don't think your case is borderline, i just
think it is borderline within the scope of the draft).

We have already in the draft geven more leeway to hint at simplification
possible with IGMPv2 than the actual IGMP proxy routing RFC, and
quite frankly i consider all such shortcuts to be unnecessary and
dangerous. The problem i explained with explicit tracking is also only
something that we understood _only_ when some years back we first
implemented this stuff, and quite frankly i am not sure that we should
feel save to say that we have excluded all possible problems that
might happen when using a shortcut - especially not with a protocl
like IGMPv3.

Cheers
    Toerless