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

[Dave Thaler <[e-mail]>]

> -----Original Message-----
> From: Bernie Volz (volz) [mailto:[e-mail]]
> Sent: Friday, July 27, 2012 7:47 AM
> To: Dave Thaler; [e-mail]
> Cc: [e-mail]
> Subject: RE: WGLC on draft-ietf-pcp-dhcp-03
> 
> 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.)

(draft-iab-identifier-comparison isn't relevant to that particular question.)
The WG goal was to be able to configure a set of strings that can be passed to
an API such as getaddrinfo() where the string can be either an IP literal or a
domain name.   I take your point as saying that using the encoding defined
in RFC 1035 section 3.1 isn't sufficient without an additional statement
that the trailing dot should be removed.   The only other alternative
I see would be to not use that encoding but define some other encoding.

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

Right.   I think the goal should be to minimize the amount of processing the
client has to do with the option contents... just pass it to getaddrinfo() or
equivalent was what the WG had discussed.

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

Agree.

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