Subject: Re: [6lowpan] nd-15 for isolated network

From: Z Z <[email-masked]>
Date: Mon, 7 Mar 2011 14:23:05 -0800 (PST)

Peter,
  I think there is some confusion.

If you are sending packets from one node to another within the PAN you do not necessarily have to send the packet to the 6lbr.  If the routing protocol has a mechanism to route point to point or if you are using some sort of layer 2.5 (mesh under) forwarding protocol then packets should be deliverable directly between the nodes based on the MAC address which is the IID.

Only if the 6lbr is the only node with knowledge of network topology would you have to send packets to the border router.

Certainly for next hop neighbors you can use the IID (which is device's short or long address mac address) as the dest address in the 15.4 header and deliver the packet directly.

For nodes two hops or more away you would use the routing protocol to deliver the packet to the next IP hop toward the destination node. With mesh under you would use the mesh forwarding mechanism to send the packet to the destination via layer 2.5 forwarding (only one ip hop away).

On Fri, 2011-03-04 at 10:23 +0100, Stok, Peter van der wrote: 
Dear Robert, Colin,
> 
>  
> 
> Thanks for your comments.
> 
> Let me motivate my interest in looking at the routing issues.
> 
>  
> 
> In the applications I am involved, the bulk (say >90%) will be messages to one hop neighbors and possibly two-hop neighbors. Actually, I expect that the quality of the link between source and destination can be better than the link quality between source and 6LBR. (people may argue that this is bad network engineering, but given costs and knowledge today it looks a very probable situation)
> 
> What worries me is that for a communication between a source and a destination with the same prefix (same LOWPAN) the packets first need to be sent to a 6LBR (or 6LR) before they are routed to the destination, although source and destination are only one hop away.
> 
> In my opinion removing this technically superfluous overhead is important.
> 
>  
> 
> Greetings,
> 
>  
> 
> peter
> 
>  
> 
> From: Robert Assimiti [mailto:[email-masked]] 
> Sent: Thursday 3 March 2011 19:43
> To: Colin O'Flynn; Stok, Peter van der; '6lowpan 6lowpan'
> Subject: RE: [6lowpan] nd-15 for isolated network
> 
> 
>  
> 
> It is good to finally see efforts (following lengthy discussions) being made for the inexorable extinction (following a long logical effort) of the mesh-under paradigm, a vestige of proprietary routing blunders……   
> 
>  
> 
> Robert Assimiti
> 
> Office: [678]-202-6859
> 
> Mobile: [404]-578-0205
> 
> [email-masked]
> 
> 
>  
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Colin O'Flynn
> Sent: Thursday, March 03, 2011 1:35 PM
> To: 'Stok, Peter van der'; '6lowpan 6lowpan'
> Subject: Re: [6lowpan] nd-15 for isolated network
> 
> 
>  
> 
> Hi Peter,
> 
>  
> 
> As a disclaimer: I’m not an author of the document, they would probably be better to give a more complete answer.
> 
>  
> 
> I believe your conclusions are entirely correct, as I had reached the same myself. Basically for mesh-under you are limited to using the link-local addresses based on EUI-64, as otherwise a 6LN cannot perform address resolution on another 6LN.
> 
>  
> 
> Regards,
> 
>  
> 
>   -Colin O’Flynn
> 
>  
> 
>  
> 
> From: Stok, Peter van der [mailto:[email-masked]] 
> Sent: March 3, 2011 2:26 PM
> To: Colin O'Flynn; '6lowpan 6lowpan'
> Subject: RE: [6lowpan] nd-15 for isolated network
> 
> 
>  
> 
> Hi Colin,
> 
>  
> 
> Thanks for the clarifications.
> 
>  
> 
> Sending packets to destinations using mesh-under still remains a bit vague to me.
> 
> Given a LOWPAN with a 6LBR connected to DHCP, DNS, etc,  nodes will use the prefix of the LOWPAN in the IP address.
> 
> According to 5.6 a packet with a non link-local IP address is assumed to be off-link and sent to 6LBR.
> 
> However, when the prefix of the destination is the same as the prefix of the source, source and destination are hosts in the same LOWPAN. In this case the packet can be sent over the link with mesh-under routing to the destination.
> 
> In my view sending the packet to 6LBR contradicts the mesh-under concept, because the packet is first routed to 6LBR.
> 
> To send the packet without passing via the 6LBR, the source needs the Link address of the destination, but this link address is only available to the 6LBR.
> 
> A solution is configuring every host as a 6LR, but that defeats the purpose of the 6LR.
> 
>  
> 
> What have I missed?
> 
>  
> 
> If the above reasoning is correct, a mechanism is lacking in which a host can ask the 6LBR the link address of a given IP address with the LOWPAN prefix to allow proper mesh-under routing.
> 
>  
> 
> Looking forward to your reaction.
> 
>  
> 
> Peter
> 
>  
> 
>  
> 
> From: Colin O'Flynn [mailto:[email-masked]] 
> Sent: Tuesday 1 March 2011 14:03
> To: Stok, Peter van der; '6lowpan 6lowpan'
> Subject: RE: [6lowpan] nd-15 for isolated network
> 
> 
>  
> 
> Hi Peter,
> 
>  
> 
> I think you are basically correct, with some additional constraints or clarifications:
> 
>  
> 
> The 6LN NC will have entries for routers it has registered with, so it’s not always empty. 
> 
>  
> 
> Section 5.6 allows you to use the MAC extraction only if the link-local address is EUI-64 based. This basically means if the U/L bit is set, indicating the address in question was generated from a known-unique MAC address. 802.15.4 for example has 16-bit addresses you could be using instead.
> 
>  
> 
> I think most networks would have the 6LBR, although obviously if you have a very specific situation as you outlined you could skip it. The 6LBR at minimum would manage the compression context (if required) and serve as an alternative way to reach a node by a default route. From a maintenance/deployment/management perspective the 6LBR is an easy way to see what nodes are alive on your network too by checking its tables.
> 
>  
> 
> Regards,
> 
>  
> 
>   -Colin
> 
>  
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Stok, Peter van der
> Sent: March 1, 2011 1:21 PM
> To: 6lowpan 6lowpan
> Subject: [6lowpan] nd-15 for isolated network
> 
> 
>  
> 
> Dear authors,
> 
>  
> 
> The document looks rather complete and comprehensive.
> 
>  
> 
> There are a few questions:
> 
> Do I understand correctly that contrary to RFC 4861, the neighbor cache is always empty in 6LN. If true, this remark may be added to Registration term of section 2.
> 
> From that do I deduce correctly that access to the link for link-local addresses (LLA) involves extracting the MAC address from the LLA.
> 
>  
> 
> MUST a 6LBR be present in an isolated LOWPAN? (6LBR text in section 2 seems to imply this)
> 
> Assuming an isolated LOWPAN without 6LR or 6LBR, then there will be no answer to the RS message, but the node can continue sending messages to LLA, where the MAC address is again extracted from the LLA. Is that correct?
> 
>  
> 
> Peter
> 
>  
> 
> Peter van der Stok
> 
> Philips Research Laboratories Eindhoven
> 
> High Tech Campus                                                          HTC 34 (WB) 1-067
> 
> 5656 AA Eindhoven                                                      The Netherlands
> 
> phone +31 40 2749657                                                Fax: + 31 40 2746321
> 
> mailto: [email-masked]
> 
>  
> 
>  
> 
> 
> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
> 
>  
> 
> 
> This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments.
> 
> 
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
>

---

From: "Colin O'Flynn" <[email-masked]>
Date: Tue, 8 Mar 2011 08:06:29 +0100

Hello,

You cannot use an IP address based on the short address and be *assured* you have mapping between the L2 & IPv6 address.

You can only be assured of this with EUI-64 (e.g.: long address) based devices.

Does anything stop a device from using an address of e.g. fe80::ff:fe00:7463 with a different short address? The long address is 'protected' against this because of the U/L bit, a node couldn't use an address that looks EUI-64 based because it can't guarantee universal uniqueness unless it is actually EUI-64 based.

For this reason 6lowpan-nd-15 seems to specify address resolution is only skipped for EUI-64 based IPv6 addresses.

Peter's other problem is that if you wish to use a global address, you do always need to send to a 6LR, even if the destination is actually on-link to you. I think it is just 'not possible' based solely on the current draft.

Regards,

  -Colin

-----Original Message-----
From: Z Z [mailto:[email-masked]] 
Sent: March 7, 2011 11:23 PM
To: Peter van derStok
Cc: Robert Assimiti; Colin O'Flynn; '6lowpan 6lowpan'
Subject: Re: [6lowpan] nd-15 for isolated network

Peter,

---

From: Z Z <[email-masked]>
Date: Mon, 7 Mar 2011 23:26:34 -0800 (PST)

--- On Mon, 3/7/11, Colin O'Flynn <[email-masked]> wrote:

> From: Colin O'Flynn <[email-masked]>
> To: "'Z Z'" <[email-masked]>, "'Peter van derStok'" <[email-masked]>
> Cc: "'Robert Assimiti'" <[email-masked]>, "'6lowpan 6lowpan'" <[email-masked]>
> Date: Monday, March 7, 2011, 11:06 PM
> Hello,
> 
> You cannot use an IP address based on the short address and
> be *assured* you have mapping between the L2 & IPv6
> address.
> 

Really?  What if the addresses are handed out with DHCP such that the IPv6 IID is the devices short address or manual configuration?  I would think that there are other ways to agree on the mapping of L2 and IPv6 IID.

> 
> Does anything stop a device from using an address of e.g.
> fe80::ff:fe00:7463 with a different short address? The long
> address is 'protected' against this because of the U/L bit,
> a node couldn't use an address that looks EUI-64 based
> because it can't guarantee universal uniqueness unless it is
> actually EUI-64 based.
> 
> For this reason 6lowpan-nd-15 seems to specify address
> resolution is only skipped for EUI-64 based IPv6 addresses.

I guess I have to re-read this.  This seems wrong.

> 
> Peter's other problem is that if you wish to use a global
> address, you do always need to send to a 6LR, even if the
> destination is actually on-link to you. I think it is just
> 'not possible' based solely on the current draft.

I don't understand this Colin.  If I'm sending a packet to a global address and that address is on-link then my network prefix will be the same and I should be able to then use the IID as the mac address to address the packet.

Peter was saying he thought you always had to send the packet to the 6LBR which shouldn't be the case.

If it is a neighbor -> send it directly.

If I'm using a mesh under then there are no 6LRs -> send it to the device using the mac address/IID.

If I'm using route over -> send it to the 6LR the routing protocol specifies.  The routing protocol ought to be able to get the packet to destination without having to send it to the 6LBR.

Do I have this wrong?

> If you are sending packets from one node to another within
> the PAN you do not necessarily have to send the packet to
> the 6lbr.  If the routing protocol has a mechanism to
> route point to point or if you are using some sort of layer
> 2.5 (mesh under) forwarding protocol then packets should be
> deliverable directly between the nodes based on the MAC
> address which is the IID.
> 
> Only if the 6lbr is the only node with knowledge of network
> topology would you have to send packets to the border
> router.
> 
> Certainly for next hop neighbors you can use the IID (which
> is device's short or long address mac address) as the dest
> address in the 15.4 header and deliver the packet directly.
> 
> For nodes two hops or more away you would use the routing
> protocol to deliver the packet to the next IP hop toward the
> destination node. With mesh under you would use the mesh
> forwarding mechanism to send the packet to the destination
> via layer 2.5 forwarding (only one ip hop away).
> 
> 
> 
> 
> 
> > In the applications I am involved, the bulk (say
> >90%) will be messages to one hop neighbors and possibly
> two-hop neighbors. Actually, I expect that the quality of
> the link between source and destination can be better than
> the link quality between source and 6LBR. (people may argue
> that this is bad network engineering, but given costs and
> knowledge today it looks a very probable situation)
> > 
> > What worries me is that for a communication between a
> source and a destination with the same prefix (same LOWPAN)
> the packets first need to be sent to a 6LBR (or 6LR) before
> they are routed to the destination, although source and
> destination are only one hop away.
> > 
> > It is good to finally see efforts (following lengthy
> discussions) being made for the inexorable extinction
> (following a long logical effort) of the mesh-under
> paradigm, a vestige of proprietary routing
> blunders……   
> > 
> >  
> > 
> > Robert Assimiti
> > 
> > Office: [678]-202-6859
> > 
> > Mobile: [404]-578-0205
> > 
> > From: [email-masked]
> [mailto:[email-masked]]
> On Behalf Of Colin O'Flynn
> > As a disclaimer: I’m not an author of the document,
> they would probably be better to give a more complete
> answer.
> > 
> >  
> > 
> > I believe your conclusions are entirely correct, as I
> had reached the same myself. Basically for mesh-under you
> are limited to using the link-local addresses based on
> EUI-64, as otherwise a 6LN cannot perform address resolution
> on another 6LN.
> > 
> >  
> > 
> > Regards,
> > 
> >  
> > 
> >   -Colin O’Flynn
> > 
> >  
> > 
> >  
> > 
> > Given a LOWPAN with a 6LBR connected to DHCP, DNS,
> etc,  nodes will use the prefix of the LOWPAN in the IP
> address.
> > 
> > According to 5.6 a packet with a non link-local IP
> address is assumed to be off-link and sent to 6LBR.
> > 
> > However, when the prefix of the destination is the
> same as the prefix of the source, source and destination are
> hosts in the same LOWPAN. In this case the packet can be
> sent over the link with mesh-under routing to the
> destination.
> > 
> > In my view sending the packet to 6LBR contradicts the
> mesh-under concept, because the packet is first routed to
> 6LBR.
> > 
> > To send the packet without passing via the 6LBR, the
> source needs the Link address of the destination, but this
> link address is only available to the 6LBR.
> > 
> > If the above reasoning is correct, a mechanism is
> lacking in which a host can ask the 6LBR the link address of
> a given IP address with the LOWPAN prefix to allow proper
> mesh-under routing.
> > 
> >  
> > 
> > I think you are basically correct, with some
> additional constraints or clarifications:
> > 
> >  
> > 
> > The 6LN NC will have entries for routers it has
> registered with, so it’s not always empty. 
> > 
> >  
> > 
> > Section 5.6 allows you to use the MAC extraction only
> if the link-local address is EUI-64 based. This basically
> means if the U/L bit is set, indicating the address in
> question was generated from a known-unique MAC address.
> 802.15.4 for example has 16-bit addresses you could be using
> instead.
> > 
> >  
> > 
> > I think most networks would have the 6LBR, although
> obviously if you have a very specific situation as you
> outlined you could skip it. The 6LBR at minimum would manage
> the compression context (if required) and serve as an
> alternative way to reach a node by a default route. From a
> maintenance/deployment/management perspective the 6LBR is an
> easy way to see what nodes are alive on your network too by
> checking its tables.
> > 
> >  
> > 
> > Regards,
> > 
> >  
> > 
> >   -Colin
> > 
> >  
> > 
> > From: [email-masked]
> [mailto:[email-masked]]
> On Behalf Of Stok, Peter van der
> > Do I understand correctly that contrary to RFC 4861,
> the neighbor cache is always empty in 6LN. If true, this
> remark may be added to Registration term of section 2.
> > 
> > From that do I deduce correctly that access to the
> link for link-local addresses (LLA) involves extracting the
> MAC address from the LLA.
> > 
> >  
> > 
> > Assuming an isolated LOWPAN without 6LR or 6LBR, then
> there will be no answer to the RS message, but the node can
> continue sending messages to LLA, where the MAC address is
> again extracted from the LLA. Is that correct?
> > 
> >  
> > 
> > Peter
> > 
> >  
> > 
> > Peter van der Stok
> > 
> > High Tech Campus         
>                 HTC
> 34 (WB) 1-067
> > 5656 AA Eindhoven         
>             The Netherlands
> > phone +31 40 2749657         
>       Fax: + 31 40 2746321
> > The information contained in this message may be
> confidential and legally protected under applicable law. The
> message is intended solely for the addressee(s). If you are
> not the intended recipient, you are hereby notified that any
> use, forwarding, dissemination, or reproduction of this
> message is strictly prohibited and may be unlawful. If you
> are not the intended recipient, please contact the sender by
> return e-mail and destroy all copies of the original
> message.
> > 
> >  
> > 
> > 
> > This e-mail (including any attachments to it) is
> confidential, proprietary, legally privileged, subject to
> copyright and is sent for the personal attention of the
> intended recipient only. If you have received this e-mail in
> error, please reply to advise us immediately, delete it and
> destroy any printed copies of it. You are notified that
> reading, disclosing, copying, distributing or taking any
> action in reliance on the contents of this information is
> strictly prohibited. No employee is authorized to conclude
> any binding agreement on behalf of NIVIS LLC with another
> party by e-mail without express written confirmation by an
> officer of the company. Although we have taken reasonable
> precautions to ensure no viruses are present in this e-mail,
> we cannot accept responsibility for any loss or damage
> arising from the viruses in this e-mail or attachments.
> > 
> >

---

From: "Colin O'Flynn" <[email-masked]>
Date: Tue, 8 Mar 2011 18:11:58 +0100

Hello,

First off, I want to stress that I'm attempting to go 'by the rules' of what is written in the relevant standards. I'm not advocating this is the necessarily the sane way. 

> Really?  What if the addresses are handed out with DHCP such 
> that the IPv6 IID is the devices short address

My point is that you are not assured that unless you control the entire network. Nothing stops a host from using an address that 'looks like' it maps to a 16-bit address when it doesn't. At least nothing I've found.

> I don't understand this Colin.  If I'm sending a packet to a 
> global address and that address is on-link then my network

Your understanding is correct in a 'sane' manner (I think), as I agree that is how it should work. But as I understand the standard that is not how it is written to work.

> always had to send the packet to the 6LBR which shouldn't be 
> the case.

Sorry I also said 'send to 6LBR' when I meant just 'send to 6LR'. 

Regards,

  -Colin

-----Original Message-----
From: Z Z [mailto:[email-masked]] 
Sent: March 8, 2011 8:27 AM
To: 'Peter van derStok'; Colin O'Flynn
Cc: 'Robert Assimiti'; '6lowpan 6lowpan'
Subject: RE: [6lowpan] nd-15 for isolated network

Do I have this wrong?