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

[Ian Farrer <[e-mail]>]

Hi Ole,

Thanks for the review. Please see inline.

Cheers,
Ian

On 7 Oct 2013, at 11:55, Ole Troan <[e-mail]> wrote:

> all,
> 
> here are some comments on a first read of the document.
> 
> I have to general comments. one is on fate-sharing (see below), the other on address provisioning conflicts.
> 
> 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.
> 
> 
> 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.

[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.

> 
>  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...

> 
> 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'.

>  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)

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. 

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].

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.

>          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?

>          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.

> 
>  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'

> 
> 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.'

> 
> 
> cheers,
> Ole
> 
> 
> On Sep 30, 2013, at 16:14 , Ian Farrer <[e-mail]> wrote:
> 
>> Hi,
>> 
>> I've just posted an update to the draft based on the discussions in Berlin and Francis' review.
>> 
>> The contents of the conclusion remains unchanged.
>> 
>> Any comments etc. appreciated.
>> 
>> Cheers,
>> Ian
>> 
>> 
>> On 30 Sep 2013, at 16:00, [e-mail] wrote:
>> 
>>> 
>>> 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           : Provisioning IPv4 Configuration Over IPv6 Only Networks
>>> 	Author(s)       : Branimir Rajtar
>>>                        Ian Farrer
>>> 	Filename        : draft-ietf-dhc-v4configuration-02.txt
>>> 	Pages           : 17
>>> 	Date            : 2013-09-30
>>> 
>>> Abstract:
>>> As IPv6 becomes more widely adopted, some service providers are
>>> taking the approach of deploying IPv6 only networks, without dual-
>>> stack functionality for IPv4.  However, access to IPv4 based services
>>> is still an ongoing requirement and approaches such as IPv4-in-IPv6
>>> softwire tunnels are being developed to meet this need.
>>> 
>>> In order to provision end-user's hosts with the necessary IPv4
>>> configuration, a number of different mechanisms have been proposed.
>>> This memo discusses the benefits and drawbacks of each, with the aim
>>> of recommending a single approach as the basis for future work.
>>> 
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-dhc-v4configuration
>>> 
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-dhc-v4configuration-02
>>> 
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-v4configuration-02
>>> 
>>> 
>>> 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/
>>> 
>>> _______________________________________________
>>> dhcwg mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dhcwg
>> 
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>