Re: [dhcwg] WGLC on draft-ietf-dhc-v4configuration-04 - respond by Jan. 31

[<[e-mail]>]

Hi Ole,

Thanks for the review. Some comments on your comments below (the rest are
agreed and will go into the next update).

A few comments in line.

Cheers,
Ian





>
>  3.  Use DHCPv6 as above for external IPv4 address and source port
>      configuration.  Use DHCPv4 over IPv4 messages within an IPv6
>      softwire for configuring additional parameters.  This is referred
>      to as DHCPv6 + Stateless DHCPv4oSW.
>
>what is "as above", map-dhcp?
>if so I suggest you rename this, or even better move it above under the
>"simple configuration".
>"stateless DHCPv4" doesn't solve the requirement you started out with for
>"complex configurations".

[ian] It needs to stay as a considered solution (IIRC, it was proposed as
an overall solution in the Atlanta meeting). The simple configuration
described in the introduction is bounded to only doing v4 address and
ports, so needs to be extended to provided additional configuration. This
extension is what is being described.

What name would you prefer here? The current name is taken from your
proposal on
7/10/13 (as a change from the previous DHCPv6+DHCPv4oSW name from v02):

Rename 3. to "stateless DHCPv4" or DHCPINFORM only.

-------------------------


>
>add some more text in the introduction about the goals of these
>mechanisms?
>e.g. reuse of existing implementations, minimal change on existing
>components,
>implementation issues so on (oh, I see you have that in section 2)

[ian] Is this a no-op?

--------------------------


>
>with regards to protocol stack. UDPv6 is not a protocol. just use UDP.
>and I think you can remove the tunnel encapsulation from your protocol
>stack,
>especially since some of the softwire mechanisms use translation.
>just like you don't have the L2 header on the native packets either.

[ian] I think it¹s more meaningful to go the other way and extended the
stack diagrams to show where there
are differences between tunnel and translation to try and give a more
complete picture with all of the L3,4,5 headers. These vary between the
solutions and between tunnel/translation. The L2 headers don¹t.

--------------------------


>
>in section 1.4:
>  Broadcast based DHCPv4
>  DHCPDISCOVER messages (necessary for IPv4 address assignment) can not
>  be transported as they are not compatible with the existing, unicast
>  based softwire architecture.
>
>I don't think this claim is correct. I don't see good reasons why DS-lite
>couldn't
>(or doesn't already) support broadcast.


[ian] A DS-Lite may have a relay, or could be extended to be a relay, but
there is nothing in the existing
RFC that states that an AFTR has this function, so it can¹t be expected.

What about changing the wording to:

Existing softwire architectures do not define how broadcast based DHCPv4
DHCPDISCOVER messages (necessary for IPv4 address assignment) should be
handled.

--------------------------


>I'm not sure this section fits in with the others. it doesn't solve the
>problem of DHCPv4 leases.
>either move it somewhere else or make it clear that this is the option
>one can use
>if the operator only requires other configuration information for IPv4.

[ian] It doesn¹t handle leases, which is what the comparison states and
why it¹s not the recommend solution in the conclusion.

----------------------------

>
>
>section 2:
>I don't understand bullet 7. more detail?

[ian] From your earlier suggestion, I¹ve updated a paragraph in the intro
to read:

"Although IPv4-in-IPv6 softwire tunnel and translation clients are
      currently the only use-case for DHCP based configuration of IPv4
      parameters in IPv6 only networks, a suitable IPv4 provisioning
solution
      should not be limited to only supporting the configuration of
softwires, 
      or be bound to specific IPv4 over IPv6 architectures or mechanisms.
The
      solution needs to be flexible enough to support new IPv4 over IPv6
      technologies as they are developed."


Between this and the existing wording of requirement 7 -

"Not restricted to specific IPv4 over IPv6 transport mechanisms or
       Architectures"

I think the intension behind the requirement is pretty clear. Does that
work?

----------------------------

>
>3.2.1 (4) I don't think existing implementations of carrying DHCPv4
>options exist.
>             if anyone really really wanted to go down this route, you
>could just create an DHCPv6 encapsulation option
>             for all DHCPv4 options. that way you don't need to port all
>options.

[ian] Creating a DHCPv6 encapsulation (message type & option) for
transporting DHCPv4 is what DHCPv4oDHCPv6 is.


>
>3.2.2     it doesn't have to be tied to the DHCPv6 leasetimes (whatever
>is meant by that).
>            IPv4 addresses could have its own IA, or be treated as such.
>anyway, I'm not suggesting this route.

[ian] This is the point (and what the text says). To decouple DHCPv6
prefix and IPv4 lease lifetimes, you would need to add a new, dedicated
IPv4 lease lifetime mechanism to DHCPv6 (such as a v4 IA with it¹s own
timers).


>
>
>3.3.2: I suggest you remove the unproven bullet 9. isn't that just a
>matter of testing it out with an existing implementation?
>         with regards to bullet 8. I suggest a separate section where you
>describe softwire behaviour.
>         _all_ proposed softwire mechanisms are hub and spoke, with
>regards to traffic outside of the softwire domain.
>         which makes bullet 8 read a little strangely, given that no
>mechanism is restricted by it.

[ian] The draft not linked exclusively to softwires. A pure mesh is a
possible architecture, even if no examples are currently standardised.


>
>
>shouldn't section 3.4 be removed? given that that method is described in
>section 5.
>
>section 3.5.2:
>add a cons about communication between the DHCPv6 and DHCPv4 server,
>presumably these need to be directly connected? or there must be an
>DHCPv4 relay directly connected to the DHCPv6 server. _or_ is the
>expectation here that the DHCPv4 and DHCPv6 servers must be co-located on
>the same host? if so, state that.
>
>section 5:
>the title is wrong. I suggest: Transporting DHCPv4 messages over an IPv4
>capable softwire"
>the tunnel is the link-layer. a link-layer that offers IPv4 transport.

[ian] The rest of the doc tries not to link the v4 provisioning
recommendation to only softwires, and the recommendation in the intro is
not limited to using unmodified DHCPv4 only for softwires. To keep it
aligned, either the intro recommendation should be changed, or the title
of section 5 shouldn¹t limit it.