Subject: [Mip6] Re: RE: I-D ACTION:draft-ietf-mip6-hiopt-03.txt

From: Heejin Jang <[email-masked]>
Date: Mon, 28 May 2007 05:49:06 +0000 (GMT)

Hi, Kilian.
 
Thanks for your comments.
See the inline. 
 
Regards, 
Heejin.
 
-----Original Message-----
From: Kilian Weniger [mailto:[email-masked]] 
Sent: Wednesday, May 23, 2007 11:35 PM
To: Heejin Jang
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-mip6-hiopt-03.txt
 
Hi Heejin,
 
I quickly went through the new version of the hiopt draft. As announced at the last meeting and on the mailing list, the assignment of HAs from an MSP that is neither ASP nor MSA but has trust relationship with MN's MSA is now supported. This is good, since it improves deployment flexibility and applicability. However, I have some questions regarding the related text in the draft.
 
The Home Network Identifier option currently has three id-types: 0 for "Visited domain/ASP", type 1 for "target network" and type 2 for "No preference". The id-type in combination with the Home Network Identifier field allow the MN to request a specific MSP.
 
Heejin> Right. We clarified this point in the draft.
 
Section 3.1 says about the Home Network Identifier field: "...This field MUST be set to the network realm as the FQDN defined in [3] when the id-type is 1.". Later, the text says "The id-type 1 indicates the mobile node is interested in learning the home network information that pertains to the given realm. ... The target network can be a home MSP or a MSP which has trust roaming relationship with the mobile node's home MSP." Isn't this contradicting? How can the MN request the assignment of an MSP different from the MSA, when the Home Network Identifier field must be set to the realm of the MN's NAI (The realm of the MN's NAI typically pertains to the MSA)? Or does the "network realm" in the cited sentence refer to something else than the MN's NAI?
 
Heejin> The "network realm" in this context is different from the MN's NAI. It is a target network
 which is home MSP or a MSP which has trust roaming relationship with MN's home MSP. We'll 
delete the following pharagrap that may cause confusion in section 3.1. 
"This type can be used to discover home agents that are hosted by a user's home domain
(as indicated by his/her NAI-based username -- user@ HomeRealm)."
 
Another comment relates to the text about id-type 2. It is not clear to me whether id-type 2 can be used by the MN to request the assignment of an MSP that is neither ASP nor MSA. Section 4.3, case C says:
 
  "In this case, the assignment of the home information relies on the
   server's local policy, and the DHCP server SHOULD have its own policy
   so that it can reply with the proper information.  "
...
   "When the DHCP server provides the home information that is retrieved
   from the MIP6 Relay Agent option, it MUST compare the NAI's realm
   information of MN-NAI option with the target network in Home Network
   Identifier option.  If they match, the DHCP server replies with the
   Reply message after copying the home information in MIP6 Relay Agent
   option to Home Network Information option.
 
   In case the server cannot find any home information for the requested
   id-type, it MUST return a Home Network Information option with the
   0-length data."
 
What should the DHCP server do if the MIP6 relay agent option contains multiple sub-options and one of the sub-options matches the NAI's realm whereas another one does not? This situation can happen if the AAAH sends home network information for mutliple MSPs to the NAS (e.g., for home MSP/MSA and other MSPs with trust relationship to MSA). Should the server respond with multiple Home Network Information Sub-options?
 
Heejin> A DHCP server extracts only the available HA info among the info privided by NAS (finally from AAA)
and includes them in a single Home Network information option with multiple sub-options. If the server has no 
info for the specified id-type in Home Network, then it replies with opt-len=0 in a Home Network Information option.
 
And why do we need this MN-NAI option check here at all?

Heejin> In case a AAA server provided only HA's IP address (not FQDN) to NAS (finally to the DHCP server), 
there is no way to decided whether it is the HA info which the MN requested with FQDN. But we'll simplify 
this by allowing the DHCP server to provide only HA info which can be mappable based on FQDN. 
(and we'll delete NAI-based mapping procedure.)
 
Thanks,
 
Kilian
 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Mittwoch, 16. Mai 2007 21:50
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-mip6-hiopt-03.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Mobility for IPv6 Working Group of 
> the IETF.
> 
>   Title       : DHCP Option for Home Information 
> Discovery in MIPv6
>   Author(s)   : H. Jang, et al.
>   Filename    : draft-ietf-mip6-hiopt-03.txt
>   Pages       : 19
>   Date        : 2007-5-16
>   
> This draft 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.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-03.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of 
> the message.
> You can also visit
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then "get 
> draft-ietf-mip6-hiopt-03.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>   [email-masked].
> In the body type:
>   "FILE /internet-drafts/draft-ietf-mip6-hiopt-03.txt".
>   
> NOTE: The mail server at ietf.org can return the document in
>   MIME-encoded form by using the "mpack" utility.  To use this
>   feature, insert the command "ENCODING mime" before the "FILE"
>   command.  To decode the response(s), you will need "munpack" or
>   a MIME-compliant mail reader.  Different MIME-compliant mail readers
>   exhibit different behavior, especially when dealing with
>   "multipart" MIME messages (i.e. documents which have been split
>   up into multiple messages), so check your local documentation on
>   how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader 
> implementation to automatically retrieve the ASCII version of the 
> Internet-Draft.
> 

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

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