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

From: "Stok, Peter van der" <[email-masked]>
Date: Tue, 1 Mar 2011 13:20:35 +0100

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.

---

From: "Colin O'Flynn" <[email-masked]>
Date: Tue, 1 Mar 2011 14:03:05 +0100

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,

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

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.

---

From: "Stok, Peter van der" <[email-masked]>
Date: Thu, 3 Mar 2011 14:26:20 +0100

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,

Peter

Peter van der Stok

---

From: "Colin O'Flynn" <[email-masked]>
Date: Thu, 3 Mar 2011 19:35:22 +0100

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,

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.

Peter

Hi Peter,

Regards,

  -Colin

Dear authors,

Peter

Peter van der Stok

High Tech Campus
HTC 34 (WB) 1-067

5656 AA Eindhoven                                                      The
Netherlands

 

  _____

---

From: Robert Assimiti <[email-masked]>
Date: Thu, 3 Mar 2011 13:42:51 -0500

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]<mailto:[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

Hi Colin,

What have I missed?

Peter

Hi Peter,

Regards,

  -Colin

Dear authors,

Peter

Peter van der Stok

________________________________
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: "Stok, Peter van der" <[email-masked]>
Date: Fri, 4 Mar 2011 10:23:43 +0100

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

Robert Assimiti
Office: [678]-202-6859
Mobile: [404]-578-0205

Hi Peter,

Regards,

  -Colin O'Flynn

Hi Colin,

What have I missed?

Peter

Hi Peter,

Regards,

  -Colin

Dear authors,

Peter

Peter van der Stok

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 4 Mar 2011 10:40:36 +0100

Hi Peter and Colin
 
> 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.

I do not see where this conclusion came from?

Provided that the mesh-under solution can derive the (short) link-layer
address from the IP address, I see no particular reason why a node
cannot reach other nodes
in the same subnet via routable addresses? (Yes, this somewhat rules out
DHCP but works nicely along the lines of the -HC draft.

If -ND seems to say otherwise, I suppose this just has to be clarified?

- Anders

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Colin O'Flynn
	Sent: Thursday, March 03, 2011 19:35
	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,

	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.

	Peter

	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,

	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

	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.

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 4 Mar 2011 10:43:22 +0100

Hi Peter

>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.

I fully agree. That is never going to work in home control and building
automation.

This is exactly the concerns that caused us to start looking at RPL-P2P
on the roll group.

Sounds like we should get together with Zach et al on this issue.

- Anders

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stok, Peter van der
	Sent: Friday, March 04, 2011 10:24
	To: Robert Assimiti; Colin O'Flynn; '6lowpan 6lowpan'
	Subject: Re: [6lowpan] nd-15 for isolated network

	Dear Robert, Colin,

	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

	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]

	Hi Peter,

	Regards,

	  -Colin O'Flynn

	Hi Colin,

	What have I missed?

	Peter

	Hi Peter,

	Regards,

	  -Colin

	Dear authors,

	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

	 

	

	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: "Stok, Peter van der" <[email-masked]>
Date: Fri, 4 Mar 2011 12:14:20 +0100

Hi Anders,

The point is that DHCP can assign addresses which do not necessarily map in a straightforward way to the link address.
I don't want to exclude that possibility.
And yes, ND says that only link-local addresses can be used for direct access to link.
That makes two points of concern.

Greetings,

peter

From: Anders Brandt [mailto:[email-masked]]
Sent: Friday 4 March 2011 10:41
To: Colin O'Flynn; Stok, Peter van der; 6lowpan 6lowpan
Subject: RE: [6lowpan] nd-15 for isolated network

Hi Peter and Colin

I do not see where this conclusion came from?
Provided that the mesh-under solution can derive the (short) link-layer address from the IP address, I see no particular reason why a node cannot reach other nodes
in the same subnet via routable addresses? (Yes, this somewhat rules out DHCP but works nicely along the lines of the -HC draft.

- Anders

Regards,

  -Colin O'Flynn

Hi Colin,

What have I missed?

Peter

Hi Peter,

Regards,

  -Colin

Dear authors,

Peter

Peter van der Stok

---

From: [email-masked]
Date: Sat, 05 Mar 2011 14:54:34 -0500

Hello,

I'm on the road right now so have sporatic access to email! Anyway:

The link-local address based on EUI-64 can always be mapped directly  
to a L2 address. This is a special case, no other address can be  
mapped that way according to the spec.

You can 'guess' that an address looks like it is based on e.g.: an  
802.15.4 short address, but you can't actually be sure like you can  
with an EUI-64 based address.

Regards,

   -Colin

Quoting "Stok, Peter van der" <[email-masked]>:

> Hi Anders,
>
> The point is that DHCP can assign addresses which do not necessarily  
> map in a straightforward way to the link address.
>> 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.
>
> Provided that the mesh-under solution can derive the (short)  
> link-layer address from the IP address, I see no particular reason  
> why a node cannot reach other nodes
> in the same subnet via routable addresses? (Yes, this somewhat rules  
> out DHCP but works nicely along the lines of the -HC draft.
>
> 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.
> 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.
>
> 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
>
> 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.
> 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
> 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.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 8 Mar 2011 14:02:43 +0100

Hi:

<Colin>
The link-local address based on EUI-64 can always be mapped directly to
a L2 address. This is a special case, no other address can be mapped
that way according to the spec.
</Colin>

<Pascal>  I'm sure you mean addresses that are formed using a link-layer
address, not just Link Local. More in section 5.7
 </Pascal>

<Peter> 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) 
</Peter>

<Pascal>  What's more troubling for Peter's point about 1-hop neighbors
is in 6.1:
"
   A router MUST NOT set the 'L' (on-link) flag in the Prefix
   Information options, since that might trigger hosts to send multicast
   Neighbor Solicitations.
"
This text prevents a node from checking whether another node is visible
at L2. I think that this recent addition is a mistake. Though clearly
costly on a mesh under, this could be reasonable in some route over
cases, as long as the multicast is not forwarded. 

What this spec should mandate is whether and how to enforce the
registration for a given prefix as opposed to classical ND. The 'L' bit
does not say that. We need a new bit.
 </Pascal>

Cheers,

Pascal

---

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

Hello,

Yes of course! I guess though what I really meant is that according to the
draft, save for the 6LR(s) address(es), a link-local address based on the
EUI-64 is the only address a 6LN could send to directly.

This is a limitation of the 6lowpan-nd draft, if I am reading this
correctly. I'm not trying to argue for or against such a limitation, just
everyone should be aware of it, and if this is not acceptable look for a
solution.

It would be good to have some confirmation from the authors to ensure I'm
not just being stupid, something we can never rule out ;-)

Regards,

  -Colin O'Flynn

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: March 8, 2011 2:03 PM
To: [email-masked]; Stok, Peter van der
Cc: 6lowpan 6lowpan
Subject: RE: [6lowpan] nd-15 for isolated network

Hi:

<Colin>

Cheers,

Pascal

---

From: "Stok, Peter van der" <[email-masked]>
Date: Wed, 9 Mar 2011 08:39:36 +0100

Thanks Colin for your reaction, given your summary I like to show my support.

"It would be good to have some confirmation from the authors to ensure I'm
not just being stupid, something we can never rule out ;-)"
--I feel exactly the same.
<<

