Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03

["Bernie Volz (volz)" <[e-mail]>]

Dave:

As the options as defined contain a domain name (encoded per RFC 1035) are address literals really appropriate? This also has consequences for configuring the option data in the servers. And, it seems rather bad to take an encoded name, convert it to a string, only to convert it back into an encoded name. But, alas, that is likely given the common APIs.

Also, given that RFC 1035 section 3.1 states: 

	Since every domain name ends with the null label of
	the root, a domain name is terminated by a length byte of zero.

And the option is to accommodate a list of domain names (knowing that each terminates in the null label makes it possible to separate them), how do you propose that literals (10.1.2.3) be encoded so that it not end up as the domain name "10.1.2.3.".

Perhaps there is a convention used to do this somewhere? (I admit I haven't looked at draft-iab-identifier-comparison carefully.)


When reviewing this and commenting the other day, I originally had thought about commenting on the rather strict rules as to how the results of DNS queries could be used and was thinking that it might be appropriate to relax them some. Just doing normal DNS lookups and using the results (AAAA if v6 is available, A if v4 is available, etc.) would likely make implementing this much easier and require less specialized code.


> 6) Section 5.2 says:
>       "The DHCPv4 client MUST verify that the
>      option length does not exceed 255 octets [RFC1035])."

Good catch. This should be removed as we have the ability to support long v4 options - see RFC 3396.

Note that per section 4 of this RFC:

   Let us divide all DHCP options into two categories - those that, by
   definition, require implementation of the mechanisms defined in this
   document, and those that do not.  We will refer to the former as
   concatenation-requiring options, and the latter as non-
   concatenation-requiring options.  In order for an option to be a
   concatenation-requiring option, the protocol specification that
   defines that option must require implementation of option splitting
   and option concatenation as described in this document, by
   specifically referencing this document.

So the draft should reference RFC 3396 and indicate that this is a concatenation-requiring option.

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Dave Thaler
Sent: Thursday, July 26, 2012 5:59 PM
To: [e-mail]
Subject: [dhcwg] FW: WGLC on draft-ietf-pcp-dhcp-03

I keep mangling the WG mailing list address, so forwarding.

-----Original Message-----
From: Dave Thaler
Sent: Thursday, July 26, 2012 2:58 PM
To: '[e-mail]'
Cc: '[e-mail]'
Subject: RE: WGLC on draft-ietf-pcp-dhcp-03

Missed responding to section 7 before sending...

7) Re "A PCP Server configured using OPTION_PCP_SERVER over DHCPv4 is likely
     to be resolved to IPv4 address(es)."
    I don't think I'd agree with that assumption.   If I put a DNS name in the option,
    it'll be resolved to whatever records are in DNS of a type the client queries for.
   The document currently doesn't say what type(s) to query for (A vs AAAA).
   Per my comment on 2, I believe the types to query for should be independent of
   how the name was obtained (DHCPv4, DHCPv6, manual, SNMP, or whatever else).
   
   "A PCP Server configured using OPTION_PCP_SERVER over DHCPv6 may be
   resolved to IPv4-mapped IPv6 address(es) or IPv6 address(es)"
   By the same reasoning as my previous comment above, it may also be resolved
   to IPv4 addresses.   If I have a dual-stack PCP server, I should be able to put
   the same DNS name in both a DHCPv4 option and a DHCPv6 option, rather
   than requiring me to have two separate names for the same server.

8) Pursuant to a discussion I've been having with some folks on
    draft-iab-identifier-comparison section 3.1.1 and some changes I'll be making to
    it as a result, it got me thinking.  I'm thinking it would be good to have a short
    subsection on Guidance to Administrators on what to configure in their DHCP
    server to return in these options, or more importantly, what not to configure.
    Specifically, strings like "10.0.258", "0xA000001", and "012.0x102" would
    all be a bad idea to configure (unless you specified how they're to be interpreted
    which is an option, though probably not the most expedient one).   I'm still strongly
    in favor of retaining the fact that it's a string that can be passed to name
    resolution APIs, but that means it's best to avoid strings that are interpreted
    differently by different such APIs.

