Subject: Re: RE : [Pana] comments on draft-suraj-dhcpv4-paa-option-00.txt

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 01 Jul 2005 16:38:07 -0400

Hi Lionel,

On Tue, Jun 28, 2005 at 12:56:14PM +0200, MORAND Lionel RD-CORE-ISS wrote:
> 
> [1] In section 5:
> 
> "
>    This document defines a DHCPv4 option that carries either a 32-bit
>    (binary) IPv4 address list or, preferably, a domain name list to be
>    used by the PANA client to locate a PANA authentication Agent. "
> 
> Why is carrying both a 32-bit IPv4 address list and a domain name list not allowed, while RFC 3263 allows both lists to be carried?
> 
> ==> in DHCPv4, only one code is requested to support the PAA option (while two different codes may be used in DHCPv6). Therefore, only one type of sub-option(i.e. IP@ or FQDN) may be provided at a time by the DHCP server. The DHCP server can not mix both sub-options in the same message in order to allow to have option lenghts exceeded the maximum permissible within a single option and to apply the RFC 3396 "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)". It is also specified like this in the RFC 3361 (DHCPv4 SIP server option). Such a limitation doesn't apply for DHCPv6.

I see.  Thanks for the clarification.

> 
> [2] In section 5:
> 
> "
>    The option has two encodings, specified by the encoding byte ('enc')
>    that follows the code byte.  If the encoding byte has the value 0, it
>    is followed by a list of domain names, as described below (Section
>    5.1).  If the encoding byte has the value 1, it is followed by one or
>    more IPv4 addresses (Section 5.2).  All implementations MUST support
>    both encodings.  The 'option-length' field indicates the total number
>    of octets in the option following the 'option-length' field,
>    including the encoding byte.
> "
> 
> Why aren't two different options used for carrying different types of list, instead of using one option with sub-option (i.e., encoding field), while RFC 3263 uses two different options?  Just a matter of preference?
> 
> ==> Since DHCPv4 suffers from a shortage of option codes, we use the encoding byte to define sub-option instead of requesting two additional option codes. It is aligned with the handling of SIP Server options in DHCPv4. Such a limitation doesn't apply for DHCPv6.

OK.

> 
> [3] In section 5.1:
> 
> "
>    The option MAY contain multiple domain names, but these SHOULD refer
>    to different NAPTR records, rather than different A records.  Domain
>    names MUST be listed in order of preference.
> "
> 
> What is the purpose of having the domain names listed in order of preference?  I think the domain name that is same as the DHCP client's domain name should be used by the client to choose a PAA in the access network.  In other words, the usage of listing multiple domain names is not clear.
> 
> ==> you may find in the option paa1.foo.com, paa2.foo.com. And paa1 may act as default PAA, and paa2 may be used as "redondant" PAA when paa1 is not available, not able to responde, or any other reason. There may be other use of this list. 

OK.

> 
> [4] In section 6:
> 
> "
>    If the PAA DHCPv4 option provided in response by the DHCPv4 server
>    contains multiple domain names, the client MUST try the records in
>    the order listed.
> " 
> 
> The same comment as [3].
> 
> ==> same response. Moreover, from the client standpoint, you can find: 
> 
>    "The client only resolves the subsequent domain
>    names if attempts to contact the first one failed or denote a domain
>    administratively prohibited by client policy."

OK.

> 
> [5] In section 7:
> 
> "
>   A DHCP server MUST NOT mix the two list types (domain names and IPv4
>    address) in the same DHCPv4 message, even if it sends two different
>    instances of the same option.
> "
> 
> The same comment as [1].
> 
> ==> Therefore, same response ;)

OK.

> 
> 
> [6] The draft might be useful for finding PAAs in different domains to perform *pre-authentication*.
> 
> ==> could you develop this point? Do you mean that such info should be added to the rational or is it only addressed to the PANA WG?

I am preparing a draft on pre-authentication support for PANA, which
is related to mobility support for handover without relying on context
transfer between PAAs in different access networks.  The framework of
pre-authentication at IP layer is defined in
draft-ohba-mobopts-mpa-framework.

I think that your draft can be expanded to carry list of PAAs in
different access networks.  Then, you might partition the list into
"clusters" where each cluster contains a list of PAAs in a particular
access network.  Of course, the PaC should choose a PAA from the
cluster corresponding to the access network in which the PaC currently
resides for normal PANA operation.  PAAs of other clusters may be used
for selecting a PAA in a different access network to pre-authenticate.

Regards,
Yoshihiro Ohba

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana