> > > * In section 4.2, why is it that a NAPT
device
> > > implementing this draft
> > > needs to aggregate IGMP message only for
IGMPv3? I think if it is
> > > implementing 'RFC4605', it will anyway do the
aggregation.
> >
> > It's my understanding that things will work --
somewhat
> > sub-optimally --
> > with IGMPv1 or IGMPv2 without the NAT doing
aggregation of IGMPv1/v2
> > messages and blindly just forwarding them
upstream.
> >
> > If my understanding is incorrect, please let me
know (it
> > may well be; multicast is not my expertise).
(By the way, to address that weakness, I have recently added
Toerless Eckert as a co-author.)
> Things should work even if we do not aggregate IGMPv3
message
> also. Why we do aggregation is that we do not want to
send multiple
> messages upstream? Because upstream would forward
multicast data
> traffic if he knows that there is atleast one host
interested in
> a group.
But if blind forwarding is done, with no aggregation, the
upstream
router will see arrival and leave packets arrive in the
wrong order.
We adjusted the text in -07 and I think it should be clearer
now.
It now reads:
***
4.3. IGMPv3 NAPT
When a IGMPv3 proxying device receives an IGMP membership
on an
inside interface, it creates its own IGMP proxying
membership state
and its own IGMP forwarding table. It then creates an
independent
IGMP membership report on its outside interface reporting
the
multicast groups/channels -- but there is no direct
relationship or
"relaying" of IGMP membership reports or
queries across the
interfaces. The NAPT device will subsequently receive a
multicast
data packet on the outside ('public') interface and
forward the
multicast packet to inside ('internal') interfaces based
on its IGMP
forwarding table.
By performing NAPT on IGMPv3 membership reports, the
membership
reports appear to originate from a single IGMPv3 reporter
instead of
different reporters. Because IGMPv3 has different types
of
membership reports differentiating between status
(IS_INCLUDE,
IS_EXCLUDE) and change indication (e.g., TO_INCLUDE,
TO_EXCLUDE), if
a NAPT were to interleave reports from two or more
reporters (joining
and leaving the same groups) the NAPT would create a
sequence of
packets that are incompliant with an IGMPv3 reporter
[RFC3376]. For
this reason,
REQ-4: If a NAPT supports IGMPv3, the NAPT MUST
implement [RFC4605].
Such compliance causes the NAPT to aggregate the
IGMPv3
membership reports and report only the aggregated
information
upstream.
Failure to do this aggregation will cause undesired
temporary
blackholing of multicast traffic. For example, consider
two hosts
behind the same NAPT. If one host is joining a session
at the same
time another is leaving the session, and the NAPT were to
merely
relay the join and leave upstream, the session will be
terminated,
and the join and leave announcements would not comply
with section 5
of [RFC3376].
***
> Aggregating IGMPv3 is a little more complex than V1 and
V2.
Yes, agreed.
> I just wanted to point out that if an NAPT is
implementing
> RFC 4605 than it should be aggregating all versions of
IGMP.
>
> So why do you want to
> specifically mention the case for IGMPv3?
But IGMPv1 and IGMPv2 predated RFC4605, and there have been
and still are IGMPv1/v2-aware NATs that should
"work" (but
perhaps not optimally) without implementing RFC4605. I
have
removed the old REQ-1 in -07 for this reason (and based on
some other feedback).
In -07, I adjusted the requirements so that RFC4605 is only
a
requirement for NATs that support IGMPv3, and not a
requirement
for NATs that only do IGMPv1 or only IGMPv2. I expect to
publish
-07 in the middle of next week.
> > > * In case of IGMPv3, why is it that
aggregation is a MUST?
> > > Also I think
> > > when one of the hosts behind the NAPT
generates LEAVE and another
> > > generates JOIN simultaneously, the session
will be UP till the
> > > group-timer timesout and as JOIN is also
received, it
> > > will be updated
> > > and so session will always be UP. Am I mixing
the session
> > > created in
> > > NAPT with the state in upstream router?
> >
> > Slightly after that requirement in the document is
this explanation:
> >
> > >
> > > Failure to do this aggregation will
cause undesired
> > > temporary blackholing of multicast
traffic. For example,
> > > consider two hosts behind the same NAPT.
If one host is
> > > joining a session at the same time
another is leaving the
> > > session, and the NAPT merely relays the
join and leave
> > > upstream, the session will be terminated
and the join and
> > > leave announcements do not comply with
section 5 of <xref
> > >
target="RFC3376"></xref>.
> > >
>
> Thats exactly why I raised this question. How does this
creates an
> issue? This can happen in a host as well. Lets say
application just
> started and send a join and immediately after this
because of some
> failure, it goes down and send a leave. I am not sure
what the problem
> is.
If it's a single host, it brought this behavior on itself.
I believe
this is identical to the behavior without a NAPT.
> > > * In section 4.4, though complete Multicast
Range is
> > > 224/4 but out of
> > > this range 232/8 is used for Source Specific
Multicast or
> > > Single-Source
> > > Multicast. So is the following statement
syntactically correct
> > >
> > > "Any-sosurce multicast (ASM) uses the IP
addresses in the
> > > 224.0.0.0 -
> > > 239.255.255.255 range [IANA-ALLOC]."
> > >
> > > What I meant is that it looks to be incorrect
to call this
> > > range as ASM range.
> >
> > You're right. I pulled this from the Terminology
section
> > of RFC3569
> > ("An Overview of Source-Specific Multicast
(SSM)"). I have adjusted
> > my document so that it describes the ASM space as
224/8 through
> > 231/8 and 233/8 through 239/8 (with a hole for
224/8).
> >
>
> I think this may not be completely correct. This is
because 239/8 is
> available to administrator and they can use this for
SSM
> within a given domain.
Is there some other way a NAT could make this determination?
Perhaps,
(see below) the NAT could determine the host is doing ASM
because the
host is sending to the same multicast group; that may well
be far easier
anyway... Although, with SSM, RTP fixed this problem (in
draft-ietf-avt-rtcpssm, where it suggests identifying hosts
using
information other than the source transport address), thus
with
SSM traffic the NAT doesn't need to keep the UDP binding
open for
60 minutes. It's ASM RTP applications which don't follow
draft-ietf-avt-rtcpssm's suggestions for identifying hosts
that
are the reason that requirement exists in
draft-ietf-behave-multicast.
> > > * In section 4.4,
> > >
> > > a. This UDP mapping SHOULD be destroyed
when the host leaves
> > > that host group.
> > >
> > > How do we find out that host has left the
group? Please correct
> > > me if I am wrong. We are talking about a
host behind the NAPT
> > > device generating Multicast data traffic [UDP
traffic]. A
> > > multicast host does not need to join the
multicast group [By
> > > sending an IGMP join message] to send
multicast traffic to that
> > > group. So how does NAPT finds out when it
can destroy this
> > > mapping and so this mapping will have to
timeout before it can
> > > be removed.
> >
> > Ah, good point which I hadn't considered. I have
removed that
> > requirement.
Sorry -- while making this edit, I remembered the genesis of
the
problem for RTP. The problem only occurs when a host is
receiving
the same multicast stream that it is also sending to.
Specifically,
when the host is receiving an RTP stream it will
occasionally
send RTCP reports. With ASM, these RTCP reports are sent to
the
multicast address (so that all participants can see all
other
participants RTCP reports and adjust some RTP behaviors
according
to the size of the group).
If a host is only sending packets into an ASM stream (such
as
sending RTP packets) and isn't also listening to the
stream,
we don't have this problem with RTP. So we don't need to
require
a NAT to have this 60-minute timeout.
So, I'm going to leave this requirement in -07, and have
tried
to adjust the discussion/justification to describe why this
requirement is only necessary when a host is both a member
of
the multicast group _and_ sends traffic to that same
multicast
group.
Related, I have previously received pushback for this
60-minute
timer being a MUST, because the difficulties this causes RTP
aren't sufficiently significant to flat-out break
interoperability
if a NAT didn't implement that MUST. I tend to agree with
this
comment, but would sure like to hear from others before I
adjust
it.
-d
> Ok. So now how do you remove that mapping? I guess only
once
> that times out. Right?
_______________________________________________
Behave mailing list
Behave ietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave
|
