Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13

From: Heejin Jang <[email-masked]>
Date: Tue, 22 Apr 2008 07:57:08 +0000 (GMT)

Hi, Alexandru.
Thanks for your concerns.

Kindly see the below. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Alexandru Petrescu
> Sent: Monday, April 21, 2008 6:34 PM
> To: Jari Arkko
> Cc: [email-masked]
> Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13
> 
> Jari Arkko wrote:
> > The last edits are in -15 now. Any additional people who want to 
> > comment on this before its approved?
> 
> Hi Jari,
> 
> I am not familiar with the advancement of this document and the recent
> discussion.
> 
> I have just quickly skimmed through it.
> 
> I am surprised by the intention to pursue the document and get it
> approved.  Because I find a few incoherencies.  It may be I'm
> not enough familiar with the document, if so my message can 
> be discarded.
> 
> For example:
> > 3.  DHCP options for HA Dynamic Discovery
> > 
> > This section introduces new DHCP options and their 
> sub-options which 
> > are used for dynamic discovery of the home agent's IPv6 
> address, IPv6
> >  home network prefix,
> 
> So the home network prefix is discovered, presumably by MN.
> 
> > 3.1.  Home Network Information Option
> > 
> > This option is proposed to allow the exchange of home network 
> > information between the mobile node (DHCP client) and the DHCP 
> > server.  It is used to indicate the target home network 
> requested by the mobile node to the DHCP server in the Information-request 
> > message.  In the Reply message, it conveys the home network 
> > information assigned by the DHCP server to the mobile node.
> 
> The MN indicates the home network information to DHCP Server, and then
> the DHCP Server indicates back to MN the home network information.  Is
> this information the same?  Can it change?

It can change. As described 4.3, the server provides the home network
information according the id-type in the request. For e.g., 
if id-type = 0 is in the request, the server returns the configured local information
irrespective of information received from NAS.
 
> If the MN knows the home network information then why does it need the
> DHCP Server to tell it back the home network information?

This is a part of integrated-bootstrapping scenario.
So, if the MN knows its home information, it does not need to send 
an Information-request at all.

> Is the home network prefix part of the home network information?

Yes. it is home network information but its use is limited only to dynamic
HA discovery. I mean, it cannot be used for address auto-configuration.
I'm not sure I understood your questino well.

> > 4.3.  DHCP Server Behavior
> > 
> > When the server receives a Relay-forward message, it may include the 
> > MIP6 Relay Agent option in case there was home information available 
> > for the mobile node at the relay.
> 
> DHCP Server includes the MIP6 Relay Agent option into what?

See to Sec 3.2. 

"The DHCP relay agent sends this option to the DHCP server in the 
Relay-forward message."

> Overall comments about some paragraphs:
> > New DHCP options are defined which allow a mobile node to request the
> >  home agent IP address, FQDN, or home network prefix and obtain it 
> > via the DHCP response.
> 
> If this is a MN, then it could be a MR, and MR may need to learn Mobile
> Network Prefixes.  Is it necessary to learn Mobile Network Prefixes as
> well?  Just a question.

As answered previously, the prefix is provided only for dynamic 
HA discovery, not for auto-configuration or MIP6 binding.
In that sense, I don't think the MNP discovery is in the scope of this document. 

> > A mobile node can indicate its home network identity when roaming to 
> > a visited network in order to obtain the MIP6 bootstrap parameters 
> > from the home network.  As an example, the visited network may 
> > determine the home network of the mobile node based on the realm 
> > portion of the NAI (Network Access Identifier) [RFC4282] used in 
> > access authentication.
> 
> This is not a good example, it is not a good idea to decide 
> the identity of a subnet based on the realm part of NAI.  There is no relationship
> about domain names and subnet addresses, and there shouldn't be any.  If
> one needs to identify a subnet then it's by its IP subnet address, not
> by its fqdn (there's no fqdn-subnet relationship).

This is not about deciding the identity of a subnet from NAI.
For e.g., if my NAI is [email-masked], it can be assumed that 
my ISP is samsung. This is just one of possible scenarios.

> I haven't read further.
> 
> Alex
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
> _______________________________________________
> 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: Alexandru Petrescu <[email-masked]>
Date: Tue, 22 Apr 2008 12:43:59 +0200

Hi Heejin, thanks for the reply,
[...]
>> The MN indicates the home network information to DHCP Server, and 
>> then the DHCP Server indicates back to MN the home network 
>> information.  Is this information the same?  Can it change?
> 
>  information according the id-type in the request. For e.g., if 
> id-type = 0 is in the request, the server returns the configured 
> local information irrespective of information received from NAS.

I'm not sure current semantics of DHCP exchanges between Client and
Server allow the Client to send information to Server and Server to send
it back Information that changed.  Isn't the proposal a departure
from the DHCP semantics?

>> If the MN knows the home network information then why does it need 
>> the DHCP Server to tell it back the home network information?
> 
> This is a part of integrated-bootstrapping scenario. So, if the MN 
> knows its home information, it does not need to send an 
> Information-request at all.

So why does the draft say that the "[Home Network Information Option] is
used to indicate the target home network requested by the mobile node to
the DHCP server in the Information-request message."

> Yes. it is home network information but its use is limited only to 
> dynamic HA discovery. I mean, it cannot be used for address 
> auto-configuration. I'm not sure I understood your questino well.

I don't understand what is the available information at MN prior to
doing DHCP.

>>> When the server receives a Relay-forward message, it may include 
>>> the MIP6 Relay Agent option in case there was home information 
>>> available for the mobile node at the relay.

Ok that, but I wondered where does the DHCP Server put its MIP6 Relay
Agent option in?  In what message?  Relay puts it in Relay-Forward
message, but the Server puts it in what?

>>> New DHCP options are defined which allow a mobile node to request
>>>  the home agent IP address, FQDN, or home network prefix and 
>>> obtain it via the DHCP response.
>> If this is a MN, then it could be a MR, and MR may need to learn 
>> Mobile Network Prefixes.  Is it necessary to learn Mobile Network 
>> Prefixes as well?  Just a question.
> 
> As answered previously, the prefix is provided only for dynamic HA 
> discovery, not for auto-configuration or MIP6 binding. In that sense,
>  I don't think the MNP discovery is in the scope of this document.

Ok.

>>> A mobile node can indicate its home network identity when roaming
>>>  to a visited network in order to obtain the MIP6 bootstrap 
>>> parameters from the home network.  As an example, the visited 
>>> network may determine the home network of the mobile node based 
>>> on the realm portion of the NAI (Network Access Identifier) 
>>> [RFC4282] used in access authentication.
>> This is not a good example, it is not a good idea to decide the 
>> identity of a subnet based on the realm part of NAI.  There is no 
>> relationship about domain names and subnet addresses, and there 
>> shouldn't be any.  If one needs to identify a subnet then it's by 
>> its IP subnet address, not by its fqdn (there's no fqdn-subnet 
>> relationship).
> 
> This is not about deciding the identity of a subnet from NAI. For 
> e.g., if my NAI is [email-masked], it can be assumed that my
>  ISP is samsung. This is just one of possible scenarios.

I'm sure this is impossible.  samsung has many subnets.  It's impossible
to identify all samsung's subnets only by one realm samsung.com.

HA acts on a subnet (HA and subnet are tightly related by HA doing proxy
ND) not across an entire domain.  Most often a domain is made of several
subnets.

That's why I thought it's not a good example.

Alex