Subject: [MEXT] Fwd: Re: Re: hiopt (Revised text)

From: Heejin Jang <[email-masked]>
Date: Fri, 23 May 2008 02:40:55 +0000 (GMT)

Oh, I misunderstood your question.

DHCPv4 issue has been proposed and discussed in last month, too 
but AD mentioned that we put  the dhcpv4 side out for the moment at that time.
 
The hiopt draft aims at supporting IPv4/IPv6 HoA in the IPv6 networks(with DHCPv6).
IMO, I don't think it is a good idea to handle DHCPv4 and DHCPv6 cases in a single document
because the specific DHCPv4 messages & procedures are different from those of DHCPv6 
though the concept is similar.

Thanks for your concerns.

- Regards, 
Heejin.

------- Original Message -------
Sender : Heejin Jang<[email-masked]> R&D Staff Member/Communication & Networking Lab/Samsung Advanced Institute of Technology
Date   : 2008-05-23 10:51 (GMT+09:00)
Title  : Re: Re: [MEXT] hiopt (Revised text)

Hi, Frank.
 
That issue was discussed in March and  April, but AD (Jari) recommends that
the draft cover  discovery of Mobile IPv6 home agents that have an IPv4 address,
but  NOT Mobile IPv4.
 
Thanks for your consideration. :)
 
-Best regards, 
Heejin 

------- Original Message -------
Sender : Frank Xia<[email-masked]>
Date   : 2008-05-23 00:03 (GMT+09:00)
Title  : Re: [MEXT] hiopt (Revised text)

Hi Heejin    
     
In this draft, a MN uses DHCPv6 to acquire home network information.    
     
However, if MN only has IPv4 CoA in DSMIPv6 scenario, IMO,    
DHCPv4 support is needed.    
     
What is your opinion?    
     
BR    
Frank  ----- Original Message -----   From:   Heejin   Jang   To: Jari Arkko         
Cc: Alexandru Petrescu ; [email-masked]         
Sent: Thursday, May 22, 2008 9:32 AM        
Subject: Re: [MEXT] hiopt (Revised text)  
Hi, Jari and Vijay.

I revised the draft as Jari&#39;s two   comments.
Kindly see the below and give me your feedbacks.

Thanks   for your kind cooperation. :)

* Modified points

1) The 3rd   paragragh was modifed according to the Jari&#39;s 1st comment. 
2) For the 2nd   comments, we allowed the Sub-opt-code 1 and mandated it in
a MIP6 Relay   option. 

1>  In Section 3.3 (Common Sub-options), page 9,   

Old:   

   While the Sub-opt-code 1 is only   available in both the requesting and
   the returned Home Network   Information options, Sub-opt-codes 2, 3, 4,
   and 5 are   available only in the returned Home Network Information
   option   and the MIP6 Relay Agent option.

New: 

   While the   Sub-opt-codes 1, 2, 3, 4, and 5 are available in the MIP6
     Relay Agent option and the Home Network Information option   returned
   by the DHCP server, a value of 1 is the only   Sub-opt-code available
   in the requesting Home Network   Information option by the mobile node.

2> In Section 4.2 (NAS/DHCP   Relay Agent Behavior), page 13, 2nd paragraph, 

Old: 

  The   relay SHOULD include each home network
   parameter in a   sub-option, and include all sub-options in a single
   MIP6 Relay   Agent option.  It MUST NOT include any sub-option whose
     Sub-opt-code is other than 2, 3, 4, and 5 as described in   Section
   3.3.

New: 

 (added   paragraph)
  When providing the home network information,   the
   relay MUST include a sub-option whose Sub-opt-code is 1,   and set the
   Home Network Parameter field to the FQDN of the   network where the
   home information is assigned.  That   FQDN information will be compared
   with the target MSP   requested by the mobile node when a DHCP server
   searches for   the matching information.

   The relay SHOULD include each   home network parameter in a sub-option,
   and include all   sub-options in a single MIP6 Relay Agent option.  It
   MUST   NOT include any sub-option whose Sub-opt-code is other than 1,
     2, 3, 4, and 5 as described in Section 3.3.
 
3>  In   Section 4.3 (DHCP Server Behavior), page 13, 

Old: 

     The home network information
   received from the relay SHOULD be   kept in the server so that the
   server can provide the   information when it is requested by the mobile
   node.    

  The server MUST ignore any sub-option in a MIP6 Relay Agent   option
   whose Sub-opt-code is other than 2, 3, 4, and 5, as   described in
   Section 3.3.

New:

  The MIP6   Relay Agent option which
   does not include a sub-option with   Sub-opt-code 1 MUST be ignored.
   Otherwise, the home network   information received from the relay
   SHOULD be kept in the   server so that the server can provide the
   information when it   is requested by the mobile node.  

  The server MUST ignore   any sub-option in a MIP6 Relay Agent option
  whose Sub-opt-code is   other than 1, 2, 3, 4, and 5, as described in
  Section   3.3.

4> In page 14, case B,   

Old:
         Any Home   Network Information option which carries more   than
         one target MSP or   which does not carry any target MSP MUST   be
           ignored.

New:

        Any   Home Network Information option which carries more   than
        one target MSP or which   does not carry any target MSP MUST   be
        ignored. Otherwise, the DHCP   server searches its database
        by   using the received target MSP as a key.

5> In page 15, the 8nd   paragraph

Old:

   The DHCP server should provide all   of the matching home information
   in Home Network Information   option(s) based on its policy.  It may
   return partially   matched results.  For example, on receipt of a Home
     Network Information option which specifies "xxx.example.com" as   the
   target network, it may return "example.com" to the mobile   node.  In
   this case, "xxx.example.com" is returned in a   sub-option with Sub-
   opt-code 1, and "example.com" in a   sub-option with Sub-opt-code 5.
   Note that the detailed rule   for returning partially matched instances
   of home network   information follows the server&#39;s own policy and is
   outside the   scope of this document.

New:

   The DHCP server should   provide all of the matching home information
   in Home Network   Information option(s) based on its policy.  While
     searching for the home network information by using the target MSP   as
   a key, it may return the results when the key is partially   matched.
   For example, on receipt of a Home Network Information   option which
   specifies "xxx.example.com" as the target   network, it may return the
   home network information assigned   for "example.com" to the mobile
   node.  Note that the   detailed rule for returning partially matched
   instances of   home network information follows the server&#39;s own policy
   and   is outside the scope of this document.

6> In Section 6   (IANA)

Old:
       o Home network   identifier                    1
         (only allowed in the   Home Network
         Information   option; value Reserved
         for   the MIP6 Relay Agent   option)

New:
       o Home network   identifier                    1

Thanks for your kind help. 

- All the best   
heejin.

------- Original Message -------
Sender : Jari   Arkko<[email-masked]>
Date     : 2008-05-20 01:12 (GMT+09:00)
Title  : hiopt

Hi all,

I   have reviewed this thread and re-reviewed the draft. While I
sympathize   with some of the questions Alex had, I see no technical
reason to block the   draft from being approved, and I see no support from
the WG from doing this   either. So I am now approving the document.

However, as a re-read the   draft, I also noticed two additional issues.
The first issue is that   Section 3 seems to be forgetting the case where
DHCP server has no   information about a particular home network. Due to
this, I would like to   make the following change:

OLD:
In a network where the NAS is not   co-
located with a DHCP relay nor a server, the server may not   be
provided with the home network information from the NAS, and   thereby
it may assign to a mobile node the home information which has   been
preconfigured by the administrator or which is acquired through   a
mechanism that is not described in this document.
NEW:
In a network   where the NAS is not co-
located with a DHCP relay nor a server, the server   may not be
provided with the home network information from the NAS, and   thereby
it may either fail to provide information, or provide home   information
which has been preconfigured by the administrator or which is   acquired
through a mechanism that is not described in this   document.

Secondly, Section 4.2 and 4.3 talk about how relays can   provide
information to servers. But I cannot see how the server knows   which
piece of information from the relay corresponds to what Home   Information
Option, in case there were multiple options with different home   network
names. I am a bit uncertain how to fix this, however. Perhaps it   is
necessary to allow suboption type 1 in relay agent options,   too.

Please suggest text, and I will place it in the RFC Editor note   part of
the tracker and approve it. (Or you can submit a new version with   these
fixes.)

Jari
_______________________________________________
MEXT   mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext
 
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Frank Xia <[email-masked]>
Date: Wed, 28 May 2008 11:27:05 -0500

Hi Folks

I propose that DHCPv4 for DSMIP6  home network information
as a WG rechartering item.

Here are some reasons:
1)DSMIP6 is adopted by 3GPP, and it is necessary to
   provide protocol support

2)Current "DHCP Option for Home Information
   Discovery in MIPv6" document only deals with
   DHCPv6 option and procedure.

  However, there  are many difference between DHCPv4 and DHCPv6.
  The option defined in the document can't be used  in DHCPv4
  scenario directly, and DHCPv4 has  no dedicated information request 
message.

BR
Frank

----- Original Message ----- 
From: "Heejin Jang" <[email-masked]>
To: "Heejin Jang" <[email-masked]>; "Frank Xia" 
<[email-masked]>; <[email-masked]>
Sent: Thursday, May 22, 2008 9:40 PM
Subject: Fwd: Re: Re: [MEXT] hiopt (Revised text)

> Sender : Heejin Jang<[email-masked]> R&D Staff 
> Member/Communication & Networking Lab/Samsung Advanced Institute of 
> Technology
> Frank
 ----- Original Message -----   From:   Heejin   Jang   To: Jari Arkko