Greg;
> I think there is an issue of mis-communication
> here which prevents us from moving beyond a certain
> point in the conversation.
Seems to be.
> I'm pretty sure that ND is critical for such devices
Why?
> in order
> to create a common link-layer address resolution mechanism
> regardless of the access medium of a particular host.
Why, do you think, it is a meaningful thing to use ND only
to reduce the efficiency of IP over the access medium?
Note also that, over WLAN, ARP, which works over various
access media, performs better than ND.
It is of course that new access medium needs its own hardware,
firmware, device driver and address resolution mechanism.
> I believe that you see the issue with regard to packet loss
> as a debilitating factor for WLAN.
I'm not sure whether you understand the problem or not.
Do you understand why ND packets are lost so often?
>> Our goal is to let IP run over (almost) all the link types
>> as efficiently as possible.
>>
>> Right?
> Yes, but I think it is also a goal to ensure that we don't
> rely on peers being modified in order to guarantee our
> own good performance.
It is of course that new access medium needs its own hardware,
firmware, device driver and address resolution mechanism.
Right?
> This is especially the case for switched access networks,
> where many different media (Bluetooth, WLAN, Ethernet) may
> be present.
Say CATENET. Never try to have large link.
It's you who said:
: 802.11's MTU is much greater than 1500 octets.
> I was also indicating that DAD is required for address
> configuration,
Wrong.
> DHCPv6 today relies upon link-local unicast packet
> transfer. Therefore it relies upon ND and Stateless
> Address Autoconfiguration and DAD for the link-local address.
Wrong.
DHCP without DAD works just fine over IPv4.
>> Thus, ND gives up after three NSes and is not robust.
>
>
> I really don't see that there's an agreed way to handle
> this issue in 802.11.
It's enough that you admit ND is not the agreed way.
> In any discovery this is going to be a problem, since
> any discovery will require multicast at the MAC layer.
"Discovery" is a wrong terminology and avoided in our draft
on DNS configuration.
Advertisement is just what is required and is a lot easier.
> What is needed is either to do away with the discovery
> phase,
Yup.
> Indeed, we may need to make some allowance for the link types.
>
> ND itself is not failed. It does a very good job of
> allowing a single message format (and single implementation)
> to work on a wide range of access technologies.
ND may be good for 3Mbps Ethernet shared by 1000 immobile
hosts, but not beyond.
> In my opinion, it is the duty of hosts which connect over
> lossy media to improve their own performance without
> relying on optimizations on other devices.
As for address resolution, WLAN is not lossy media. ND over
WLAN is a lossy way of address resolution.
> Reliance upon such optimizations
Never bother to optimize ND.
>> IP is generally useful. Forget to expect "generally useful"
>> for ND.
> I think that the existing ND can be used as a basis
> for messaging in any case
It is a lot better to use the existing ARP as the basis.
Note that DAD is useless.
> With regards to its usefulness: It's certainly useful to be
> able to guarantee that a host is running a particular service
> and _will_ respond if it receives a message.
ND does not assure that a host is "running a particular
service".
To detect a host is alive, ICMP echo is more than enough.
> Even if you don't receive it the first time.
DNS and URL is the way to know a host is "running a particular
service".
> If we can rely upon this form unoptimized hosts then
> I guess that we can utilize cleverer polling techniques,
> or install state on peers in order to remove the need for
> retransmissions when packets are arriving.
You can do it only at the transport layer or above.
> Replies
> are unicast except for in the case of DAD (which has its own
> retransmission mechanisms), and router advertisement
> (which is repeated at intervals).
That's the difference.
> Actually, if your peer or router is on the fixed network,
> the multicast router or neighbour solicitation will go
> from the Wireless Host (STA) through the AP (getting Acked or
> retransmitted) to the peer.
You are merely saying ARP works over wired LAN or wired part
of the LAN, which has nothing to do with the current problem.
> If you sent a Source Link-Layer Address Option (i.e. a MAC address)
> in the solicitation, it will set a neighbour cache entry in
> the peer or router, in which case there will not be a multicast
> neighbour discovery from the peer or router when it wishes to
> send data.
Now, you are making ND link layer specific only to make ND
as good as ARP over wired part of the LAN.
Why do you bother?
> In most cases, the wireless host will want packet delivery
> from a router, which it will have discovered using
> router discovery.
And router discovery is slow.
>>> Unicast RAs are likely to increase the load
>>> in the case many devices configure simultaneously though.
>> It's not a problem of modern networks, which has broad enough
>> bandwidth for small number of hosts.
> Indeed, it depends on the number of residents in the cell, in this
> case.
As I said, ND timing is good for 3Mbps link shared by 1000 immobile
hosts, which has nothing to do with the current reality.
Masataka Ohta
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
