Hi Carsten,
It looks like the approach is to remove as much as possible, with the
view of what current applications need
The approach I guess we are defending is
- do existing protocols work on this medium (/media)?
- if not can we make them work transparently to IP?
- if not what do we need to change to IP/ND/..., and in which WG (does
it concern only 6lowpan, 802.15.4, or others?)
This was the RFC2491 approach for NBMA:
"A number of key advantages are claimed for this approach. These are:
The IPv6 stacks on hosts do not implement separate ND protocols
for each link layer technology."
What is the percentage of IPv6-over-foo RFC that decided to define a
totally new ND for their medium (which was not an optional extension)?
If we go down the way of doing a custom ND, we could also ask the
questions:
"are IP addresses needed?" I am sure we can twick specs to do without in
the lowpan.
"is transport needed?"...
Is layering needed?
So regarding address resolution, the balance between what we gain (less
NS, though there are not many as Jonathan mentions, and there are less
if you send RAs) and what we loose (one ND stack for all mediums, one
RPL for all mediums, one SeND, one MIPv6, ...? ) is for me in favor of
trying to redefine as little as we can.
Julien
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Carsten Bormann
> Sent: mercredi 14 octobre 2009 00:31
> To: 6lowpan
> Subject: [6lowpan] Fundamental assumptions of 6lowpan-nd-06:
> (1) Addressresolution is a waste of energy
>
> 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
>
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
