DHCP Options for Home Information Discovery in Mobile IPv6 (MIPv6)
draft-ietf-mip6-hiopt-18

[Ballot discuss]
The Gen-ART Review by Suresh Krishnan states that the document is not
  ready for publication, yet the authors have not received a response.
  The Gen-ART Review needs a response.  The review can be found at:

    http://www.alvestrand.no/ietf/gen/reviews/
    draft-ietf-mip6-hiopt-11-krishnan.txt

[Ballot comment]
To use the IANA policies defined in RFC 2434, you need that as a
(normative) reference.

In couple of places, "SHOULD not" should be spelled "SHOULD NOT".

Please use example.com/net/org instead of "myhomeisp.com".

[Ballot discuss]
Section 3.1 says that "Option-len" is equal to "1 + length of
Sub-options in units of 8 octets". I believe it should say "1 +
length of Sub-options in octets". The same error (octets vs 8 octets)
occurs in several other places, too.

Section 3.1.1 doesn't define the format for Home Network Prefix
Sub-options, and there's no IANA considerations on how they could
be defined in the future.

The spec seems to have conflicting text about whether the DHCP server
must copy the home network identifier (FQDN) from the request to
reply, or whether it can return something else. In particular, the
paragraph discussing "partially matched results" seems to contradict
a MUST earlier in the same section.

The remainder is a "discuss discuss", and will be probably cleared
after the telechat: Given the ongoing work on DSMIPv6, should this
document also define the option code for DHCPv4 use?

[Ballot discuss]
In section 4.1:

"  A mobile node does not need to perform the home information discovery
  procedure after every change in attachment.  It may try to perform
  the home network information discovery when it lacks home network
  information for MIPv6 or needs to change the home agent for some
  reasons, for example, to recover from the single point of failure of
  the existing home agent or to use the topologically best home agent."


There is no discussion on how the mobile node is to use this information or select "the topologically best home agent." There at least needs to be a reference. Also, why is "topologically best" the best home agent to use? Why not the least loaded?


Later in the same section, it mentions that a mobile node can request multiple home information. What is interesting is that in the definition of passing the information in section 3 there is no hint, policy knob or preference given in the information. One can easily imagine the utility if there was an ability to bias which home information was to be used. It is certainly useful in the selection of the "topologically best home agent" or "best home agent" in general.

[Ballot discuss]
In section 4.1:

"  A mobile node does not need to perform the home information discovery
  procedure after every change in attachment.  It may try to perform
  the home network information discovery when it lacks home network
  information for MIPv6 or needs to change the home agent for some
  reasons, for example, to recover from the single point of failure of
  the existing home agent or to use the topologically best home agent."


There is no discussion on how the mobile node is to use this information or select "the topologically best home agent." There at least needs to be a reference. Also, why is "topologically best" the best home agent to use? Why not the least loaded?


Later in the same section, it mentions that a mobile node can request multiple home information. What is interesting is that in the definition of passing the information in section 3 there is no hint, policy knob or preference given in the information. One can easily imagine the utility if there was an ability to bias which home information was to be used. It is certainly useful in the selection of the "topologically best home agent" or "best home agent" in general.

IANA Last Call comments:

Action 1:

Upon approval of this document, the IANA will make the following
assignments in the "DHCPv6 and DHCPv6 options" registry located
at http://www.iana.org/assignments/dhcpv6-parameters
sub-registry "DHCP Option Codes"

Value Description Reference
----- ---------------------- ---------
[tbd] OPTION_MIP6_HNINF [RFC-mip6-hiopt-11]
[tdb] OPTION_MIP6_RELAY [RFC-mip6-hiopt-11]


Action 2:

Upon approval of this document, the IANA will in the following
registry "DHCPv6 and DHCPv6 options" located at
http://www.iana.org/assignments/dhcpv6-parameters
create a new sub-registry "OPTION_MIP6_HNINF option"

Registration Procedures: Standards Action or IESG Approval
Initial contents of this sub-registry will be:

