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

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 27 Jun 2005 18:29:19 -0400

I agree with defining a new DHCP option for PAA information.  In that,
all of my comments might be minor.

This draft is similar to RFC 3319 (as well as RFC 3898) except that
the information is specific to PAAs.  But I found some differences
from RFC 3319 and most of my comments are from that viewpoint.

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

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

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

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

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

[6] The draft might be useful for finding PAAs in different domains to
perform *pre-authentication*.

Regards,
Yoshihiro Ohba

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

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Tue, 28 Jun 2005 12:56:14 +0200

Hi Yoshi,

Thank you for the review.
I attempt to responde to your concerns below.

Cheers,

Lionel

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Yoshihiro Ohba
Envoyé : mardi 28 juin 2005 00:29
À : [email-masked]
Objet : [Pana] comments on draft-suraj-dhcpv4-paa-option-00.txt

I agree with defining a new DHCP option for PAA information.  In that, all of my comments might be minor.

This draft is similar to RFC 3319 (as well as RFC 3898) except that the information is specific to PAAs.  But I found some differences from RFC 3319 and most of my comments are from that viewpoint.

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

[2] In section 5:

"

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.

[3] In section 5.1:

"

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. 

[4] In section 6:

"

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

[5] In section 7:

"

The same comment as [1].

==> Therefore, same response ;)

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

Regards,
Yoshihiro Ohba