Subject: [Mip6] Reply for AD's comments on draft-ietf-mip6-hiopt

From: Heejin Jang <[email-masked]>
Date: Wed, 31 Oct 2007 06:30:43 +0000 (GMT)

Hi Jari and folks.

The draft has been revised based on AD's review results and comments
from DHC folks. For detailed modification based on AD's feedback,
please see the below.

Jari, kinly see that the revision was done properly, and let us know
your opinion. 
Thanks again.

-------------------------------------------------------------
> 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.

- Show quoted text -
> 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.

Ok. We'll replace the existing paragraph with the above one.

> >    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.

Ok. The proposed scheme is a kind of bootstrapping mechanisms, so the
discovery procedure does not need to be performed at every MN's
movement, but is performed when the mobile node needs bootstrapping or
change of current home agent. For clarity, we'll add the following

paragraph in section 4.1 (Mobile Node Behavior).

" The mobile node does not need to perform the home information
discovery procedure after its every movement. 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 instance, to recover from the single point of failure of
the existing home agent or to find the topologically best home agent"

> >         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?

Ok. We considers FQDN of domain requested by the mobile node instead

of full NAI, which can remove the problems you mentioned.

> >         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?

The id-type is necessary to clarify the mobile node's preference for the
requested home network.

If the mobile node wants to retrieve the home information both from
the visited network and the specified target MSP, it is better to
clarify its intent by specifying the id-type 0 and 1 in two options
than simply by sending two options, one option with no id-type and one

option with the target MSP (this looks ambiguous).
Additionally, If DHCP can know the kind of home network requested by
MN explicitly, it does not need to transfer unnecessary information
which is not in the mobile node's interest. So, we think it's better
to keep the id-type in the HN Identifier option.

> > 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.

Ok. The text will be rewrited as below.

" This option carries the home network information parameters which
were transferred to the NAS from AAAH by using [I-D.ietf-mip6-radius].
The DHCP relay agent sends this option to the DHCP server in the
Relay-Forward message."

> 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.

The following paragraph in Section 4.3 (DHCP server behavior) describes that
there can be more than one ways for DHCP server to learn the home

network information, but the mechanism is not in the scope of this document.

- Show quoted text -

"The DHCP server should provide all of the matching home information
in Home Network Information option(s) based on its policy.  There can
be several ways that a DHCP server learns mechanism to know or
retrieve the requested home network information.  For instance, as
described in [I-D.ietf-mip6-radius], the NAS can learn the
information via RADIUS during network access authentication, and NAS-
collocated DHCP relay can transfer it to the DHCP server by the
proposed DHCP option in this document.  However, the mechanism by
which the DHCP server is provisioned with the home network
information or obtains it dynamically is outside the scope of this document."

It will be slightly revised as follows.

"The DHCP server should provide all of the matching home information
in Home Network Information option(s) based on its policy.  There can
be several ways that a DHCP server learns mechanism to know or
retrieve the requested home network information.  For instance, as
described in [I-D.ietf-mip6-radius], the NAS can learn the
information via RADIUS during network access authentication, and NAS-
collocated DHCP relay can transfer it to the DHCP server by the
proposed DHCP option in this document. Or the home information may have
been configured statically in the DHCP server by administrators. However,
the mechanism by which the DHCP server is provisioned with the home network
information or obtains it dynamically is outside the scope of this document."

> 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?

Ok. The use of sequence number seems to be enough. we'll delete the
id-type field in the HN information option.

> >    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.

Ok. The "MUST" will be relaxed into "recommended".
Regarding the option ordering, we got the feedback from DHC WG that
the dependency of the option ordering is not a recommended approach
and the strict ordering of the options should not be stipulated in the
document. So we decided to avoid the use of option ordering and define
sequence numbers in the options instead.

> >    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.

Ok. We'll replace the above paragraph as follows.

"   The NAS is required to store the home information for the mobile node which
 is attached into itself so that it can provide the information at the time of
 receiving the Information-request from the mobile node"

> > 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.)

Ok. The description will be moved to earlier section, Section 3
because Section 1 only describes the necessaity of the proposed scheme
without mentioning DHCPv6 itself. The sentence is also rewrited as the
below:

" The NAS and the DHCP relay agent are assumed to be collocated in this
solution. In the network where the NAS is not cllocated with the the DHCP
relay agent, the DHCP server will provide the home information which has

been preconfigured by the administrator or which is acquired through the

- Hide quoted text -
mechanism that is not described in this document."

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

Ok. We'll change option codes into OPTION_MIP6_HNID and OPTION_MIP6_HNINF.

- Best Regards,
Heejin.
_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6