Code Name Reference
-------- ------------------------- ---------
0 Reserved [RFC-mip6-hiopt-11]
1 Home network identifier [RFC-mip6-hiopt-11]
2 Home network prefix [RFC-mip6-hiopt-11]
3 Home agent address [RFC-mip6-hiopt-11]
4 Home agent FQDN [RFC-mip6-hiopt-11]
5-65535 Reserved [RFC-mip6-hiopt-11]


Action 3:

Upon approval of this document, the IANA will in the following
registry "DHCPv6 and DHCPv6 options" located at
http://www.iana.org/assignments/dhcpv6-parameters
create a new sub-registry "OPTION_MIP6_RELAY option"

Registration Procedures: Standards Action or IESG Approval
Initial contents of this sub-registry will be:

Code Name Reference
-------- ------------------------- ---------
0 Reserved [RFC-mip6-hiopt-11]
1 Home network prefix [RFC-mip6-hiopt-11]
2 Home agent address [RFC-mip6-hiopt-11]
3 Home agent FQDN [RFC-mip6-hiopt-11]
4-65535 Reserved [RFC-mip6-hiopt-11]


Action 4:

Upon approval of this document, the IANA will in the following
registry "DHCPv6 and DHCPv6 options" located at
http://www.iana.org/assignments/dhcpv6-parameters
create a new sub-registry "Home Network Information Option Id-Type Values"

Registration Procedures: Standards Action or IESG Approval
Initial contents of this sub-registry will be:

Code Name Reference
-------- ------------------------- ---------
0 Visited Domain (local ASP) [RFC-mip6-hiopt-11]
1 Target MSP [RFC-mip6-hiopt-11]
2 No preference [RFC-mip6-hiopt-11]
3-65535 Reserved

We understand the above to be the only IANA Actions for this
document.

[Ballot discuss]
The security considerations section notes that there is no impact
on DHCP security, but fails to describe the implications for mobile
IPv6.  RFC 3315 notes a number of issues that *could* be important:

The DHCP threat model does not consider the privacy of the contents of
DHCP messages to be important.  I would think that home network
information could be considered sensitive in cases, couldn't it?
I beleive this is covered in sections 15.5 and 15.6 of the security
considerations in 3775.  If this is the correct material for this
situation, a pointer would suffice.

However, communication between a server and a relay agent, and
communication between relay agents, can be secured through the use
of IPSec, as described in section 21.1.  Does the transmission of
home network information make IPSec more important to apply?

DHCP authentication provides for authentication of the identity of
DHCP clients and servers, and for the integrity of messages delivered
between DHCP clients and servers.  Is this service likely to be
available in the mobile case?

I would like to see a summary of the implications of this spec for
IPv6.  (Stating that there are none is okay if that is really the
case, although I am initially skeptical!)

[Ballot comment]
Section 4.3 is "DHCP Server Behavior" but the first sentence talks about the mobile node
recieving a relay-forward message.  As I skimmed 3315, it appears the relay-forward
message is transmitted from the relay agent to the dhcp server.

[Ballot discuss]
The security considerations section notes that there is no impact
on DHCP security, but fails to describe the implications for mobile
IPv6.  RFC 3315 notes a number of issues that *could* be important:

The DHCP threat model does not consider the privacy of the contents of
DHCP messages to be important.  I would think that home network
information could be considered sensitive in cases, couldn't it?

However, communication between a server and a relay agent, and
communication between relay agents, can be secured through the use
of IPSec, as described in section 21.1.  Does the transmission of
home network information make IPSec more important to apply?

DHCP authentication provides for authentication of the identity of
DHCP clients and servers, and for the integrity of messages delivered
between DHCP clients and servers.  Is this service likely to be
available in the mobile case?

I would like to see a summary of the implications of this spec for
IPv6.  (Stating that there are none is okay if that is really the
case, although I am initially skeptical!)

[Ballot comment]
The following issues were raised by Scott Bradner in his OPS-DIR review. I do not think that they are show-stoppers, but it would be very goo for the issues to be considered and addressed f the document goes through an extra round of editing.