"This is a limitation of the 6lowpan-nd draft, if I am reading this
correctly. I'm not trying to argue for or against such a limitation, just
everyone should be aware of it, and if this is not acceptable look for a
solution."
-- I would like to see a solution as it generates unwanted overhead
<<

peter

-----Original Message-----
From: Colin O'Flynn [mailto:[email-masked]]
Sent: Tuesday 8 March 2011 18:20
To: 'Pascal Thubert (pthubert)'; Stok, Peter van der
Cc: '6lowpan 6lowpan'
Subject: RE: [6lowpan] nd-15 for isolated network

Hello,

Regards,

  -Colin O'Flynn

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: March 8, 2011 2:03 PM
To: [email-masked]; Stok, Peter van der
Cc: 6lowpan 6lowpan
Subject: RE: [6lowpan] nd-15 for isolated network

Hi:

<Colin>

Cheers,

Pascal

---

From: "Colin O'Flynn" <[email-masked]>
Date: Thu, 10 Mar 2011 08:09:09 +0100

Just as another point: nothing stops another protocol (the mesh protocol,
etc) from either populating the neighbor table, or defining additional
address resolution strategies for 6LN.

So I don't think 6lowpan-nd is broken. It just may not provide all the
features some are expecting, but doesn't stop a future extension or protocol
from providing those features.

Regards,

  -Colin

-----Original Message-----
From: Stok, Peter van der [mailto:[email-masked]] 
Sent: March 9, 2011 8:40 AM
To: Colin O'Flynn; 'Pascal Thubert (pthubert)'
Cc: '6lowpan 6lowpan'
Subject: RE: [6lowpan] nd-15 for isolated network

Thanks Colin for your reaction, given your summary I like to show my
support.

peter

-----Original Message-----
From: Colin O'Flynn [mailto:[email-masked]]
Sent: Tuesday 8 March 2011 18:20
To: 'Pascal Thubert (pthubert)'; Stok, Peter van der
Cc: '6lowpan 6lowpan'
Subject: RE: [6lowpan] nd-15 for isolated network

Hello,

Regards,

  -Colin O'Flynn

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: March 8, 2011 2:03 PM
To: [email-masked]; Stok, Peter van der
Cc: 6lowpan 6lowpan
Subject: RE: [6lowpan] nd-15 for isolated network

Hi:

<Colin>

Cheers,

Pascal

---

From: "Stok, Peter van der" <[email-masked]>
Date: Thu, 10 Mar 2011 09:59:39 +0100

Hi Colin,

Populating the neighbor table form a mesh protocol sounds to me as a last resort.
The neighbor table is very much the responsibility of the nd protocol.
Other mesh protocols, possibly developed by other standardization groups, changing the contents of the neighbor table are subject to (according to me) unwanted cross dependencies.

Greetings,

peter

-----Original Message-----
From: Colin O'Flynn [mailto:[email-masked]]
Sent: Thursday 10 March 2011 8:09
To: Stok, Peter van der; 'Pascal Thubert (pthubert)'
Cc: '6lowpan 6lowpan'
Subject: RE: [6lowpan] nd-15 for isolated network

Regards,

  -Colin

-----Original Message-----
From: Stok, Peter van der [mailto:[email-masked]]
Sent: March 9, 2011 8:40 AM
To: Colin O'Flynn; 'Pascal Thubert (pthubert)'
Cc: '6lowpan 6lowpan'
Subject: RE: [6lowpan] nd-15 for isolated network

peter

-----Original Message-----
From: Colin O'Flynn [mailto:[email-masked]]
Sent: Tuesday 8 March 2011 18:20
To: 'Pascal Thubert (pthubert)'; Stok, Peter van der
Cc: '6lowpan 6lowpan'
Subject: RE: [6lowpan] nd-15 for isolated network

Hello,

Regards,

  -Colin O'Flynn

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: March 8, 2011 2:03 PM
To: [email-masked]; Stok, Peter van der
Cc: 6lowpan 6lowpan
Subject: RE: [6lowpan] nd-15 for isolated network

Hi:

<Colin>

Cheers,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 10 Mar 2011 11:37:48 +0100

Hi Colin

I think that what you're getting at is that an external operation could
be used to determine whether an address is on-link. Once an address is
determined to be on-link, RFC 4861 allows to look it up, even if the PIO
indicates that the prefix is not known to be on-link ('L' bit is reset).

RFC 4861 :     
'
   Prefix Information options that have the "on-link" (L) flag set
   indicate a prefix identifying a range of addresses that should be
   considered on-link.  Note, however, that a Prefix Information option
   with the on-link flag set to zero conveys no information concerning
   on-link determination and MUST NOT be interpreted to mean that
   addresses covered by the prefix are off-link.
'
I'm still not in agreement with:

ND-15
 '
   A router MUST NOT set the 'L' (on-link) flag in the Prefix
   Information options, since that might trigger hosts to send multicast
   Neighbor Solicitations.
'
Which amongst other things indicates that multicast NS is always evil,
and thus seems to prohibit looking up an address that is determined to
be on link. When the link is 1 radio hop (route over), the operation is
not that evil, and is in fact a very good idea if there is an external
indication that the target is actually on-link.

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

> Sent: Thursday, March 10, 2011 8:09 AM
> To: 'Stok, Peter van der'; Pascal Thubert (pthubert)
> Cc: '6lowpan 6lowpan'
address
> resolution strategies for 6LN.
> 
features
> some are expecting, but doesn't stop a future extension or protocol
from
> providing those features.
> 
> Regards,
> 
>   -Colin
> 
correctly. I'm
> not trying to argue for or against such a limitation, just everyone
should be
> aware of it, and if this is not acceptable look for a solution."
> -- I would like to see a solution as it generates unwanted overhead <<
> 
> peter
> 
> address, not just Link Local. More in section 5.7  </Pascal>
> 
correctly. I'm
> not trying to argue for or against such a limitation, just everyone
should be
> aware of it, and if this is not acceptable look for a solution.
> 
to a L2
> address. This is a special case, no other address can be mapped that
way
> according to the spec.
> address, not just Link Local. More in section 5.7  </Pascal>
> 
> 
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) </Peter>
> 
> 
> <Pascal>  What's more troubling for Peter's point about 1-hop
neighbors is in
> 6.1:
> This text prevents a node from checking whether another node is
visible at
> L2. I think that this recent addition is a mistake. Though clearly
costly on a
> mesh under, this could be reasonable in some route over cases, as long
as
> the multicast is not forwarded.
> 
> registration for a given prefix as opposed to classical ND. The 'L'
bit does not
> say that. We need a new bit.
>  </Pascal>
> 
> Cheers,
> 
> Pascal
> 
> 
legally
> 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.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Mar 2011 04:25:32 -0700

On 3/3/11 5:26 AM, Stok, Peter van der wrote:

> host can ask the 6LBR the link address of a given IP address with the
> LOWPAN prefix to allow proper mesh-under routing.

For mesh-under 6lowpan-nd allows Redirect messages as a way for a router 
to inform a host about the L2 address of a host that is on the same 
(mesh-under) link. (For those not familiar with IPv6, unlike IPv4, the 
redirect message includes the L2 address.)

    Erik