On Oct 13, 2009, at 3:30 PM, Carsten Bormann wrote:
(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.
Being a part of the discussion in Dublin, I wouldn't say that the
above reasoning was incorrect, just incomplete in thinking through the
architectural implications. Playing devil's advocate here, some
points on the flip side:
- This limits IIDs to one 64-bit and one 16-bit value at a time, is
this OK? It limits the number of addresses. It limits the ability to
assign multiple addresses from different pools possibly from different
administrative domains. It limits games one might play with
addressing for various purposes.
- The improvement in header compression is limited to the first and
last IP hops. Assuming 14-byte prefix is compressible, the added cost
is 2 bytes for each address (a total of 4 bytes) overhead when both
IIDs do not map directly to their respective link addresses. When
communicating outside the network, one of the addresses is either
always compressible or not, so the compression argument is even less.
I agree with the primary concern about energy of sending extra packets
to resolve and address. This is not a code complexity issue. I would
prefer a mechanism to know if a link address can be computed from an
IID, if not then perform AR. But I'm not sure there is a feasible way
to get there. There are ways to reduce the frequency by including
LLAOs wherever possible, but doesn't eliminate the need for NS/NA in
the most general case.
--
Jonathan Hui
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
