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

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 17 Jan 2014 22:50:21 +0100

Folks,

Authors and chairs feel that draft-ietf-dhc-v4configuration-04
(http://datatracker.ietf.org/doc/draft-ietf-dhc-v4configuration/) is
ready for WGLC. Please post your comment by end of January.

If you support this draft moving forward, please say so. If you object
this draft moving forward, please explain your concerns. Please limit
your posts to technical comments and skip your personal preferences. "I
like the other solution better" is not a technical comment.

Please note that:
- Softwires WG is expecting an answer from DHC WG on how to configure
IPv4 devices in IPv6-only networks. We should answer that question.

- There is a temptation to sneak in certain A+P pieces here. We must not
do that. This is related, but a different problem. Let's solve one issue
at a time.

- -04 features an update that is a result of some off the list
discussions. In essence, the addition is "if possible, use native DHCPv4
without modifications. If not, here's what DHC recommends:
DHCPv4-over-DHCPv6".

With my DHC chair hat off, I'd like to ask you to do your best to not
reopen the discussion of solution X being marginally better over Y in
scenario Z. Yes, we can keep coming up with new metrics that would prove
whatever metric inventor wants to prove. But that will lead us nowhere.
There is probably no single solution that will be the best in every
possible deployment scenario. We discussed that for over a year (much
more if you take into account Softwire discussions). It's a high time to
wrap things up here and move on.

Bernie & Tomek

---

From: Ole Troan <[email-masked]>
Date: Mon, 20 Jan 2014 11:37:19 +0100

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

---

From: <[email-masked]>
Date: Tue, 21 Jan 2014 10:02:15 +0100

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

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

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

>implementation issues so on (oh, I see you have that in section 2)

[ian] Is this a no-op?

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

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

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

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

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

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

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

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

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

>             if anyone really really wanted to go down this route, you
>could just create an DHCPv6 encapsulation option

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

>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?
>         _all_ proposed softwire mechanisms are hub and spoke, with
>regards to traffic outside of the softwire domain.

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

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

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

---

From: Ole Troan <[email-masked]>
Date: Tue, 28 Jan 2014 14:01:08 +0100

Ian,

> solutions and between tunnel/translation. The L2 headers don¹t.

the tunnel is a L2. I don't think you need to include that virtual L2 in the stack diagrams.

> RFC that states that an AFTR has this function, so it can¹t be expected.

that's a deployment choice, and nothing that's required to be in an RFC.
ds-lite is an 'normal' point to point tunnel as far as IPv4 forwarding is concerned.

> DHCPDISCOVER messages (necessary for IPv4 address assignment) should be

I wouldn't state it so broadly.
I would say that not some of the softwire mechanisms implement NBMA links,
where broadcast isn't supported, and A+P in general have open issues with regards to using
fixed ports, when the IP address is shared among multiple users.

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

OK, perhaps I disagree with the intention of this then.
we're creating this whole thing, just because we want the flexibility for something that may be invented in the future?
given that it is for IPv4, that seems a little unnecessary.
no-one has a single example where this requirement actually matters now?

you encapsulate the "messages", I said you could encapsulate the "options".

> IPv4 lease lifetime mechanism to DHCPv6 (such as a v4 IA with it¹s own

OK, you may want to make that text clearer then.

> possible architecture, even if no examples are currently standardised.

what's a pure mesh?

> of section 5 shouldn¹t limit it.

I don't think there is anything in my proposal that links v4 provisioning to a particular L2 either.
it does set some requirements on the behaviour on that L2 though.

again, without some real examples I think it is quite meaningless to talk about v4 provisioning outside the context of a IPv4 capable link-layer.

cheers,
Ole

---

From: Qi Sun <[email-masked]>
Date: Fri, 31 Jan 2014 20:48:17 +0800

Dear all,

I support this document to move forward.

Best Regards,
Qi 

On 2014-1-18, at 上午5:50, Tomek Mrugalski wrote:

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Cong Liu <[email-masked]>
Date: Fri, 31 Jan 2014 22:12:54 +0800

+1 support.

Cong

---

From: <[email-masked]>
Date: Fri, 31 Jan 2014 15:17:32 +0100

I support forwarding this doc.

Olaf

On 2014-1-18, at 5:50, Tomek Mrugalski wrote:

> [email-masked]<mailto:[email-masked]>