[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[dhcwg] Re: AD review of draft-ietf-mip6-hiopt
Hi, Jari.
I appreciate your kind review.
The hiopt draft is currently under revision based on your comments and DHC folks,
and we're planning to submit the revised one next week.
- Best regards,
Heejin.
------- Original Message -------
Sender : Jari Arkko<jari.arkko at piuha.net>
Date : 2007-10-21 21:59
Title : AD review of draft-ietf-mip6-hiopt
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.
The draft needs to talk about when such discovery is used. Its
limitations must be described more accurately. And there are a number of
issues in the description of the option formats.
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 <athene at sait.samsung.co.kr>...
> User unknown'
> 5.1.0 - Unknown address error 550-'5.1.1 No such user
> <alper01.yegin at partner.samsung.com>
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg