Hi,
At 07:47 AM 08/01/2004, Pekka Savola wrote:
A look how the draft was changed in response to LC comments..
substantial -----------
1) this revision has added a lot of text that the ND approach is unfit to WLAN, and performs poorly. However, the document never explains the background or assumptions to such claims. I guess this is mased on Masataka's point that multicast on WLAN actually results in a lot of point-to-point communication. But this needs to be spelled out, keeping in mind three things: 1) in some environments, this may not be a problem; 2) this is no worse than WLAN today; 3) if folks thought multicast on WLAN had such big problems, they might have devised a different mechanism for it -- for example, if pure broadcast does not suffer from this issue, certain multicast addresses, which are expected to have a larger number of recipients, could be mapped to the broadcast address instead.
2) A major (IMHO) advantage of RA option hasn't been mentioned -- that it leverages SEND security out of the box, with zero new specification (if you assume that if someone is authorized as a router, it is authorized to send you any kind of RDNSS option). This is potentially a really big benefit.
3) The anycast approach should maybe instead use the term "shared-unicast", as coined by draft-ietf-ipngwg-anycast-analysis-02.txt. That makes it clearer which anycast it's referring to.
4) 3GPP still needs to explain whether RA's are being used at all at the moment -- that is, some have at least stated that e.g., addresses/prefixes are configured as part of PDP context activation, which would seem to hint at the fact that even if RA's would be possible, they might not be used that much..
I agree with all of Pekka's substantial comments and think the document needs to be updated.
Bob
semi-editorial --------------
The RA approach is useful in some non-WLAN mobile environments where the addresses of the RDNSSes are changing because the RA option includes a lifetime field. This can be configured to a value that will require the client to time out the entry and switch over to another RDNSS address [8].
==> I fail to see a strong justification for lifetime option in the first place -- and it complicates the matters. If your network connectivity breaks, you'll lose DNS lookups no matter what. If it doesn't break, but a server gets renumbered, the advertising router's DNS information has to be updated, no matter the lifetime in any case -- and if there is no lifetime, a new advertisement without the removed server could simply overwrite the old. In summary, I can't figure a really convincing usage case for lifetime in the first place.
RFC2461 [3] states, however, that there may be some link type on which ND is not possible; on such a link, some other mechanism will be needed for DNS configuration.
==> do such media exist? If not, maybe it's worth stating the case; if yes, noting that they aren't commonplace.
1) ND is mostly implemented in kernel part of operating system. Therefore, if ND supports the configuration of some additional services, such as DNS, NTP and SIP servers, ND should be extended in kernel part.
==> , and completed by an user-land process.
The DHCPv6 option for RDNSS has a few disadvantages. These include:
1) Update currently requires message from server (however, see [10]).
==> I don't understand 1). Doesn't update always require some kind of message? Please elaborate.
3.3.2 Disadvantages
Well-known anycast addresses approach requires that DNS servers (or routers near it as a proxy) act as routers to advertise their anycast addresses to the routing system, which requires some configuration (see the last paragraph of the previous section on the scalability of the effort).
==> I think this requires a bit more beef. In particular, one should describe the model for failure recovery. For example, if a site or ISP doesn't have a route to the well-known service, for example, but has a default discard route which blackholes the packets -- then what? You're down to the timeouts.
I think the biggest issue with (inter-domain) anycast is that the service which relies on it might not function properly in the case that the address is blackholed due to whatever reasons, or if anyone close by isn't offering service, you could end up travelling to the ends of the earth to get DNS service...
Regarding DNS configuration on the IPv6 host, several mechanisms have being considered at the DNSOP Working Group such as RA option,
==> s/have being/are being/ (or "have been") ?
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
. dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
