On Oct 14, 2009, at 1:30 , Carsten Bormann wrote:
I'll try to untangle this thread
I think we need to revisit the Dublin assumptions, one by one.
So here is assumption number one:
(1) Address resolution is a waste of energy
IPv4 needed address resolution for Ethernet to map a 32-bit address
space, n<32 bits of which were a host number within a network, to a
48-bit MAC address. IPv6 continued to follow that model for
Ethernet even if that strong need no longer was there, with a likely
default mapping but a possibility for manual assignment (or DHCP),
so address resolution (AR) was still needed.
In 6lowpans, the congruence of MAC and IP addresses is a
prerequisite to efficient header compression.
Also, we actually have a way to assign *MAC addresses* the way DHCP
did this for *IP addresses*: 16-bit addresses are not owned by a
device but can be assigned (using NR/NC in 6lowpan-nd-06), so if
there is a need to assign a functional IP address to a device this
can be done by assigning it the equivalent 16-bit MAC address.
In 6lowpans, address resolution requires the establishment (using
energy-wasting packets) and maintenance (using precious memory) of
state that no longer serves a useful purpose.
Using anything but the default mapping causes additional header
overhead, wasting energy.
The need for assigned addresses can easily be covered by assigning
16-bit addresses.
Hence, the decision was to get rid of address resolution and
hardwire the (IID part of the) mapping.
I would like to hear arguments why the above reasoning was incorrect.
[Editor hat off]
In my opinion this assumption (and reasoning) is still valid (I
know... this was supposed to be for arguments against...). Let me add
in a commercial viewpoint.
I know of no commercially deployed 6LoWPAN networks where address
resolution is being performed. We have experience working with 6LoWPAN
on a wide range of link-layer technologies and an even wider range of
applications - and AR has not been a requirement so far.
If there is no real (not imaginary) need for it, then it is a waste of
energy. And yes, having to be able to send and process NS/NA messages,
LLOAs as well as the caches involved does take both ROM and RAM.
I do agree with Jonathan that ideally it would be great to know if an
IID has been derived from a link-layer address - but that is a
shortcoming of IPv6 in general...
Zach
(Tomorrow I will follow up with another assumption, but please let's
beat this horse for today.)
Argh, how many days are we going to be at this? ;-(
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
--
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297
Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND
This e-mail and all attached material are confidential and may contain
legally privileged information. If you are not the intended recipient,
please contact the sender and delete the e-mail from your system
without producing, distributing or retaining copies thereof.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
