Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues
RFC 4477

Summary: Needs a YES.

Deborah Brungard No Record

Alissa Cooper No Record

Roman Danyliw No Record

Martin Duke No Record

Benjamin Kaduk No Record

(David Kessens) No Record

Comment (2006-02-21)
No email
send info
Comments received from the Ops Directorate by Pekka Savola:

This seemed to be a relatively good document.  More or less editorial
comments below.

(in Section 5)
   On reflection on the above observations, it was the strong consensus
   of the dhc WG to adopt the two-server approach (separate DHCP and
   DHCPv6 servers) in favour to a combined, single server returning IPv4
   information over IPv6.  The two servers may be co-located on a single
   node, and may have consistent configuration information generated
   from a single asset database.

==> this is the first time you mention that DHC WG has already made a
decision on this.  Making this more prominent earlier in the spec (e.g.,
abstract, introduction, section 4.1/4.2) would probably be useful.

If the goal of this to-be-RFC is to document issues and discussions for
historical reference and further development, some minor rewording could be

mostly editorial

==> please remove references from the abstract.

   These protocols allow nodes to communicate via IPv4 or IPv6 to
   retrieve configuration settings for operation in a managed

==> s/IPv6/IPv6 (respectively)/, otherwise this could be read that DHCPv4
would also support v6, or DHCPv6 support v4.

   While there is a more general multihoming issue to be solved for DHC,
   in this text we focus on the specific issues for operating DHCP in a
   mixed (typically dual-stack) IPv4 and IPv6 environment.

==> you mention 'multihoming' in two occasions, but don't really include
enough context to convey what you're talking about.  The last paragraph
of section 5 makes this a bit clearer; maybe reordering text or making a
separate subsection on multihoming would help.

   The DNS search path may vary for administrative reasons.  For
   example, a site under the domain foo.com chooses to place an early
   IPv6 deployment under the subdomain ipv6.foo.com, until it is
   confident of offering a full dual-stack service under its main
   domain.  The subtlety here is that the DNS search path then affects
   choice of protocol used, such as IPv6 for nodes in ipv6.foo.com.

==> s/foo.com/example.com/, s/chooses/may choose/ ?

==> btw, a related issue (similar text in 1st paragraph of section 4.4)
has been discussed briefly in section 4.2 of
draft-ietf-dnsop-ipv6-dns-issues-12.txt (in rfc-ed queue).

   principle operational choice is whether separate DHCP and DHCPv6
   servers should be maintained by a site, or whether DHCPv6 should be
   extended to carry IPv4 configuration settings for dual-stack nodes.

==> is this only an operational choice?  it's probably also an
implementation and specification choice.

Erik Kline No Record

Murray Kucherawy No Record

Warren Kumari No Record

Barry Leiba No Record

Alvaro Retana No Record

Martin Vigoureux No Record

Éric Vyncke No Record

Magnus Westerlund No Record

Robert Wilton No Record