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.
(Tomorrow I will follow up with another assumption, but please let's
beat this horse for today.)
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
