Subject: [Roll] IPv6 multicast scope 0x03 in trickle-mcast

From: Ralph Droms <[email-masked]>
Date: Wed, 13 Mar 2013 09:33:20 -0400

WG - To help move the trickle multicast spec along for ZigBee, I applied to IANA for the well-known multicast address for ALL_MPL_FORWARDERS.

As part of the review, Stig Venaas (designated expert) pointed out that draft-ietf-roll-trickle-mcast specifies the use of IPv6 multicast scope 0x03, which is currently "reserved" [RFC4291].  Turns out it was never officially defined as "subnet-local scope" in an RFC, although it was identified as such in early IPv6 addressing architecture I-Ds.  So, something has to be done to allow MPL to use scope 0x03.

Stig, the Internet ADs, 6man co-chairs, roll co-chairs and I discussed the issue, and devised a plan to redefine scope 0x03 to be "unassigned" (like the other unused scope values), and then identify scope 0x03 in draft-ietf-roll-trickle-mcast as a special-purpose use for "trickle multicast networks" (rather than a "subnet").

draft-ietf-roll-trickle-mcast-04 will need to be edited a little, but otherwise I think this plan should meet ZA's requirements.  Also, I'll need to publish a 1-paragraph RFC with the new definition of scope 0x03, but that will be a very quick process.

The next revision of draft-ietf-roll-trickle-mcast will include the necessary edits.  I'll start the process to publish the RFC to redefine scope 0x03 next week.

- Ralph

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 13 Mar 2013 10:35:02 -0400

On Wed, Mar 13, 2013 at 9:33 AM, Ralph Droms <[email-masked]> wrote:

> WG - To help move the trickle multicast spec along for ZigBee, I applied
> to IANA for the well-known multicast address for ALL_MPL_FORWARDERS.
>
> As part of the review, Stig Venaas (designated expert) pointed out that
> draft-ietf-roll-trickle-mcast specifies the use of IPv6 multicast scope
> 0x03, which is currently "reserved" [RFC4291].  Turns out it was never
> officially defined as "subnet-local scope" in an RFC, although it was
> identified as such in early IPv6 addressing architecture I-Ds.  So,
> something has to be done to allow MPL to use scope 0x03.
>
> Stig, the Internet ADs, 6man co-chairs, roll co-chairs and I discussed the
> issue, and devised a plan to redefine scope 0x03 to be "unassigned" (like
> the other unused scope values), and then identify scope 0x03 in
> draft-ietf-roll-trickle-mcast as a special-purpose use for "trickle
> multicast networks" (rather than a "subnet").
>
> draft-ietf-roll-trickle-mcast-04 will need to be edited a little, but
> otherwise I think this plan should meet ZA's requirements.  Also, I'll need
> to publish a 1-paragraph RFC with the new definition of scope 0x03, but
> that will be a very quick process.
>
> The next revision of draft-ietf-roll-trickle-mcast will include the
> necessary edits.  I'll start the process to publish the RFC to redefine
> scope 0x03 next week.
>
> - Ralph
>
> I don't mean to hijack this thread, but I mentioned in the ROLL meeting
yesterday that
I'd have comments/questions regarding draft-ietf-roll-trickle-mcast-04
(MPL) and I think
they're relevant to this proposed definition of IPv6 multicast scope 0x03.

My interest is in using MPL in networks of heterogeneous links, e.g.
homenet.  My
original thinking was that when Proactive Forwarding is employed it might
be useful
to identify links that have no hidden nodes (e.g. ethernets) and suppress
repeating MPL
Data Messages on links that have this property if the message was received
on that link
(flooding bridges work this way).

In further conversation with Jonathan, it seemed that e.g. a site-scoped
message could
be propagated by MPL through a heterogeneous network using link-local
(0x02) multicast
scope and without any changes to the document.  For example, assuming a
site-scoped
multicast message originates in the 6LoWPAN it would be decapsulated at the
6LBR.
The MPL Option header could be re-written with the original packet's source
address
now included as the seed-id.  The packet is then encapsulated with
link-local multicast
scope.  Crucially, reactive forwarding is used on ethernet or other BMA
links to avoid
unnecessary traffic.  (Would this all work as I think?)

If I understand the proposed use of multicast scope 0x03, there would no
longer be a
scope boundary at the 6LBR.  Any router acting as a MPL forwarder would
presumably
treat all its ports as being in multicast scope 0x03 by default, modulo
site-boundary detection.
I think it would be useful in this context to assign proactive/reactive
forwarding behavior
on a port-by-port basis with ports on BMA (e.g. ethernet) links defaulting
to "reactive".

Thoughts?

-K-