Subject: [dhcwg] draft-bpw-pcp-dhcp-00.txt

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Oct 2010 08:53:45 -0700

I noticed that you've published a draft proposing a new set of options for PCP.   It looks like it's the same draft that used to be called draft-bpw-softwire-pcp-dhcp, although I could be mistaken about that--I didn't look very closely at the older draft.

There's a really big problem with this draft: you specify two different ways of communicating the same information.   The two ways you specify are IP address and FQDN.

There are a couple of things you should be aware of with respect to IP addresses and FQDNs in DHCP.   The first is that every DHCP server that I know of will do the translation from fqdn to IP address for you.   So you can just write an FQDN in the config file, and the DHCP server will look up the name and send the resulting IP address or addresses to the client.

What this means is that unless your client is going to cache the FQDN, do a lookup on it, and cache the TTL of the response, there is no benefit to sending the FQDN.   If the A and/or AAAA RRsets for that name change, the client will find out about it when it renews its lease.   This is a comparable effect to what happens if the client goes through the much more complicated process of maintaining the TTL state locally.

Of course, most clients just get the IP address and keep using it until they are restarted, and would not notice a change either from DHCP or from DNS.

The second thing to be aware of is that when you specify two ways for a client to get the same information, you create an interoperability problem.   DHCP servers don't have special code for each option, so the server won't know that the IP address and FQDN option are equivalent.   This means the administrator will have to configure both, in order for clients that only request the FQDN, or only request the IP address to be configured.   So you either need special code on the server, special operating practices on the part of the admin, or special code on the client, in order to make this work the way you'd want.

Whereas if you provide only one way to get the information, there is no potential interoperability problem.   No special code is required on the server or on the client, and no special practices are required of the administrator.

The point of this long winded diatribe is this: please pick FQDN or IP address.   Really, please pick IP address.   If you have some strong reason for wanting to use the FQDN instead, by all means make your case for it, but if you are just trying to cover all bases, please rest assured that defining just the IP address option will do that; the FQDN option is not necessary.

---

From: <[email-masked]>
Date: Mon, 11 Oct 2010 18:11:58 +0200

Dear Ted,

Thank you for your comments.

We changed the filenames so the IDs appear in the PCP WG wiki page. I sent a notification [email-masked] to request for adding a tombstone for the older files.

As for the options, what about defining a single option with sub-code field which indicates whether the option conveys an IP address or a FQDN? Is this acceptable?

Cheers,
Med 

-----Message d'origine-----
De : Ted Lemon [mailto:[email-masked]] 
Envoyé : lundi 11 octobre 2010 17:54
À : BOUCADAIR Mohamed NCPI/NAD/TIP; Reinaldo Penno; Dan Wing
Cc : [email-masked] Group
Objet : draft-bpw-pcp-dhcp-00.txt 

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 11 Oct 2010 09:16:57 -0700

Yes, the change from draft-bpw-softwire-pcp-dhcp to draft-bpw-pcp-dhcp was
mostly to make it show up as a draft related to the PCP working group.

Based on your feedback we will strongly consider if we need FQDN; I expect
we can live without FQDN and return IPv6 address via DHCPv6 and IPv4 address
via DHCP.

-d

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]]
> Sent: Monday, October 11, 2010 8:54 AM
> To: Mohamed Boucadair; Reinaldo Penno; Dan Wing
> Cc: [email-masked] Group
> Subject: draft-bpw-pcp-dhcp-00.txt
> 
> I noticed that you've published a draft proposing a new set of options
> for PCP.   It looks like it's the same draft that used to be called
> draft-bpw-softwire-pcp-dhcp, although I could be mistaken about that--I
> didn't look very closely at the older draft.
> 
> 
> There's a really big problem with this draft: you specify two different
> ways of communicating the same information.   The two ways you specify
> are IP address and FQDN.
> 
> There are a couple of things you should be aware of with respect to IP
> addresses and FQDNs in DHCP.   The first is that every DHCP server that
> I know of will do the translation from fqdn to IP address for you.   So
> you can just write an FQDN in the config file, and the DHCP server will
> look up the name and send the resulting IP address or addresses to the
> client.
> 
> What this means is that unless your client is going to cache the FQDN,
> do a lookup on it, and cache the TTL of the response, there is no
> benefit to sending the FQDN.   If the A and/or AAAA RRsets for that
> name change, the client will find out about it when it renews its
> lease.   This is a comparable effect to what happens if the client goes
> through the much more complicated process of maintaining the TTL state
> locally.
> 
> Of course, most clients just get the IP address and keep using it until
> they are restarted, and would not notice a change either from DHCP or
> from DNS.
> 
> The second thing to be aware of is that when you specify two ways for a
> client to get the same information, you create an interoperability
> problem.   DHCP servers don't have special code for each option, so the
> server won't know that the IP address and FQDN option are equivalent.
> This means the administrator will have to configure both, in order for
> clients that only request the FQDN, or only request the IP address to
> be configured.   So you either need special code on the server, special
> operating practices on the part of the admin, or special code on the
> client, in order to make this work the way you'd want.
> 
> Whereas if you provide only one way to get the information, there is no
> potential interoperability problem.   No special code is required on
> the server or on the client, and no special practices are required of
> the administrator.
> 
> The point of this long winded diatribe is this: please pick FQDN or IP
> address.   Really, please pick IP address.   If you have some strong
> reason for wanting to use the FQDN instead, by all means make your case
> for it, but if you are just trying to cover all bases, please rest
> assured that defining just the IP address option will do that; the FQDN
> option is not necessary.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Oct 2010 10:01:07 -0700

