Subject: Re: Re: [dhcwg] EXTENDED: Joint mip6 and dhc WG last call on draft-ietf-mip6-bootstrapping-integrated and draft-ietf-mip6-hiopt

From: Heejin Jang <[email-masked]>
Date: Fri, 29 Jun 2007 04:25:53 +0000 (GMT)

Hi, David.

Glad to hear the useful comments from dhcwg.

Thanks for your feedback and see the inline below regarding hiopt draft.

- Regards,

Heejin

-------- Original Message -------
Sender : David W. Hankins<[email-masked]>
Date : 2007-06-26 03:47
Title : Re: [dhcwg] EXTENDED: Joint mip6 and dhc WG last call on
draft-ietf-mip6-bootstrapping-integrated and draft-ietf-mip6-hiopt

On Mon, Jun 25, 2007 at 10:43:12AM -0400, Ralph Droms wrote:

> There has been no response to this WG last call, so the deadline will be

> extended to 1700EDT, 07/02/07.

My excuse is that I was in Alaska.

> http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integrated

> -04.txt

Correction (I think?):

http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-04.txt

I actually don't see a lot in there for DHCWG to review.  Maybe I'm

not looking hard enough?

I am a little concerned (but only a little) at the extent to which

it defines simplified RFC3315 behaviour ("summarizing" the process

in which a client is identified and configured).

(3) The Relay Agent intercepts the Information Request from the

I think "receives" is a better word, considering that the packet is

transmitted to a multicast address.  "intercept" has more of an

insinuation that the relay would not normally receive the packet.

So I see no problem advancing this draft to the IESG.

> and http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-05.txt

ISC DHCP and others share option processing code between the v4

and v6 side of the house.  I don't know about the others, but the

net effect for ISC DHCP is that code 0 is treated as an "end tag"

(code 255, or "code all ones" for any code width, is not).  This

sounds a little weird, but that's the contrivance of the loop we

selected.

If the sub-options could be numbered from 1, then this draft would

be compatible with our currently released alpha.

If not, then it would take new code, adding more branches between

each run of the option processing loop.

Heejin >> Ok. We'll reflect this point so that sub-options start from
number 1.

I note also that the sub-option codes are 8-bit code/length pairs.

That doesn't affect ISC DHCP, but I wanted to point it out for other

implementors.

I think this is the first time we've seen non-16-bit code/lengths

inside DHCPv6?

Heejin >> IPv6 main options & lengths are defined as 16 bit-fields
but I cannot find any 16 bits code & length in IPv6 sub-options.

Some of sub-options (Binding Unique Identification option) or proposals suggested
to use 8-bit code & length IPv6 sub-options.

Is there any sub-option with 16 bits code & length in IPv6? If I missed
something, kindly let me know it.

If the request message carries more than one Home Network Identifier

options, the reply message MUST contain Home Network Information

options as many as Home Network Identifier options in the request.

I think 'as many' wants to be moved left 4 words or so.

Heejin >> Thanks for correcting this.

Second, I think MUST is too strong, since if the DHCP server is not

configured with values, it will be unable to reply.  Consider

specifically server software that does not (yet) have support for

these options - they will certainly have no code which enforces the

construction of 'empty' options.

Heejin >> The use of 'MUST' is selected taking into account option ordering
and mapping.

Without the same number of options in reply, options with the same
id-type cannot be mapped

based on ordering. This is also relative to the following answer.

The

Home Network Information options in the reply SHOULD appear in the

same order as Home Network Identifier options in the request and the

matching is based on the sequential order of options.  This provides

a way of matching for Home Network Information options with the same

id-type.

I don't get it.  The options SHOULD ppear in the same order, which

means they might not, and the order is also used to match replies

against requests?  So the protocol stipulates that sometimes replies

will not match their requests?

I'm pretty sure this doesn't work, and I'm pretty certain that

we don't want to stipulate the strict ordering of the options.

So, I'm not in favor of advancing this document.

If there is a requirement for mulitple instances of these options,

it would be my strong preference for the mechanism to more closely

mimic IA_* options than has been presented here.

Heejin >>  To avoid the dependency of options ordering,  We
also considered the use of

identifier for matching (such as  a IAID) but just worried about its overhead
since we expected that

usually not so many same id-types are included in the request option.
We'll discuss this again and

consider to relax MUST to SHOULD (previous comment).

I'd also like to see the sub-option-codes numbered from 1, but that's

not a requirement.

--

Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.

https://secure.isc.org/store/t-shirt/

--

David W. Hankins    "If you don't do it right the first time,

Software Engineer             you'll just have to do it again."

Internet Systems Consortium, Inc.        -- Jack T. Hankins

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