Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

From: Ole Troan <[email-masked]>
Date: Mon, 2 Dec 2013 20:21:36 +0100

> Folks, the authors of draft-ietf-dhc-dhcpv4-over-dhcpv6-03 (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-03.txt) believe it is ready for working group last call. Please review this draft and indicate whether or not you feel it is ready to be published. Your input is important! Please respond by Dec 9th, 2013.

I do not support publication of this document.
I believe that using DHCPv4 as currently specified (RFC2131, RFC5107, RFC3456, RFC3046) is sufficient also for A+P softwire tunnels.

RFC7040 references DHCPv4 over IPv6. is this working group also going to specify this alternative transport?

cheers,
Ole

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 3 Dec 2013 01:46:33 +0000

Hi:

That's an informational RFC and references (informational) work in progress (which sometimes changes or is even abandoned). That's the risk the IETF acknowledges with such references.

If DHCPv4 works "as is", what more do you need from the DHC WG? Use DHCPv4 "as is" - what's stopping you?

We are trying to solve the general problem when all that can be assured is the ability to send IPv6 packets.

We will consider your objection during the rough consensus review.

- Bernie (from iPad)

---

From: Ole Troan <[email-masked]>
Date: Tue, 3 Dec 2013 10:30:09 +0100

Bernie,

> That's an informational RFC and references (informational) work in progress (which sometimes changes or is even abandoned). That's the risk the IETF acknowledges with such references.

you are saying that RFC7040 should be updated?

> If DHCPv4 works "as is", what more do you need from the DHC WG? Use DHCPv4 "as is" - what's stopping you?

to stop inventing solutions to non-existing problems.

> We are trying to solve the general problem when all that can be assured is the ability to send IPv6 packets.

I have asked multiple times for an explanation of what you are trying to achieve, and what makes this a "general problem".
I don't believe there is such a problem. and not one that makes sense in an A+P / softwire context.

> We will consider your objection during the rough consensus review.

I would expect so. note also for your shepherding document that I have threatened an appeal.

Best regards,
Ole

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 3 Dec 2013 11:34:01 +0000

I don't understand your points here. Your solution is not what RFC 7040 references either. And in fact the dhcpv4-over-dhcpv6 solution is very close to the dhcpv4-over-ipv6 solution as in some of the models it also only uses IPv6 packets. 

- Bernie (from iPad)

> On Dec 3, 2013, at 4:30 AM, "Ole Troan" <[email-masked]> wrote:
> 
> Bernie,
>

---

From: Ole Troan <[email-masked]>
Date: Tue, 3 Dec 2013 12:54:40 +0100

Bernie,

> I don't understand your points here. Your solution is not what RFC 7040 references either. And in fact the dhcpv4-over-dhcpv6 solution is very close to the dhcpv4-over-ipv6 solution as in some of t…

my point was that you've already put one alternative way of carrying DHCPv4 out there. my question was if you should try to put that cat back into the bag?

in any case, let's not digress on RFC7040. that wasn't the point.

it appears you think it is important that DHCPv4 uses "only IPv6 packets". that's what a tunnel does, why do you think DHCPv4 needs to build its own transport?

cheers,
Ole

---

From: Sten Carlsen <[email-masked]>
Date: Tue, 03 Dec 2013 13:12:40 +0100

On 03/12/13 12.54, Ole Troan wrote:
> Bernie,
>
>> I don't understand your points here. Your solution is not what RFC
7040 references either. And in fact the dhcpv4-over-dhcpv6 solution is
very close to the dhcpv4-over-ipv6 solution as in some of the models it
also only uses IPv6 packets.
>
> my point was that you've already put one alternative way of carrying
DHCPv4 out there. my question was if you should try to put that cat back
into the bag?
> it appears you think it is important that DHCPv4 uses "only IPv6
packets". that's what a tunnel does, why do you think DHCPv4 needs to
build its own transport?
A couple of questions comes to mind here (at least my mind):
- - Is the IPv4 island expected to be a real island all on it's own OR
is it an island connected via a tunnel to other islands of IPv4?
- - Will the DHCP4 server have IPv4 connectivity via the tunnel and
maybe more or will it be all IPv6, with only the DHCP4 communicating
over it's own protocol?
> Ole

- -- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Dec 2013 09:44:14 -0500

> I would expect so. note also for your shepherding document that I have threatened an appeal.

If you think this proposal is genuinely useless, then you should feel comfortable in implementing the solution you prefer, and ignoring the working group's recommendation. But I think you are not comfortable doing that—you are saying this because you expect that you will have to implement this, because there will be demand for it.

Is that correct?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Dec 2013 09:49:09 -0500

> it appears you think it is important that DHCPv4 uses "only IPv6 packets". that's what a tunnel does, why do you think DHCPv4 needs to build its own transport?

Ole, this is a straw-man argument.   Nobody ever said that.   I would hate to see the working group try to argue this point.   Please try to stick to arguing about things people have actually said, or you are just creating useless noise and wasting peoples' valuable time.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 03 Dec 2013 10:29:07 -0500

> I believe that using DHCPv4 as currently specified (RFC2131, RFC5107, RFC3456, RFC3046) is sufficient also for A+P softwire tunnels.

IMHO Ole's objection is legitimate and my understanding of it is that he 
disagrees with the conclusion of draft-ietf-dhc-v4configuration.

The way I see it, consensus on draft-ietf-dhc-v4configuration is the 
core issue. If we don't already have consensus on the analysis of the 
problem space and of the proposed solutions, I don't see how we can send 
one of the proposed solutions to IESG.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Dec 2013 10:31:17 -0500

On Dec 3, 2013, at 10:29 AM, Simon Perreault <[email-masked]> wrote:
> The way I see it, consensus on draft-ietf-dhc-v4configuration is the core issue. If we don't already have consensus on the analysis of the problem space and of the proposed solutions, I don't see how we can send one of the proposed solutions to IESG.

Who is "we"?

---

From: Simon Perreault <[email-masked]>
Date: Tue, 03 Dec 2013 10:41:46 -0500

>> The way I see it, consensus on draft-ietf-dhc-v4configuration is the core issue. If we don't already have consensus on the analysis of the problem space and of the proposed solutions, I don't see…

The working group.

Simon

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Dec 2013 11:09:17 -0500

> The working group.

Which working group?

---

From: Simon Perreault <[email-masked]>
Date: Tue, 03 Dec 2013 11:20:27 -0500

> Which working group?

DHC.

Simon

---

From: Cong Liu <[email-masked]>
Date: Wed, 4 Dec 2013 17:17:25 +0800

Dear all,

I support this document moving forward. And I support the conclusion in
current draft-ietf-dhc-v4configuration-02 that
DHCPv4oDHCPv6 is the best underlying approach for provisioning IPv4
parameters over an IPv6 only network.

Best Regards,
Cong

