Re: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-02.txt

Qi Sun <> Wed, 23 October 2013 13:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E85811E839B for <>; Wed, 23 Oct 2013 06:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.049
X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, GB_ABOUTYOU=0.5, J_CHICKENPOX_53=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NQqZ1JBQscIn for <>; Wed, 23 Oct 2013 06:58:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c01::22b]) by (Postfix) with ESMTP id 2A85F11E838B for <>; Wed, 23 Oct 2013 06:58:01 -0700 (PDT)
Received: by with SMTP id md12so699232pbc.16 for <>; Wed, 23 Oct 2013 06:58:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YmWAisqnbdAaIkSpFxTagRrj9FmmJfLY8RYntjCxSk4=; b=y1HCuz68QxTIs6tmKdjmPHc2e7chkSTugcHXRMLe/Z0dvbxprXDQkI+wa7tFilhF2E Mvh1VtpCKM7SDK0xblm8xUcB7zsdG0Sax2MttmGWREKQbI0dn+nSLSmuw1WnSVPr9uWH mWyKBRvkDtQHCWQzl2TRZvFpoEBPxO4FmQpycHjkSZctMpZLkVXUr+ArNGR1oMY+hvzc Wxqy455lM1wHjVq86Rq/gsttKqKP1ZgLS3kGRys5YGoeMO0MTZFf3tjPvkgvpU4eTtjt IOSRUscEWHN0Ps8zUX3cF9G0wcFqEw1dbKfX9fNIMy3rxf+fMilcb3Tz5TpCxMkMjpbH 0dFQ==
X-Received: by with SMTP id ca3mr1885291pbb.20.1382536680950; Wed, 23 Oct 2013 06:58:00 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id xn12sm41457377pac.12.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 06:57:59 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Qi Sun <>
In-Reply-To: <>
Date: Wed, 23 Oct 2013 21:57:52 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Ole Troan <>
X-Mailer: Apple Mail (2.1085)
Cc: "" <>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-02.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Oct 2013 13:58:02 -0000

Dear Ole ,

I have some thinkings about your message. Please see inline.

