Subject: [pcp] Comments on draft-ietf-pcp-dhcp-01.txt

From: Dave Thaler <[email-masked]>
Date: Sat, 26 Nov 2011 20:41:53 +0000

Section 1:
>   This document defines IPv4 DHCP [RFC2131] and DHCPv6 [RFC3315]

s/IPv4 DHCP/DHCPv4/

>   In order to make use of these options,

>   this document assumes appropriate name resolution means (see Section

>   6.1.1 of [RFC1123]) are available on the host client.

The above reference to Section 6.1.1 of [RFC1123] is at odds with WG
consensus as noted in the minutes of IETF 81:

"Consensus: Yes, general strings such as can be passed to getaddrinfo,

    including address literals."

Specifically RFC 1123 section 6.1.1 only mentions DNS and hosts file (or equivalent).

Section 2:

> o  DHCPv4 refers to IPv4 DHCP [RFC2131].

s/IPv4 DHCP/the Dynamic Host Configuration Protocol [RFC2131] for IPv4/

Section 3:

First paragraph should be removed before publication as an RFC.  Suggest then

changing:

OLD: This choice of defining the PCP Name option rather than the IP

OLD:   address is motivated by operational considerations:

to

NEW: This document defines an option to carry a name rather than an

NEW: IP address.  This choice is motivated by operational considerations:

Also

s/a regional PCP Servers/a regional PCP server/

Also

>   If the PCP Server is located in a LAN, a simple FQDN such as "pcp-

>   server.local" can be used.

That statement steps into another rathole that would best be avoided

in this particular document.  (As examples of why this is a rathole,

RFC 4795 says that it should only be used with a single-label name,

and various other sources disagree as to whether .local is on a LAN

or a larger organization-wide network.)

Suggest removing that sentence, since "general strings such as can

be passed to getaddrinfo, including address literals" will of course

include .local and many other things.  Just stick with the safe

consensus and avoid ratholes so we can get this document done.

Section 5.2:

Grammar problem "is a properly encoded as"

Also

>   The DHCPv6 client MUST verify the FQDN is a properly encoded as

>   detailed in Section 8 of [RFC3315].

It's unclear whether this is consistent with the aforementioned

WG consensus.  For example, if the option contains a single-label

name "example", is that a "fully-qualified" domain name?   It could

be considered properly encoded as in Section 8 of [RFC3315], as

could (the length-encoded form of) "fe80::5efe:192.168.0.197".

But are they "FQDNs"?  As noted in the meeting minutes, the term

FQDN is problematic so should either be added to section 2 with

a liberal definition, or else another term used (either is fine

with me).

Also

> If more than one IPv6/IPv4

> address are retrieved, the PCP Client MUST use the procedure defined

> in [I-D.ietf-pcp-base] for address selection.

Not sufficient...  [I-D.ietf-pcp-base] section 7.1 states:

>   For the purposes of this document, only a single PCP server address

>   is supported.  Should future specifications define configuration

>   methods that provide a list of PCP server addresses, those

>   specifications will define how clients select one or more addresses

>   from that list.

Hence it has to be defined in this spec.

See http://trac.tools.ietf.org/wg/pcp/trac/ticket/49

for some additional discussion of this issue.

-Dave

---

From: <[email-masked]>
Date: Mon, 28 Nov 2011 10:40:58 +0100

Dear Dave,

Thank you for the review.

Please see inline.

Cheers,
Med

________________________________
De : Dave Thaler [mailto:[email-masked]]
Envoyé : samedi 26 novembre 2011 21:42
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : [email-masked]
Objet : Comments on draft-ietf-pcp-dhcp-01.txt

>   This document defines IPv4 DHCP [RFC2131] and DHCPv6 [RFC3315]

s/IPv4 DHCP/DHCPv4/
[Med] Done.

[Med] Section 6.1.1 of [RFC1123] is provided as an example (BTW, the core text mentions also RFC6055). Would it be fine with you to change the text to reflect this (i.e., "s/see/e.g.,")?

