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

From: Heejin Jang <[email-masked]>
Date: Wed, 23 Apr 2008 01:13:20 +0000 (GMT)

Hi, Alexandru.

Please read the document carefully.
I think that answers to some of your questions can be found in the draft already.

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Tuesday, April 22, 2008 7:44 PM
> To: [email-masked]
> Cc: Jari Arkko; [email-masked]
> Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13
> 
> Hi Heejin, thanks for the reply,
> [...]
> >>> 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.
> 
> 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?

HN info option is used differently in the request & reply, respectively.
In the request, it specifies its preference where the home information is assigned.
while, in the request, it carries the information provided by the server.

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

As document saids, the procedures follow the stateless DHCPv6.
So, only when the MN wants to retrieve the required information, it
intiates the stateless DHCPv6.

> >> 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.
> 
> I don't understand what is the available information at MN prior to
> doing DHCP.
> 
> >>> 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."
> 
> 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?

Server puts the HN information option in the Reply, not MIP6 Relay option.
Sever replies with the HN information option according to the HN info option 
in the request, based on the collected information which may have been delivered 
from NAS with MIP6 relay option or pre-configured by admin.

This is described in the 1st paragraph of Sec 4.3.

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

There can be many deployment ways to enable the scenario.
For e.g., 

1) the server simply returns the HN prefix. 
Then the MN perform dynamic HN discovery according to rfc3775.

2) the NAS is configured a proper HA info. 
For example, AAA server may deliver to NAS the nearest HA info 
considering each NAS's location such as "ha_philly.samsung.com" in Philly. 

2) suppose the server replied with the FQDN ("ha.samsung.com").
But it does not necessarily mean phisycally a single HA instance all the time. 
The fqdn may be shared among multiple HAs and dns server may return the different
IP based on a source IP of the DNS request or simply as a round-robin. 

There can be multiple ways to implement this.
however, how to do depends on deployment policy, and not in the scope 
of the hiopt document. 

> 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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 23 Apr 2008 12:21:22 +0200

Heejin Jang wrote:
> 
> Hi, Alexandru.
> 
> Please read the document carefully. I think that answers to some of
> your questions can be found in the draft already.

Hi Heejin, please take my remarks as speaking from my own experience of
using DHCP.  I don't have a vast DHCP experience and you may be right at
some points.  I just find that some logic is a bit flawed.

>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Tuesday, April 22, 2008
>> 7:44 PM To: [email-masked] Cc: Jari Arkko; [email-masked] 
>> Hi Heejin, thanks for the reply, [...]
>>>>>  information between the mobile node (DHCP client) and the
>>>>> DHCP server.  It is used to indicate the target home network
>>>> The MN indicates the home network information to DHCP Server,
>>>> and then the DHCP Server indicates back to MN the home network
>>  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?
> 
> HN info option is used differently in the request & reply,
> respectively. In the request, it specifies its preference where the
> home information is assigned. while, in the request, it carries the
> information provided by the server.

Ok.  Is there another example of non-mip6 information exchanged with
DHCP that follows this kind of logic?

For example, is there an existing DHCPv6 possibility for Client to
suggest e.g. Printer-Address to Server and Server reply back to Client
another Printer-Address?  Or some other information: DNS Server
suggested by Client and suggested back differently by Server, or similar
example.

>>>> 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 
>> 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."
> 
> As document saids, the procedures follow the stateless DHCPv6. So,
> only when the MN wants to retrieve the required information, it 

I'm not sure I understand you.  First, do you mean the "Stateless
DHCPv6" described in RFC3736?

I think that RFC doesn't suggest the Client to put data in a request and
the Server to suggest back a different data.  Or, apparently, a hiopt-13
Client puts  IPv6 home network prefix in a Request, with sub-opt-code
equal 2, Relay forwards it to Server, and Server puts another IPv6 home
network prefix in a Reply, apparently.  Is this the intended hiop-13
behaviour?

Is this behaviour in this sense completely different than the typical
DHCPv6 operation?

>>> Yes. it is home network information but its use is limited only
>>> to dynamic HA discovery. I mean, it cannot be used for address 
>>>>> 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?
> 

In the Relay-Reply or in the Reply?  I think the document should be
clear about this.

I would go as far as to suggest two new subsections (1) that describes
simply and clearly the overall hiopt message exchanges and (2) list a
concentrate of what are the modifications to DHCPv6 RFC3315 that this
document suggests.  A subsection picturing the topology involved 
wouldn't hurt either.

> Sever replies with the HN information option according to the HN info
> option in the request, based on the collected information which may
> have been delivered from NAS with MIP6 relay option or pre-configured
> by admin.

I don't understand how the Reply is based on the collected information.
  To understand that, the hiopt-13 draft suggests reading
mip6-integrated, mip6-bootstrapping-integrated-dhc and mip6-radius drafts.

Could hiopt-13 document be made standalone, so I could understand it
without reading other documents?

> This is described in the 1st paragraph of Sec 4.3.

Ok.  It should say Relay-Reply sometimes, not only Reply.

>>>>> 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,
>>>>> 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.
>>>>  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).
>> 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.
>> 
> There can be many deployment ways to enable the scenario. For e.g.,
> 
> 1) the server simply returns the HN prefix. Then the MN perform
> dynamic HN discovery according to rfc3775.

Ok, but the NAI identification of a subnet is still a wrong example, right?

> 2) the NAS is configured a proper HA info. For example, AAA server
> may deliver to NAS the nearest HA info considering each NAS's
> location such as "ha_philly.samsung.com" in Philly.

And thus DHCP is not involved, right?

> But it does not necessarily mean phisycally a single HA instance all
> the time. The fqdn may be shared among multiple HAs and dns server
> may return the different IP based on a source IP of the DNS request
> or simply as a round-robin.

This is typically what happens with VPN servers, not Home Agents.  It is
very rare if at all feasible to use a Home Agent as a VPN Server.

The goals of a HA (mainly support continuous sessions and permanent
publicly reachable HoA) are completely different than the goals of a VPN
Server (mainly offering secure access to private non-reachable network).
  These goals are completely different.

It is wrong to give an example of HA when you actually mean VPN.  Please
use VPN in the above description.

> There can be multiple ways to implement this. however, how to do
> depends on deployment policy, and not in the scope of the hiopt
> document.

Please don't redirect me to policy.

Thanks,

Alex