[dhcwg] about v4configuration and co (2)

Francis Dupont <Francis.Dupont@fdupont.fr> Thu, 01 August 2013 11:30 UTC

Return-Path: <Francis.Dupont@fdupont.fr>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81DB521F8F78 for <dhcwg@ietfa.amsl.com>; Thu, 1 Aug 2013 04:30:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level:
X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_53=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcVBRdEY0HDb for <dhcwg@ietfa.amsl.com>; Thu, 1 Aug 2013 04:30:36 -0700 (PDT)
Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF2821F9C98 for <dhcwg@ietf.org>; Thu, 1 Aug 2013 04:30:34 -0700 (PDT)
Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id r71BUXm3054957 for <dhcwg@ietf.org>; Thu, 1 Aug 2013 13:30:33 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr)
Message-Id: <201308011130.r71BUXm3054957@givry.fdupont.fr>
From: Francis Dupont <Francis.Dupont@fdupont.fr>
To: dhcwg@ietf.org
Date: Thu, 01 Aug 2013 13:30:33 +0200
Sender: Francis.Dupont@fdupont.fr
Subject: [dhcwg] about v4configuration and co (2)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Aug 2013 11:30:37 -0000

Review of draft-ietf-dhc-v4configuration-01.txt

IMHO the introduction (section 1) should be clearer about the fact
one of the needed function is the ability to assign an IPv4 address
to a node without one, the so called 'booting node'. This makes
a difference for the applicability of DHCPv4oSW.

To be complete all proposed mechanisms have the hidden requirement
that this function is available only after IPv6 address (and often
other DHCPv6 parameters) assignment (/ provisioning).

1.2.  DHCPv4o6 Based Provisioning - Functional Overview

   The DHCPv4o6 server must either provide an IPv6 interface to the
   client, or an intermediary 'Transport Relay Agent' device can act as
   the gateway between the IPv4 and IPv6 domains.

=> either supposes exclusivity: it is possible to provide both a
DHCPv4o6 (aka TSV) and CRA6ADDR capable legacy DHCPv4 server functions
in the same process. So s/either//

   For the dynamic allocation of IPv4 addresses, the DHCPv4o6 server
   needs to be extended to support the new functionality, such as
   storing the IPv6 address of DHCPv4o6 clients.  The CRA6ADDR option
   must also be implemented.

=> the text is unclear: the last statement applies only to DHCPv4o6
capable (so in fact CRA6ADDR capable) legacy DHCPv4 server.
I.e., the "also" must be replaced by the same ", or" than in
the previous paragraph.

   This approach currently uses functional elements for ingress and
   egress of the IPv6-only transport domain--the CRA on the host and the
   TRA or TSV on the server.  As a result, this approach has sometimes
   been referred to as a tunneling approach.  However, relay agent
   encapsulation is not a tunnel, since it carries only DHCP traffic; it
   would be more accurate to describe it as an encapsulation.

=> you can replace tunnel by encapsulation this doesn't change the fact
it is a transport mechanism, not a tunnel nor an encapsulation one.

   It is worth noting that there is no technical reason for using relay
   encapsulation for DHCPv4o6; this approach was taken because the
   authors of the draft originally imagined that it might be used to
   provide configuration information for an unmodified DHCPv4 client.

=> I deeply disagree: as the DHCPv4 server is not attached directly
the client link there must be a relay information added to queries
from clients so the server knows where are clients and where to
send back responses. This has nothing to do with the analysed problem,
in fact it is simply the basis of what is a DHCPv4 relay for after
the simple "DHCPv4 packets don't go through routers".

   Given that this is the case, there is no technical reason why
   DHCPv4o6 can't simply use the IPv6 transport directly, without any
   relay encapsulation.  This would greatly simplify the specification
   and the implementation, and would still address the requirements
   stated in this document.

=> there is a technical reason which is obvious to anyone who worked
with DHCP relays (which I have to confess are incredibly bad documented
so I understand well why you missed this point).

1.3.  DHCPv6 Based Provisioning - Functional Overview

=> two comments: first the IPv4 address assignment feature is critical
here as it supposes a massive change (aka mess in the case :-) in
DHCPv6, second it should make clearer we DO NOT WANT this (with this
being DHCPv6 extended to provide all DHCPv4 features including IPv4
address assignment).

1.4.  DHCPv4oSW Based Provisioning - Functional Overview

   Any additional IPv4 configuration parameters which are required are
   then provisioned using a DHCPv4 messages transported within IPv6 in
   the configured softwire in the same manner as any other IPv4 based
   traffic.

=> as I explained before it doesn't work because DHCPv4 is not
really over UDP/IP. With other words without a lot of dedicated
hacking there is no chance for a booting node DISCOVER to go
through a tunnel...

   On receipt at the tunnel concentrator (e.g.  MAP Border Router or a
   Lightweight 4over6 lwAFTR), the DHCPv4 message removed from the
   softwire and forwarded to the DHCPv4 server in the same way as any
   other IPv4 packet is handled.

=> in fact this statement is wrong: the DHCPv4 server must get the
IPv6 address so it can identify where is the client and know how
to send back responses. Note in softwire it is common to have
many nodes on the client sides (note the 's') with the same (private)
IPv4 address, for instance in DS-Lite all B4 (aka CPE aka HG) have
the same IPv4 address...

   the messages exchanged between the DHCPv4 client and server would
   be strictly DHCPINFORM/DHCPACK messages, for the configuration of
   additional IPv4 parameters.

=> note DHCPv4oSW works perfectly for this but this is only a part
of what is needed. And if another message type is handled it likely
makes a lot of trouble to another mechanism.

   Broadcast based DHCPDISCOVER messages can not be transported as they
   are not compatible with the softwire architecture.

=> I fully agree but this must be the first statement in the section!

   From a transport perspective, the key difference between this method
   and DHCPv4o6 (described above) is that here, the DHCPv4 message is
   put into UDPv4 and IPv4 and then put into the IPv6 softwire, instead
   of directly placing the DHCPv4 message into UDPv6 and IPv6.

=> yes, it is tunnelling/encapsulation and not transport.

   Currently, this approach is only theoretical and does not have a
   corresponding Internet Draft providing more detail.

=> it should stay theorical as it is a partial solution and
doesn't provide something not already available from full solutions.

1.5.  DHCPv4oDHCPv6 Based Provisioning - Functional Overview

   These messages types must be implemented in both the DHCPv4oDHCPv6
   client and server.

=> this is IMHO the critical difference between DHCPv4oDHCPv6 and
DHCPv4o6: DHCPv4o6 implies one or two very easy to implement relays
to switch between IPv4 and IPv6 transports, DHCPv4oDHCPv6 requires
a major change in the client. Of course this has many benefits,
for instance the DHCPv4oDHCPv6 client should be an integrated
DHCPv4 *and* DHCPv6 client.

2.  Requirements for the Solution Evaluation

   4.  Enable the separation of IPv4 and IPv6 host configuration
       infrastructure, i.e.  independent DHCPv4 and DHCPv6 servers.

=> I can't see how 4 can be made impossible.

3.  Comparison of the Four Approaches

   The table below shows a comparison of how the different approaches
   meet the solution requirements described above.

       +----------+----------+--------+-----------+---------------+
       | Req. No. | DHCPv4o6 | DHCPv6 | DHCPv4oSW | DHCPv4oDHCPv6 |
       +----------+----------+--------+-----------+---------------+
       |    1     |    No    |  Yes   |     No    |      Yes      |
       |    2     |   Yes    |   No   |    Yes    |      Yes      |
       |    3     |   Yes    |   No   |     No    |      Yes      |
       |    4     |   Yes    |   No   |    Yes    |      Yes      |
       |    5     |   Yes    |   No   |    Yes    |      Yes      |
       |    6     |    No    |   No   |    Yes    |      Yes      |
       +----------+----------+--------+-----------+---------------+

=> note the table is not consistent with the given detailed
pros/cons in this document (pros/cons I disagree for some too)