[Med] BTW, I added this term to the terminology section:

   o  Name is a domain name (as per Section 3.1 of [RFC1035]) that
      contains one or more labels.  In particular, a PCP name may be
      structured as DNS qualified name or be composed of strings such
      as can be passed to getaddrinfo, including address literals, etc.

[Med] Done.

Section 3:

changing:

to

[Med] Done.

Also

[Med] Done.

Also

[Med] This sentence was provided as an example, but OK to remove it.

Section 5.2:

[Med] Corrected. Thanks.

Also

with me).
[Med] As mentioned above, "Name" has been added to the terminology section. The text has been updated to mention "Name" instead of "FQDN".

Also

[Med] We need to agree first on the scope of this discussion: do you want to cover

* how to select a PCP server among a configured list of IP servers?: e.g., sort the list, try the first in list N times: if responsive, attach to that PCP server, if not try the next in the list, etc.

* how to bound PCP server to a given interface: PCP server for 3G interface while another PCP server is used for WiFi?

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Mon, 28 Nov 2011 17:18:20 +0000

> [Med] Section 6.1.1 of [RFC1123] is provided as an example (BTW, the core
> text mentions also RFC6055). Would it be fine with you to change the text to
> reflect this (i.e., "s/see/e.g.,")?

Yes, that would work fine.
 
>       as can be passed to getaddrinfo, including address literals, etc.

s/getaddrinfo/a name resolution API (e.g., getaddrinfo as specified
in [RFC3493] Section 6.1)/

> [Med] We need to agree first on the scope of this discussion: do you want to

Yes to both of the below.

> * how to select a PCP server among a configured list of IP servers?: e.g., sort
> the list, try the first in list N times: if responsive, attach to that PCP server, if
> not try the next in the list, etc.

As I noted in the ticket:
   > Personally I believe that if you're behind a stateful NAT, then one PCP 
   > server will do (since it's the server with your external address and hence
   > is guaranteed to be on-path). But if you're behind stateless boxes (e.g.
   > firewall only, no NAT) then you probably want to talk to *all* PCP servers,
   > since no single one is guaranteed to be on path.

So if you're behind a stateful middlebox, then yes what you say is correct 
(and the sort can reference [RFC3484] or 3484bis if we want to wait for that).
But if you're behind only stateless middleboxes, then I believe you want to
use all PCP servers.

I believe it's also a good simplifying assumption to assume that all PCP
servers in the same list (e.g., obtained via DHCP) are of the same type
(stateful vs stateless).   But I believe this does motivate adding a bit to
the DHCP option to indicate whether the set is stateful or stateless.

> * how to bound PCP server to a given interface: PCP server for 3G interface
> while another PCP server is used for WiFi?

Yes.  I think it's important that each PCP server learned be associated with
an interface (the interface via which it was learned, if learned via a 
protocol, e.g. DHCP).   The PCP server(s) chosen for a given source address
to be used by an application should then be from among those on the 
interface that address is assigned to.   (This is similar to how the router is
chosen in the Strong Host aka Strong ES model defined in RFC 1122 section
3.3.4.)

Also I note the ticket stated on June 7 (noting discussion at a webex meeting)
> Multiple interfaces text in section 7 moves to extension.
So you may want to pull the section 7 text from the pcp base doc
as of that date.

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Mon, 28 Nov 2011 17:23:59 +0000

> s/getaddrinfo/a name resolution API (e.g., getaddrinfo as specified in
> [RFC3493] Section 6.1)/

On further thought (and remembering comments made by others
at the Quebec meeting) I think it's important that RFC3493 be a normative
reference not an informative one, so instead:

s/getaddrinfo/getaddrinfo ([RFC3493] Section 6.1)/

The comment I remember is basically that implementations/administrators
need to know what they can put in the option without knowing what API
the client is using.

So the language needs to define it as a string usable with getaddrinfo
but not specify what API an app actually uses (whether gethostbyname,
GetAddrInfoEx on Windows, etc.).   I believe my revised suggested change
above meets those requirements.

-Dave

---

From: Simon Perreault <[email-masked]>
Date: Mon, 28 Nov 2011 13:17:03 -0500

> above meets those requirements.

That's also what I remember from the discussion in Québec. And I agree with your
conclusion.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: <[email-masked]>
Date: Tue, 29 Nov 2011 08:10:27 +0100

Dear Dave,

The text now reads:

   o  Name is a domain name (as per Section 3.1 of [RFC1035]) that
      contains one or more labels.  In particular, a PCP 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.

RFC3493 is now listed as normative reference.

Cheers,
Med

> -----Message d'origine-----
> Envoyé : lundi 28 novembre 2011 18:24
> Objet : RE: Comments on draft-ietf-pcp-dhcp-01.txt
>

---

From: Tina TSOU <[email-masked]>
Date: Tue, 29 Nov 2011 07:26:39 +0000

Supported.

Sent from my iPad

On Nov 28, 2011, at 11:11 PM, "[email-masked]" <[email-masked]> wrote:

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

---

From: <[email-masked]>
Date: Tue, 29 Nov 2011 08:40:29 +0100

Re-,

Please see inline.

Cheers,
Med 

> Envoyé : lundi 28 novembre 2011 18:18

> > [Med] We need to agree first on the scope of this 
> discussion: do you want to
> > cover
> 

We can have a stateful context in which all IP addresses need to be used: theoretical e.g., an IPv6 network involving an IPv6 FW, a NAT64 and NPTv6.

If we allow returning several Name options, then what about the following behaviour?

   * If only one Name option is returned: If
   after resolving the Name conveyed in DHCP PCP Name Option, a list of
   IP addresses is returned, the PCP Client selects only one IP address from the list.
 
   * If many PCP Name options are received: (Step 1) For each Name option, if a list of IP addresses is
   returned, only one IP address is selected. Then (Step 2), contact all IP addresses obtained in Step 1.

Then the question is, when several IP addresses are used, how the PCP client detects the capabilities of each PCP Server (FW, NPTv6, NAT64, etc.)?
Does it make sense to add a capability field similar to what is defined in http://tools.ietf.org/html/draft-boucadair-pcp-extensions-02#section-4?

> So you may want to pull the section 7 text from the pcp base doc

I will check that text.

---

From: <[email-masked]>
Date: Tue, 29 Nov 2011 12:20:05 +0100

Re-,

> > So you may want to pull the section 7 text from the pcp base doc

I added the following text to the draft:

   A host may have multiple network interfaces (e.g, 3G, WiFi, etc.);
   each configured differently.  Each PCP Server learned MUST be
   associated with the interface via which it was learned.  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.  Means to bind a PCP Name
   configuration to a given interface in a multiple-interface host are
   out of scope of this document.

Comments?

Cheers,
Med

---

From: Dave Thaler <[email-masked]>
Date: Tue, 29 Nov 2011 17:43:50 +0000

Mohamed Boucadair writes:
>    associated with the interface via which it was learned.

I need to see the context this text was added in.
In the context of DHCP, the last sentence above is fine.
If independent of mechanism, it's not general enough since static
config isn't "learned via an interface".   So as long as the "learned"
is clear that it's talking about DHCP, the above text is good.

>    When an

I think the last sentence above should be deleted.   It seems to
contradict the earlier sentence "Each PCP Server learned MUST be
associated with the interface via which it was learned."

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Tue, 29 Nov 2011 17:52:54 +0000

[...]
> addresses obtained in Step 1.

For a given name, I think the behavior about choosing 1 vs all addresses
for that name should not depend on whether there are other names.
Hence I don't like the inconsistency between the two proposed bullets.

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Tue, 29 Nov 2011 18:00:07 +0000

I wrote:
> For a given name, I think the behavior about choosing 1 vs all addresses for
> that name should not depend on whether there are other names.

I also wonder if the behavior needs to be different for MAP vs PEER.
For MAP, I argue that (at least for middleboxes like firewalls) you want to
use all.

