Re: [dhcwg] Comments on draft-rajtar-dhc-v4configuration-01

["Bernie Volz (volz)" <[e-mail]>]

I think comments are always welcome :).

One concern I have (WG co-chair hat mostly off) with this whole area is that I don't really have a clear sense for what is required of the players - operator/service provider (in its network, for its devices) and what is required by the subscriber (client side) or OS provider.

While I understand that there may be situations where operators have no choice (because they have few IPv4 addresses), but I think it is important for us to understand what the tradeoffs are as there may be some operators that will continue to prefer providing IPv4.

Note that this isn't necessarily something that this particular draft has to provide, but it more of a general comment for all of the drafts in this space.

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Tomek Mrugalski
Sent: Friday, February 22, 2013 4:07 PM
To: [e-mail]
Subject: [dhcwg] Comments on draft-rajtar-dhc-v4configuration-01

On 15.02.2013 15:26, Ted Lemon wrote:
> So I'd like to propose that we stop the call for adoption on this 
> version of the document now, and that the authors reissue the 
> document, without the recommendation section, and with the addition of 
> Roberta's argument in favor of a DHCPv6-only solution, which I think 
> captures the real issue best.
What is the plan with this work? I suppose it will be presented/discussed in Orlando, updated version will be published and second adoption call will be issued?

Ted said that this is adoption thread, not a technical comments thread, but since the adoption call was cancelled, I hope it is ok to post my comments on it.

I noted that -01 version does not include specific conclusion, merely a note that this conclusion will emerge as a group consensus. This is a step in right direction. My suggestion for the work forward would be to decide what are the changes needed (if we want to be more specific about requirements, what inside and what outside of scope, what the conclusion should be) and then adopt it, not the other way around. At first, this may be counter-intuitive, but there's a very good reason to do this in that order. There was (still is, but it seems to be dying slowly and being revived constantly) a draft about DHCPv6 routing configuration in MIF wg. The draft was adopted a long time ago, but the group didn't have consensus how it really should work. This is a hot controversial topic with many participants having strong opinions, similar to what we have here with draft-rajtar-dhc-v4configuration. If you attend MIF meetings, you'll notice that discussion about this takes a significant amount of time of every single MIF meeting, without much work going forward. I would very much like to avoid similar case in DHC. This draft has similar potential for endless pro and cons discussions as was demonstrated many times in Softwires.

I agree with Woj's and Med's comments about a need to define what are the requirements (or preferences as Ted calls some of them). Depending on them, some pros/cons become very important or not important at all.

Ok, here are my comments specific to the text:

It would be helpful to add a stack description in sections 2.1, 2.2 and
2.3 (omething like DHCPv4/UDPv6/IPv6, DHCPv6/UDPv6/IPv6, and DHCPv4/UDPv4/IPv4/IPv6).

Section 2.1: "The DHCPv4o6 server needs to be extended to support the new functionality, such as storing the IPv6 address of DHCPv4o6 clients." Is this really true? My undestanding is that the server needs to remember
IPv6 address of the source packet to respond to it, but once the response is sent there is no need to store it further.

Section 2.2 is overly simplistic. DHCPv6 based provisioning aims to provide only bare minimum to configure IPv4 stack, not the whole multitude of options that DHCPv4 has.

Section 2.2 refers to I-D.mdt-softwire-map-dhcp-option, which is obsolete. It was adopted as I-D.softwire-map-dhcp.

Section 2.3. Is there a draft available that proposes that architecture?

Section 3.1.1, bullet 1: Remove extra "be".

It should be mentioned that there's existing software that was proven to work (other pro/con sections mention existence or lack of suitable software).

Section 3.1.2, bullet 1: can you elaborate? CRA is the only new element required. You can integrate it with client if you want to minimize number of new elements.

Bullet 2 could possibly reference
draft-mrugalski-softwire-dhcpv4-over-v6-option-01.

Bullet 3 "DHCPv4 clients needs to be updated to implement the IPv6 encapsulation and decapsulation function." My understanding is that it is not always true. CRA can be a separate entity, you don't have to modify DHCPv4 client code.

Bullet 4 "The DHCPv4 server needs to be updated to implement new
DHCPv4o6 functionality.". I think that is not always true, as you can deploy Transport Relay Agent, right?

You should add "requires DHCPv4 server to be deployed and maintained" to cons.

Section 3.2.1 should mention that some solutions (MAP for sure. 4rd used to, I'm not sure if it still does) reuse parts of the IPv6 configuration (e.g. parts of PD) to provide IPv4 configuration.

Section 3.2.2, bullet 1 suggests that there are many DHCPv4 options that would need to be ported, but in fact there are few (or even none) in most cases.

I assume that bullet 2 discusses a new DHCPv6 options that are used to configure IPv4 transition technology, e.g. MAP. It raises an interesting point, which is considered a strong argument against that solution. Here's an idea to consider that could largely mitigate it. We could define a special range in DHCPv6 option space reserved for transition technologies, similar to what we have in DHCPv4 option space for reserved or private use. Any DHCPv6 options that would become useless after IPv4 goes away, would be assigned from that range. Once a vendor wants to go IPv6-only, it's just a matter of not supporting specific range of options.

Bullet 3: I'm not sure where did you get the idea that DHCPv4 legacy options would be ported to DHCPv6? Such a thing is unreasonable to say the least. Can you point out specific draft or comment that suggested that?

Section 3.3.1
"Uses the existing DHCPv4 and DHCPv6 architectures in order to provide
IPv4 configuration in an IPv6 only environment.". If you reword to "requires..." instead of "uses...", it suddenly may be considered a con in many deployments that do not have DHCPv4 deployed.

Section 3.3.2, bullet 4 mentions ietf-dhc-dhcpinform-clarify. This draft is dead for over 2 years and David, its author, is unlikely to revive it.

You should add "requires DHCPv4 server to be deployed and maintained" to cons.

You should add "no existing software available yet" to cons.

My personal observation is that this is not a completely solvable problem and there won't be a single conclusion, like "use DHCPv4" or "use DHCPv6" that would satisfy everyone (or at least a large majority).
I think the way forward here would be to do something similar as we did in dhc-option-guidelines: define a set of guidelines, not "you must always use X".

Hope that helps,
Tomek

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg