Subject: [Roll] Non-storing mode address types

From: Stephen Dawson-Haggerty <[email-masked]>
Date: Thu, 11 Nov 2010 09:11:55 -0800

Hi -- trying to figure out how to construct downward source routes using DAOs.

The 6lowpan-nd draft says that "All other prefixes are assumed to be
off-link ... They are therefore sent to one of the routers in the
Default Router List."  This presumably means up, not down, so the
addresses in the routing header wold need to be link local?  It seems
more likely that RPL wanted them to be global, though?

Related, the target option in the DAO specifies a global address, of
course; it looks like the parent address is also a global address.
This is what leads to my confusion about the source route because
while you can construct a path of global addresses, I must be missing
how the intermediate hops can resolve the next hops of the addresses.

If the parent addresses were link-local, I think it would work, so
long as the originating DAO also included a SLLA option; then the path
would be composed of only link-layer addresses. This seems a little
strange, though. I looked in 6.7.8  and 9 for guidance on this, but am
still confused...

Thanks,
Steve

-- 
stephen dawson-haggerty
http://cs.berkeley.edu/~stevedh
uc berkeley wireless and embedded systems lab
berkeley, ca 94720

---

From: "Colin O'Flynn" <[email-masked]>
Date: Thu, 11 Nov 2010 22:35:16 -0000

Hi Steve,

That exact problem you mention was discussed on the 6LoWPAN mailing list. If
you follow the way the standards are written, it won't work since global
addresses are 'off-link' and you can never reach them!

How it can be accomplished though use of the neighbor cache & NUD to
determine if a link is reachable or not. The point of assuming the prefix is
off-link is so you don't send NS for an unreachable node, but instead send
to the default router. But if you have NC entries, you should consider the
nodes on-link. See section 6.5.4 of 6lowpan-nd-14.

Another method is just to always assume a node which you have received a
downward source route to is reachable. Presumably RPL is taking care of
ensuring that node is actually registered through you, so if you got a
message which indicates the next-hop is that node, it should be reachable. 

HTH,

  -Colin O'Flynn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Dawson-Haggerty
Sent: November 11, 2010 5:12 PM
To: ROLL WG
Subject: [Roll] Non-storing mode address types

Hi -- trying to figure out how to construct downward source routes using
DAOs.

Thanks,
Steve

-- 
stephen dawson-haggerty
http://cs.berkeley.edu/~stevedh
uc berkeley wireless and embedded systems lab
berkeley, ca 94720
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Stephen Dawson-Haggerty <[email-masked]>
Date: Thu, 11 Nov 2010 14:46:39 -0800

Ahh -- I only checked the roll mailing list archives... I don't really
like the idea of keeping a neighbor cache for the downstream nodes,
since it seems like it partially defeats the point of being
"non-storing"; although you only would need one-hop neighbors that
could still be a large set and you don't know which ones.

I thought about just assuming it's on-link, but in that case we'll
need to require that there is a mapping from the global address to the
LL address.  I think this will be mostly true, but seems like either
RPL or 6lowpan should explicitly require it.  It's also a little
strange, I think, to make an exception and say that "other addresses
are off link, unless they're in a routing header."

Anyways, I'll go scan those 6lowpan archives, thanks for the clarification.

Steve

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 11 Nov 2010 15:49:38 -0800

Steve,

You can make the on-link assumption when using the RPL routing header.  Section 4.2 of draft-ietf-6man-rpl-routing-header requires routers to ensure that the next entry is on-link.  If the next entry is not on-link, the router must drop the packet.

BTW, I'm not convinced that using 6lowpan-nd between RPL routers even the right approach.  The current 6lowpan-nd spec is primarily focused on the host-router interface, which makes much more sense to me than applying the same protocol for router-router interfaces.

--
Jonathan Hui

---

From: Stephen Dawson-Haggerty <[email-masked]>
Date: Thu, 11 Nov 2010 15:58:23 -0800

Okay, that sounds good; does that mean RPL routers might need to run
ND to solve the link-layer address of the next hop?  Could I also
assume that the addresses RPL puts in the source header are derived
from link-layer addresses (maybe if we're in the same prefix) so that
I can just directly translate them?  Let's face it, that's what I
really want to do :).

Steve

---

From: "Colin O'Flynn" <[email-masked]>
Date: Fri, 12 Nov 2010 07:47:56 -0000

Hi Steve,

> ND to solve the link-layer address of the next hop?  

Yes - 6lowpan-ND does say that between routers you can use classic multicast RS to figure out a node's L2 address.

> I think this will be mostly true, but seems like either
> RPL or 6lowpan should explicitly require it.  

No IETF spec is going to say that you can always assume the L2/IPv6 address mapping. Doing so eliminates the possibility of assigning addresses, and some networks might want to have fixed IPv6 addresses even when the L2 addresses change.

> Let's face it, that's what I
> really want to do :).

If in your network you know this is always the case, then you can get away with making the assumption. There is probably some sort of '6lowpan optimized sending algorithm' you could create if you really wanted, where you try an L2 address based on the IPv6 address before doing ND. With a 15.4 network you will instantly know if your packet was received at the L2 layer anyway. In the generic case though you might still have a different IPv6 address, so even if it was received at the L2 layer it could be dropped at the IP layer. However - if in your network L2 and IP mapping is kept, a packet being received at the L2 layer should always mean it is accepted at the IP layer.

