Subject: beloeil-ipv6-dns-resolver-option-00 comments

From: Pekka Savola <[email-masked]>
Date: Tue, 17 Dec 2002 11:45:40 +0200 (EET)

Hello,

I'm also bringing this to the w.g. list, as I believe an RA option for 
discovering DNS resolvers could be one very viable mechanism.

Generic comments:

 1) It's not clear to me whether this option is to be included in periodic 
unsolicited router advertisements, or only in explicit request-reply 
pairs.  Based on the fact that the option includes Code reply/query pair, 
this seems likely to fall somewhere between the two of these.

The way spec is written, the routers which would support DNSR option would 
not include it in every RA message.  (This could be considered both a good 
and a bad thing.)

 2) perhaps it should be explicitly stated, for clarity, that unrecognized 
DNSR options must be ignored by receivers by RFC2461.

 3) Security considerations could use some additional considerations 
related to adding DNS resolvers in the RS/RA messaging.  At least it 
should be mentioned -- I don't think there's necessarily all that 
dangerous stuff out there, as if you use RA, you already have quite a lot 
of trust in the system.

 4) On systems which configure manually ie. disable RA-advertisements, I 
believe this will also not be used?

Specifics:

The purpose is
   also to enhance the efficiency of [DISCOVERY] when DHCPv6 servers can
	not be used.

==>  s/servers can not be/is not/

4.2.2 Passive mode
                         
   On any link a node MUST listen to Router Advertisements (DISCOVERY].
   
==> MUST is news to me.  Did I miss something?

Purely editorial:

   This document defines the DNS resolver (DNSR) option used to advertise
   IPv6 addresses of DNS resolvers on a link.

==> "on a link" is an ambious reference: it could refer to _DNS resolvers_ 
on a link, or _advertising_ on a link.

   Because of the deployment of IPv6 network, DNS resolution might
   become a key issue.

==> please reword the first 7 words, they make no sense :-)

4.2.1 Active mode

   If a node wants to learn the IPv6 addresses of available DNS
   resolvers, it SHOULD send a "DNS resolver Query". A "DNS resolver
	Query" is a Router solicitation with a DNSR option.

==> s/solicitation/Solicitation/

   On any link a node MUST listen to Router Advertisements (DISCOVERY].
   By that way a node may learn the IPv6 addresses of available DNS
   resolvers in the case another node has just query for such an
   information, and that a router has just replied by a Routeur
   Advertisement including a DNSR option.

==> s/(/[/
==> s/query/queried/
==> s/Routeur/Router/

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "BELOEIL Luc FTRD/DMI/CAE" <[email-masked]>
Date: Thu, 19 Dec 2002 09:52:17 +0100

Hi,

Thanks a lot for your comments (again).

>De: Pekka Savola [[email-masked]]
>

LB:
My idea was to reduce the use of that option at a maximum. That means
that routers would not have to send DNSR option in unsolicited Router
Advertisements. But a node would have to ask for that option with a DNSR
Query option in a Router Solicitation. Moreover the same node should
also listen to DNSR option so as to not ask for that option if another
node as just ask for one. 

What do the wg think about ?

>DNSR options must be ignored by receivers by RFC2461.

LB: ok it can be clarified

>dangerous stuff out there, as if you use RA, you already have quite a
lot 

LB: I'm not an expert in security issues, could you explain a bit more?
I have some ideas but I'm actually not sure.

>==> MUST is news to me.  Did I miss something?

LB:... I have just read again RFC2461. Yes the "MUST" is incorrect.

LB: Thanks for other comments, I will add those changes is the next
version.

Luc