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

[Ole Troan <[e-mail]>]

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


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.

  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.

  Rename 3. to "stateless DHCPv4" or DHCPINFORM only.


Section 2:
  Drop requirement 6, I can't see how you can evaluate that.
  8 is empty

  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.

Section 3:
  DHCPv4oDHCPv6 is "no" for requirement 4. and "no" on fate sharing.

  In the evaluation in section 3.x I suggest dropping the use of "complex" and "simple".
  That appears very subjective.

  3.4.2 bullet 3. applies to all approaches allowing DHCPv4 leases.
          bullet 4. please expand.
          bullet 5. change to "Restricted to a broadcast capable link-layer."

  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.

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.


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