1. this document would significantly benefit from a clear description of the use case for this technology.  The problem this ID seems to be addressing comes up when a mobile node is starting up in a remote location and wants to find its home agent.  The mobile node multicasts a dhcp request with some options to indicate that it wants to know its home agent info and some home network information and the dhcp server provides the mobile node with the requested info.  I'm not sure I got that right and I do not see how the dhcp server knows or gets the info about the home agent.  I'm sure its all here somewhere but a paragraph giving a use case overview would help.

2. I do not see where the doc describes the behavior of the mobile node in the case where the dhcp server does not support the required options. (I would have expected to see something about this in section 4.1)

3. The draft does refer to a number of other IDs  such that the ID may be hung up in the RFC Editor queue until  some of them are published.  It also includes the text "[Editor's note: The Diameter AVPs need to be defined]" in section 4.2 that does not seem like the right thing to be publishing in a RFC.

4. a final nit - RFC 2119 should be an informative not a normative reference

[Ballot discuss]
The Gen-ART Review by Francis Dupont states that the document is not
  ready for publication, yet the authors have not received a response.
  The Gen-ART Review needs a response.  The review can be found at:

    http://www.alvestrand.no/ietf/gen/reviews/
    draft-ietf-mip6-hiopt-10-dupont.txt

[Ballot comment]
Section 3.1., paragraph 5:
>      option-len
>          2 + length of Home Network Identifier field

  Please make it clear that all lentgh fields are in units of bytes.

Section 3.1., paragraph 7:
>          The type of Home Network Identifier:
>              0    Visited domain (local ASP)
>              1    Target MSP
>              2    No preference

  Please clarify what to to with options that have id-types > 2.
  Usually: "MUST NOT send, MUST ignore on receive."

Section 3.2.1., paragraph 3:
>      sub-opt-code

  When sub-opt-code is 1 or 2, the sub-option becomes fixed-length and
  doesn't really need the sub-opt-len length field.

Section 3.2.1., paragraph 4:
>          A 16-bit unsigned integer for the type of the following
>          Home Network Information field. Possible values are:
>              1    Home network prefix
>              2    Home agent address
>              3    Home agent FQDN

  Please clarify what to to with sub-options that have sub-opt-code 0
  or > 2. Usually: "MUST NOT send, MUST ignore on receive." (Also for the
  corresponding option in Section 3.3.1.)

Section 3.2.1., paragraph 8:
>          A home network prefix, home agent IP address or home agent
>          FQDN to be provided to a mobile node according to the
>          sub-opt-code. These are encoded as specified in Section
>          3.2.1.

  This text *is* in Section 3.2.1 (do you mean "as specified below"?)

Section 4.1., paragraph 9:
> In case the Home Network Information option carries the sub-option
> whose 'V' flag is not consistent with the id-type, the mobile node
> SHOULD ignore and skip the sub-option.

  Please define which cases are considered to be consistent and which
  are inconsistent.

[Ballot discuss]
Section 4.1., paragraph 7:
> The mobile node matches the returned Home Network Information options
> with the corresponding Home Network Identifier options based on
> sequence numbers in the options.  Sequence numbers provide the way to
> match options when the mobile node has requested with the multiple
> Home Network Identifier options with the same id-type 1 but with the
> different Home Network Identifiers.

  DISCUSS: Use of sequence numbers needs to be clarified. How are they
  initialized and incremented? What happens when they roll over? Also,
  because the text above seems to imply that they only matter for
  id-type 1 options, something needs to be said about what to do with
  them for other id-types, because they are present as a field in the
  option.

