Subject: RE: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconf ig-02.txt

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Mon, 10 Feb 2003 12:43:54 -0600

Ralph:

All of the previous comments should be incorporated. But, in addition:

Section 4 and 5 state that a "Server sends ... option to the DHCP client".
However, the list of messages in which these options may appear includes
client generated messages (Solicit, Request, Renew, Rebind,
Information-Request).

I believe that client generated messages can request these option codes
in an ORO option, but should they include these options? There may be
little harm in allowing them? Though it is difficult to see how they
could appear in a Solicit even in that case.

In section 7, for:

   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
   authenticated DHCP when a Domain Search List option is included in a
   DHCP message.

Might it be better to instead state that a client MUST NOT install the Domain
Search List unless the message was authenticated? This is cleaner as to what
it requires a client and server to do. It is difficult for a client to know
in advance whether a server will supply the option?

The same might be true of the Domain Name Server option??

Otherwise, the draft looks fine and I would like to see it advanced.

- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Monday, February 10, 2003 11:23 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dhcwg] Re: WG last call on
draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

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

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Mon, 24 Feb 2003 13:33:27 -0600

Isn't it possible for the DHCPv6 server to return IPv4 addresses as per
RFC 2373, section 2.5.4 (IPv6 Addresses with Embedded IPv4 Addresses),
in particular:

   A second type of IPv6 address which holds an embedded IPv4 address is
   also defined.  This address is used to represent the addresses of
   IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses.
   This type of address is termed an "IPv4-mapped IPv6 address" and has
   the format:

   |                80 bits               | 16 |      32 bits        |
   +--------------------------------------+--------------------------+
   |0000..............................0000|FFFF|    IPv4 address     |
   +--------------------------------------+----+---------------------+

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Monday, February 24, 2003 12:43 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dhcwg] Re: WG last call on

Summary of discussion during WG last call on 
draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

Pekka Savola, Tony Lindstrom, Bernie Volz and Peter Koch all responded with 
editorial suggestions.  These suggestions have been incorporated into the 
draft and will appear in next published rev.

Peter Koch and Rob Austein commented on the "Security Considerations"; 
specifically, whether DNSSEC can prevent problems caused by a search list 
supplied as part of an attack by a DHCP server.  Based on Rob's argument 
(and assuming I understood Rob correctly) that DNSSEC can guarantee that a 
host can trust the replies it receives, but DNSSEC can't guarantee that the 
host has asked the right question based on its search list, I'm inclined to 
leave the text in question unchanged.

Alain Durand raised the issue of supplying both IPv4 and IPv6 addresses for 
DNS resolvers in the DNS server option.  I judged the rough consensus in 
the responses to be that restricting the DNS server option to return only 
IPv6 addresses is acceptable.

- Ralph

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