Hamid Mukhtar a écrit :
On Wed, Feb 18, 2009 at 12:27 AM, Alexandru Petrescu
<[email protected]> wrote:
Hamid Mukhtar a écrit :
On Mon, Feb 16, 2009 at 11:51 PM, Alexandru Petrescu
<[email protected]> wrote:
[I cut ROLL from the distribution list, because it seems I post
too much on the ROLL list]
Thanks for the message. I mainly agree with you. I commented
on some of the text, below.
Eunsook "Eunah" Kim a écrit : [...]
Some high-level questions: -is there a requirement to
connect a 6LoWPAN network to the Internet?
Do you mean in terms of routing? Or a general view of
6LoWPAN? The birth of 6LoWPAN is to make the Low-power low
rate network (based on IEEE 802.15.4) look like an IPv6 link.
If you only meant routing, the reachability can be achieved
by mesh routing (or mesh switching in your comment below) or
route-over.
I don't know if it answers your question.
If a network running 6LoWPAN routing system (designed according
to 6lowpan-routing-requirements) is connected to the Internet
- will anything break?
-is the 6LoWPAN using addressing architecture and
longest-prefix match based routing as in the Internet?
Alex, I think RFC 4944 may help your curiosity of 6lowpan
fundamental.
Although the header compression format is updating in 6lowpan
now, you can find a basic needs of 6lowpan in the RFC. If I
shortly explain, an IPv6 Interface Identifier is obtained
from the 64-bit or 16-bit IEEE 802.15.4 address. The IPv6
link-local address for an IEEE 802.15.4 interface is formed
by appending the Interface Identifier to a certain prefix
(see Section 6 and Section 7 of RFC 4944). With regard to
routing, I understand the answer is 'yes' in the case of
route-over. Please kindly let me know if you already checked
the RFC and your intention from the question was different
from my answer. :)
Yes, thanks for posting rfc4944, I checked it.
Will the 6LoWPAN router use longest-prefix match (as IP
protocols do) or exact-match (as some VLAN switch protocols
do).
Will the 6LoWPAN addressing architecture be local to the
network, or integrated in the Internet.
RFC4944's HC1 supports both link-local and global addressing i.e.
all 128 bits can be carried inline or the elided suffix can be
derived from lower-layers.
The new HC scheme also supports both types of addressing.
I have no doubts the header compression scheme can accommodate both
global and link-local addresses.
By 'local' I meant also Unique Local IPv6 Unicast Addresses
(rfc4193).
The discussion was around how is the IPv6 addressing architecture
designed for a 6LoWPAN network.
For the 6LoWPAN side the IIDs are derived from the lower-layers.
Ok, but there should be freedom for manual configuration of global
addresses as well. Or for use of DHCPv6.
As per my understanding of 6LoWPAN, the Unique Local Addresses (ULAs)
are not utilised for local communication i.e. for local
communication the addresses are link-local addresses with prefix
elided.
Not sure why should the f80 prefix be elided.
However, for communication with nodes outside 6LoWPAN the 6LoWPAN
node's prefix can either be a global prefix or a ULA's prefix.
Well yes, that's a good principle, but rfc4944 seems to be saying only
/64 prefixes are valid (supposedly /56 are not ok). Which is not good.
I will comment separately for this RFC.
Alex
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
