Hi Jonathan and Carsten:
I concur with the Dublin agreement that RFC 4861 based address
resolution is not desirable.
Looking back, we used till 02 to use the white board for address
resolution and redirect.
But as we generalized the protocol to any mesh under technology, we
found that the whiteboard could not necessarily help there:
* If the mesh is only partial, the white board cannot know if there is a
direct path between the 2.
* If the mesh is based on virtual circuits, then the white board cannot
know the OD of the virtual circuit between the 2 even if such a circuit
exists.
So we stopped using address resolution and redirects through the white
board.
What beats me is your wording that we depend on the encoding of the L2
address in the L3 address.
And to be honest there's some text added in 03 and still present to this
day that seems to imply this:
"
1.1. Goals & Assumptions
...
o Link-local IPv6 addresses are derived from a unique identifier
(e.g. EUI-64).
o There is a direct mapping between the IPv6 address IID and the
link-layer address (as in e.g. [RFC4944]), thus address
resolution is not required.
"
"
Address Resolution: Not performed as there is a direct mapping
between the IID and the link-layer address.
"
This is not correct. do agree that IF there is such a thing as this tie
between the LLA and the IPv6 IID then there can be local optimizations,
just like there is a way to do stateless compression. But we do not need
this in general and the spec works without it. And BTW, the new HC is
designed to enable stateful compression and thus works with any address,
whether it is formed from MAC or not.
The real reason for which we do not need resolution in the LoWPAN is
that we can always go through the router. No NUD but ICMP unreachable.
No redirect. This makes full sense in route-over and it still enables
connectivity in mesh-under via the edge router.
This might lead to non-optimal path in the latter case, but in practice
there is no way to generalize mesh-under, that's just too diverse. Some
are proactive whereas others can and will create a path on-demand. Some
are fully meshed whereas others are only partial (which is probably more
economical and thus favored in sensor space). And a mesh-under coverage
does not need to match the group of nodes attached to a given edge
router.
At the end of the day, if there is or there can be a mesh-under path
between two end-nodes that is better than the path via the routers, then
an additional mesh dependent mechanism must be put in place that is out
of scope for 6LoWPAN-ND. Examples of such additional mechanisms can be
found in Classical IP over ATM (NHRP) and Inverse ND.
We could have a small additional draft that would describe the use of
the white board for the purpose of address resolution in 802.15.4 from
version prior to 03 of this draft, and the optimizations that can derive
from the LLA/IID tying assumptions if they are enforced in a given
deployment. But that should not be in the main 6LoWPAN ND draft that
aims at the larger problem of ND over non-transitive links.
If you agree with this reasoning then we should really rework the text
above. The assumptions should go away. The second excerpt should become:
"
Address Resolution: Not performed. Nodes only forward via routers
with which they have a NR/NC relationship.
Any optimization for direct host to host
connectivity is out of scope.
"
What do you think?
Pascal
>-----Original Message-----
>From: [email protected] [mailto:[email protected]] On
Behalf Of Jonathan Hui
>Sent: mercredi 14 octobre 2009 01:01
>To: Carsten Bormann
>Cc: 6lowpan
>Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1)
Addressresolution is a waste of energy
>
>
>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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
