Subject: Re: some comments about DHCPv6 I-Ds

From: "Michael W. Carney" <[email-masked]>
Date: Sun, 30 Jul 2000 19:58:30 -0700

Hi Francis,

Thanks for the comments. My points are added below.

Francis Dupont wrote:
> 
> Here are some comments about DHCPv6 I-Ds by our Indian student
> who is supposed to do a DHCPv6 first implementation for the next week.
> 
> I disagree with him about (1) because in fact you can get the link
> from an address. With a prefix-length the test is an equality (same
> length and prefix), without it is a matching (harder but still possible).
> (more accurately it is a matching between the relay address for off-link
> clients and one of the prefixes configurated (in the config file) for the
> link).
> Proposal: get rid of the prefix length field.
> 
> (2) is really misleading, (3) is a general comment (too much freedom).
> 
> You already know (4) (:-) but I have not perverted Dhawal (he has found
> the issue by himself).
> 
> (5) is about poor wording
> 
> (6) => remove the R bit (the C bit is enough).
> 
> (7) is from an older draft (today relay is very easy to implement :-).
> 
> (8) is like (3) (and Dhawal has looked for a missing profile).
> 
> (9) is about the rules for I-D format which is *mandatory*:
> please replace word by a text editor (:-), cfd RFC 2223:
> 
>    3a.  ASCII Format Rules
> 
>       The character codes are ASCII.
> 
>       Each page must be limited to 58 lines followed by a form feed on a
>       line by itself.
> 
>       Each line must be limited to 72 characters followed by carriage
>       return and line feed.
> 
>       No overstriking (or underlining) is allowed.
> 
>       These "height" and "width" constraints include any headers,
>       footers, page numbers, or left side indenting.
> 
>       Do not fill the text with extra spaces to provide a straight right
>       margin.
> 
>       Do not do hyphenation of words at the right margin.
> 
>       Do not use footnotes.  If such notes are necessary, put them at
>       the end of a section, or at the end of the document.
> 
>       Use single spaced text within a paragraph, and one blank line
>       between paragraphs.
> 
>       Note that the number of pages in a document and the page numbers
>       on which various sections fall will likely change with
>       reformatting.  Thus cross references in the text by section number
>       usually are easier to keep consistent than cross references by
>       page number.
> 
>       RFCs in ASCII Format may be submitted to the RFC Editor in e-mail
>       messages (or as online files) in either the finished publication
>       format or in nroff.  If you plan to submit a document in nroff
>       please consult the RFC Editor first.
> 
> Regards
> 
> [email-masked]
> 
> PS: we have not found a problem which makes implementation impossible.
>
> Dear Sir,
> I have the following problems in context of the two drafts:
> (a) draft-ietf-dhc-dhcpv6-15.txt
> (b) draft-ietf-dhc-dhcpv6exts-12.txt
>
> (1) Client binding has been defined as "a group of server
> data records indexed by <client's link-local address,
> subnet prefix> containing the releasable resource data
> which a DHCP server has assigned to a client" on page
> 3 of (a) but there is no prefix-len field in a DHCP
> Request or Release message. The result is that if a server
> receives a request message with c bit set and no IP Address
> Extension or a release message without any IP Address Extension,
> it can't release a resource because it can't identify a
> binding without prefix-len.

Agreed. Seems that unicasting messages directly to off-link servers
complicates the server's job of the identification of a binding. In
order to disambiguate requests/releases, the client would need to
provide a link identifier (subnet prefix?) which it cannot know.
Suggestions?

>
> (2) On page 27 of (b) the figure for Subnet Prefix Extension shows
> it to be 32-bit field while its actually only 8-bit field.
> (Poor drawing).

Will fix.

>
> (3) Nothing has been mentioned in either of the drafts regarding
> when a non IP Address Extension should be sent. (Which ones
> are mandatory and which ones are optional in a DHCP message.)
> e.x. Can I send an extension other than Subnet Prefix Extension
> in an advertise message even if "administrative policy requires it"?
> (page 3 of (b)).

Actually, only subnet prefix extensions and authentication extensions
make sense for advertisements, at this time. Are they the only ones
moving toward the future? Probably not. So is the suggestion that we
itemize which extensions are legal for each message?

>
> (4) There is no clause saying "multi-link-subnets" are not allowed in DHCP.

Is such support required to make DHCP useful immediately? (are such
architectures going to be common place?)

>
> (5) Page 27 of (a) says: "The client waits ADV_MSG_TIMEOUT, collecting
> Advertise messages." while page 45 of same draft says "A client MUST
> wait for SRVR_PREF_WAIT seconds after sending a DHCP Solicit message
> to collect Advertise messages". I think that the clause on page 45
> should be modified to "A client MUST wait for SRVR_PREF_WAIT seconds
> after receiving first advertise to collect Advertise messages".

Good find. A couple of things need to happen here -

        a) Spec must be clarified to state that a client MUST stop
        waiting for advertise messages after one with a preference of
        255 is detected. Only that advertise message is accepted for
        processing (others are ignored).

        b) The server preference section (14.4 of (a) (page 45)) really
        belongs in the main body of the document where preference is
        described, and not languish in its own enty in the DHCP client
        implementors notes. (part of the protocol). This will happen in
        the next draft.  

>
> (6) Page 47 of (a) says that Transaction-ID cache "enables the server to
> quickly determine whether a Request is a retransmission or a new Request".
> Page 46 of the same draft says that "server MUST include the
> transaction-ID from the client's Request along with the releasable
> resource identifier(s) within the binding". Thus clearing transaction
> ID cache entries through "R" bit in request message is of no use. The
> server can still detect a retransmission because transaction-ID is still
> there in stable storage.

In general, the purpose / use of the transaction ID (cache or otherwise)
needs to be clarified. If we are planning on using the transaction ID to
preserve idempotence by including it within the client's binding, then
the entry for binding in the DHCP terminology section needs to be
updated, and the client's requirement to preserve transaction ID over
restarts becomes apparent, and the purpose of the 'R' bit goes away. A
server may implement the cache for performance reasons, but it isn't a
protocol requirement.

>
> (7) "ICMPError" defined on page 8 of (a) has been used nowhere else.
> Probably this is used by relays when server is unreachable.

May mean DNS server is unavailable. Need to clarify if that's the case,
remove otherwise.

>
> (8) There should be table of allowed combination of bits (C, I, L, Q, A,
> P) in IP Address Extension.

Nice suggestion. I'll discuss this with the other authors.

>
> (9) The last problem is same as yours: "Format of the drafts".

The document is in LaTex, and the dvi2tty converter I have isn't the
greatest. For sure in the next version, the formating will be corrected
and the tables fixed (no underlining).

> Thanking you,
> Yours sincerely,
> Dhawal Kumar.