2013/12/4 Simon Perreault <[email-masked]>

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

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Dec 2013 15:09:11 +0100

> I have asked multiple times for an explanation of what you are trying to achieve, and what makes this a "general problem".

anyone with an answer to this?

cheers,
Ole

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 6 Dec 2013 15:05:29 +0000

Hi:

As the assigned document shepherd for this work, I have reviewed it fairly carefully. And, I have the follow more significant comments regarding this draft:

1.       I've already commented on the two vs. one option issue. I think simplifying this to use a single option which is returned by the server to enable this feature and, optionally, specify a list of IPv6 addresses to which to send the packets.

2.       I think we should rename the messages to be BOOTP, not BOOT. BOOTPREQUESTV6 and BOOTPREPLYV6 (and Bootp-request-v6, Bootp-reply-v6). (I also wonder whether we really need the v6, but it may help in clarifying this from standard BOOTP packets, so OK to leave it.)

3.       At the end of section 7 (Use of the Boot-request-v6 Unicast flag), I think it would be useful to add a note to make it clear that this flag represents how the DHCPv4 packet would have been sent, not how the v6 packet is sent. (Note: The "Unicast" flag reflects the how the DHCPv4 packet would have been sent; not how the DHCPv6 packet itself is sent.)

4.       In section 8 (4o6 DHCP Client Behavior), should we be clear that everything is 'interface' specific? 'Client' here is a bit open to its meaning. Though on the other hand, everything with respect to DHCP is typically interface specific so perhaps clarifying this isn't that critical.

5.       Also in section 8, it may be useful to add something about IPv6 source address considerations ... Section 13 of RFC3315 doesn't mention the IPv6 source address, but it is important that packets sent to a global address have sufficient scope. Though in most cases, this can be left to the kernel (if the source address is unspecified).

6.       Also in section 8, for "There are no explicit transmission parameters associated with a Boot[p]-request-v6 message." I think adding ", as this is governed by the DHCPv4, [RFC2131], "state machine"." Or something like that.

7.       In section 10, 2nd paragraph, I wonder if "...broadcast or unicast address if DHCPv4 protocol was used" should be "broadcast or unicast address if IPv4 has been used." The packet is transmitted over IPv4. But this is minor.

8.       In section 12 (IANA Considerations), please improve this to make it clear exactly what registry. You may want to look at the SOLMAX draft text:

IANA is requested to assign one option code each for OPTION_SOL_MAX_RT and OPTION_INF_MAX_RT from the "DHCP Option Codes" table of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Registry.

There have been a few cases where IANA used the wrong table; while we will hopefully catch that ...

You could even provide the URL for the table (http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml).

