Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-dhcpv6-05.txt

From: [email-masked]
Date: Fri, 14 Feb 2014 13:10:06 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

        Title           : DHCPv4 over DHCPv6 Transport
        Authors         : Qi Sun
                          Yong Cui
                          Marcin Siodelski
                          Suresh Krishnan
                          Ian Farrer
	Filename        : draft-ietf-dhc-dhcpv4-over-dhcpv6-05.txt
	Pages           : 14
	Date            : 2014-02-14

Abstract:
   IPv4 connectivity is still needed as networks migrate towards IPv6.
   Users require IPv4 configuration even if the uplink to their service
   provider supports IPv6 only.  This document describes a mechanism for
   obtaining IPv4 configuration information dynamically in IPv6 networks
   by carrying DHCPv4 messages over DHCPv6 transport.  Two new DHCPv6
   messages and two new DHCPv6 options are defined for this purpose.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv4-over-dhcpv6-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Marcin Siodelski <[email-masked]>
Date: Fri, 14 Feb 2014 22:22:24 +0100

The version -05 incorporates some minor (mostly editorial) changes
suggested by Bernie during his shepherd work:

1. Update reference to the latest
draft-ietf-dhc-dhcpv6-unknown-msg-05, instead of -04
2. Section 5.3 references section 7 which discusses the use of Unicast
Flag in detail
3. In section 8, use "global address of appropriate scope" instead of
"global scope"
4. Clarify the text about use of Information Refresh Time option (use
when in stateless mode)
5. Use the term DHCP 4o6 client (or client) term consistently.
6. Remove reference to RFC6842 - there is no need to mandate that the
server copies client id in the DHCPv4 response
7. Clarify how the text which says what the client should do if there
is duplicated DHCP 4o6 server address (editorial change)
8. Use MBZ instead of Reserved to make the unused flags in the new messages.

Marcin

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Fri, Feb 14, 2014 at 10:10 PM
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-dhcpv6-05.txt
To: [email-masked]
Cc: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Dynamic Host Configuration Working
Group of the IETF.

Abstract:

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

---

From: Andre Kostur <[email-masked]>
Date: Fri, 14 Feb 2014 19:08:09 -0800

Perhaps a quick question on section 6.2.

I'm curious as to why there's a special case of "if there are no
addresses, use All_DHCP_Relay_Agents_and_Servers"?  If an
administrator wanted the client to send to that address, they could
also just supply that one address in the option.  And then clients
wouldn't have to have a special case handling of receiving an empty
option.

Also the section says "This list may include either multicast or
unicast addresses."  Is that intended to say that it cannot contain a
mix of both?

-- 
Andre Kostur

---

From: Qi Sun <[email-masked]>
Date: Sun, 16 Feb 2014 22:44:48 +0800

Hi Andre,

Thanks for review. Please see inline.

> wouldn't have to have a special case handling of receiving an empty

[Qi] This is intended to be compatible with the DHCPv6 architecture, where the client sends packets to the multicast address by default. So if there is no address in the 4o6 Server Address option, the 4o6 DHCP client just works like a DHCPv6 client. 

> unicast addresses."  Is that intended to say that it cannot contain a

[Qi] There should be no such limit. The client just sends packets to the address(es) listed int the 4o6 Server Address option. An administrator can configure this option according to his needs. 
Will improve the wording.

Thanks,
QI

---

From: Ted Lemon <[email-masked]>
Date: Sun, 16 Feb 2014 16:18:22 -0500

> Will improve the wording.

suggestion: "may include multicast and unicast addresses".