Subject: Re: You asked about multicast scope

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 29 Mar 2012 12:02:46 +0200

On 28 Mar 2012, at 12:08 , Fred Baker wrote:

>> I haven't read the spec yet, but isn't PCP supposed to work in the service provider run NAT64/CGN case, too? In that case, the multicasts need to escape out of the site or even organization to reach the service provider at least in the SOHO case. So this would be a scope just shy of global, maybe a new "service provider" scope?

> I personally rarely use "zero configuration" and "service provider" in the same sentence...

Am I understanding you correctly when I take that to mean that the admin (value 4) scope is appropriate because then the people running the multicast routing can determine exactly how far these packets travel?

That makes sense, but there is one potential issue, that I think some people who are well-steeped in IPv6 multicast should look at: in this situation, the scope value 4 may need wider distribution than side-wide, which is scope 5. I can't find any documentation on whether that's ok or not between sessions right now, but I'm reluctant to assume that a lower scope value can have wider distribution than a higher one without having a spec that explicitly says so or hearing from some implementers.

Iljitsch

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 29 Mar 2012 12:38:54 +0200

On Thu, Mar 29, 2012 at 12:02 PM, Iljitsch van Beijnum
<[email-masked]>wrote:

> >> I haven't read the spec yet, but isn't PCP supposed to work in the
> service provider run NAT64/CGN case, too? In that case, the multicasts need
> to escape out of the site or even organization to reach the service
> provider at least in the SOHO case. So this would be a scope just shy of
> global, maybe a new "service provider" scope?
>
> Am I understanding you correctly when I take that to mean that the admin
> (value 4) scope is appropriate because then the people running the
> multicast routing can determine exactly how far these packets travel?
>
> That makes sense, but there is one potential issue, that I think some
> people who are well-steeped in IPv6 multicast should look at: in this
> situation, the scope value 4 may need wider distribution than side-wide,
> which is scope 5. I can't find any documentation on whether that's ok or
> not between sessions right now, but I'm reluctant to assume that a lower
> scope value can have wider distribution than a higher one without having a
> spec that explicitly says so or hearing from some implementers.
>
> Correct me if I'm wrong, but isn't Admin Scoped multicast defined on a per-
port, per-application basis?  That would suggest that some multicast group
addresses can (selectively) be forwarded through the CER uplink to the ISP.

-K-

Iljitsch
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Fred Baker <[email-masked]>
Date: Thu, 29 Mar 2012 13:13:28 +0200

> That makes sense, but there is one potential issue, that I think some people who are well-steeped in IPv6 multicast should look at: in this situation, the scope value 4 may need wider distribution…

I imagine. Note that the document actually says "organization scope".

The non-boilerplate part of the document contains 44 sentences; three of them, in sections 4 and 5, mention the specifics of the scope. Is it fair to assume that you have no issue with the remaining sentences?

4.  IANA Considerations

   This note requests of the IANA the assignment of a set of multicast
   addresses as described in Section 2.7 of the IP Version 6 Addressing
   Architecture [RFC4291] from the registry [v6mult].  This set of
   addresses is referred to as "ALL-NPTv6-TRANSLATORS".  One address
   should be assigned for each of the following scopes: Link-Local,
   Admin-Local, Site-Local, and Organization-Local.

5.  Operational Considerations

   This document defines a set of multicast addresses in several scopes.
   Operationally, the choice of which scope is appropriate is made by
   the administration.  A reasonable default value in system
   configurations might be Organization-Local (e.g., all NPTv6
   Translators operated by the organization).  However, a large
   organization might well choose Site-Local or Admin-Local, and
   consider that "site" or "administrative" domain to include the set of
   NPTv6 Translators advertising a default route into a specific part of
   its network.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 29 Mar 2012 04:16:14 -0700

On 3/29/2012 3:38 AM, Kerry Lynn wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>      >> I haven't read the spec yet, but isn't PCP supposed to work in
>     the service provider run NAT64/CGN case, too? In that case, the
>     multicasts need to escape out of the site or even organization to
>     reach the service provider at least in the SOHO case. So this would
>     be a scope just shy of global, maybe a new "service provider" scope?
>
>     Am I understanding you correctly when I take that to mean that the
>     admin (value 4) scope is appropriate because then the people running
>     the multicast routing can determine exactly how far these packets
>     travel?
>
>     That makes sense, but there is one potential issue, that I think
>     some people who are well-steeped in IPv6 multicast should look at:
>     in this situation, the scope value 4 may need wider distribution
>     than side-wide, which is scope 5. I can't find any documentation on

IMO you cannot do that. The higher scope value, the wider distribution.
If you have scopes X and Y where X < Y, then the distribution of X
should be a subset (can be the same) of the distribution of Y.

There are implementations making such assumptions.

>     whether that's ok or not between sessions right now, but I'm
>     reluctant to assume that a lower scope value can have wider
>     distribution than a higher one without having a spec that explicitly
>     says so or hearing from some implementers.
>

There is nothing magical with scope 4. It is wider than link-local, and
you need to configure routers to limit the distribution according to
your policy.

Stig

>     [email-masked] <mailto:[email-masked]>

---

From: Brian Haberman <[email-masked]>
Date: Thu, 29 Mar 2012 08:15:41 -0400

> There are implementations making such assumptions.

It is not an assumption, it is stately quite clearly in the Scoped 
Addressing Architecture (RFC 4007).  From Section 5 :

       A zone of a given scope (less than global) falls completely within
       zones of larger scope.  That is, a smaller scope zone cannot
       include more topology than would any larger scope zone with which
       it shares any links or interfaces.

> you need to configure routers to limit the distribution according to

RFC 4007 lays out all the rules you need to adhere to for scoped 
addressing boundaries.

Regards,
Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 29 Mar 2012 14:52:29 +0200

On 29 Mar 2012, at 14:15 , Brian Haberman wrote:

> It is not an assumption, it is stately quite clearly in the Scoped Addressing Architecture (RFC 4007).  From Section 5 :

>      it shares any links or interfaces.

Brian, Stig, thanks for the help.

Fred: I think what would be best is to define a "service provider" scope that is smaller than global, and larger than organization. These would be defined to be forwarded to ISPs by default, although organizations that don't want that can always filter them at the desired boundary.

That way, the clients can always use a fixed scope = fixed multicast group, avoiding the need for discovery or configuration here.

---

From: Brian Haberman <[email-masked]>
Date: Thu, 29 Mar 2012 08:57:09 -0400

On 3/29/12 8:52 AM, Iljitsch van Beijnum wrote:
> Fred: I think what would be best is to define a "service provider"
> scope that is smaller than global, and larger than organization.
> These would be defined to be forwarded to ISPs by default, although
> organizations that don't want that can always filter them at the
> desired boundary.
>

RFC 3513 describes the multicast scopes and there are some that are not 
currently defined.

Regards,
Brian

---

From: Fred Baker <[email-masked]>
Date: Thu, 29 Mar 2012 23:31:07 +0200

> That way, the clients can always use a fixed scope = fixed multicast group, avoiding the need for discovery or configuration here.

I don't think this is a service provider discussion.