Section 4.1., paragraph 8:
> When the mobile node has requested the home network information with
> the id-type 0 or 1 but cannot be provided with the proper
> information, that is, option-len = 1 in the Home Network Information
> option, then it may request again by setting the id-type to 2 in the
> Home Network Identifier option.

  DISCUSS: This is the first time the draft talks about errors and that
  they apparently can be indicated by replying with empty options
  (and/or sub-options?) Something more needs to be said about this,
  especially if it triggers retries. AFAIK (but I'm no DHCP expert),
  DHCP has no concept of "try one kind of request and if that fails, try
  another."

Section 4.3., paragraph 8:
> C. Home Network Identifier option with the id-type 2

  DISCUSS: I don't understand how id-type 2 ("no preference") results
  in a useful service. The client doesn't care what it requests, and the
  server can basically respond with whatever it wants. I'm not convinced
  that this will lead to interoperable implementations. Can the "no
  preference" case be clarified or be removed?

IANA Last Call comments:


[ Note: Document doesn't discuss unallocated space in new registries. Assuming it is all available. ]

Action 1:

Upon approval of this document, the IANA will make the following
assignments in the "DHCPv6 and DHCPv6 options " registry located
at
http://www.iana.org/assignments/dhcpv6-parameters
sub-registry "DHCP Option Codes"

Value Description Reference
----- ---------------------- ---------
[tbd] OPTION_MIP6_HNID [RFC-mip6-hiopt-10]
[tbd] OPTION_MIP6_RELAY [RFC-mip6-hiopt-10]
[tbd] OPTION_MIP6_HNINF [RFC-mip6-hiopt-10]


Action 2:

Upon approval of this document, the IANA will in the following
registry "DHCPv6 and DHCPv6 options" located at
http://www.iana.org/assignments/dhcpv6-parameters
create a new sub-registry "DHCPv6 Mobile IPv6 Sub-option Codes"

Registration Procedures: Standards Action or IESG Approval.
Initial contents of this sub-registry will be:

Value Description Reference
----- ---------------------- ---------
1 Home network prefix [RFC-mip6-hiopt-10]
2 Home agent address [RFC-mip6-hiopt-10]
3 Home agent FQDN [RFC-mip6-hiopt-10]
4-65535 Available for assignment [RFC-mip6-hiopt-10]


Action 3:

Upon approval of this document, the IANA will in the following
registry "DHCPv6 and DHCPv6 options" located at
http://www.iana.org/assignments/dhcpv6-parameters
create a new sub-registry "Home Network Identifier Option id-type
Values"

Registration Procedures: Standards Action or IESG Approval.
Initial contents of this sub-registry will be:

Value Description Reference
----- ---------------------- ---------
0 Visited domain (local ASP) [RFC-mip6-hiopt-10]
1 Target MSP [RFC-mip6-hiopt-10]
2 No preference [RFC-mip6-hiopt-10]
3-255 Available for assignment [RFC-mip6-hiopt-10]

We understand the above to be the only IANA Actions for this
document.

New AD review:

I have reviewed the new version and it satisfies my AD review
concerns with the exception of the following minor issues.

I expect that the draft also has to satisfy DHC WG's review,
and address the issues raised by Bernie. I have not looked
at those yet, Bernie have you?

>>        id-type
>>
>>            The type of Home Network Identifier:
>>
>>                0    Visited domain (local ASP)
>>
>>                1    Target MSP
>>
>>                2    No preference
>
> This seems unnecessarily complicated. Is there some reason why you could
> simply include the target MSP domain information if it is known or an
> empty string otherwise and be allocated a local ASP in that case?

I still disagree that this is needed, but I'm not making this
a blocking comment if the WG wants to do it.

>> 3.2.  MIP6 Relay Agent Option
>>
>>    This option carries the RADIUS or Diameter attributes that are
>>    received at the NAS from the AAAH.  The DHCP relay agent sends this
>>    option to the DHCP server in the Relay-Forward message.
> It does not carry RADIUS or Diameter attributes (and nor should it).
> Please align this text with the actual subattributes that you have.
>
> Also, it is inappropriate to assume that the information can only come
> from AAA. Presumably we'd like the mechanisms to be general enough that,
> for instance, manual configuration, link identifier, etc. could also be
> used to determine what mobility domains are appropriate for this client.

Text was changed, but it still assumes the data comes from AAAH only. Suggested edit:

OLD:
  This option carries the home network information which was
  transferred to the NAS from AAAH by using [I-D.ietf-mip6-radius].
NEW:
  This option carries the home network information for the mobile
  node (the NAS may know this, for instance, through AAA by
  using [I-D.ietf-mip6-radius]).

>>            OPTION_MIP6-HNID (TBD)
> Do you really have to mix underscore and dash in the same symbol?

Some of this still remains: OPTION_MIP6-HNINF (TBD).

I have made my AD review of this document.

This document still needs a revision. Both due to comments given by Bernie Volz in DHC review (at the end of this e-mail), as well as for other reasons.

I believe that the delivery of mobility information via DHCP is a valid approach. However, there are a number of details that still need work.

Substantial:

>    As part of configuring the initial TCP/IP parameters, a mobile node
>    can obtain home network information for the subnet it is directly
>    attached to, other subnets in the visited domain, or a subnet from
>    its home domain.

This text makes it sound like a new home network is needed for everywhere the mobile node travels to. That is wrong. Suggested rewrite:

As part of configuring the initial TCP/IP parameters, a mobile node can find itself a suitable home agent. Such a home agent might reside in the access network that the mobile node first connects to, or in a home network that the mobile node is associated with.

>    The mobile node MUST include
>    this option along with its Option Request option in its request.
... unless it already has configured home agent and other information for itself? It would be very expensive to do this on every movement, not to mention losing sessions if the home agent and home address are actually changed.

That being said, the mobile node probably should do this occasionally to ensure that it is connected to the topologically best home agent. Yet you want to keep the old home agents still in use, to avoid losing your sessions... some text about this is probably needed either in this draft or somewhere else.

>        Home Network Identifier
>
>            The identifier to specify the requested home network of
>            the mobile node. This field MUST be set in the form of user's
>            NAI [RFC4282].

The full NAI? This is problematic in many ways, including privacy, operation with mobile nodes that only know their domain but do not have a NAI, etc.

Wouldn't it be more appropriate to simply provide the user's domain?

>        id-type
>
>            The type of Home Network Identifier:
>
>                0    Visited domain (local ASP)
>
>                1    Target MSP
>
>                2    No preference

This seems unnecessarily complicated. Is there some reason why you could simply include the target MSP domain information if it is known or an empty string otherwise and be allocated a local ASP in that case?

> 3.2.  MIP6 Relay Agent Option
>
>    This option carries the RADIUS or Diameter attributes that are
>    received at the NAS from the AAAH.  The DHCP relay agent sends this
>    option to the DHCP server in the Relay-Forward message.
It does not carry RADIUS or Diameter attributes (and nor should it). Please align this text with the actual subattributes that you have.

Also, it is inappropriate to assume that the information can only come from AAA. Presumably we'd like the mechanisms to be general enough that, for instance, manual configuration, link identifier, etc. could also be used to determine what mobility domains are appropriate for this client.

Affects Section 4.2, too.

>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      OPTION_MIP6-HNINF      |          option-len          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |    id-type  |    reserved  |    HNID_seq  |              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+              +
>    .                          sub-options                          .
>    .                                                              .
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>          option-code
>
>            OPTION_MIP6-HNINF (TBD).
>
>          option-len
>
>            Total length of the option-data in octets
>
>          id-type
>
>            The type of Home Network Identifier:
>
>                0    Visited domain (local ASP)
>
>                1    Home domain
>
>                2    No preference
>
>          reserved
>
>            An 8-bit field reserved for future use.  The value MUST
>            be initialized to 0 by the sender and MUST be ignored by
>            the receiver.
>
>          HNID_seq
>
>            An 8-bit unsigned integer used for matching for Home Network
>            Identifier options when the mobile node has requested with
>            the multiple Home Network Identifier options with the same
>            id-type 1 but having different Home Network Identifiers.
>
>          sub-options
>
>            A series of sub-options carrying MIP6 bootstrap
>            information.

Why is id-type field needed here? Just to be able to reply to the requested option? That does not seem so useful, IMHO. Or to be able to implement the Section 4.1 processing that is different depending on what type of network we are talking about? But wouldn't HNID_seq and the ordering of options be sufficient for this?

>    When the mobile node receives a Reply message from the DHCP server
>    and gets more than one home network information, it MUST have a
>    selection mechanism to determine which one to use for establishing a
>    Mobile IPv6 session.  For example, if the mobile node acquires both
>    IPv6 address and FQDN of the home agent, it may try to use the
>    address information of the home agent first.

I agree that a selection mechanism is needed. But is clear how I can evaluate an implementation's conformance to the MUST above. It might be better to simply enumerate in this draft what the order should be, and whether multiple in parallel contact attempts are required/allowed/discouraged. The subsequent text does do this, at least to an extent. Its not clear that the MUST above is needed if the text is complete.

>    However, how long the NAS should keep
>    the home information depends on the administrator's policy.  When the
>    NAS does not keep the home information for the requesting mobile node
>    at the time of receiving the Information Request from the mobile
>    node, it may try to acquire the information by interacting with a AAA
>    server again through some other mechanisms which are not in the scope
>    of this document

But such mechanisms do not exist in the general case. I would recommend simply requiring that the NAS needs to store the information. In any case, a NAS is required to know about the sessions it has.

> 4.2.  NAS/DHCP Relay Agent Behavior
>
>    The NAS and the DHCP relay agent are assumed to be collocated in this
>    solution.

This limitation needs to be stated upfront, in the Introduction.

(And the limitation does not appear to be exactly what you say above. Presumably type 0 home agents can be requested without any relays.)

Editorial:

>            OPTION_MIP6-HNID (TBD)
Do you really have to mix underscore and dash in the same symbol?

Bernie Volz's review:

> 3.2.1.  MIP6 Relay Agent Sub-option
>
>    This sub-option carries the assigned home network information to the
>    DHCP server.
>
>
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          sub-opt-code        |  sub-opt-len  |    reserved  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    .                                                              .
>    .                  Home Network Information                    .
>    .                                                              .
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>          sub-opt-code
>
>            A 16-bit unsigned integer. The sub-option identifies the
>            type of the following Home Network Information field.
>            Possible values are:
>
>                1    Home subnet prefix
>
>                2    Complete IPv6 address of the home agent
>
>                3    FQDN of the home agent
>
>          sub-opt-len
>
>            An 8-bit unsigned integer. The length of the following
>            Home Network Information field + 1.
>
>
> --> DHCPv6 uses 16-BIT option/suboption CODES AND 16-BIT LENGTHS, not
> 8-bit lengths! And mixing 16/8 bits is the WORST thing that they could
> ever do. My recommendation would be to use 16-bit codes and 16-bit
> lengths. PERIOD.
>
> This same issue exists in 3.3.1, Home Network Information Sub-option.
>
>
> Section 4 (and 4.3 in particular) mentions the ORO option but doesn't
> make it clear that the OPTION_MIP6-HNINF option code *MUST* be included
> in the ORO if the client ever wants this option returned by the server.
>
> In 4.1, is stated:
>                                                In this message
>    the mobile node (DHCP client) SHALL include the Option Code for the
>    Home Network Identifier option in the OPTION_ORO.
>
> But, why would the client include the OPTION_MIP6-HNID in the ORO, as
> this is FROM CLIENT TO SERVER. I think they meant OPTION_MIP6-HNINF.
> Section 3.1 states:
>
> 3.1.  Home Network Identifier Option
>
>    This option is used to indicate the target home network requested by
>    the mobile node to the DHCP server.  The mobile node MUST include
>    this option along with its Option Request option in its request.
>
>
> Personally, they need to go back to clean up this draft. It is NOT
> acceptable and full of mistakes.
>
> I haven't studied it carefully, but as I've already found the above
> issues, more work is needed to clean it up.

> Oh, you can add another issue to this draft. Two of the email addresses
> in the draft are bad:
>
> 5.1.0 - Unknown address error 550-'5.1.1 ...
> User unknown'
> 5.1.0 - Unknown address error 550-'5.1.1 No such user
>

Bernie Volz's review:

No, this draft is still very broken.

3.2.1.  MIP6 Relay Agent Sub-option

  This sub-option carries the assigned home network information to the
  DHCP server.


    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          sub-opt-code        |  sub-opt-len  |    reserved  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  .                                                              .
  .                  Home Network Information                    .
  .                                                              .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        sub-opt-code

            A 16-bit unsigned integer. The sub-option identifies the
            type of the following Home Network Information field.
            Possible values are:

                1    Home subnet prefix

                2    Complete IPv6 address of the home agent

                3    FQDN of the home agent

        sub-opt-len

            An 8-bit unsigned integer. The length of the following
            Home Network Information field + 1.


--> DHCPv6 uses 16-BIT option/suboption CODES AND 16-BIT LENGTHS, not
8-bit lengths! And mixing 16/8 bits is the WORST thing that they could
ever do. My recommendation would be to use 16-bit codes and 16-bit
lengths. PERIOD.

This same issue exists in 3.3.1, Home Network Information Sub-option.


Section 4 (and 4.3 in particular) mentions the ORO option but doesn't
make it clear that the OPTION_MIP6-HNINF option code *MUST* be included
in the ORO if the client ever wants this option returned by the server.

In 4.1, is stated:
                                              In this message
  the mobile node (DHCP client) SHALL include the Option Code for the
  Home Network Identifier option in the OPTION_ORO.

But, why would the client include the OPTION_MIP6-HNID in the ORO, as
this is FROM CLIENT TO SERVER. I think they meant OPTION_MIP6-HNINF.
Section 3.1 states:

3.1.  Home Network Identifier Option

  This option is used to indicate the target home network requested by
  the mobile node to the DHCP server.  The mobile node MUST include
  this option along with its Option Request option in its request.


Personally, they need to go back to clean up this draft. It is NOT
acceptable and full of mistakes.

I haven't studied it carefully, but as I've already found the above
issues, more work is needed to clean it up.

Is anyone in the mip6 WG reviewing this draft?

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Document shepherd: Basavaraj Patil
I have reviewed this version of the I-D and believe it is ready for
IESG review and publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes. The document has been reviewed extensively by MIP6 WG
members. Additionally this I-D has been reviewed by members of the DHC
WG as well. No concerns about the depth or breadth of review by the
document shepherd exist.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

No further review from security, AAA or XML experts is needed for this I-D.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No concerns or issues about this I-D exist. This I-D has been in WG
discussion for quite sometime now and has been presented and discussed
at several WG meetings as well.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

WG consensus is solid. The WG as a whole understands the need for
using DHCP for bootstrapping and hence I believe it is not the opinion
of just a few individuals but the broader WG.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No appeals have been threatened or any other action. No serious
discontent to be noted exists either.


(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

The draft has been run through the ID-nits checker tool.


(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The document split references into normative and informative sections.

(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG
Evaluation?

I have verified the IANA considerations section and it provides enough
information for IANA to act on it.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The document does not have any XML code, BNF or MIB specification.


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This draft defines a DHCP-based scheme to enable dynamic discovery of
Mobile IPv6 home network information. New DHCP options are defined
which allow a mobile node to request the home agent IP address, FQDN,
or home subnet prefix and obtain it via the DHCP response.


Working Group Summary

The I-D initially also had the Home address (HoA) as a DHCP
option. Concerns about this were expressed and subsequently deleted
from the I-D. The WG has a good understanding of the use of DHCP
for bootstrapping and consensus exists on publishing it.

Document Quality

No known implementations of the DHCP options specified in the I-D
exists. However there has been interest expressed in using these
options in other organizations such as WiMAX forum. Several vendors
have expressed plans to implement these options for MIP6
bootstrapping.

All reviewers have been acknowledged.


Personnel

Document shepherd: Basavaraj Patil
Responsible AD: Jari Arkko