Subject: [6lo] Realm-Local scopes

From: Carsten Bormann <[email-masked]>
Date: Thu, 27 Aug 2015 08:50:25 +0200

RFC 7346 defines the realm-local multicast scope for 802.15.4 6LoWPAN,
but not for any other 6Lo technology.  We probably should be looking
into whether we want to define them for any technology we are working on.
We missed that for RFC 7428 (lowpanz).

Grüße, Carsten

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 27 Aug 2015 19:03:33 +0000

Hi Carsten,

Looking at RFC 7346 section 3 (definition of realm-scope), it refers to :

   " Any RFCs that include the definition of a Realm-Local scope will be
   added to the IANA "IPv6 Multicast Address Scopes" registry under the
   Realm-Local scope entry, and those specifications must include such a
   request in their IANA Considerations."

Thanks for pointing this out.    

My question is: should we use different scop values for every ipv6-over-foo RFC  ?
[ This is what the current specification suggests, but will not that eat up the scop unassigned values pretty soon?]

Ralph, is the author of RFC7346.  Ralph, do you have comments on the allocation of realm-local scope values for other 6lo technologies?

6lowpanz is one of them.  How about BT-LE?  
Do they have realm-local scope? How is it different from link-local scope? 

 Section 5 of RFC 7346 defines realm-local scope for IEEE802.15.4:

Definition of Realm-Local Scope for IEEE 802.15.4:

   When used in an IP-over-IEEE802.15.4 network, scop 3 is defined to
   include all interfaces sharing a Personal Area Network Identifier
   (PAN ID).

In the above case, it seems that either same nodes could belong to multiple PAN-ID or a link-local (larger scope) scope could consist of multiple PAN co-ordinators. Thus a router forwards neither link-local nor realm-local scope traffic.

-Samita

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Wednesday, August 26, 2015 11:50 PM
To: [email-masked]
Subject: [6lo] Realm-Local scopes

RFC 7346 defines the realm-local multicast scope for 802.15.4 6LoWPAN, but not for any other 6Lo technology.  We probably should be looking into whether we want to define them for any technology we are working on.
We missed that for RFC 7428 (lowpanz).

Grüße, Carsten

_______________________________________________
6lo mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lo

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 27 Aug 2015 16:59:52 -0400

Hi Samita,

See inline...

On Thu, Aug 27, 2015 at 3:03 PM, Samita Chakrabarti <
[email-masked]> wrote:

> [ This is what the current specification suggests, but will not that eat
> up the scop unassigned values pretty soon?]
>
> No, Realm-local is always defined as scop == 3.  What RFC 7346 says is
that every RFC
that defines Realm-Local for a particular technology should be listed in
http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#ipv6-scope
in the "Realm-Local" row (and should make an explicit request of IANA to be
listed there).

Ralph, is the author of RFC7346.  Ralph, do you have comments on the
> allocation of realm-local scope values for other 6lo technologies?
>
> 6lowpanz is one of them.

The definition of Realm-Local for 6lowpanz (RFC 7428) would be something
like:

  The set of connected interfaces sharing a HomeID (G.9959 Link-Layer
Network Identifier).

> How about BT-LE?

I do not think Realm-Local needs to be defined for BTLE, which is only a
star topology.
The spec says:

   ... a 6LN always has to send packets to or through 6LBR.

   Hence, when a 6LN needs to transmit an IPv6 multicast packet,

   the 6LN will unicast the corresponding Bluetooth LE packet to

   the 6LBR.

That suggests to me that a 6LR could send a Link-Local multicast to the
6LBR and it
would be replicated (unicast) to on that subnet.

>
> Mesh networks define Link-Local scope as including only adjacent nodes.
Hence,
in a *mesh*, Realm-Local is required in order to reach every node on the
subnet
(which may be several L2 hops in diameter).

> In the above case, it seems that either same nodes could belong to
> multiple PAN-ID or a link-local (larger scope) scope could consist of
> multiple PAN co-ordinators. Thus a router forwards neither link-local nor
> realm-local scope traffic.
>
> No router can forward a Link-Local multicast, according to RFC 4291,
section 2.5.6:

   Routers must not forward any packets with Link-Local source or
   destination addresses to other links.

I'm pretty sure (someone correct me if I'm wrong) that a 6LR will
forward a Realm-

