Re: Last Call: 'IPv6 Router Advertisement Option for DNS Configuration' to Experimental RFC (draft-jeong-dnsop-ipv6-dns-discovery)

Pekka Savola <pekkas@netcore.fi> Fri, 30 June 2006 07:53 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwDon-00055N-Rv; Fri, 30 Jun 2006 03:53:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwDol-00054z-Tu; Fri, 30 Jun 2006 03:53:35 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwDEE-0000P2-FN; Fri, 30 Jun 2006 03:15:50 -0400
Received: from netcore.fi ([193.94.160.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FwD08-0008UV-43; Fri, 30 Jun 2006 03:01:17 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k5U717PF026186; Fri, 30 Jun 2006 10:01:07 +0300
Date: Fri, 30 Jun 2006 10:01:07 +0300
From: Pekka Savola <pekkas@netcore.fi>
To: JINMEI Tatuya / 神明達哉 <jinmei@wide.ad.jp>
In-Reply-To: <y7vodwbnt34.wl%jinmei@isl.rdc.toshiba.co.jp>
Message-ID: <Pine.LNX.4.64.0606300948410.25854@netcore.fi>
References: <E1FsTSV-0005EA-7Z@stiedprstage1.ietf.org> <y7vac7wp9hg.wl%jinmei@isl.rdc.toshiba.co.jp> <y7vodwbnt34.wl%jinmei@isl.rdc.toshiba.co.jp>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-1138325424-1151650867=:25854"
X-Virus-Scanned: ClamAV 0.88.2/1577/Thu Jun 29 23:18:18 2006 on otso.netcore.fi
X-Virus-Status: Clean
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.2
X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on otso.netcore.fi
X-Spam-Score: -2.4 (--)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: ipv6@ietf.org, iesg@ietf.org
Subject: Re: Last Call: 'IPv6 Router Advertisement Option for DNS Configuration' to Experimental RFC (draft-jeong-dnsop-ipv6-dns-discovery)
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Errors-To: ipv6-bounces@ietf.org

On Fri, 30 Jun 2006, JINMEI Tatuya / ¿ÀÌÀãºÈ wrote:
> This time I'm also copying the ipv6 list.  In fact, ipv6@ietf would be
> more suitable place for discussions on this proposal, since it's an
> extension to ND.
...

Disclaimer: router-side support for this has been added (as it was 
contributed by others) to radvd which I maintain.  However, I do not 
have a strong opinion on this topic one way or the other.

If this goes forward, as an implementor I'd like to get IANA codepoint 
assigned quickly so that experiments would interoperate (and 
implementors wouldn't need to steal the next unused value or wait for 
draft-fenner-iana-exp-2780-05.txt to get published).

[whether IPv6 ND was designed for applictions above layer-3]
>  So,
>  + I'd first like to confirm whether my understanding about the
>    'design principle' is correct.  If it's wrong, then I'm fine and
>    this concern will be resolved.
>  + if my understanding is correct, I'd like this document to discuss
>    why this particular option is so special and needs to be defined
>    despite the violation of the principle, and to add an explicit
>    note that configuration information around this layer should not
>    be provided via RA unless there is a very strong reason.

The IETF doesn't do a very good job of documenting (and gaining 
consensus on) its design principles, so for any opinions you might get 
on this, you would also have opposite opinions, and hence I'm not sure 
how useful pursuing this line of argument is.

I guess this underlines that to avoid fuss like this in the future, 
better documentation of design principles might avoid ratholes.

>>                     This flag
>>                     SHOULD be set only if the routers or firewalls in
>>                     the network allow DNS Query messages to be routed
>>                     to the destination RDNSS without being filtered
>>                     out, and the RDNSS is configured to perform
>>                     recursive queries for all hosts regardless of
>>                     their addresses.
>
>My understanding is that current operational trend is generally
>against such "open recursive servers" as documented in
>draft-ietf-dnsop-reflectors-are-evil-00.txt.  So I'm skeptical about
>the usefulness of this flag.  Standardizing such a practice may even
>be regarded as a conflict with the operational trend.
>
>I don't have a strong opinion by pointing it out, but I might 
>consider removing this flag.

This is a good point and at the very least should be pointed out in 
the security considerations.  However, the text as written does not 
preclude DNS server requiring other form of identification (e.g., 
TSIG) instead of addresses.  In practice, I doubt such authentication 
would be used very often.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------