Subject: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

From: Ralph Droms <[email-masked]>
Date: Wed, 05 Feb 2003 16:17:49 -0500

This message announces a WG last call on "DNS Configuration options for 
DHCPv6" <draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt>.  The last call will 
conclude on Friday, 2/21.

Note that this is a parallel WG last call in the dhc, ipv6 and dnsext WGs.

draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for 
DHCPv6: the Domain Name Server option and the Domain Search List 
option.  This document is being considered for Proposed Standard as an 
extension to the base DHCPv6 specification, and is available as 
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

- Ralph Droms

--------------------------------------------------------------------
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: Pekka Savola <[email-masked]>
Date: Thu, 6 Feb 2003 11:00:38 +0200 (EET)

On Wed, 5 Feb 2003, Ralph Droms wrote:
> DHCPv6: the Domain Name Server option and the Domain Search List option.  
> This document is being considered for Proposed Standard as an extension
> to the base DHCPv6 specification, and is available as

A few comments; I haven't looked too deep into DHCPv6 to be able to 
comment on those parts, but there are some definite need for revisal in 
the doc..:

2. Requirements

   The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   [...]

==> I'd put these under Introduction or Terminology sections, no use 
having a separate section with a questionable title.

   option-length: Length of the 'options' field in octets; must be a
      multiple of 16

==> 'options' field has not been defined.  Is it the whole option or just
the length of DNS-server address options (I assume so)?  If the former,
there must be 32 bits of zero padding.  Is it ok that the options aren't 
64-bit aligned?

   The list of domain names in the 'searchstring' MUST be encoded as
   specified in section "Representation and use of domain names" of the
   DHCPv6 specification [4].

==> I didn't bother to check, but I guess this document also defines how 
to pad the names to get some desired level of alignment?

6. Appearance of these options

   The Domain Name Server option MUST appear only in the following
   messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, 
   Information-Request, Reply.

   The Domain Search List option MUST appear only in the following
   messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, 
   Information-Request, Reply.

==> I would reword these differently, like:

 The Domain Name Server option MUST NOT appear in other than the following 
messages: ....

==> is it ok to server to give only one of these options but not the 
other?

References

==> split the references

   [4]  Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R.
        Droms (ed.), "Dynamic Host Configuration Protocol for IPv6
        (DHCPv6)", draft-ietf-dhc-dhcpv6-23 (work in progress), February
        2002.

==> update this draft version

Author's Address

   Ralph Droms (ed.)

==> the author is an editor, but the draft does not have acknowledgements 
or contributors section.  Just remove Editor if nobody else contributed to 
the document.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Ralph Droms <[email-masked]>
Date: Mon, 10 Feb 2003 11:23:07 -0500

Pekka,

Thanks for the review and feedback; my comments are in line...

And - for other members of the dhc, dnsext and ipv6 WGS: please
respond to this last call notice with comments or an explicit
ack to indicate you accept the draft as published.  Thanks...

- Ralph

>    option-length: Length of the 'options' field in octets; must be a

Should read "Length of the list of DNS servers in octets; ..."

>there must be 32 bits of zero padding.  Is it ok that the options aren't

It's OK that options are not 64-bit aligned; I don't think the padding
is necessary.

>to pad the names to get some desired level of alignment?

DHCPv6 doesn't require alignment of the contents of options.

>  The Domain Name Server option MUST NOT appear in other than the following

OK.

>==> is it ok to server to give only one of these options but not the

Yes.

>==> split the references

OK.

>==> update this draft version

OK.

>or contributors section.  Just remove Editor if nobody else contributed to

Thanks for noticing the oversight.  I'll add an acknowledgments seciton.

>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 11 Feb 2003 14:03:58 +0900

>>>>> On Mon, 10 Feb 2003 11:23:07 -0500, 
>>>>> Ralph Droms <[email-masked]> said:

> ack to indicate you accept the draft as published.  Thanks...

I'm okay to publish the draft.  I've reviewed it, and implemented the
Domain Name Server option.  The specification is useful and important,
and (at least regarding the part I implemented) working well.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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: Robert Elz <[email-masked]>
Date: Tue, 11 Feb 2003 16:18:24 +0700

Date:        Mon, 10 Feb 2003 11:23:07 -0500
    From:        Ralph Droms <[email-masked]>
    Message-ID:  <[email-masked]>

  | And - for other members of the dhc, dnsext and ipv6 WGS: please
  | respond to this last call notice with comments or an explicit
  | ack to indicate you accept the draft as published.  Thanks...

With the various changes (mostly fairly minor) that have been
suggested, it looks Ok to me.

kre

---

From: Ralph Droms <[email-masked]>
Date: Thu, 20 Feb 2003 14:55:11 -0500

Thanks for your feedback, Peter; my comments in line...

- Ralph

At 08:27 PM 2/10/2003 +0100, Peter Koch wrote:

> >    This document uses terminology specific to IPv6 and DHCPv6 as defined
> >    in section "Terminology" of the DHCP specification.
>
>Might want to add an explicit normative reference here?

OK.

> > 4. Domain Name Server option
> >
> >    The Domain Name Server option provides a list of one or more IP
> >    addresses of DNS servers to which a client's DNS resolver MAY send
>
> >From a purist's point of view I'm tempted to say that you're not really 
> looking
>for a DNS server here but instead for a (list of) recursive resolvers.

Should this sentence read (I'm not a DNS purist!):

    The Domain Name Server option provides a list of one or more IP
    addresses of DNS recursive resolvers to which a client's DNS resolver
    MAY send DNS queries [2].

> >    DNS-server:    IP address of DNS server

(change to "DNS recursive resolver"?)

>I did not follow the DHCPv6 effort too close, so I must admit not knowing
>the usual "culture", but wouldn't it be better to say IPv6 address here?

Yes; also see follow up by Alain Durand.

> >    A server sends a Domain Search List option to the DHCP client to
> >    specify the domain search list the client is to use when resolving
> >    hostnames with DNS.  This option does not apply to other name
> >    resolution mechanisms.
>
>The draft does not say for which kind of domain names the client is expected
>to process the list, i.e. one-label names only, n-label names (how to
>communicate the 'n', aka 'ndots', then?) or whether this is left to the
>application(s).
>
> >    Because the Domain Search List option may be used to spoof DNS name
> >    resolution in a way that cannot be detected by DNS security
> >    mechanisms like DNSSEC [5], DHCP clients and servers MUST use
>
>Apart from the sad fact that DNSSEC isn't yet deployed I don't see why it
>wouldn't be able to detect spoofing. If, however, you want to say that
>using domain names in the search list you don't control is a dangerous
>thing, that could be emphazised by a reference to RFC 1535.

The idea here (note that I'm not a DNSSEC expert, either) is that
a search list that the host doesn't control might still pass DNSSEC
authentication while yielding unexpected results.

I would be happy to hear that DNSSEC can prevent the problem and would
be willing to follow your suggestion and replace the reference to
DNSSEC with a more general reference to untrusted search lists.

> >    authenticated DHCP when a Domain Search List option is included in a
> >    DHCP message.
>
>Why is this a MUST while there's a SHOULD only for the server option?

They probably both should have the same level of requirement; I would
think SHOULD would be sufficient for both.

>-Peter
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://ops.ietf.org/lists/namedroppers/>