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

From: Ralph Droms <[email-masked]>
Date: Mon, 25 Jun 2007 10:43:12 -0400

There has been no response to this WG last call, so the deadline will be
extended to 1700EDT, 07/02/07.

=====
This message announces a joint mip6 and dhc WG last call on
"MIP6-bootstrapping for the Integrated Scenario"
<draft-ietf-mip6-bootstrapping-integrated-04.txt> and "DHCP Option for
Home Information Discovery in MIPv6" <draft-ietf-mip6-hiopt-05.txt>.
The last call will conclude at 1700EDT on 06/28/07.

Note that draft-ietf-mip6-hiopt-05.txt was recently submitted for
publication and should appear on all the usual I-D repositories soon.

The dhc WG is asked to review the use and design of DHCP options in
these documents.

Please respond to this WG last call.  Responses may be sent to either
[email-masked] or [email-masked].  If you support acceptance of the
documents without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Lack of discussion does not
represent positive support.  If there is no expression of support for
acceptance during the WG last call, the documents will not be advanced
to the IESG.

Summary of documents:

In an integrated mobility scenario, the mobile node's mobility service
is authorized by the same service authorizer as the network access
service authorizer.  draft-ietf-mip6-bootstrapping-integrated-04.txt
defines a method for home agent information discovery for the
integrated scenario.  draft-ietf-mip6-hiopt-05.txt defines a
DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home
agent address, home agent FQDN and home subnet.  New DHCP options are
defined to carry the information from a DHCP server to the DHCP client
running on the mobile node.

These drafts are available as:
http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integrated
-04.txt
and http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-05.txt

- Stig Venaas, Ralph Droms
  dhc WG chairs

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

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 25 Jun 2007 11:47:52 -0700

> 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

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.

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?

   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.

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.

   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.

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

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 29 Jun 2007 12:31:38 -0400

Regarding
http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-05.txt, David
did an excellent and thorough review.

I too have many of the same issues as David.

1. Use of 16-bit suboptions in OPTION_MIP6-RELAY and OPTION_MIP6-HNINF.
Using 8-bit suboptions just complicates implementations that must
support this and packages that decode it. For DHCPv6, we really should
stick to use 16-bit TLV data *ALL THE WAY*. And, the cost of 2 more
bytes/suboption isn't a big deal.

But, perhaps these really aren't sub-option but instead radius encoded
attributes ("This option carries the RADIUS or Diameter attributes that
are received at the NAS from the AAAH.")? In that case, shouldn't the
sub-options description clearly indicate that and be radius-attributes
or something like that. It is CRITICAL to note that for radius
attributes, the L field in the TLV *includes* the L field (which is not
the case for DHCP options!).

But, then "3.2.1.  MIP6 Relay Agent Sub-option" lists these suboptions
which clearly are not the radius encode attributes.

2. Do not use suboption 0. All other sub-options that I'm aware of
always start numbering at 1 and you're just asking for trouble with
implementations (apparently such as ISC's) that assume 0 is not "valid".
We also have code that would break if sub-option 0 is used in our server
(though for a completely different reason than the ISC issue).

While you can argue that any suboption value should be valid, that isn't
the issue. If you want these options supported by implementations,
everything you can do to make that easy to do (by following existing
conventions) will make it that much easier for the support to be added.
If a lot of code needs to be reworked and retested, you're not as likely
to get the options deployed.

[The remaining comments are probably more because of my ignorance of
this solution as I haven't kept up with the MIP6 work.]

3. Is there a need to establish a registry for id-type in these options,
or does this already exist somewhere else in the MIP6 space? If it does
exist elsewhere, how about referencing that? 

If these are newly assigned values, wouldn't using 0 for no-preference
make more sense?

4. Is there a need to establish a registry for the suboptions for these
options?

5. Home Network Identifier field:

- "In this case, the Home Network Identifier field SHOULD be set to 0."
Don't you mean that it should not be present? (IE, option length should
be 2 and just have the id-type and reserved bytes?)

- It might be useful to indicate that this Home Network Identifier field
does NOT include a null byte to terminate the string? Or, perhaps this
should always be null terminated and hence why you say "SHOULD be set to
0"?

Bottom line, I agree with David that we SHOULD NOT advance this draft at
this time. It still needs work.

- Bernie

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]] 
Sent: Monday, June 25, 2007 2:48 PM
To: DHC WG
Subject: Re: [dhcwg] EXTENDED: Joint mip6 and dhc WG last call
ondraft-ietf-mip6-bootstrapping-integrated and draft-ietf-mip6-hiopt

http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integr
ated

Correction (I think?):

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

   The