Regards,

   -Colin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Dawson-Haggerty
Sent: November 11, 2010 11:58 PM
To: Jonathan Hui
Cc: Colin O'Flynn; ROLL WG
Subject: Re: [Roll] Non-storing mode address types

Steve

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 12 Nov 2010 19:38:51 +0100

Hi Stephen:

Not might. They do need to run ND to solve the link-layer address of the next hop. Avoiding the ND exchange between parent and child was the whole point of placing the SLLAO in the DAO/DIO. The list was not unanimous in thinking that was a good idea. 

Maybe real world experience will make us add that capability to the protocol as an extension. For now you have to play the NS/NA game, and whether you do the registration or the classical mcast way is not RPL's business.  Note that RPL does not provide DAD, either.

Pascal
http://www.xtranormal.com/watch/7011357/

> Sent: Friday, November 12, 2010 12:58 AM
> To: Jonathan Hui
> Cc: ROLL WG
> Okay, that sounds good; does that mean RPL routers might need to run ND
> to solve the link-layer address of the next hop?  Could I also assume that the
> addresses RPL puts in the source header are derived from link-layer
> addresses (maybe if we're in the same prefix) so that I can just directly
> translate them?  Let's face it, that's what I really want to do :).
> 
> Steve
> 
> > You can make the on-link assumption when using the RPL routing
> header.  Section 4.2 of draft-ietf-6man-rpl-routing-header requires routers
> to ensure that the next entry is on-link.  If the next entry is not on-link, the
> router must drop the packet.
> >
> > BTW, I'm not convinced that using 6lowpan-nd between RPL routers even
> the right approach.  The current 6lowpan-nd spec is primarily focused on the
> host-router interface, which makes much more sense to me than applying
> the same protocol for router-router interfaces.
> >
> > --
> > Jonathan Hui
> >
> >> Ahh -- I only checked the roll mailing list archives... I don't
> >> really like the idea of keeping a neighbor cache for the downstream
> >> nodes, since it seems like it partially defeats the point of being
> >> need to require that there is a mapping from the global address to
> >> the LL address.  I think this will be mostly true, but seems like
> >> either RPL or 6lowpan should explicitly require it.  It's also a
> >> little strange, I think, to make an exception and say that "other
> >> addresses are off link, unless they're in a routing header."
> >>
> >>> That exact problem you mention was discussed on the 6LoWPAN mailing
> >>> list. If you follow the way the standards are written, it won't work
> >>> since global addresses are 'off-link' and you can never reach them!
> >>>
> >>> determine if a link is reachable or not. The point of assuming the
> >>> prefix is off-link is so you don't send NS for an unreachable node,
> >>> but instead send to the default router. But if you have NC entries,
> >>> you should consider the nodes on-link. See section 6.5.4 of 6lowpan-nd-
> 14.
> >>>
> >>> Another method is just to always assume a node which you have
> >>> received a downward source route to is reachable. Presumably RPL is
> >>> taking care of ensuring that node is actually registered through
> >>> you, so if you got a message which indicates the next-hop is that node, it
> should be reachable.
> >>>
> >>> HTH,
> >>>
> >>>  -Colin O'Flynn
> >>>
> >>>
> >>> From: [email-masked] [mailto:[email-masked]] On Behalf
> >>> Of Stephen Dawson-Haggerty
> >>> addresses in the routing header wold need to be link local?  It
> >>> seems more likely that RPL wanted them to be global, though?
> >>>
> >>> while you can construct a path of global addresses, I must be
> >>> missing how the intermediate hops can resolve the next hops of the
> addresses.
> >>>
> >>> long as the originating DAO also included a SLLA option; then the
> >>> path would be composed of only link-layer addresses. This seems a
> >>> little strange, though. I looked in 6.7.8  and 9 for guidance on
> >>> this, but am still confused...
> >>>
> >>> Thanks,
> >>> Steve
> >>>
> >>> --
> >>> stephen dawson-haggerty
> >>> uc berkeley wireless and embedded systems lab berkeley, ca 94720
> >> uc berkeley wireless and embedded systems lab berkeley, ca 94720

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 12 Nov 2010 11:35:05 +0800

> I can just directly translate them?  Let's face it, that's what I

(I can't answer the general question about RPL; the below is for 6LoWPAN only.)

There is some text on the router-to-router use of 6LoWPAN-ND in section 6.5.5 of draft-ietf-6lowpan-nd-14.txt.
The first paragraph is right to the point.

The "optional" approach in the second paragraph is probably not the right way to do things in a 6LoWPAN.
I don't think there is a way for a router in 6LoWPAN to send a packet to a neighboring router without revealing its L2 address, so I don't know what kind of network this functionality would be used for.  (But then the same is true for most uses of SLLAO, and some people continue to insist they should be used even in 6LoWPANs.)

I don't think one should ever use an algorithmic mapping of L3 to L2 addresses.
(It is fine as an implementation optimization -- don't store both if they match.  
But never assume they will.)

It is probably most useful to continue the ND part of discussion on the 6LoWPAN list; therefore I put ROLL on BCC.
(Context below for 6lowpan-only subscribers.)

Gruesse, Carsten