3.2.  DHCPv4o6 Based Provisioning

3.2.1.  Pros

   1.  Once implemented, all existing DHCPv4 options will be available
       with no further ongoing development work necessary.

=> note DHCPv4o6 is already (at least twice) implemented,
so future -> present.

   3.  Easy to implement through minor adaptation of existing DHCPv4
       client/server code.

=> s/client/relay/

   4.  Simple, in that no additional functional elements are necessary
       except the DHCPv4o6 client and server.  The Transport Relay Agent
       is completely optional.

=> client -> CRA. It is true the TRA is optional but you need at least
a TRA or a TSV.

   6.  Implementations already exist, proving that the approach works.

=> so why the 1. wording? And BTW it makes late surprises very unlikely.

3.2.2.  Cons

   1.  More complex, in that there are more new functional elements
       (CRA, DHCPv4o6 server and optionally TRA) within the architecture
       than are necessary in DHCPv6 based provisioning.

=> I don't understand this statement, in particular compared to
the DHCPv4oDHCPv6 one.

   2.  A new DHCPv6 option is necessary in order to provision the IPv6
       address of the DHCPv4 server to the end device.

=> s/option/relay sub-option/ and it is needed only with TRA
(I have a presentation concern here: you should not write a constraint
from an option applies to the whole mechanism: it is more than unfair).

   3.  For a Host CRA (HCRA), DHCPv4 client host needs to be updated to
       implement the IPv6 encapsulation and decapsulation function.

=> I can't parse the wording: what I believe it should mean is
with a HCRA the DHCPv4 client host must run a HCRA (which is a
tautology). It can be parsed too as the HCRA function must be
included in the DHCPv4 client software which is *not* true.

       Otherwise a physically separate On-Link CRA (LCRA) functional
       element must be deployed.

=> "physically separate" is not a requirement.

   5.  The DHCPv4 server needs to be updated to implement new DHCPv4o6
       functionality.

=> the CRA6ADDR capable code is 20 lines of very straightforward code
(just a new relay sub-option in a space which is already well handled
in a DHCPv4+DHCPv6 code) so the burden is just "needs to be updated".

3.4.  DHCPv4oDHCPv6 Based Provisioning

3.4.2.  Cons

   1.  More complex, in that there are more new functional elements
       within the architecture than are necessary in DHCPv6 based
       provisioning.

   2.  DHCPv6 clients needs to be updated to implement the new DHCPv6
       message types (BOOTPREQUESTv6 and BOOTPREPLYv6).

   3.  The DHCPv6 server needs to be updated to implement new
       DHCPv4oDHCPv6 message types and functionality.

=> given these how you can put a No in row 1 of the table???

   5.  The approach is currently unproven as no existing implementations
       exist.

=> IMHO it is the main drawback of this solution (fortunately it has
a known way to solve :-)

4.  Conclusion

   The dynamic leasing of IPv4 addresses is fundamental to the efficient
   use of remaining IPv4 resources.  This will become increasingly
   important in the future, so a mechanism which supports this is
   necessary.  DHCPv4oSW does not provide this function and so is not
   recommended.

=> IMHO this must be in the introduction too!

   The DHCPv4o6 approach requires a DHCPv4 server (with DHCPv4o6
   functionality) for all deployment scenarios, even when DHCPv4
   specific functionality is not required by the operator.

=> I don't understand this: if you don't want DHCPv4 you don't need
a DHPv4* server?

   Therefore, this memo recommends DHCPv4oDHCPv6
   [I-D.ietf-dhc-dhcpv4-over-dhcpv6] as the best underlying approach for
   provisioning IPv4 parameters over an IPv6 only network.

=> IMHO such a recommendation can be done *only after* two independent
(and interworking) implementations of this solution.

6.  Security Considerations

=> I can't accept empty security considerations (and I am far to be
alone in this case). And it is not clear proposed solutions are so
security neutral.

Regards

Francis.Dupont@fdupont.fr

PS: the softwire part was written before the discussion about
O. Troan's proposal.