Hi,
Masataka Ohta wrote:
Hi,
However, with the current DHCPv6, it means that IP address should be configured by DHCP with four messages.
I'm not so clear on your intention here, but I'd guess that Stateless Address Autoconfiguration is OK, if there is sufficient robustness in the (re)transmission of DAD NS's and NAs.
DAD?
Duplicate Address Detection (from rfc2462).
Address resolution of ND gives up after three NSes and is not robust.
Note that hand over means new routers are involded and everything must be tried again.
Actually, Address resolution doesn't give up after 3 retransmissions (as defined in RFC 2461).
As indicated in the State transition table in appendix C, The address unreachable message is sent in response to each of the queued packets and then the NC entry is deleted.
Indeed, the address has been unreachable during the probe period, so this may be interpreted as correct behaviour.
Newly arriving packets will cause a new NC entry to be created, and this may establish connectivity.
This may have a significant cost in time and packet loss, though.
I think that the issue is what needs to be done on:
* wireless hosts * base-station/routers * fixed devices which bridge to the WLAN.
I'd guess that the first two classes are easier to handle, since they have direct knowledge of Wireless LAN requirements.
We really can't rely upon deployed ipv6 hosts and routers being implemented with WLAN specific changes (unless these are good in every network).
If we can come up with some options (or generally useful mechanisms) that may be OK, but it's probably better to concentrate on the wireless hosts first.
Base-station/routers may be fixable, although there's no reason for a host to believe that their particular AP is a combined AP/Router as opposed to a bridge.
Whether this is time critical or not depends on the requirements on the subsystems in question.
which is why it is a broken idea to have ND with fixed timing, which makes ND inappropriate for most subsystems.
It's possible that devices which know that they're using WLAN could adopt a better ND strategy. For example:
* Send packets which are likely to be robustly transmitted (not multicast downstream to WLAN hosts).
* attempt to set neighbour cache entries before a neighbour solicitation from the peer is sent.
This second option also has the advantage that the uplink packet queue is likely to be shorter than the downlink through the Access Point (and so has better MAC contention properties).
For example, sending SLLAOs or TSLLAOs in an NS from the a wireless host to the fixed network can be used to avoid NS/NA exchanges when packets are expected on the downlink.
Both of the above strategies could be used with unmodified nodes on the wired portion of the network (and would be suitable for an IPv6 over WLAN type document).
I'd guess that a host could solicit for router advertisement and get a response within a few seconds,
If RS were successfully received AND corresponding RA were successfully received, which are not likely the case over congested WLAN.
Indeed, any congested link may have a difficulty sending packets.
For WLAN the RS and the RA (if the RA is unicast) can be sent robustly (with retransmission) if the router is configured to send unicast RAs. Unicast RAs are likely to increase the load in the case many devices configure simultaneously though.
Greg
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