For PEER, you want to use the PCP server that relates to the actual data path
of a given flow.   In some cases the choice of PCP server might be obvious
to the PCP client (like when it's the default router).   In other cases
(like when they're several hops away), it might not be so obvious and it
might have to try querying them until it finds the one that it believes
is the on-path one (e.g., by querying with a 0 lifetime and observing a
non-0 lifetime response).

-Dave

---

From: <[email-masked]>
Date: Wed, 30 Nov 2011 08:05:12 +0100

Dear Dave,

Please see inline. 

> Envoyé : mardi 29 novembre 2011 18:44

Med: The text is talking about DHCP. I will let the text as it is.

> associated with the interface via which it was learned."

Med: There is no contradiction. The sentence says that no particular implementation method to bind a PCP server to an interface is defined.

---

From: <[email-masked]>
Date: Wed, 30 Nov 2011 08:11:54 +0100

Re-,

To have a full view, the current text I has is:

   If the DHCPv6 client receives more than one OPTION_PCP_SERVER option
   from the DHCPv6 server, it extracts the Name conveyed in each
   OPTION_PCP_SERVER option and proceeds to validating it.  If more than
   one Name is included in a OPTION_PCP_SERVER option occurence, only
   the first instance MUST be used.  Then, The DHCPv6 client MUST verify
   that the option length does not exceed 255 octets [RFC1035]).  The
   DHCPv6 client MUST verify the name is properly encoded as detailed in
   Section 8 of [RFC3315].

   Once the name conveyed in each OPTION_PCP_SERVER option is validated,
   the included Name is passed to the name resolution library (e.g.,
   Section 6.1.1 of [RFC1123] or [RFC6055]) to retrieve the
   corresponding IP address(es) (IPv4 or IPv6).

   Then, the PCP Client follows the procedure specified in Section 5 to
   contact its PCP Server(s).

The rationale behind this is:

* having several Name options is a hint to try all PCP Servers
* if an operator want to indicate a PCP Client to try all PCP Servers, then it should return several PCP Name option rather than including several Names in the same PCP Name option
* When several names are included, then only the first one is used. This is coherent with select only one server among the list.

IMHO, this current behaviour covers your case. No?

Cheers,
Med

> Envoyé : mardi 29 novembre 2011 18:53
> > If we allow returning several Name options, then what about 
> the following
> > behaviour?
> > 
> >    IP addresses is returned, the PCP Client selects only 
> one IP address from
> > the list.
> > 
> >    * If many PCP Name options are received: (Step 1) For 
> each Name option, if
> > a list of IP addresses is
> >    returned, only one IP address is selected. Then (Step 
> 2), contact all IP
> > addresses obtained in Step 1.
>

---

From: <[email-masked]>
Date: Wed, 30 Nov 2011 08:16:52 +0100

Re-,

I don't see much difference between PEER and MAP for the PCP Server discovery. As I said earlier, we have cases where you need to try all servers (e.g., FW, NAT64, NPTv6); this is orthogonal to MAP or PEER.

Cheers,
Med

> Envoyé : mardi 29 novembre 2011 19:00
> À : Dave Thaler; BOUCADAIR Mohamed OLNC/NAD/TIP
> Cc : [email-masked]
> 2), contact
> > > all IP addresses obtained in Step 1.
> >

---

From: Dave Thaler <[email-masked]>
Date: Wed, 30 Nov 2011 18:09:48 +0000

> Med: There is no contradiction. The sentence says that no particular
> implementation method to bind a PCP server to an interface is defined.

I don't know what you mean by "bind".   It still looks like a contradiction
to me.

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Wed, 30 Nov 2011 18:21:58 +0000

> I don't see much difference between PEER and MAP for the PCP Server
> discovery. As I said earlier, we have cases where you need to try all servers
> (e.g., FW, NAT64, NPTv6); this is orthogonal to MAP or PEER.

I don't follow.   PEER is with respect to a specific connection (5-tuple).

I'm having trouble finding which message you refer to as "said earlier",
so would be good if you could repeat when you'd want to send a PEER
for a single 5-tuple to all servers.

(And proposing text to be added in the document would be even better...)

-Dave