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

From: Heejin Jang <[email-masked]>
Date: Mon, 28 Apr 2008 02:38:50 +0000 (GMT)

Hi, Alex.
Please see below.

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Wednesday, April 23, 2008 7:21 PM
> To: [email-masked]
> Cc: Jari Arkko; [email-masked]
> Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13
> 
> 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]
> >> 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.
> 
> 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.

Server does not reply differently. Once MN sends a preference about
HA's location with an id-type field, then server replies with the
corresponding HA information that satisfies a preference in the request. 

> >>>> 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.
> 
> I'm not sure I understand you.  First, do you mean the 
> "Stateless DHCPv6" described in RFC3736?

Yes.

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

Section 3.3 says

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

Section 4.1 says

 "  A value of 1 is the only Sub-opt-code available in the request."

An MN cannot carry sub-opt-codes other than 1. This means that
a sub-option in the request is used only to carry the MN's prefered 
target MSP in case of id-type 1 so that the server can reply the matching 
HA information.

So, the server never replys with "the different" data. 

> >>>> 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.
> 
> In the Relay-Reply or in the Reply?  I think the document 
> should be clear about this.

First of all Severs construct a Reply message, and then
it makes Rely-Reply with the Reply message before relaying the
messages to the relays. 

Actually, I mentioned it in detail in Section 4.3 previously (you can see 
this in hiopt-09), but it was commented to be deleted by Gen-art review results
(Francis) because it is too trivial.

In hiopt-09,

  " The DHCP server MUST follow the following logic to construct a Reply
   message with the Home Network Information option, and include the
   Reply message in the payload of a Relay Message option of Relay-reply
   message."

In hiopt-15,

  " It MUST construct the Home Network Information option(s) according to
   the following logic, and include it or them in the Reply."

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

The complete procedures and the message flow figure are
described in the integrated-scenario draft.
 
> > 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.

Alex. This has been discussed in MIP6 WG long before. 
Over one year ago (or more than that) there has been discussion 
on the merge of this draft and integrated-draft, and finally the concensus
was to make them separated. I don't think we need to mention this
again now.
 
> 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,
> >>> 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.
> 
> Ok, but the NAI identification of a subnet is still a wrong 
> example, right?

See below.

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

The NAS will deliver the information to the server finally
by using MIP6 relay agent option, so DHCP is involved here.

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

Such method is very well-known and typical method for load-balancing. 

> > 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
> 
> 
> ______________________________________________________________________
> 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: Mon, 28 Apr 2008 09:38:40 +0200

Heejin Jang wrote:
>> 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.
> 

Ok, I retain this.  Thanks for the clarification.

>>>>>> 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 
>>>>>> 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.
>> 
>> I'm not sure I understand you.  First, do you mean the "Stateless 
>> DHCPv6" described in RFC3736?
> 
> Yes.

Then I don't see why stateless DHCPv6 is needed for this?  Plain full
DHCPv6 can accommodate this scenario.

>> 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?
> 
> Section 3.3 says
> 
> " 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."
> 
> Section 4.1 says
> 
> An MN cannot carry sub-opt-codes other than 1. This means that a 
> sub-option in the request is used only to carry the MN's prefered 
> target MSP in case of id-type 1 so that the server can reply the 
> matching HA information.
> 

Right, thanks, now I understand it better as being the basic hiopt
behaviour.

Let me agree with you for a short while that it's good to identify the
subnet by a FQDN.

If so basically MN (DHCP Client) puts FQDN in the request and the DHCP
Server sends back an IP address of the Home Agent.

How is this different than DNS Resolution?  Why do we need DHCP
to do DNS Resolution?

>> In the Relay-Reply or in the Reply?  I think the document should be
>>  clear about this.
> 
> First of all Severs construct a Reply message, and then it makes 
> Rely-Reply with the Reply message before relaying the messages to the
>  relays.
> 
> Actually, I mentioned it in detail in Section 4.3 previously (you can
>  see this in hiopt-09), but it was commented to be deleted by Gen-art
>  review results (Francis) because it is too trivial.
> 
> In hiopt-09,
> 
> " The DHCP server MUST follow the following logic to construct a 
> Reply message with the Home Network Information option, and include 
> the Reply message in the payload of a Relay Message option of 
> Relay-reply message."
> 
> In hiopt-15,
> 
> " It MUST construct the Home Network Information option(s) according
>  to the following logic, and include it or them in the Reply."

Ah ok, thanks for the gen-art explanation.  It's not trivial to me as
implementor.

>> 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.
> 
> The complete procedures and the message flow figure are described in
>  the integrated-scenario draft.

You mean that this (hiopt) draft can not work without the
integrated-scenario draft?

>>> 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.
>> 
>> information. To understand that, the hiopt-13 draft suggests 
>> reading mip6-integrated, mip6-bootstrapping-integrated-dhc and 
>> mip6-radius drafts.
> 
> Alex. This has been discussed in MIP6 WG long before. Over one year 
> ago (or more than that) there has been discussion on the merge of 
> this draft and integrated-draft, and finally the concensus was to 
> make them separated. I don't think we need to mention this again now.

Ok.  I wanted to understand hiopt separately but if you think it
absolutely needs integrated-scenario then so be it.

>>> server may deliver to NAS the nearest HA info considering each
>>> NAS's location such as "ha_philly.samsung.com" in Philly.
>> 
> The NAS will deliver the information to the server finally by using 
> MIP6 relay agent option, so DHCP is involved here.

If the 'NAS' is a DHCP Relay I'd prefer to always call it DHCP Relay
instead of NAS.

Generally, it's good to me to have as few entities as possible.

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

I'm sorry I'm afraid there are many things mixed up here.

MIP6 HAs do load-balancing in the form of DHAAD.  How do VPN Servers do
load balancing, which RFC?  I'm sure it's different than what MIP6 does.

Why mixing VPN and HA concepts here?

And finally, I completely disagree identifying a subnet with a FQDN.  I 
also disagree relying the workings of a protocol on that identification.

That said, we seem to be in complete respectful disagreement.

Alex

For more information please visit http://www.messagelabs.com/email

---

From: Jari Arkko <[email-masked]>
Date: Mon, 28 Apr 2008 11:20:00 +0300

We're not changing the document structure. Hiopt contains the options,
the bootstrapping document contains the bigger picture. The readers have
to read all...

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 28 Apr 2008 13:41:33 +0300

Alex,

> How is this different than DNS Resolution?  Why do we need DHCP

Having DHCP provide address and other parameter information relating to
services is an established practice. This draft is no different from
that. I would expect one simple use case for the draft to be sending a
request with no preference and getting back an address for an HA. This
cannot be done with DNS. Similarly, even where you do have a preference,
DNS does not easily allow the response to be decided based on local
policy, proximity of the home agent, etc.

>>> describes simply and clearly the overall hiopt message exchanges and
>>> (2) list a concentrate of what are the modifications to DHCPv6

No, hiopt is the technical content that needs to be implemented. But to
understand the overall system behavior, rationale, etc. one has to read
other documents, too.

Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 28 Apr 2008 13:37:23 +0200

Jari Arkko wrote:
> Alex,
> 
>>> Section 3.3 says
>>> 
>>> " 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."
>>> 
>>> 
>>> 
>>> 
>>> Section 4.1 says
>>> 
>> Let me agree with you for a short while that it's good to identify
>>  the subnet by a FQDN.
>> 
>> If so basically MN (DHCP Client) puts FQDN in the request and the 
>> DHCP Server sends back an IP address of the Home Agent.
>> 
>> How is this different than DNS Resolution?  Why do we need DHCP to
>>  do DNS Resolution?
> 
> Having DHCP provide address and other parameter information relating
>  to services is an established practice. This draft is no different 
> from that. I would expect one simple use case for the draft to be 
> sending a request with no preference and getting back an address for
>  an HA.

That yes.  The simplest case like that makes a lot of sense to me too.
Should be described alone I believe, put first and foremost.

This could be described in a much shorter document.  It could be
described independently of the bootsrapping-integrated scenario.

The current hiopt document puts "A part of the solution is the
capability to deliver home network prefix information to the mobile node
by means of the stateless DHCPv6 [RFC3736] [RFC3315]." first in Section
1 Introduction, first paragraph.

Or, "home network prefix information" is much more that what you're
saying "an address for an HA".

The simplest and most straightforward DHCP options is to have them in
the Reply only.  The Solicit and/or Request already have many
identifiers (NAI, MAC address), no need to add new ones.

Why do people think there's a need for new identifiers in the Request?

> This cannot be done with DNS.

Well, yes, more or less, there is multicast DNS that could address this
request, but not much widely deployed.

>>>> modifications to DHCPv6 RFC3315 that this document suggests. A
>>>>  subsection picturing the topology involved wouldn't hurt 
>>>> either.
>>> The complete procedures and the message flow figure are described
>>>  in the integrated-scenario draft.
> No, hiopt is the technical content that needs to be implemented. But
>  to understand the overall system behavior, rationale, etc. one has
> to read other documents, too.

Jari, sorry, I don't agree.  The paragraph that disturbs me most is the
following:
> The Mobile IPv6 specification [RFC3775] describes how home agents can
>  be dynamically discovered by mobile nodes that know the home network
>  prefix.  This scheme does not work when prefix information is not 
> already available to the mobile node.  One architecture to solve this
>  problem is described in
> [I-D.ietf-mip6-bootstrapping-integrated-dhc].

If there's a need to specify architecture it's good to specify them
separately from protocols, IMHO.  Have protocols work with whatever
architecture one may come up with.

Sorry, I will stop here,

Alex