[dhcwg] A few comments about draft-farrer-dhc-shared-address-lease-00

Marcin Siodelski <msiodelski@gmail.com> Mon, 21 October 2013 11:25 UTC

Return-Path: <msiodelski@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7BB9311E8190 for <dhcwg@ietfa.amsl.com>; Mon, 21 Oct 2013 04:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id h2brczM-C3PY for <dhcwg@ietfa.amsl.com>; Mon, 21 Oct 2013 04:25:32 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2019711E8189 for <dhcwg@ietf.org>; Mon, 21 Oct 2013 04:25:30 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id eh20so389118lab.25 for <dhcwg@ietf.org>; Mon, 21 Oct 2013 04:25:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=rwjHuZxhb3M6c/8G3gUiIKjUrtToaD1iX0pAKEqjm8U=; b=p3CgOsLq4oLpbqiLbyszLRnj3oBT421yDnctzScrPcSAyDhyG/ejPPa4c06CXowuab erVDIBujdKwSZ2cID8TOCYIp+/5PRyMV78zL4Mm5HJFs8jQKsjmZjkjUqtQPyVu50eks dYMGHt9IEG5OP2UsnXA/oAUKoN6bC+4quFTjDW9X10jrp+zHcvYIOInDJYyCPH9UnHQK DugZ2dID8D6yNO1SmRTjGswEKMjfE9b4HWRpBSiMh+JTUm/kRvcNNnhZRGb5WntUjYtW RVUo0hoSNpeZAHbNZY0svmrp76m40My7ALtbf0ScfCBIbEot01UeyBube1UBV3iHJSFh gbtw==
MIME-Version: 1.0
X-Received: by with SMTP id e5mr725343lam.58.1382354729984; Mon, 21 Oct 2013 04:25:29 -0700 (PDT)
Received: by with HTTP; Mon, 21 Oct 2013 04:25:29 -0700 (PDT)
Date: Mon, 21 Oct 2013 13:25:29 +0200
Message-ID: <CAFGoqUMBnfTjOA+AGHqLKj0hyrvazzDsf5vRb0PvrDdHfNDj2g@mail.gmail.com>
From: Marcin Siodelski <msiodelski@gmail.com>
To: "ian.farrer@telekom.de" <ian.farrer@telekom.de>
Content-Type: multipart/alternative; boundary=089e0160a478a2697504e93e8a4e
Cc: "<dhcwg@ietf.org>" <dhcwg@ietf.org>
Subject: [dhcwg] A few comments about draft-farrer-dhc-shared-address-lease-00
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Oct 2013 11:25:39 -0000


I apologize for doing a review so late before IETF. I should have done that
a few weeks ago. A few (hopefully useful) comments...


With respect to this:
"This memo describes an update to [RFC2131], which enables the dynamic
leasing of shared IPv4 address and layer 4 source ports to DHCPv4 over
DHCPv6 clients [I-D. etf-dhc-dhcpv4-over-dhcpv6]."

Is it intended to restrict shared addresses functionality to
DHCPv4-over-DHCPv6 clients? It is ok that the draft addresses a specific,
real life use cases, but if it is possible to implement it as a more
generic approach, the document should strive to make it sound generic.

It may be useful to provide a definition of DHCPv4-over-DHCPv6 client
(which is a term used multiple times throughout the document). Although,
there is a reference to the DHCPv4-over-DHCPv6 draft, this draft doesn't
provide a definition for it. Some form of the glossary may be useful.

"[I-D.ietf-dhcp-dhcpv4-over-dhcpv6] introduces a Unified Server..."

After one of the reviews we have changed the terminology in the DHCPv4 over
DHCPv6 draft and we refer to the server processing DHCPv4 requests over
DHCPv6 protocol as "4o6 Server".

3.1 Allocation a Shared, Dynamic IPv4 Address
"The process described below detail...". Should it be "The process
described below details...." ?

Since, the draft is intended to update RFC2131, it should be mentioned what
the server which doesn't support the Dynamic Shared addresses should do
when it receives a message with the OPTION_PORTPARAMSV4. Should it ignore
the message? What should do the server which supports this extension (and
is configured to use it) but haven't received the OPTION_PORTPARAMSV4
option from the client.

"... within the BOOTPRELAYV6 message  may respond with a DHCPOFFER ...".

Suggest to use MAY instead of "may".

3.1.3. It may be implicitly assumed, because RFC2131 describes the message
exchange process in detail, but IMHO it should be mentioned that client
MUST include yiaddr in DHCPREQUEST to indicate the desired configuration
(besides PSID). Also, the DHCPREQUEST message MUST contain the Client
Identifier (the same that was used to create DHCPDISCOVER).

In the RFC2131 sections: 2.2 and 3.1 it is said that server SHOULD or MAY
probe that the address being assigned is already in use. The draft is
intended to update RFC2131 so it should be mentioned that server MUST NOT
probe that the address being assigned is in use using ICMP Echo. The text
about client not performing final check is fine obviously.

3.2. Reusing a Previously Allocated Shared, Dynamic IPv4 address

"OPTION_PORTPARAMSV4 MUST be included in the message flow, with the
client's requested port set being included in the DHCPDISCOVER message".

Note that section 3.2 of RFC2131 doesn't mention DISCOVER. The whole
communication is based on 2-way exchange DHCPREQUEST/DHCPACK. Did you mean

Although, I support the idea to refer to the draft being updated rather
than rewriting whole sections, but in this case it may be unavoidable. For
- With the standard DHCP, the client will broadcast REQUEST which is not
the case for the Shared Dynamic allocation.
- normally server would broadcast the DHCPNAK if requested binding is
invalid (expired or whatever), it is not the case here.
- Client MUST not perform final check on the assigned address when Shared
Dynamic allocation is used (RFC2131 section 3.2. says it does).

What I mean here is that there are two many disparities between the bare
DHCP protocol described in the RFC2131 and extension described in your
draft to be just able to say: "The RFC2131 is followed with the exception
that OPTION_PORTPARAMSV4 must be included everywhere."

5. Additional Changes to RFC2131 Behvaiour
Neither should server probe IPv4 addresses assigned.

6. Typo: MUST use apply. Should be MUST apply.

7. Specific Behaviour for Softwire Clients
I would rather see this section in the different draft and leave this one a
more generic extension to DHCPv4 to simply allocate IPv4 address + PSID.

8. DHCPv4 over DHCPv6 Source Address Option
The format of the option is wrong. The fields holding lengths of the
variable length fields should be laid before the variable length fields as
typically the server would parse the option from the beginning to the end.

cipv6-prefix-hint is not described

What are the minimal lengths of the prefixes (and minimal length of the
option)? Blank prefix means length=0?