Colin O'Flynn a écrit :
Hello,
What would it be used for and how?
The initial version of 6lowpan-nd added this idea in. See
http://tools.ietf.org/html/draft-hui-6lowpan-nd-00
You mean the "EUI-64 Identifier"? (it's not an address,
it's an
identifier). Is there such a thing as a 64bit MAC
The 802.15.4 Address (aka: MAC address) is guaranteed to be unique by IEEE
802.15.4-2006, at least everywhere within the PAN.
Nodes can use either 64-bit or 16-bit addressing.
Ok, and these are their MAC addresses.
When nodes power up they
are preprogrammed with a 64-bit IEEE MAC address they use to communicate.
They then may be assigned a shorter 16-bit address, which they can use to
save some bytes.
Ok - for this assignment, I don't think ND nor DHCP is necessary. Let
other MAC-based mechanism assign MAC addresses.
However the 64-bit address still remains valid, and the
node can be addresses by it.
Well this is wonderful. It's a great help for forming IP addresses and
ensure their uniqueness on the link and further.
Nor do you need to do this 16-bit addressing. You can keep just using 64-bit
addressing and skip assigning 16-bit addresses.
The idea is almost very node in the world could be programmed with a
different 64-bit MAC address. Hence you could bring two nodes together and
be sure there was no address collision. But with 16-bit MAC addressing you
are much more likely to get a collision, hence why the 16-bit addresses are
assigned dynamically by the network.
WEll, I agree, but who is the network who assigns these 16-bit
addresses? I guess it is a MAC-based mechanism(?) I don't think IP
mechanisms are needed to assign 16-bit MAC addresses. I mean I have
never seen an IP-based mechanism which assigns MAC addresses to nodes.
The closest I could think of is PPPv6, but that is "negotiation" of an
Interface ID, and not assignment of an IP address. PPP negotiates an
Interface ID, and then each node self-forms an IPv6 address from that
IID. The IPv6 address is not delivered to the end node by some server.
The network assures no two nodes are
assigned the same 16-bit address.
Do you call "network" some MAC-based and MAC-specific mechanism? I call
network an IP network. BEcause a network covers several types of MACs
whereas the "network" term used above seems to be a 802.15.4-only weave
of threads, if I can say so.
Sounds as forming an IPv6 link-local address in order to
do DHCP dance
prior to obtain a global IPv6 address.
Basically yes! The node has to do this anyway, as a node using 6LoWPAN will
bring up minimum of two valid unicast addresses:
Link-local based on 64-bit 802.15.4 Address
Global based on 64-bit 802.15.4 Address
If the node can use short addressing, you add two more:
Link-local based on 16-bit 802.15.4 Address
Global based on 16-bit 802.15.4 Address
Sorry can't follow this. Which prefix? Which PAN-ID?
I mean when the node joins a network, it knows that network's PAN-ID.
I suspect we have a terminology issue on the use of the term network...
Let's
say it's running on 0xBAAD. From the RS/RA it also knows the prefix, or
maybe even DHCP tells the node.
Ok, only the RA tells the prefix, DHCP doesn't, not currently.
Say it's dead:beef:cafe:0::/64 . Hence if
the node is assigned the following address:
Dead:Beef:cafe:0:b8ad:00ff:fe00:0005
>
The node can derive that that address becomes 6LoWPAN compressible if it has
the 802.15.4 short address '5'.
Sorry, which address becomes compressible? The IPv6 address? Or the
MAC address?
I am very reluctant to accept that an IP address is compressible.
Compress it and you no longer talk to anyone on the Internet. DO you
care connecting this to the Internet?
Could I ping a 6lowpan node without relying on converting various
addresses? The dumb network? Can I traceroute through a 6lowpan please
(increasing packet size, getting ICMP errors, etc.)?
Or will I see a 6lowpan subnet as some completely invisible network, no
traceroute, not Path MTU discovery, no reuse of routing protocols, all
within one single hop...
Do IP nodes care whether their MAC address (the short MAC address
included) is unique?
Well they have to be, as specified by IEEE 802.15.4.
Well, up to now, I haven't seen anywhere IP to care or to try to make
some MAC address unique...
If 802.15.4 wants their MAC addresses unique, then let 802.15.4 define
uniqueness mechanisms for MAC addresses.
All IP can do is - at most - signal to the user that some MAC address is
_probably_ (not even sure) not unique... and refuse to configure an IP
address based on it. But IP can't try to form a unique _MAC_ address.
How you decide they are
unique is part of the discussion.
I think IP shouldn't ever decide whether some MAC address is unique or
not. It could signal this to an operator, some risk of collision. But
it shouldn't make strong statements about uniqueness of some MAC
addresses. Simply it can't know and that is good. Keep layers separated.
Sure you could run a full 802.15.4 MAC,
followed by a full 6LoWPAN layer, followed by a full IPv6 stack. It would
work and make a nice block diagram for a paper.
Hmm... I sense the ironic referral to diagram on paper. But I think
more of the interface between ip6_output, dev_xmit and ndev_t struct...
it's there it stays there don't change it.
But you'd be wasting tons of code space and transmission time.
Hmm... or you could try to cross between layers... danger danger
danger... many times danger.... don't do that... it's a slippery slope,
people have tried it (cross-layer designs, link-layer indicators for
fast handovers, more), it's a rathole, what else can I say...
6LoWPAN deal with - is it IP? Is it MAC?
Both isn't it? I mean I think the whole point is that you need to 'break'
the nice clean divisions between layers when it comes to constrained
devices. After all:
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks"
Right. I am not sure DHCP mechanism assigning a MAC address should be
part of this.
Sorry, my statements may read too strong, and I may need to read more
than write... but the compressible IP addresses make not much sense to
me, sorry.
Yours,
Alex
Regards,
-Colin
-----Original Message-----
From: Alexandru Petrescu [mailto:[email protected]]
Sent: December 17, 2009 6:41 PM
To: Colin O'Flynn
Cc: 'Alexandru Petrescu'; [email protected]; [email protected]
Subject: Re: [6lowpan] Whiteboards
Colin O'Flynn a écrit :
Hello,
Excuse me, sorry, but are the other non-16bit addresses (48bit)
ever assigned by DHCP?
There's at least two options I know of for this:
#1 Add another 6lowpan-nd specific extension to DHCPv6 to add a
simple link-layer address option
Hmm... makes some sense, what would it look like? (rfc4944 defines such
an option for ND).
What would it be used for and how?
#2 Nodes could assign their own short addresses. Nodes power on and
autoconfigure a IPv6 address based on the 64-bit MAC address.
You mean the "EUI-64 Identifier"? (it's not an address, it's an
identifier). Is there such a thing as a 64bit MAC address?
With this they then do the DHCP dance, and get another address.
Sounds as forming an IPv6 link-local address in order to do DHCP dance
prior to obtain a global IPv6 address. (yes, in IPv4 one could say that
the node uses its MAC address while doing the DHCP initial dance and the
unspecified IPv4 address 0.0.0.0, but in IPv6 the unspecified addresses
(search " :: " in rfc3315) are not used DHCPv6 in the initial DHCPv6
dance, but the link-local addresses are).
Forming an IPv6 link-local address based on the 16bit short MAC address
- ok, using on RFC4944. And then do DAD on this IPv6 link-local
address, because the EUI-64 identifier based on the 16bit short MAC
address is not guaranteed global, has that g bit unset.
Nodes check if this address can be used to assign their own short
address.
Yes, usually they do DAD to make sure their IPv6 link-local address is
unique within that link.
But don't rely on the IP address uniqueness to conclude that the MAC
address corresponding to that IP address is unique.
Aka: the IPv6 address it assigns matches the prefix, the PAN-ID, etc.
Sorry can't follow this. Which prefix? Which PAN-ID?
Thus nodes 'figure out' if a certain short address will make their
IPv6 address compressible.
Do IP nodes care whether their MAC address (the short MAC address
included) is unique? I don't think so. I think IP nodes care only
whether their IP address is unique.
Also, it is completely unclear to me what kind of layer does 6LoWPAN
deal with - is it IP? Is it MAC?
Alex
Regards,
-Colin
-----Original Message----- From: [email protected]
[mailto:[email protected]] On Behalf Of Alexandru Petrescu
Sent: December 16, 2009 9:14 PM To: [email protected] Cc:
[email protected] Subject: Re: [6lowpan] Whiteboards
Daniel Gavelle a écrit :
I agree with the recent proposal to remove the mandatory
requirement for a whiteboard and duplicate address detection.
However, 16 bit 802.15.4 addresses are a very useful optimisation.
Assigning these in a standard way is important in the absence of a
whiteboard. One option may be to use DHCPv6. However, the DHCPv6
packet sizes are quite large and so some sort of DHCPv6 message
compression would be useful. Extended LowPANs would also be useful
in some applications.
If the whiteboard and DAD are removed, I would like the issues of
16 bit address assignment and extended LowPANs
Excuse me, sorry, but are the other non-16bit addresses (48bit) ever
assigned by DHCP?
I doubt IETF could spec a means to assign MAC addresses...
Thanks,
Alex
to still be addressed by an RFC
within the IETF 6LowPAN group, rather than having several different
non interoperable implementations.
_______________________________________________ 6lowpan mailing list
[email protected] https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
