Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary for the changes in hiopt-13)

From: Heejin Jang <[email-masked]>
Date: Tue, 29 Apr 2008 15:03:01 +0000 (GMT)

Hi, Alex. 
See below.

ps> I'm supposed to have a vacation till next Monday, 
and cannot access my samsung account.
So kindly refer my gmail account as well. 
([email-masked])

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Monday, April 28, 2008 4:39 PM
> To: [email-masked]
> Cc: Jari Arkko; [email-masked]
> Subject: Re: why having DHCP do DNS resolution? (was: [MEXT] 
> FW: Summary for the changes in hiopt-13)
> 
> 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.
> > 
> > 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.
> 
> 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 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.
> 
> Then I don't see why stateless DHCPv6 is needed for this?  Plain full
> DHCPv6 can accommodate this scenario.

Basically plain (stateful) DHCPv6 is used for address configuration while 
stateless DHCPv6 is for other parameters configuration such as DNS server 
address. So this HN information should be delivered through stateless
DHCPv6.

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

While MNs are required to know an exact FQDN of the target (HA)
for DNS resolution, DHCP discovery enables HA discovery in variable ways
even in case MN does not have exact information about its home network. 
For e.g. it can request the local HAs with the id-type 0. 
Or the server may return partially matching HA information as described in 
Section 4.3. 

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

Ok.
 
> >> 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.
> 
> 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.
> >> 
> >> 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.
> 
> Ok.  I wanted to understand hiopt separately but if you think 
> it absolutely needs integrated-scenario then so be it.
> 
> >>> 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.
> 
> 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.
> 
> >>> 3) 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.
> 
> 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.

IMHO, such a load-balancing approach is wellknown and does not need to 
be limited to VPN. 
Anyway here the key point is "to provide HA information based on NAI" can be 
implemented in various ways as least by using 1) and 2)  as described in 
previous mails. 

> 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, 30 Apr 2008 11:41:26 +0200

Heejin Jang wrote:
> Hi, Alex. See below.
> 
> ps> I'm supposed to have a vacation till next Monday, and cannot 
> access my samsung account. So kindly refer my gmail account as well.

Heejin, enjoy vacations :-)  when back in office see below.

[...]
>> Then I don't see why stateless DHCPv6 is needed for this?  Plain 
>> full DHCPv6 can accommodate this scenario.
> 
> Basically plain (stateful) DHCPv6 is used for address configuration 
> while stateless DHCPv6 is for other parameters configuration such as
>  DNS server address. So this HN information should be delivered 
> through stateless DHCPv6.

Let's clarify this use of Stateless DHCPv6 RFC3736.

Why does a hiopt MN need to include a Home Network Identifier
(Sub-Opt-Code 1, eg realm of NAI) in the Home Network Information Option
in the Information-Request?  Why isn't it sufficient to use the Client
Identifier Option DUID section 22.2 of RFC 3315 DHCPv6.

Why isn't the DUID enough to identify the Client (1 - Link-layer address
plus time, 2 - vendor-assigned unique id based on enterprise number, 3 -
link-layer address).

Why is it thought that it is necessary to specify Home Network
Identifier Sub-Opt-Code 1 as being, for example, the realm part of a
NAI, when the DUID exists, is used and covers a different range of cases.

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

Right, now makes better sense.  For easing my humble reading this
statement could appear in section 3.1 where the message encoding of Home
Network Information Option is described.

>>>  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?
> 
> While MNs are required to know an exact FQDN of the target (HA) for 
> DNS resolution, DHCP discovery enables HA discovery in variable ways 
> even in case MN does not have exact information about its home 
> network. For e.g. it can request the local HAs with the id-type 0. Or
>  the server may return partially matching HA information as described
>  in Section 4.3.

I agree at high level but not in detail.

The really big problem here - and in all bootstrapping documents - is
that we have not precisely described what is the information available
at the MN prior to bootstrapping phase.  Different documents make
different assumptions and they overlap.

[skipped some for focusing the discussion]

> IMHO, such a load-balancing approach is wellknown and does not need 
> to be limited to VPN. Anyway here the key point is "to provide HA 
> information based on NAI" can be implemented in various ways as least
>  by using 1) and 2)  as described in previous mails.

If it is the key point then it should be much more clear than that.
It is far from being clear.  Now here it's said "NAI" but in the
document it's said "for example, the realm part of NAI".  If we decide
to do only NAI-based HA address bootstrapping with DHCPv6 then I can
agree we can have a better document.

That is a big if.

Because - does DHCPv6 or DHCPv4 ever use NAI for address allocation or
parameter configuration?  I don't think so.  They use MAC address (or
DUID) but not NAI.  I find hiopt very much different than DHCPv6 in this
sense.  IMHO. ?.

If one wants to use NAI (or its realm part) to find the corresponding IP
address then use DNS straight resolution, not DHCP.

Alex

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