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

[Tomek Mrugalski <[e-mail]>]

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