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 protected]>:
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 protected]]
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
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 protected] [mailto:[email protected]] 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 protected]]
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 protected]]
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 protected] [mailto:[email protected]] 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 protected]
________________________________
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.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