>>> MAP provides a data-link layer that supports transport of IPv4. given that it uses embedded addresses from
>>> IPv6 to algorithmically determine an end-points IPv4 address, you can say that IPv4 addressing is inherit 
>>> in the data-link layer. in this model the IPv4 address is tied to IPv6. this document proposes to provision IPv4
>>> addressing separately with DHCPv4. either this document needs to describe how this is supposed to work,
>>> or I think make a larger separation between in which cases only stateless DHCPv4 can be used, versus
>>> which data-links that also stateful DHCPv4 can be used. (I'm only aware of Public 4over6 that can support full DHCPv4).
>> [ian] Could we clarify this by extending the introduction to scope the document a little more? Something like:
>> In the most basic case of IPv4 provisioning, where the client only needs to receive a static IPv4 address and restricted port range assignment (with no dynamic address leasing or additional IPv4 configuration), DHCPv6 based approaches (such as the one proposed in [I-D.ietf-softwire-map-dhcp] may provide a suitable solution. This document is concerned with more complex IPv4 configurations scenarios, to bring DHCPv4 configuration over IPv6 only networks in line with DHCPv4 over IPv4 networks.

[Qi] Why static IPv4 address and port-set assignment is 'the most basic case of IPv4 provisioning'? For DHCPv4 (_Dynamic_ Host Configuration Protocol), dynamic assignment of IPv4 is the 'most basic case', IMO.

> yes, I think a clarification in the introduction would help.
> stateful DHCPv4 doesn't apply to DS-lite, and it is difficult to see how it applies to MAP.
> which link-layer did you have in mind for this?

[Qi] What is the 'link-layer' you mentioned? Do you mean IPv6 can be seen as the 'link-layer' for IPv4 in the context of IPv4-over-IPv6 scenario? Sorry if I mis-understood you.

> is this work meant to also provide stateful DHCPv4 for MAP tunnels?
> e.g. a configured RFC2473 tunnel or Public 4over6, could work.
> when it comes to provisioning of a shared IPv4 address, DHCPv4 doesn't really do that.
> I don't see that described in this document?
> I think we need to evaluate if there should be a completely new option for IPv4 address and port set, or
> a the classic IPv4 address option combined with a new port set option.

[Qi] AFAIK, in DHCPv4, IPv4 address is not put in an option. So to support the assignment of a shared IPv4 address, port-set is the information that needs to go to an option.

Actually there have been mechanisms to describe the usage. 

>>> Section 1.1
>>> "2. Extend DHCPv6 with new options for IPv4 configuration, such as
>>> [I-D.ietf-softwire-map-dhcp] describes."
>>> I think that could be phrased better. MAP DHCP does give the CE enough
>>> information so that it can calculate it's own IPv4 address. Here it reads as if
>>> we're adding DHCPv4 options to DHCPv6.
>>> I'm not even sure you should have MAP DHCP in this table, it is not a solution
>>> for passing DHCPv4 options, nor is it a solution to replicate all DHCPv4 options
>>> in DHCPv6. It is a solution for having the CE calculate it's own IPv4 address,
>>> shared IPv4 address or prefix. Note that the last two are not even supported in DHCPv4.
>>> It does not offer any other IPv4 configuration information.

[Qi] MAP-dhcp is _not_ the solution for having the CE calculate IPv4 info. MAP does. MAP-dhcp only provisions information. 

//A side note: I don't understand why map-dhcp needs to support to assign IPv4 prefix. It was not even supported when IPv4 addresses were sufficient. At the time we are running out of IPv4 addresses, but we need to assign IPv4 prefixes...
Sorry if I mis-lead the discussion...

>> [ian] The text at the moment says that 'DHCPv6 has been extended to convey the parameters necessary for IPv4 in IPv6 softwire configuration' which is true. It doesn't say that MAP DHCP has, or will be, extended any further with additional DHCPv4 options.
>> So, as an example of extending DHCPv6 to carry IPv4 configuration, it's accurate. However, if we go with the scoping clarification above then we could remove the reference here.
> thanks.

[Qi] From my reading, the reference here is reasonable. map-dhcp does extend DHCPv6 with new options for IPv4 configuration. Further more, if there are needs to support other IPv4 configuration information using purely DHCPv6, the new mechanisms should be used together with map-dhcp, or update map-dhcp. Because map-dhcp is the base for configuring IPv4 using purely DHCPv6.

>>> If you have it in the "approaches" list at all:
>>> 2. Depend on the setup of data-link (softwire) to offer enough information to create IPv4 addressing.
>>>    Require no other IPv4 configuration information.
>>> ** Reading section 1.3. If you want this approach to be "copy relevant DHCPv4 options into DHCPv6",
>>> then I suggest removing all references to MAP-DHCP.
>> [ian] See above.
>>> Rename 3. to "stateless DHCPv4" or DHCPINFORM only.
>> [ian] You mean the approach that's currently called DHCPv6+DHCPv4oSW (horrible name:-)? If so, are you proposing 'DHCPv6+stateless DHCPv4 over SW' as the new name? I not sure that's much better...
> we don't call DHCPv4, "DHCPv4 over Ethernet" today.
> "stateless DHCPv4" is most likely the only option available on link-layers which have IPv4 address configuration built in.
[Qi] Could you please explain what 'stateless DHCPv4' is? Is this a term that I missed? Thanks!

>>> Section 2:
>>> Drop requirement 6, I can't see how you can evaluate that.
>> [ian] You can evaluate it on the following basis: If the requirements that are described in this document are not your requirements as an operator, then you shouldn't be forced to use whatever the conclusion of this document is. In practical terms, I see this as 'if MAP DHCP meets your requirements, you don't need to bring in DHCPv4 over Foo or whatever else'.
> I didn't quite understand the implications of that.
>>> 8 is empty
>> [ian] Will fix.
>>> I suggest you add a new requirement:
>>> x. Fate sharing. The provisioning of IPv4 addressing and other configuration information should be logically tied
>>>    to the data-link layer that is uses to provide IPv4 connectivity.
>> [ian] This one's going to be more of a problem, as it pretty much directly conflicts with requirement 7, in that the two contradict each other. You can only implement data link fate sharing if you've got a hub and spoke architecture to locate the hub in (so that if it's not available, then IPv4 provisioning also fails)
> which link-layer fails that?
> I'm dubious about requirement 7 overall. and e.g. DHCPv4 over DHCPv6 is restricted to there being a DHCPv6 transport available.
>> In the case of a pure mesh network, with no hub and spoke, how could you have fate sharing for the data-link layer? The proposed requirement pre-supposes a specific underlying architecture. 
> is this the equivalent to the dentist's office case? can you give an example of other data link-layers where IPv4 can be provisioned on a NBMA link, without a router?
>> Can we put this one to the workgroup to ask if this should be included as a new req, as it' has not been previously discussed?
>>> Section 3:
>>> DHCPv4oDHCPv6 is "no" for requirement 4. and "no" on fate sharing.
>> [ian] Why is it a 'no' for req 4? Section 8 of the DHCPv4 over DHCPv6 draft:
>> Additionally, the DHCPv6 relay agent MAY allow the configuration of
>>  dedicated DHCPv4 over DHCPv6 specific destination addresses,
>>  differing from the addresses of the DHCPv6 only server(s).  To
>>  implement this function, the relay checks the received DHCPv6 message
>>  type and forwards according to the following logic:
>>  1.  If the message type is BOOTREQUESTV6, then the DHCPv6 request is
>>      relayed to the configured DHCPv4 aware 4o6 Server's address(es).
>>  2.  For any other DHCPv6 message type, forward according to section
>>      20 of [RFC3315].
> DHCPv4 over DHCPv6 requires support for transporting DHCPv4 messages in DHCPv6 servers and clients.
> what do you mean by "independent DHCPv4 and DHCPv6 servers" then?

[Qi] IMHO, the intended meaning here is: the process of DHCPv4 and DHCPv6 are independent in DHCPv4-over-DHCPv6. 
Besides what Ian has quoted, DHCPv4 over DHCPv6 support the client to communicate with a dedicated 4o6 Server for IPv4 configuration information (with the help of 4o6 Servers Addresses Option).

> could you clarify the requirements?
> now they do read like they have been reverse engineered.
>> For the fate sharing req, as stated above.
>>> In the evaluation in section 3.x I suggest dropping the use of "complex" and "simple".
>>> That appears very subjective.
>> [ian] OK
>>> 3.4.2 bullet 3. applies to all approaches allowing DHCPv4 leases.
>> [ian] How so? If you have a 'wrapper' type of approach (where DHCPv4 is being put into IPv6 or DHCPv6), then the DHCPv4 over xv6 client function can be agnostic to what the physical interface is beyond 'it must support multicast or unicast'. If the DHCPv4oSW mechanism is not linked just to softwires and is essentially a 'vanilla' DHCPv4 client, then it must have awareness of the link layer capabilities of the link on which it is running and potentially adapt it's behaviour accordingly, such as per-client l4 port-restrictions.
> I read this bullet to be about the interface to be _provisioned_. regardless of how that information reaches the client, the client must be aware of the link-layer restrictions. and that I believe apply to all mechanisms, regardless.
>>>        bullet 4. please expand.
>> [ian] This was from a question I asked on the ML some time ago, but wasn't answered. Does MAP-T support broadcasts through the translator function?
> I don't see why it wouldn't.
>>>        bullet 5. change to "Restricted to a broadcast capable link-layer."
>> [ian] Is the hub-and-spoke restriction incorrect? As mentioned above, I don't see how this approach can work in a mesh environment. The 'broadcast capable' restriction is not correct as if a h&s softwire can support broadcast, then a ptp mesh softwire can as well. You could broadcast DHCPDISCOVERs to peers in a mesh group, but it's not going to get you any response.
> MAP in mesh mode, still has a point to point tunnel to the BR.
> we have not described MAP in a 'pure' mesh mode, i.e. without a BR.
>>> 3.5.1 bullet 3. DHCPv4 and DHCPv6 cannot really be separated from each other since it 
>>>        it is DHCPv6 that provides transport for DHCPv4. and support for the new BOOTP messages
>>>        are required in DHCPv6.
>> [ian] But a dedicated DHCPv4 over DHCPv6 server could be deployed separate from the DHCPv6 only server. What about changing to read?:
>> 'DHCPv4 and DHCPv6 based provisioning infrastructure can be seperated'
> as long as there is a DHCPv4 message capable DHCPv6 server.
>>> Minor comments:
>>> Introduction:
>>> "A general trend here is to relocate NAT44 functionality and IPv4
>>> address sharing from the centralized tunnel concentrator to the CPE
>>> in order to achieve better scalability. "
>>> I understand what you are trying to say, but unless the reader understands that the starting point
>>> are mechanisms like NAT444 and DS-lite, he would find this strange. As current deployments
>>> of IPv4 already use distributed NAT.
>> [ian] What about changing the wording to:
>> 'A general trend here is to relocate the translation of privately addressed IPv4 traffic to a shared, public external address from the centralized tunnel concentrator to the CPE. The distribution of this function allows for better scalability.'
> that reads better, but I don't agree with the statement that this is a general trend.
> the trend as I see it from current deployments are centralised NAT. that happens in mobile, with NAT444 and with DS-lite.

[Qi] IMHO, Ian's new wording is precise enough. The centralized NAT has the problem of scalability which is known to all. So the trend _is_ to relocate the NAT function to CPE.

Best Regards,

> couldn't you say something along the lines of "In todays residential networks, each residential user gets a single global IPv4 address. Continuing that model of a decentralised NAT, provides excellent scaling properties and combined with stateless functions in the network, simple redundancy and logging." modify as you please.
> cheers,
> Ole
> _______________________________________________
> dhcwg mailing list