[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.
- [dhcwg] about v4configuration and co (2) Francis Dupont
- Re: [dhcwg] about v4configuration and co (2) Ian Farrer