9) On the same point, Section 4.2 currently states:
   "Once each Name conveyed in the OPTION_PCP_SERVER option is validated,
   each included Name is passed to the name resolution library (e.g.,
   Section 6.1.1 of [RFC1123] or [RFC6055])"
   The ambiguity of "e.g." and "section 6.1.1 of [RFC1123]" in particular are 
   problematic because as worded a client that chose not to support IP literals
   would be legal, and it would try to resolve "10.11.12.13" in DNS, which we
   don't want.   Surprising (as draft-iab-identifier-comparison already points out),
   even [RFC1123] allows this to be optional (a "SHOULD") in:  "The host SHOULD check
   the string syntactically for a dotted-decimal number before looking it up in 
   the Domain Name System."

   Instead it's important here to require that the client be able to 
   use IP literals.   Most name resolution APIs (gethostbyname, getaddrinfo,
   etc.) all meet that criteria.

-Dave

> -----Original Message-----
> From: Dave Thaler
> Sent: Thursday, July 26, 2012 2:32 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: WGLC on draft-ietf-pcp-dhcp-03
> 
> Here's my personal comments on draft -03...  I have a few editorial 
> nits I'll just send to the authors.
> 
> 1) I agree with the conclusion of the rationale but the sentence
>      "DHC WG's position is this flexibility have some drawbacks such as inducing
>      errors."
>    isn't intelligible.   What does "inducing errors" mean?   Either explain or
> remove.
> 
> 2) The text on what to do with a name conveyed in an option is duplicated in
>     Section 4.2 and 5.2.   I'd prefer that this be specified only once, to avoid
>     opportunities for discrepancies.   That is, section 4.2's first two paragraphs
> are
>     fine, as are the first 1 1/2 paragraphs of 5.2, since those are 
> about how to get
>     the name out of the option.    The rest isn't DHCPv4 or DHCPv6 specific and
>     should be in its own subsection.
> 
> 3) Re "It is RECOMMENDED to associate a validity lifetime with any address
>     resulting from resolving the Name".  The text should be more specific about
>     what the validity lifetime should be.   If the name is resolved in DNS, I'd
>     say the validity lifetime should be the TTL of the DNS record.
> 
> 4) Re "When an
>       application issues a PCP request to a PCP Server, the source address
>       of the request MUST be among those assigned on the interface to which
>       the destination PCP Server is bound.
> 
>    This doesn't belong in a DHCP-specific document, it's out of scope.   That's
>    the job of the pcp-base spec.
> 
> 5) Same as point 4, but for all of section 6.  In my view it belongs either in
>    pcp-base or perhaps more likely in a separate spec that's not DHCP specific.
>    E.g., if I manually configure one or more names, the same behavior 
> should apply.
> 
> 6) Section 5.2 says:
>       "The DHCPv4 client MUST verify that the
>      option length does not exceed 255 octets [RFC1035])."
> 
>    What does this mean?   The length field is only 1 byte so cannot contain
>    a value larger than 255 anyway.   So what exactly is a client supposed to
>    "verify" here?
> 
> -Dave
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf 
> > Of Dave Thaler
> > Sent: Wednesday, July 18, 2012 2:21 PM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03
> >
> > As discussed at last IETF, the authors believe that all issues 
> > raised so far have been addressed.  No new issues have been raised 
> > since then, so this message begins a Working Group Last Call on
> > draft-ietf-pcp-
> dhcp-03.
> >
> > This call would normally conclude in two weeks but that is during 
> > IETF week, so the last call is extended to conclude at the end of 
> > IETF (as of the Friday PCP meeting).
> >
> > We also agreed in Vancouver that this last call will be cross-posted 
> > to the DHC list, hence cc'ing the DHC WG.
> >
> > We need at least 5 reviewers.  Please send comments to the list.
> >
> > Thanks,
> > -Dave Thaler
> >
> > _______________________________________________
> > pcp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/pcp


_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg