Subject: Re: [dhcwg] about v4configuration and co (2)

From: Ian Farrer <[email-masked]>
Date: Mon, 30 Sep 2013 15:59:31 +0200

Hi Francis,

Thanks for the in-depth review and my apologies for the length of time that it's taken me to respond.

I've just posted an update to the draft that incorporates your review (see inline below), plus the agreements from the DCH WG meeting in Berlin.

Cheers,
Ian

On 1 Aug 2013, at 13:30, Francis Dupont <[email-masked]> wrote:

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

[ian] Updated wording in introduction.

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

[ian] That's not a requirement, but rather a symptom of separating V6 and V4 config - V6 must be there to bootstrap the v4 config with the relevant parameters.

But if you take method 2 (Extend DHCPv6 with IPv4 config), then the v4 and v6 config would be conveyed within a single DHCPv6 response, so it's not a universal pre-requisite.

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

[ian] Cleared up wording.

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

[ian] Cleared up.

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

[ian] Cleared up.

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

[ian] The paragraph is directly describing the TRA function, which is essentially unworkable. For it to be used, there needs to be a v4 only LAN with a separate softwire gateway and TRA attached to that LAN. The v4 client would be allocated the public v4 address, but this address cannot taken from the IPv4 LAN addressing (unless you're addressing all of your clients with public addresses, of course).

So, even if the host was modified to attach that public address to a logical interface and then do port restricted NAT so that all sessions were initiated from the acceptable port range of the public IP address, there would still be no way for the software gateway to be able to route return traffic from the softwire back to the client. There's no mechanism for the gateway to learn this route.

Further, there would need to be a separate softwire gateway for each client that needs to communicate outside of the LAN to satisfy the uniqueness of binding table entries in the softwire concentrator (to give unambiguous bindings between v4 addresses and v6 tunnel endpoints)

The point isn't meant to say that the CRA is not necessary - this has to be there (co-located with the softwire client) to wrap the DHCPv4 messages in v6.

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

[ian] See above

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

[ian] Agree with what you say, but this section is meant to describe how it would work, rather than evaluate it. I've added an additional line to make it clearer.

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

[ian] The description states that DHCPDISCOVER does not work - only DHCPINFORM can be supported.

This comment is probably better targeted at the new definition of DHCPv4oSW described by Ole in draft-troan-dhc-dhcpv4osw-00 and is described in the new version of the draft in section 1.5. Ole has reported that he has tested this and it works, although I don't have any more details than that.

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

[ian] But for the DS-lite case, the IPv4 packet, sourced from a well-known IPv4 address will have passed through the CGN function on the AFTR, and so will have a unique public IPv4 address allocated to it the same as any other flow. Of course, the CGN would have to have some kind of DHCP ALG to ensure that the source port remained unchanged.
> 
>   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.

[ian] I think that the current text is clear that only DHCPINFORM messages can be handled. Is there something else that needs to be said here?
> 
>   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!

[ian] Promoted to the last sentence in the first paragraph.

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

[ian] It's doesn't score well in the comparison, so it's pretty likely to stay theoretical.

> 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.
> 
[ian] Is there a change that should be made to the text to describe this?

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

[ian] For the DHCPv6 based model, the IPv4 configuration would have to come from the DHCPv6 server - there is no way of separating this.

Or have I missed your point?

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

[ian] Can you be more specific on which ones (or are they in the comments below)

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

[ian] Corrected

> 
>   3.  Easy to implement through minor adaptation of existing DHCPv4
>       client/server code.
> 
> => s/client/relay/

[ian] Corrected
> 
>   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.

[ian] Reworded to clear up.
> 
>   6.  Implementations already exist, proving that the approach works.
> 
> => so why the 1. wording? And BTW it makes late surprises very unlikely.

[ian] Fixed, see above
> 
> 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.

[ian] This point is saying that new functional elements are necessary, compared to the modification of existing elements (such as the DHCPv6 case, which is what it is being compared with)

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

[ian] The client must be configured with the IPv6 address of the element (TRA or TSV) which has an interface in the IPv6 domain. This is true for TRA and TSV and the server or relaying architecture is invisible to the client.

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

[ian] Cleaned up.
> 
>       Otherwise a physically separate On-Link CRA (LCRA) functional
>       element must be deployed.
> 
> => "physically separate" is not a requirement.

[ian] Changed to just 'separate'.
> 
>   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".

[ian] The sentence doesn't say anything about what or how complex the update is, only that one is necessary. Should the wording be changed?

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

[ian] It's a 'yes' in 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 :-)

[ian] Yup!

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

[ian] Clarified wording
> 
>   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.

[ian] OK - I'm not sure about the implementation status of this at the moment. Is anyone in the WG currently working on this who could comment?

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

[ian] Added pointers to the relevant sections of each of relevant drafts.

> 
> Regards
> 
> [email-masked]
> 
> PS: the softwire part was written before the discussion about
> O. Troan's proposal.
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg