Subject: [pcp] draft-ietf-pcp-dhcp-05.txt

From: Stuart Cheshire <[email-masked]>
Date: Mon, 05 Nov 2012 23:25:59 -0800

Some comments on draft-ietf-pcp-dhcp-05.txt

I found the document confusing and contradictory. In "Terminology" it says:

>    name may be structured as DNS qualified name or
>    be composed of strings such as can be passed to getaddrinfo
>    (Section 6.1 of [RFC3493]), including address literals, etc.

but "Introduction" says:

>    Motivations for defining PCP option as a name and not an IP address
>    are discussed in Appendix A.

I'm not sure which statement applies.

>    The domain name(s) is encoded as string.

This is ambiguous. What kind of string? It should state explicitly that it's a <character-string> as defined in RFC 1035.

And what can it contain? An FQDN? Does it need to end with a trailing dot? Or does it need to *not* end with a trailing dot, because that would be redundant (but the client MUST add one before passing it to gethostbyname)? Can it contain a dotted-decimal IPv4 literal? An IPv6 literal? In square brackets? Are leading/trailing/interior spaces allowed? Or are they illegal?

>    When several names are included, a space character is used as separator.

If there's more than one, they should be concatenated together as with an RFC 1035 TXT record.

On the other hand, if only FQDNs are allowed, not address literals, then instead of <character-string>s, it would be better to use the already-defined name list format from RFC 3397.

>    Once each Name conveyed in the OPTION_PCP_SERVER option is validated...

How is a name "validated"?

Stuart Cheshire

---

From: <[email-masked]>
Date: Tue, 6 Nov 2012 12:41:58 +0100

Dear Stuart,

Please see inline.

Cheers
Med 

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la 
>part de Stuart Cheshire
>Envoyé : mardi 6 novembre 2012 02:26
>À : PCP
>Objet : [pcp] draft-ietf-pcp-dhcp-05.txt
>

Med: The new text in my local copy is as follows:

   o  Name is a string that can be passed to getaddrinfo (Section 6.1 of
      [RFC3493]), such as a DNS name, address literals, etc.  The name
      MUST NOT contain spaces or nulls.

>I'm not sure which statement applies.

Med: The sentence above is to say the option is not encoded as an IP address but as a name. The definition of the name in the draft allows IP address literals to be conveyed as string in the name option.

What about changing:

OLD:

NEW:

   Motivations for not defining PCP option as an IP address
   are discussed in Appendix A

>This is ambiguous. What kind of string? It should state 
>explicitly that it's a <character-string> as defined in RFC 1035.

Med: 1035 encoding was abandoned as per the last IETF meeting. I added a reference to RFC3629. The new text is:

      The name is encoded as a UTF-8 [RFC3629] string.  When several
      names are included, a space character is used as separator.

>
>And what can it contain? An FQDN? Does it need to end with a 
>trailing dot? Or does it need to *not* end with a trailing 
>dot, because that would be redundant (but the client MUST add 
>one before passing it to gethostbyname)? Can it contain a 
>dotted-decimal IPv4 literal? An IPv6 literal? In square 
>brackets? Are leading/trailing/interior spaces allowed? Or are 
>they illegal?

Med: See the definition above.

>On the other hand, if only FQDNs are allowed, not address 
>literals, then instead of <character-string>s, it would be 
>better to use the already-defined name list format from RFC 3397.
>

Med: This is detailed in this updated text:

   If the DHCPv6 client receives an OPTION_PCP_SERVER option from the
   DHCPv6 server, it extracts the name(s) conveyed in the
   OPTION_PCP_SERVER option.  The DHCPv6 client uses the space character
   to identify each individual name.  A name is considered as valid if
   it is a legal UTF-8 string which does not contain any spaces or
   nulls.  The DHCPv6 client MUST silently discard non valid names.

>
>Stuart Cheshire
>
>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp
>

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 06 Nov 2012 22:19:26 -0800

>      MUST NOT contain spaces or nulls.

It would be helpful to spell out exactly what strings are legal, for example:
 Dotted decimal IPv4 addresses - e.g. "10.1.2.3"
 IPv6 addresses in RFC 2373 text representation format - e.g. "FE80::A"
  - IPv6 addresses containing a scope identifier ("%en0") MUST be silently ignored
 Fully-Qualified Domain Names (ending with a dot) - e.g. "natgateway-7.isp.net."
  - Domain Names not ending in a trailing dot MUST be silently ignored

> Med: The sentence above is to say the option is not encoded as an IP address but as a name.

When I write the IP address "10.1.2.3" using ASCII characters it's still an IP address, not a name. Calling "10.1.2.3" a "name" is confusing to most readers. Call it an address.

>   are discussed in Appendix A

How about:
   Motivations for expressing the PCP option as a textual string rather than a 32- or 128-bit binary address are discussed in Appendix A.

>      names are included, a space character is used as separator.

I suggest Net-Unicode [RFC5198].

Is the string null-terminated like a conventional C string?

Is there any precedent in DHCP for using space-separated strings in an option? I'm not aware of any DHCP precedent.

I'd suggest specifying that it's multiple null-terminated Net-Unicode strings packed into the option. Alternatively, define the option to hold exactly one string (no need for null-terminator) and allow the DHCP message to contain multiple occurrences of the option if multiple PCP server strings are being specified.

As a final observation, most existing DHCP options pass an IP address to the client rather than a name string, on the basis that the DHCP server is typically better connected than the DHCP client, so the server can look up a host name faster than the client can, and passing the resulting IP address to the client typically takes less space in the packet than the host name would have. The DHCP server configuration still uses a host name, but the DHCP server resolves it on demand and passes the resulting address(es) to the client in the DHCP OFFER.

Is there a reason that the PCP DHCP option needs to be different?

Stuart Cheshire