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

[Ole Troan <[e-mail]>]

this document now looks  a lot better.
here are some comments (draft text indented).



  In today's home networks, each residential user is allocated a single
  global IPv4 address which is used for NAT44.  Decentralizing NAT44
  allows for much better scaling and, when combined with stateless
  network functions, can simplify redundancy and logging.  This results
  in the need to provision a number of configuration parameters to the
  CPE, such as the external public IPv4 address and a restricted port-
  range to use for NAT.  Other parameters may also be necessary,
  depending on the underlying transport technology that is in use.  In
  IPv4 only networks, DHCPv4 has often been used to provide IPv4
  configuration, but in an IPv6 only network, DHCPv4 messages cannot be
  transported natively.

you need to contrast "Decentralised NAT44" with CGN for this paragraph to make sense.

  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 approach must not be
  limited to only supporting softwires configuration or be reliant on
  specific underlying IPv4 over IPv6 architectures or mechanisms.

are you saying that there is a requirement for a host to acquire information
over DHCPv4, but that node does not have any IPv4 connectivity?
that seems quite farfetched, I think this needs elaboration, or just delete
the paragraph

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

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)

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.

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

also remove that "only theoretical" language and lack of internet draft statement.
unless there is a strong belief that there are unsolved problems here and that
protocol changes are required to run DHCPINFORM over a p2p link.



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

section 3 title, you only have four mechanisms

3.1.1. should be more truthful in that multiple new relay components are required. 3.1.2. says that, so remove the conflict

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.

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.


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.


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.

apart from that the section looks fine.

cheers,
Ole