> As for the options, what about defining a single option with sub-code field which indicates whether the option conveys an IP address or a FQDN? Is this acceptable?

No.   Why do you want this?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Oct 2010 10:01:43 -0700

> we can live without FQDN and return IPv6 address via DHCPv6 and IPv4 address

That would be great.   Thanks for considering the feedback!

---

From: <[email-masked]>
Date: Tue, 12 Oct 2010 07:57:58 +0200

Dear Ted,

One of the main use cases of the PCP is to control Carrier Grade NAT such as DS-Lite CGN or NAT64. It is likely that the PCP Server be co-located with the CGN function. A similar use case is discussed in http://www.ietf.org/mail-archive/web/softwires/current/msg01649.html: load-balancing.

Cheers,
Med

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Oct 2010 07:01:34 -0700

On Oct 11, 2010, at 10:57 PM, <[email-masked]> <[email-masked]> wrote:
> One of the main use cases of the PCP is to control Carrier Grade NAT such as DS-Lite CGN or NAT64. It is likely that the PCP Server be co-located with the CGN function. A similar use case is discussed in http://www.ietf.org/mail-archive/web/softwires/current/msg01649.html:load-balancing.

Okay, so get rid of the IP address option.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 12 Oct 2010 10:18:30 -0400

I don't understand how the mechanism in msg01649.html can work.  As I read the description, the DHCP server sends both "a generic FQDN of the AFTR [and] a suffix in the dns search list option."  The host combines those two strings into an FQDN for the service it is trying to discover.  Without some explicit rules about what part of the AFTR FQDN is replaced by which suffix in the DNS search list option, what is the expected behavior of the host?

- Ralph

On Oct 12, 2010, at 1:57 AM 10/12/10, <[email-masked]> <[email-masked]> wrote:

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

---

From: <[email-masked]>
Date: Tue, 12 Oct 2010 16:37:24 +0200

Dear Ralph,

You are right the concatenation behaviour should be specified for the host so that this mechanism to work. This can be simplified if only a hostname is conveyed in the option instead of the FQDN (e.g., "cgn" or "aftr") and a domain search name (e.g., "city1.example.com"). The concatenation would lead to "cgn.city1.example.com". If in the same DHCP offer, a name for SBC/P-CSCF (e.g., "sbc") is provided, the host would build its specific FQDN for the SBC/P-CSCF (i.e., "sbc.city1.example.com"). This concatenation operation can be avoided if the specific FQDN is included in the AFTR name option.

Cheers,
Med

-----Message d'origine-----
De : Ralph Droms [mailto:[email-masked]] 
Envoyé : mardi 12 octobre 2010 16:19
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Lemon Ted; [email-masked] Group; Reinaldo Penno
Objet : Re: [dhcwg] draft-bpw-pcp-dhcp-00.txt

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Oct 2010 09:17:23 -0700

> You are right the concatenation behaviour should be specified for the host so that this mechanism to work. This can be simplified if only a hostname is conveyed in the option instead of the FQDN (e…

This is a really bad idea.   It requires the search list to contain the subdomain that the PCP server's name is in, which may not otherwise be required.   And it presents the possibility that the client will come up with the wrong address because some other subdomain in the search list precedes the one with the PCP server's name, and also contains that name.   If you are going to send an FQDN, you should just send an FQDN.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 12 Oct 2010 12:17:43 -0400

I think we're crossing message threads at this point.

In any event, I don't think the concatenation behavior was specified in any rev of either draft-bpw-pcp-dhcp or draft-ietf-softwire-ds-lite-tunnel-option.  You'll need to nail down that behavior and get WG consensus for it.

- Ralph