9.       A general issue ... I wonder whether we have a kind of catch-22. As DHCP is interface specific, and the tunnel interface may not be able to 'come up' until after the address is assigned, what interface is this 'DHCPv4' (4o6) client associated with? Is it the v6 interface? Or a 'provisional' tunnel interface? Or, is this left up to the implementation to deal with (since in one sense it probably doesn't matter much - except of course if one was trying to bring up multiple tunnel interfaces over the same v6 interface; but that requires other special logic so may not be a concern).

As well as the following minor nits (note that I did NOT apply changes to the message names as indicated in 2 above):

In section 1, Introduction:

   This document describes a transport mechanism to carry DHCPv4
   messages using DHCPv6 protocol, for the dynamic provisioning of IPv4
   addresses and other DHCPv4 specific configuration parameters across
   IPv6-only networks.  It leverages the existing infrastructure for
   DHCPv4, e.g. failover, DNS updates, leasequery, etc.

Line 2, should be (add the, remove comma):

   messages using the DHCPv6 protocol for the dynamic provisioning of IPv4

In section 3, Terminology:

   CPE:                  Customer Premises Equipment (also known as

                         Customer Provided Equipment), which provides

                         the access of devices connected to Local Area

                         Network (typically at customer's site/home) to

                         Internet Service Provider's network.
Should be (add a and the twice):

   CPE:                  Customer Premises Equipment (also known as

                         Customer Provided Equipment), which provides

                         the access of devices connected to a Local Area

                         Network (typically at the customer's site/home) to

                         The Internet Service Provider's network.

In section 4, Architecture Overview:

   Typically, a 4o6 DHCP client communicates with the 4o6 DHCP servers

   using well-known All_DHCP_Relay_Agents_and_Servers multicast address.

Should be (add the):

   Typically, a 4o6 DHCP client communicates with the 4o6 DHCP servers

   Using the well-known All_DHCP_Relay_Agents_and_Servers multicast address.

And also:

   Client SHOULD request the 4o6 Server Address Option from a DHCPv6

   server and the server may be configured to respond to the client with

   one such option that contains one or more unicast addresses of the

   4o6 DHCP Servers.  The server includes 4o6 Server Address Option in

   Advertise and Reply messages.  The format of the option is defined in

   Section 6.3<http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-03#section-6.3>.

Should be (add the twice):

   The client SHOULD request the 4o6 Server Address Option from a DHCPv6

   server and the server may be configured to respond to the client with

   one such option that contains one or more unicast addresses of the

   4o6 DHCP Servers.  The server includes the 4o6 Server Address Option in

   Advertise and Reply messages.  The format of the option is defined in

   Section 6.3<http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-03#section-6.3>.

In section 5.2, Message formats:

   msg-type        Identifies message type.  It can be either

                   BOOTREQUESTV6 (TBD) or BOOTREPLYV6 (TBD) which

                   corresponds to the Boot-request-v6 or Boot-reply-v6,

                   respectively.

Should be (add the):

   msg-type        Identifies the message type.  It can be either

                   BOOTREQUESTV6 (TBD) or BOOTREPLYV6 (TBD) which

                   corresponds to the Boot-request-v6 or Boot-reply-v6,

                   respectively.

In section 7, Use of the Boot-Request-v4 Unicast Flag

   A DHCPv4 client conforming to the [RFC2131<http://tools.ietf.org/html/rfc2131>] may send its DHCPREQUEST

   message to either broadcast or unicast address depending on its

   state.  For example, the client in the RENEWING state uses a unicast

   address to contact a DHCPv4 server to renew its lease.  The client in

   the REBINDING state uses a broadcast address.  If there is a DHCPv4

   relay agent in the middle, a client in the RENEWING state may send a

   DHCPREQUEST message to the unicast address of the relay agent.  In

   such case the server can't find out whether the client sent a message

   to a unicast or broadcast address and thus it can't determine the

   client's state.  [RFC5010<http://tools.ietf.org/html/rfc5010>] introduced the "Flags Suboption" which

   relay agents add to relayed messages to indicate whether broadcast or

   unicast was used by the client.

Should be (remove the, replace "it can't find out" with "the server may be unable to", replace "can't" with "is unable to"):

   A DHCPv4 client conforming to[RFC2131<http://tools.ietf.org/html/rfc2131>] may send its DHCPREQUEST

   message to either broadcast or unicast address depending on its

   state.  For example, the client in the RENEWING state uses a unicast

   address to contact a DHCPv4 server to renew its lease.  The client in

   the REBINDING state uses a broadcast address.  If there is a DHCPv4

   relay agent in the middle, a client in the RENEWING state may send a

   DHCPREQUEST message to the unicast address of the relay agent.  In

   such case the server is unable to determine whether the client sent a message

   to a unicast or broadcast address and thus the server may be unable to determine the

   client's state.  [RFC5010<http://tools.ietf.org/html/rfc5010>] introduced the "Flags Suboption" which

   relay agents add to relayed messages to indicate whether broadcast or

   unicast was used by the client.

And in the following, drop "the" before the RFC?

   In DHCPv4 over DHCPv6, IPv6 is used to deliver DHCPv4 messages to the

   4o6 DHCP Server.  There is no relation between the outer IPv6 address

   and the inner DHCPv4 message.  So the server is not able to know

   whether the DHCPv4 messages should have been sent using broadcast or

   unicast in IPv4 by checking the IPv6 address.  This is similar to the

   case addressed by the [RFC5010<http://tools.ietf.org/html/rfc5010>].

And in the following add "The" before Client (The client MUST...):

   In order to allow the server to determine the client's state, the

   "Unicast" flag is carried in the Boot-request-v6 message.  Client

   MUST set this flag to 1 when the DHCPv4 message would have been sent

In section 8, 4o6 DHCP Client Behavior:

In the first bullet, change doesn't to does not.

And:

   o  If the client receives both options, it SHOULD enable the DHCPv4

      -over-DHCPv6 function and send requests to the unicast address(es)

      in the 4o6 Server Address Option.

Should be (add SHOULD and add each of):

   o  If the client receives both options, it SHOULD enable the DHCPv4

      -over-DHCPv6 function and SHOULD send requests to each of the unicast address(es)

      in the 4o6 Server Address Option.

Add "the" before "DHCP protocol" in:

   The client signaled by the server to use DHCPv4 over DHCPv6 SHOULD

   cease to send DHCPv4 messages using DHCP protocol described in

Also:

   Client MUST follow rules defined in Section 7<http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-03#section-7> when setting Unicast

   flag.

May be improved by adding "based on the DHCPv4 destination):

   Client MUST follow rules defined in Section 7<http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-03#section-7> when setting Unicast

   Flag based on the DHCPv4 destination.

And in:

   On receiving a Boot-reply-v6 message, the client MUST look for the

   BOOTP Message option within this message.  If this option is not

   found, the Boot-reply-v6 message is discarded.  If the BOOTP Message

   Option presents, the client extracts the DHCPv4 message it contains

   and processes it as described in section 4.4 of [RFC2131]<http://tools.ietf.org/html/rfc2131#section-4.4>.

The "presents" is odd. Did you mean "is present"?

And finally, in section 11:

   which can cause an amplification attack.  To avoid this, the client

   MUST check if there are repeated IPv6 addresses in a 4o6 Server

   Address Option when receiving one.  The client MUST ignore those

   duplicated unicast IPv6 addresses.

Perhaps change 'repeated' to 'duplicate'? As you use that in the next sentence, so better to be consistent?

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Sunday, November 24, 2013 5:03 PM
To: [email-masked]
Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

At the time of this writing, there is no IPR reported against this draft.

Bernie will be the document shepherd.

Thanks,

-          Tomek & Bernie

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Dec 2013 11:08:53 -0500

> anyone with an answer to this?

DHCPv4 over DHCPv6 provides a mechanism for transporting DHCPv4 packets over an IPv6 network layer without the support of a pre-established 4over6 tunnel.   It has the added benefit of providing information about the IPv6 network over which the request is sent, as a result of having passed through one or more DHCPv6 relay agents.   This information would not be available in the case of a DHCPv4 packet carried directly over a pre-established tunnel.

I would characterize it as a solution that can work well in the context of an existing IPv6 network with DHCPv6 service, and that is general in the sense that it does not assume a particular use model other than "DHCPv4 over a plain IPv6 network."   But you are right to point out that it is not a "general solution" if "general" is left unqualified.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 06 Dec 2013 11:17:44 -0500

Le 2013-11-24 17:02, Bernie Volz (volz) a écrit :
> Folks, the authors of draft-ietf-dhc-dhcpv4-over-dhcpv6-03
> (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-03.txt)
> believe it is ready for working group last call. Please review this
> draft and indicate whether or not you feel it is ready to be published.
> Your input is important! Please respond by Dec 9^th , 2013.

Here's my review. I tried not to read Bernie's review so as not to be 
influenced by it, so there may be some overlap.

The major comments are:

1. Section "4. Architecture Overview" ends before explaining a crucial 
point: what does the client do with the IPv4 configuration it has 
received? For example, when it receives an IPv4 address, does it assign 
it to an interface? Which one? We need a general idea of how this works 
before this section is over.

(Now that I have read the full draft, I realize that this is not 
discussed at all. If this is out of scope, then that means this RFC is 
not readily usable without another RFC describing how to use it in one 
particular context. That could be fine if that's the intent, but then 
that should be stated explicitly in this RFC.)

2. I already mentioned that we should have only one option for enabling 
and conveying the 4o6 server address (unicast or multicast). Just go 
with Bernie's suggestion.

Minor comments inline...

Simon

>
>
>
>
> DHC Working Group                                                 Q. Sun
> Internet-Draft                                                    Y. Cui
> Intended status: Standards Track                     Tsinghua University
> Expires: May 26, 2014                                       M. Siodelski
>                                                                      ISC
>                                                              S. Krishnan
>                                                                 Ericsson
>                                                                I. Farrer
>                                                      Deutsche Telekom AG
>                                                        November 22, 2013
>
>
>                       DHCPv4 over DHCPv6 Transport
>                   draft-ietf-dhc-dhcpv4-over-dhcpv6-03
>
> 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 as well as new DHCPv6 options are defined for the purpose of
>    conveying DHCPv4 messages through IPv6 networks.
>
> Status of This Memo
>
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF).  Note that other groups may also distribute
>    working documents as Internet-Drafts.  The list of current Internet-
>    Drafts is at http://datatracker.ietf.org/drafts/current/.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    This Internet-Draft will expire on May 26, 2014.
>
> Copyright Notice
>
>    Copyright (c) 2013 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
>
>    This document is subject to BCP 78 and the IETF Trust's Legal
>
>
>
> Sun, et al.               Expires May 26, 2014                  [Page 1]
> 
> Internet-Draft             DHCPv4 over DHCPv6              November 2013
>
>
>    Provisions Relating to IETF Documents
>    (http://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>    carefully, as they describe your rights and restrictions with respect
>    to this document.  Code Components extracted from this document must
>    include Simplified BSD License text as described in Section 4.e of
>    the Trust Legal Provisions and are provided without warranty as
>    described in the Simplified BSD License.
>
> Table of Contents
>
>    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
>    2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
>    3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
>    4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   3
>    5.  New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . .   5
>      5.1.  Message Types . . . . . . . . . . . . . . . . . . . . . .   5
>      5.2.  Message Formats . . . . . . . . . . . . . . . . . . . . .   5
>      5.3.  Boot-request-v6 Message Flags . . . . . . . . . . . . . .   6
>      5.4.  Boot-reply-v6 Message Flags . . . . . . . . . . . . . . .   6
>    6.  New DHCPv6 Options  . . . . . . . . . . . . . . . . . . . . .   7
>      6.1.  BOOTP Message Option Format . . . . . . . . . . . . . . .   7
>      6.2.  DHCPv4-over-DHCPv6 Enable Option Format . . . . . . . . .   7
>      6.3.  4o6 Server Address Option Format  . . . . . . . . . . . .   8
>    7.  Use of the Boot-request-v6 Unicast Flag . . . . . . . . . . .   8
>    8.  4o6 DHCP Client Behavior  . . . . . . . . . . . . . . . . . .   9
>    9.  Relay Agent Behavior  . . . . . . . . . . . . . . . . . . . .  10
>    10. 4o6 DHCP Server Behavior  . . . . . . . . . . . . . . . . . .  11
>    11. Security Considerations . . . . . . . . . . . . . . . . . . .  11
>    12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
>    13. Contributors List . . . . . . . . . . . . . . . . . . . . . .  12
>    14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
>      14.1.  Normative References . . . . . . . . . . . . . . . . . .  12
>      14.2.  Informative References . . . . . . . . . . . . . . . . .  13
>    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13
>
> 1.  Introduction
>
>    As the migration towards IPv6 continues, IPv6-only networks will
>    become more prevalent.  At the same time, IPv4 connectivity will
>    continue to be provided as a service over IPv6-only networks.  In
>    addition to providing IPv4 addresses for clients of this service,
>    other IPv4 configuration parameters may also need to be provided
>    (e.g.  addresses of IPv4-only services).
>
> Sun, et al.               Expires May 26, 2014                  [Page 2]
> 
> Internet-Draft             DHCPv4 over DHCPv6              November 2013
>
>
> 2.  Requirements Language
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].
>
> 3.  Terminology
>
>    This document makes use of the following terms:
>
>    4o6 DHCP Client:      A DHCP client which supports both DHCPv6
>                          protocol [RFC3315] as well as the DHCPv4 over
>                          DHCPv6 protocol described in this document.
>                          Such a client is capable to request its IPv6

s/to request/of requesting/

>                          configuration using DHCPv6 and IPv4
>                          configuration using DHCPv4 over DHCPv6.
>
>    4o6 DHCP Server:      A DHCP server that is capable of processing
>                          DHCPv4 packets encapsulated in the BOOTP
>                          Message option (defined below).
>
>    DHCPv4 over DHCPv6:   A protocol described in this document, which is
>                          used to carry DHCPv4 messages in the payload of
>                          DHCPv6 messages.
>
> 4.  Architecture Overview
>
>    The architecture described in this document addresses a typical use
>    case, where a DHCP client's uplink supports IPv6 only and the Service
>    Provider's network supports IPv6 and limited IPv4 services.  In this
>    scenario, the client can only use the IPv6 network to access IPv4
>    services.  So it must configure IPv4 services using IPv6 as the
>    underlying network protocol.
>
>    Although the purpose of this document is to address the problem of
>    communication between the DHCPv4 client and the DHCPv4 server, the
>    mechanism that it describes does not restrict the transported
>    messages types only to DHCPv4.  As the DHCPv4 message is a special
>    type of the BOOTP message, BOOTP messages can also be transported
>
>
>
> Sun, et al.               Expires May 26, 2014                  [Page 3]
> 
> Internet-Draft             DHCPv4 over DHCPv6              November 2013
>
>
>    using the same mechanism.
>
>    DHCP clients can be running on CPE devices, end hosts or any other
>    device which supports the DHCP client function.  At the time of
>    writing, DHCP clients on CPE devices are easier to modify compared to
>    those implemented on end hosts.  As a result, this document uses the
>    CPE as an example for describing the mechanism.  This does not
>    preclude any end-host, or other device requiring IPv4 configuration,
>    from implementing the mechanism in the future.
>
>    This mechanism works by carrying DHCPv4 messages encapsulated within
>    DHCPv6 messages.  Figure 1, below, illustrates one possible
>    deployment architecture.
>
>    The 4o6 DHCP client implements a new DHCPv6 message called Boot-
>    request-v6, which contains a new option called BOOTP Message option.
>    The format of this option is described in Section 6.1.
>
>    The DHCPv6 message can be transmitted either via DHCPv6 Relay Agents
>    or directly to the 4o6 DHCP Server.  The server replies with a Boot-
>    reply-v6 message, which is a new DHCPv6 message type.  This message
>    carries the DHCPv4 response encapsulated in the BOOTP Message option.
>
>                   _____________             _____________
>                  /             \           /             \
>                  |             |           |             |
>         +--------+-+  IPv6   +-+-----------+-+  IPv6   +-+--------+
>         | 4o6 DHCP | network |    DHCPv6     | network | 4o6 DHCP |
>         |  Client  +---------+  Relay Agent  +---------+  Server  |
>         | (on CPE) |         |               |         |          |
>         +--------+-+         +-+-----------+-+         +-+--------+
>                  |             |           |             |
>                  \_____________/           \_____________/
>

Could the left "IPv6 network" be renamed to "IPv6 link"?

>
>                       Figure 1: Architecture Overview
>
>    By default, the DHCPv4-over-DHCPv6 function MUST be disabled on the
>    client.  Before the client can use DHCPv4 over DHCPv6, it MUST obtain
>    the IPv6 configuration.  It requests the DHCPv4-over-DHCPv6 Enable
>    option by sending its code in Option Request Option (ORO) described
>    in [RFC3315].  The DHCPv6 server includes the DHCPv4-over-DHCPv6
>    Enable option in response to a client's request to instruct the
>    client to use DHCPv4 over DHCPv6 for IPv4 configuration.  The format
>    of the DHCPv4-over-DHCPv6 Enable option is described in Section 6.2.
>
> Sun, et al.               Expires May 26, 2014                  [Page 4]
> 
> Internet-Draft             DHCPv4 over DHCPv6              November 2013
>
>
>    Section 6.3.
> 5.  New DHCPv6 Messages
>    There are two new DHCPv6 messages defined in this document which
>    carry DHCPv4 messages between a client and a server using DHCPv6
>    protocol: Boot-request-v6 and Boot-reply-v6.  This section describes
>    the structures of these messages.
>
> 5.1.  Message Types
>
>    BOOTREQUESTV6 (TBD):  Identifies a Boot-request-v6 message.  A 4o6
>                          DHCP client sends this message to a 4o6 DHCP
>                          server.  The BOOTP Message Option carried by
>                          this message contains a BOOTREQUEST message
>                          that the 4o6 DHCP client uses to request IPv4
>                          configuration parameters from the server.
>
>    BOOTREPLYV6 (TBD):    Identifies a Boot-reply-v6 message.  A 4o6 DHCP
>                          server sends this message to a 4o6 DHCP client.
>                          It contains a BOOTP Message Option carrying a
>                          BOOTREPLY message in response to a BOOTREQUEST
>                          received by the server in the BOOTP Message
>                          Option of the Boot-request-v6 message.
>
> 5.2.  Message Formats
>
>    Both DHCPv6 messages defined in this document share the following
>    format:
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Please move the previous two lines to the right by one character.

>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |    msg-type   |                     flags                     |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                                                               |
>      .                            options                            .
>      .                           (variable)                          .
>      |                                                               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>                       Figure 2: Architecture Overview
>
>
>
>
> Sun, et al.               Expires May 26, 2014                  [Page 5]
> 
> Internet-Draft             DHCPv4 over DHCPv6              November 2013
>
>
>    flags           Specifies flags which provide additional information
>                    required by the server to process a DHCPv4 message
>                    encapsulated in Boot-request-v6 message, or required
>                    by the client to process DHCPv4 message encapsulated
>                    in Boot-reply-v6 message.
>
>    options         The options carried by the message.  The BOOTP
>                    Message Option described in Section 6.1 MUST be
>                    carried by the message.
>
> 5.3.  Boot-request-v6 Message Flags
>
>    The "flags" field of the Boot-request-v6 is used to carry additional
>    information which may be used by the server to process the
>    encapsulated DHCPv4 message.  Currently only one bit of this field is
>    used.  Remaining bits are reserved for the future use.  The "flags"
>    field has the following format:
>
>              0                   1                   2
>              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4

Please move the previous two lines to the right by one character. Also 
remove the "4" at the end.

>              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>              |U|                 Reserved                    |
>              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>                   Figure 3: Boot-request-v6 flags format
>
>    U               Unicast Flag.  If set to 1, it indicates that the
>                    DHCPv4 message encapsulated with the Boot-request-v6
>                    message would be sent to a unicast address if it was
>                    sent using IPv4.  If this flag is set to 0, it
>                    indicates that the DHCPv4 message would be sent to

Add "the" here.

>                    broadcast address if it was sent using IPv4.
>
>    Reserved        Bits reserved for future use.  A client that doesn't
>                    implement future extensions using these bits MUST set
>                    them to 0.

Suggestion: replace the previous sentence with the idiomatic "MUST be 
set to zero when sending and MUST be ignored when receiving." Leave it 
to future RFCs to override that.

>
> 5.4.  Boot-reply-v6 Message Flags
>
>    This document introduces no flags to be carried in the "flags" field
>    of the Boot-reply-v6 message.  They are all reserved for the future
>    use.  The 4o6 Server MUST set all bits of this field to 0 and the 4o6
>    client MUST ignore the content in this field.
>
>
>
> Sun, et al.               Expires May 26, 2014                  [Page 6]
> 
> Internet-Draft             DHCPv4 over DHCPv6              November 2013
>
>
> 6.  New DHCPv6 Options
>
> 6.1.  BOOTP Message Option Format
>
>    The BOOTP Message option carries a BOOTP message that is sent by the
>    client or the server.  Such BOOTP messages exclude any IP or UDP
>    headers.
>
>    The format of the BOOTP Message Option is:
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Move the previous two lines one character to the right.

>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |        OPTION_BOOTP_MSG       |           option-len          |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                                                               |
>      .                         BOOTP-message                         .
>      .                                                               .
>      .                                                               .
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>                    Figure 4: BOOTP Message Option Format
>
>    option-code     OPTION_BOOTP_MSG (TBD).
>
>    option-len      Length of BOOTP message.
>
>    BOOTP-message   The BOOTP message sent by the client or the server.
>                    In a Boot-request-v6 message it contains a
>                    BOOTREQUEST message sent by a client.  In a Boot-
>                    reply-v6 message it contains a BOOTREPLY message sent
>                    by a server in response to a client.
>
> 6.2.  DHCPv4-over-DHCPv6 Enable Option Format
>
>    The DHCPv4-over-DHCPv6 Enable option is sent by the DHCPv6-only
>    server to signal that the client SHOULD use DHCPv4 over DHCPv6 to
>    obtain IPv4 configuration.  The server includes this option if it is
>    requested by the client.
>
>    The format of the DHCPv4-over-DHCPv6 Enable option is:
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Please move the previous two lines one character to the right.

>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |  OPTION_DHCP4_O_DHCP6_ENABLE  |           option-len          |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
> Sun, et al.               Expires May 26, 2014                  [Page 7]
> 
> Internet-Draft             DHCPv4 over DHCPv6              November 2013
>
>
>              Figure 5: DHCPv4-over-DHCPv6 Enable Option Format
>
>    option-code     OPTION_DHCP4_O_DHCP6_ENABLE (TBD).
>
>    option-len      0
>
> 6.3.  4o6 Server Address Option Format
>
>    The 4o6 Server Address option carries one or more unicast IPv6
>    addresses of the 4o6 DHCP Server(s).  The DHCPv6-only server includes
>    this option if it is requested by the client.
>
>    The format of the 4o6 Server Address option is:
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Please move the previous two lines one character to the right.

>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | OPTION_DHCP4_O_DHCP6_SERVER   |           option-len          |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                                                               |
>      .                        IPv6 Address(es)                       .
>      .                                                               .
>      .                                                               .
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>                 Figure 6: 4o6 Servers Address Option Format
>
>    option-code     OPTION_DHCP4_O_DHCP6_SERVER (TBD).
>
>    option-len      Length of the IPv6 address(es) carried by the option,
>                    i.e. multiple of 16 octets.
>
>    IPv6 Address    One or more IPv6 addresses of the 4o6 DHCP Server(s).
>
> 7.  Use of the Boot-request-v6 Unicast Flag
>
>    A DHCPv4 client conforming to the [RFC2131] may send its DHCPREQUEST
>    client's state.  [RFC5010] introduced the "Flags Suboption" which
> Sun, et al.               Expires May 26, 2014                  [Page 8]
> 
> Internet-Draft             DHCPv4 over DHCPv6              November 2013
>
>
>    case addressed by the [RFC5010].
>
>    to the unicast address if using DHCPv4 over IPv4.  This flag MUST be
>    set to 0 if the DHCPv4 client would have sent the message to the
>    broadcast address in IPv4.  The choice whether a given message should
>    be sent to a broadcast or unicast address MUST be made based on the

The intent behind that MUST is fuzzy. Suggestion: replace with "is made 
based on..."

>    [RFC2131] and its extensions.
>
> 8.  4o6 DHCP Client Behavior
>
>    The DHCPv4-over-DHCPv6 function MUST be disabled by default.  The
>    client MUST obtain its IPv6 configuration before using DHCPv4 over
>    DHCPv6.  The client that intends to use DHCPv4 over DHCPv6 MUST
>    request the DHCPv4-over-DHCPv6 Enable Option and SHOULD request the
>    4o6 Server Address Option in the Option Request Option (ORO) in every
>    Solicit, Request, Renew and Information-request messages.  The 4o6
>    DHCP client MUST NOT request the DHCPv4-over-DHCPv6 Enable Option nor
>    the 4o6 Server Address Option in the Boot-request-v6 message.
>
>    The DHCPv6 server MAY include these options in the responses to the
>    client.  The client determines how to enable the DHCPv4-over-DHCPv6
>    function based on the presence / absence of the two options:
>
>    o  If the client doesn't receive the DHCPv4-over-DHCPv6 Enable
>       option, it MUST NOT enable the DHCPv4-over-DHCPv6 function.  In
>       the case where the DHCPv4 over DHCPv6 service is running, the
>       client MUST disable the function.

I don't understand the last sentence. What is a "DHCPv4 over DHCPv6 
service"?

>
>    o  If the client receives the DHCPv4-over-DHCPv6 Enable Option but no
>       4o6 Servers Address Option, it SHOULD enable the DHCPv4-over-

Why not MUST?

>       DHCPv6 function and use IPv6 All_DHCP_Relay_Agents_and_Servers
>       multicast address to communicate with servers and relays.
>

Why not MUST?

>    o  If the client only receives 4o6 Server Address Option, the client
>
>
>
> Sun, et al.               Expires May 26, 2014                  [Page 9]
> 
> Internet-Draft             DHCPv4 over DHCPv6              November 2013
>
>
>       MUST ignore the 4o6 Server Address Option and MUST NOT enable the
>       DHCPv4-over-DHCPv6 function.
>
>    The client supporting DHCPv4 over DHCPv6 SHOULD use Information
>    Refresh Time Option [RFC4242] to refresh the status of DHCPv4-over-
>    DHCPv6 service as well as other DHCPv6 configuration data.
>

Why not MUST?

>    [RFC2131] and use the DHCPv4 over DHCPv6 to request IPv4
>    configuration from the 4o6 DHCP Server.

This directive needs to be rewritten so that it applies only to the 
interface in question, not to the whole client node. It should also be 
rewritten to account for the fact that the client may not have been 
doing regular DHCPv4 in the first place (you cannot cease doing 
something that you are not doing).

>    The DHCPv4 message is stored
>    verbatim in the BOOTP Message option carried by the Boot-request-v6
>    message.  The client MUST put exactly one BOOTP Message option into a
>    single Boot-request-v6 message.
>
>    Client MUST follow rules defined in Section 7 when setting Unicast
>    flag.
>
>    If the client has not received the 4o6 Server Addresses option from
>    the DHCPv6 server, it transmits the Boot-request-v6 message as
>    specified in Section 13 of [RFC3315].  If the client received this
>    option, it SHOULD send Boot-request-v6 message to all unicast
>    addresses listed in the option.
>
>    and processes it as described in section 4.4 of [RFC2131].
>
>    When dealing with IPv4 configuration, the 4o6 DHCP client SHOULD

Why not MUST?

>    follow the normal DHCPv4 retransmission requirements and strategy as
>    specified in section 4.1 of [RFC2131].  There are no explicit
>    transmission parameters associated with a Boot-request-v6 message.
>
>    The 4o6 DHCP client MUST implement [RFC4361] to ensure that the
>    device correctly identifies itself.
>
> 9.  Relay Agent Behavior
>
>    When a DHCPv6 relay agent receives a Boot-request-v6 message, it may
>    not recognize this message.  It can just forward this message as in
>    [I-D.ietf-dhc-dhcpv6-unknown-msg].
>
>    Additionally, the DHCPv6 relay agent MAY allow the configuration of a
>    dedicated DHCPv4 over DHCPv6 specific destination address(es),
>    differing from the address(es) of the DHCPv6-only server(s).  To
>    implement this function, the relay checks the received DHCPv6 message
>
>
>
> Sun, et al.               Expires May 26, 2014                 [Page 10]
> 
> Internet-Draft             DHCPv4 over DHCPv6              November 2013
>
>
>    type and forwards according to the following logic:
>
>    1.  If the message type is BOOTREQUESTV6, the packet is relayed to
>        the configured 4o6 DHCP Server's address(es) in the form of
>        normal DHCPv6 packet (i.e. DHCPv6/UDP/IPv6).
>
>    2.  For any other DHCPv6 message type, forward according to section
>        20 of [RFC3315].
>
>    The above logic only allows for separate relay destinations
>    configured on the relay agent closest to the client (single relay
>    hop).  Multiple relaying hops are not considered in the case of
>    separate relay destinations.
>
> 10.  4o6 DHCP Server Behavior
>
>    When the server receives a Boot-request-v6 message from a client, it
>    searches for the BOOTP Message Option.  The server discards the
>    packet without this option.  The server MAY notify an administrator
>    about the receipt of a malformed packet.  The mechanism for this
>    notification is out of scope for this document
>
>    If the server finds a valid BOOTP Message option, it extracts the
>    original DHCPv4 message and the contents of the "flags" field carried
>    in the Boot-request-v6 message and uses them to generate the
>    appropriate DHCPv4 response (server to client message).  The response
>    is generated as described in [RFC2131] with the exception that the
>    server SHOULD use the information carried in the "flags" field of the
>    Boot-request-v6 message to find out whether the client's message
>    would have been sent to the broadcast or unicast address if DHCPv4
>    protocol was used.  This is useful for the server to determine the
>    state of the client.  The use of the "flags" field is described in
>    detail in Section 7.
>
>    When appropriate DHCPv4 response is generated, the 4o6 Server places
>    it in the payload of a BOOTP Message Option, which it puts into the
>    Boot-reply-v6 message.
>
>    If the Boot-request-v6 message was received directly by the server,
>    the Boot-reply-v6 message MUST be unicast from the interface on which
>    the original message was received.
>
>    If the Boot-request-v6 message was received in a Relay-forward
>    message, the server creates a Relay-reply message with the Boot-
>    reply-v6 message in the payload of a Relay Message option, and
>    responds as described in section 20.3 of [RFC3315].
>
> 11.  Security Considerations
>
>
>
> Sun, et al.               Expires May 26, 2014                 [Page 11]
> 
> Internet-Draft             DHCPv4 over DHCPv6              November 2013
>
>
>    In this specification, DHCPv4 messages are encapsulated in the newly
>    defined option and messages.  This is similar to the handling of the
>    current relay agent messages.  In order to bypass firewalls or
>    network authentication gateways, a malicious attacker may leverage
>    this feature to convey other messages using DHCPv6, i.e. use DHCPv6
>    as a form of encapsulation.  However, the potential risk from this is
>    no more severe than that with the current DHCPv4 and DHCPv6 practice.
>
>    There are chances that a rogue DHCPv6 server may reply with a 4o6
>    Server Address Option containing duplicated unicast IPv6 addresses,
> 12.  IANA Considerations
>    IANA is requested to allocate three DHCPv6 option codes for use by
>    OPTION_BOOTP_MSG, OPTION_DHCP4_O_DHCP6_ENABLE and
>    OPTION_DHCP4_O_DHCP6_SERVERS, and two DHCPv6 message type codes for
>    the BOOTREQUESTV6 and BOOTREPLYV6.
>
> 13.  Contributors List
>
>    Many thanks to Ted Lemon, Bernie Volz, Tomek Mrugalski, Yuchi Chen
>    and Cong Liu, for their great contributions to the draft.
>
> 14.  References
>
> 14.1.  Normative References
>
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", BCP 14, RFC 2119, March 1997.
>
>    [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol", RFC
>               2131, March 1997.
>
>    [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
>               and M. Carney, "Dynamic Host Configuration Protocol for
>               IPv6 (DHCPv6)", RFC 3315, July 2003.
>
>    [RFC4242]  Venaas, S., Chown, T., and B. Volz, "Information Refresh
>               Time Option for Dynamic Host Configuration Protocol for
>               IPv6 (DHCPv6)", RFC 4242, November 2005.
>
>    [RFC4361]  Lemon, T. and B. Sommerfeld, "Node-specific Client
>               Identifiers for Dynamic Host Configuration Protocol
>               Version Four (DHCPv4)", RFC 4361, February 2006.
>
>
>
> Sun, et al.               Expires May 26, 2014                 [Page 12]
> 
> Internet-Draft             DHCPv4 over DHCPv6              November 2013
>
>
> 14.2.  Informative References
>
>    [I-D.ietf-dhc-dhcpv6-unknown-msg]
>               Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6
>               Messages", draft-ietf-dhc-dhcpv6-unknown-msg-03 (work in
>               progress), November 2013.
>
>    [RFC5010]  Kinnear, K., Normoyle, M., and M. Stapp, "The Dynamic Host
>               Configuration Protocol Version 4 (DHCPv4) Relay Agent
>               Flags Suboption", RFC 5010, September 2007.
>
> Authors' Addresses
>
>    Qi Sun
>    Tsinghua University
>    Beijing  100084
>    P.R.China
>
>    Phone: +86-10-6278-5822
>    Email: [email-masked]
>
>
>    Yong Cui
>    Tsinghua University
>    Beijing  100084
>    P.R.China
>
>    Phone: +86-10-6260-3059
>    Email: [email-masked]
>
>
>    Marcin Siodelski
>    950 Charter Street
>    Redwood City, CA  94063
>    USA
>
>    Phone: +1 650 423 1431
>    Email: [email-masked]
>
>
>    Suresh Krishnan
>    Ericsson
>
>    Email: [email-masked]
>
>
>
>
>
>
>
> Sun, et al.               Expires May 26, 2014                 [Page 13]
> 
> Internet-Draft             DHCPv4 over DHCPv6              November 2013
>
>
>    Ian Farrer
>    Deutsche Telekom AG
>    GTN-FM4,Landgrabenweg 151
>    Bonn, NRW  53227
>    Germany
>
>    Email: [email-masked]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Sun, et al.               Expires May 26, 2014                 [Page 14]

---

From: Cong Liu <[email-masked]>
Date: Wed, 11 Dec 2013 19:49:15 +0800

Hi Simon,

2013/12/7 Simon Perreault <[email-masked]>

> point: what does the client do with the IPv4 configuration it has received?
> For example, when it receives an IPv4 address, does it assign it to an
> interface? Which one? We need a general idea of how this works before this
> section is over.
>
> (Now that I have read the full draft, I realize that this is not discussed
> at all. If this is out of scope, then that means this RFC is not readily
> usable without another RFC describing how to use it in one particular
> context. That could be fine if that's the intent, but then that should be
> stated explicitly in this RFC.)
>

When client receives an IPv4 address, it will assign it because it's
DHCPv4. The difference is to which interface the IPv4 address is assigned.
It's described in -00 version of this draft: "The IPv4 address allocated
from the server MAY be assigned to a
different interface from the IPv6 interface requesting the information."
Maybe it should be added back to cover this issue.

Best Regards,
Cong

---

From: Qi Sun <[email-masked]>
Date: Wed, 11 Dec 2013 23:22:55 +0800

Hi Bernie, 

Many thanks for your thorough review! We will address the issues you mentioned in the next version.

> 2.       I think we should rename the messages to be BOOTP, not BOOT. BOOTPREQUESTV6 and BOOTPREPLYV6 (and Bootp-request-v6, Bootp-reply-v6). (I also wonder whether we really need the v6, but it ma…

I check the the RFC 951 (Bootstrap Protocol) that defines BOOTP messages. The two message types defined is BOOTREQUEST and BOOTREPLY. In order to be consistent with that naming system, we chose BOOTREQUESTV6 and BOOTREPLYV6 as the new message names in DHCPv4 over DHCPv6. 

Would it be OK if we keep the current message names?

Best Regards,
Qi

---

From: Simon Perreault <[email-masked]>
Date: Wed, 11 Dec 2013 11:03:05 -0500

Le 2013-12-11 06:49, Cong Liu a écrit :
>     1. Section "4. Architecture Overview" ends before explaining a
>     crucial point: what does the client do with the IPv4 configuration
>     it has received? For example, when it receives an IPv4 address, does
>     it assign it to an interface? Which one? We need a general idea of
>     how this works before this section is over.
>
>     discussed at all. If this is out of scope, then that means this RFC
>     is not readily usable without another RFC describing how to use it
>     in one particular context. That could be fine if that's the intent,
>     but then that should be stated explicitly in this RFC.)
>
>

I would expect much more substantial informative text to be added to the 
draft. Some things can be left out of scope for this draft, but at least 
enumerating and describing what those things are is necessary.

Simon

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 11 Dec 2013 16:18:58 +0000

Hi:

What's in a name anyway? (http://idioms.thefreedictionary.com/What's+in+a+name%3F)

My concern with BOOT is that people might confuse it with booting, not address assignment. Even BOOTP may not be the best. (I think I may have suggested using the underlying v4 protocol name early on?)

If no one else has any view on this, leave it alone. I just wanted to raise this issue to make sure the WG was OK with the message names.

-          Bernie

From: Qi Sun [mailto:[email-masked]]
Sent: Wednesday, December 11, 2013 10:23 AM
To: Bernie Volz (volz)
Cc: [email-masked]; [email-masked]
Subject: Re: WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

Hi Bernie,

About item 2:

Best Regards,
Qi

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Sunday, November 24, 2013 5:03 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

Thanks,

-          Tomek & Bernie

---

From: Marcin Siodelski <[email-masked]>
Date: Wed, 11 Dec 2013 20:39:31 +0100

On Fri, Dec 6, 2013 at 4:05 PM, Bernie Volz (volz) <[email-masked]> wrote:
>
> 9.       A general issue … I wonder whether we have a kind of catch-22. As
> DHCP is interface specific, and the tunnel interface may not be able to
> ‘come up’ until after the address is assigned, what interface is this
> ‘DHCPv4’ (4o6) client associated with? Is it the v6 interface? Or a
> ‘provisional’ tunnel interface? Or, is this left up to the implementation to
> deal with (since in one sense it probably doesn’t matter much – except of
> course if one was trying to bring up multiple tunnel interfaces over the
> same v6 interface; but that requires other special logic so may not be a
> concern).
>
>

I wonder if we have to associate the 4o6 client with any interface
before the tunnel configuration arrives. The draft mandates that
conforming implementation uses RFC4361 so there should be no problem
of lacking chaddr on the client side. I think we should also mention
that RFC6842 should be implemented on the server side so as it
respects a client identifier, not chaddr.
Before the client gets the tunnel configuration the tunnel interface
doesn't exist. The 4o6 client just generates the client identifier
(unique by IAID) for the tunnel to be established. Once the v4
configuration is complete, the tunnel is created and the client
associates the client identifier with this tunnel/interface.

Marcin

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Dec 2013 23:20:11 -0500

> associates the client identifier with this tunnel/interface.

I think it's important to be aware that this function is for "getting an IPv4 configuration," not "configuring an interface."   The document should certainly say as much as it can about what to do with the configuration, but we're really documenting a mechanism here for getting a configuration from a DHCP server, not documenting specific use cases for that mechanism.   So e.g. the expectation is that if lw4over6 uses this mechanism, it will say what to do with the information gathered as a result.   If some future spec needs this mechanism, it will say something that might be quite different. It is un-possible that this mechanism might be used without some other spec referring to it.

---

From: Qi Sun <[email-masked]>
Date: Thu, 12 Dec 2013 20:39:49 +0800

Hi Bernie,

I'm OK with your suggestion (using the  BOOTPREQUESTV6 and BOOTPREPLYV6).

Thanks!
Qi 

On 2013-12-12, at 上午12:18, Bernie Volz (volz) wrote:

> Hi:
>  
> What’s in a name anyway? (http://idioms.thefreedictionary.com/What's+in+a+name%3F)
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Dec 2013 09:48:35 -0500

> I'm OK with your suggestion (using the  BOOTPREQUESTV6 and BOOTPREPLYV6).

The only reason to use BOOTREQUESTv6 and BOOTREPLYv6 is the similarity between that name and the name of the BOOTP packet that DHCPv4 rides in.   If you are going to change the name, you might as well call it DHCPv4QUERY and DHCPv4RESPONSE or something.   Using the BOOTP name allows you to avoid confusion between DHCPREQUEST/DHCPREPLY and DHCPv4REQUEST/DHCPv4REPLY, but you could use QUERY/RESPONSE to avoid that just as well.

Anyway, I don't think BOOTPREQUESTv6 makes a whole lot of sense.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 12 Dec 2013 17:01:07 +0000

I wonder whether DHCPV4REQUEST and DHCPV4REPLY (perhaps with a hyphen) may actually be better choices for the V6 messages. While the underlying protocol is BOOTP, that name is somewhat misleading and most everything now uses DHCP[v4] -- yes, I know that I was likely the source of those original message names.

I'm not sure using QUERY/RESPONSE adds much value.

But again, I really have no good answer here and was not trying to promote one name over the other - I was just asking the WG the question as to whether these are good message names or whether we wanted to change them now, before we are stuck with them 'forever'.

It is a minor issue (as what goes over the wire is really a message type code), but it does make a difference in tools (i.e., packet decoders), logs, and in source code.

- Bernie

---

From: Marcin Siodelski <[email-masked]>
Date: Thu, 12 Dec 2013 19:19:04 +0100

> I wonder whether DHCPV4REQUEST and DHCPV4REPLY (perhaps with a hyphen) may actually be better choices for the V6 messages. While the underlying protocol is BOOTP, that name is somewhat misleading a…
I think you were the source of the names, Bernie. And I also think I
was the one who changed the original names to those that you suggested
:)
On reflection, I think we should revert it to something that has
DHCPV4 in it - it is less confusing and it is much easier to read than
BOOTREQUESTV6. I like DHCPV4-REQUEST/DHCPV4-REPLY.

Marcin

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Dec 2013 13:27:55 -0500

On Dec 12, 2013, at 12:01 PM, Bernie Volz (volz) <[email-masked]> wrote:
> I wonder whether DHCPV4REQUEST and DHCPV4REPLY (perhaps with a hyphen) may actually be better choices for the V6 messages.

I think this is going to create confusion.   But it's not desperately important.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 12 Dec 2013 21:26:16 +0000

I already indicated (twice) that I was likely the source of the current names (though I believe I suggested BOOTP, not BOOT, because that was the protocol). Not all my ideas are good and sometimes what looks good at first turns out to be poor when seen in more context or given more thought.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Marcin Siodelski
Sent: Thursday, December 12, 2013 1:19 PM
To: Bernie Volz (volz)
Cc: [email-masked]; Ted Lemon; [email-masked]
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

> I wonder whether DHCPV4REQUEST and DHCPV4REPLY (perhaps with a hyphen) may actually be better choices for the V6 messages. While the underlying protocol is BOOTP, that name is somewhat misleading a…
I think you were the source of the names, Bernie. And I also think I was the one who changed the original names to those that you suggested
:)
On reflection, I think we should revert it to something that has
DHCPV4 in it - it is less confusing and it is much easier to read than BOOTREQUESTV6. I like DHCPV4-REQUEST/DHCPV4-REPLY.

Marcin

---

From: Qi Sun <[email-masked]>
Date: Fri, 13 Dec 2013 11:15:23 +0800

Hi, 

I would prefer DHCPV4-QUERY and DHCPV4-RESPONSE. IMHO, the DHCPV4-REQUEST/REPLY might cause confusion with DHCPREQUEST in RFC2131. 

Best Regards,
Qi

---

From: Marcin Siodelski <[email-masked]>
Date: Fri, 13 Dec 2013 04:46:36 +0100

That is fine by me, Qi.

Marcin