Subject: [dnsop] ipv6-dns-configuration-02 comments

From: Pekka Savola <[email-masked]>
Date: Sun, 1 Aug 2004 17:47:03 +0300 (EEST)

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..

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

---

From: Bob Hinden <[email-masked]>
Date: Mon, 02 Aug 2004 08:21:48 -0700

Hi,

>A look how the draft was changed in response to LC comments..

I agree with all of Pekka's substantial comments and think the document 
needs to be updated.

Bob

.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 02 Aug 2004 18:30:14 -0400

>>A look how the draft was changed in response to LC comments..

If and when SEND is done.  DHCPv6 has security built in today.

>>at the fact that even if RA's would be possible, they might not be used that

Agreed...

- Ralph

.