Local multicast using the L3 source address of the original sender.
Note that if a

router has multiple interfaces that are each in a different
Realm-Local zone, the

router will not forward between them (they are disjoint).

HTH, Kerry

-Samita
> RFC 7346 defines the realm-local multicast scope for 802.15.4 6LoWPAN, but
> not for any other 6Lo technology.  We probably should be looking into
> whether we want to define them for any technology we are working on.

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 27 Aug 2015 21:36:18 +0000

Agree that it would make sense to define it for other 6lowpan technologies. BTLE is currently a start topology, but the Bluetooth SIG has started work on mesh, so depending on how that ends up, it may also makes for that in the future.

One clarification when you say:

Mesh networks define Link-Local scope as including only adjacent nodes.  Hence,
in a *mesh*, Realm-Local is required in order to reach every node on the subnet
(which may be several L2 hops in diameter).

s/mesh/route-over mesh/

the point is that with a mesh-under mesh, link-local reaches the whole mesh.

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 27 Aug 2015 17:38:21 -0400

On Thu, Aug 27, 2015 at 5:36 PM, Gabriel Montenegro <
[email-masked]> wrote:

> Agree that it would make sense to define it for other 6lowpan
> technologies. BTLE is currently a start topology, but the Bluetooth SIG has
> started work on mesh, so depending on how that ends up, it may also makes
> for that in the future.
>
>
>

Point taken.

-K-

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 27 Aug 2015 21:38:57 +0000

Hi Kerry,

Yes, it helps with explantiaon Thanks.

As for forwarding: I wrote “Thus a router forwards neither link-local nor realm-local scope traffic.”
We all know from Ipv6 that link-local addresses are not forwarded. [ as you made a reference below]
But I was looking for clarification on real-local scope for 6LN and what you describe makes sense.
-Samita

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kerry Lynn
Sent: Thursday, August 27, 2015 2:00 PM
To: Samita Chakrabarti
Cc: Carsten Bormann; [email-masked]
Subject: Re: [6lo] Realm-Local scopes

Hi Samita,

See inline...

On Thu, Aug 27, 2015 at 3:03 PM, Samita Chakrabarti <[email-masked]<mailto:[email-masked]>> wrote:
Hi Carsten,

My question is: should we use different scop values for every ipv6-over-foo RFC  ?
[ This is what the current specification suggests, but will not that eat up the scop unassigned values pretty soon?]
No, Realm-local is always defined as scop == 3.  What RFC 7346 says is that every RFC
that defines Realm-Local for a particular technology should be listed in
http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#ipv6-scope
in the "Realm-Local" row (and should make an explicit request of IANA to be listed there).

6lowpanz is one of them.

The definition of Realm-Local for 6lowpanz (RFC 7428) would be something like:

  The set of connected interfaces sharing a HomeID (G.9959 Link-Layer Network Identifier).

How about BT-LE?

I do not think Realm-Local needs to be defined for BTLE, which is only a star topology.
The spec says:

   the 6LBR.

That suggests to me that a 6LR could send a Link-Local multicast to the 6LBR and it
would be replicated (unicast) to on that subnet.

In the above case, it seems that either same nodes could belong to multiple PAN-ID or a link-local (larger scope) scope could consist of multiple PAN co-ordinators. Thus a router forwards neither link-local nor realm-local scope traffic.
No router can forward a Link-Local multicast, according to RFC 4291, section 2.5.6:

I'm pretty sure (someone correct me if I'm wrong) that a 6LR will forward a Realm-

Local multicast using the L3 source address of the original sender.  Note that if a

router has multiple interfaces that are each in a different Realm-Local zone, the

HTH, Kerry

-Samita

-----Original Message-----
From: 6lo [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Carsten Bormann
Sent: Wednesday, August 26, 2015 11:50 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [6lo] Realm-Local scopes

Grüße, Carsten

_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo
_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 27 Aug 2015 17:49:59 -0400

On Thu, Aug 27, 2015 at 5:38 PM, Kerry Lynn <[email-masked]> wrote:

> Actually, you raise an interesting point.  As 6lo proposals are agnostic
with respect
to routing, a given proposal SHOULD include a definition of Realm-Local if
there's
a possibility that it will be used in route-over networks and the
underlying data link
technology supports such a definition.

-K-