Subject: [dhcwg] IP address vs. FQDN discussion

From: <[email-masked]>
Date: Thu, 8 Nov 2012 16:30:21 +0100

Dear all,

As this question is repeatedly raised, including in the ongoing dhc meeting, we have edited a draft which proposes an approach which conciliates both modes: It defines a name option encoded as UTF-8 string which can be a domain name, IPv4 address literals, etc. The draft is available at:

http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-01

Comments are welcome.

Cheers,
Med

---

From: Erik Kline <[email-masked]>
Date: Wed, 14 Nov 2012 19:24:18 -0800

After a very cursory reading, I would say largely +1.  I'm in favour
of something like "a UTF-8 string intended to passed to a higher layer
address resolution mechanism, a la getaddrinfo(), et cetera".

On 8 November 2012 07:30,  <[email-masked]> wrote:
> Dear all,
>
> As this question is repeatedly raised, including in the ongoing dhc meeting,
> we have edited a draft which proposes an approach which conciliates both
> modes: It defines a name option encoded as UTF-8 string which can be a
> domain name, IPv4 address literals, etc. The draft is available at:
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: <[email-masked]>
Date: Thu, 15 Nov 2012 16:04:01 +0100

Dear Erik,

Thanks for reading the draft and also for supporting this proposal. 

For information, I have submitted an updated version of the draft which is available at:

http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-02

Comments from WG are more than welcome.

Cheers,
Med 

>-----Message d'origine-----
>De : Erik Kline [mailto:[email-masked]] 
>Envoyé : jeudi 15 novembre 2012 04:24
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : <[email-masked]>
>Objet : Re: [dhcwg] IP address vs. FQDN discussion
>

---

From: Bud Millwood <[email-masked]>
Date: Fri, 16 Nov 2012 23:42:05 +0100

If I understand this correctly, it's a proposal to allow sending
either a name or ip address encoded as a string?

Space in DHCPv4 packets is limited. Encoding an IP address as text is
a huge waste of valuable packet space for that protocol.

Also, proposing that multiple names be separated with whitespace is
equivalent to either a) introducing a new encoding for sequences or b)
having the option value treated as opaque date. If it's the latter, we
lose the ability to verify that the payload is properly formatted.

Some options use a type specifier, 0 or 1, to denote ip address or dns
name. Is there any reason to not use that?

- Bud

---

From: <[email-masked]>
Date: Mon, 19 Nov 2012 08:37:51 +0100

Dear Bud,

Please see inline.

Cheers,
Med 

>De : Bud Millwood [mailto:[email-masked]] 
>Envoyé : vendredi 16 novembre 2012 23:42

Med: Yes.

>a huge waste of valuable packet space for that protocol.

Med: I don't see this as an issue as fqdn can be conveyed also in a dhcpv4 option.

>lose the ability to verify that the payload is properly formatted.

Med: in -02, we are using length-encoded strings to pack multiple options when needed.

>name. Is there any reason to not use that?

Med: dhw wg is not in favor of that design; please refer to http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-08#section-7.

---

From: Bud Millwood <[email-masked]>
Date: Fri, 23 Nov 2012 15:09:18 +0100

> Med: I don't see this as an issue as fqdn can be conveyed also in a dhcpv4 option.

Sure, you can convey FQDN, but in many cases you can also convey a
binary IP address. If you're short on space, you prefer binary
representation of an IP address over fqdn. We're counting bytes in
DHCPv4 packets, and the difference between 4 bytes versus even 5 or 6
bytes can mean a lot.

To be clear, my concern is specifically about DHCPv4. Your proposal
solves a sticky problem, but it comes at a cost and I'm not sure that
cost is acceptable for DHCPv4.

> Med: in -02, we are using length-encoded strings to pack multiple options when needed.

Sounds great, I'm all for it.

> Med: dhw wg is not in favor of that design; please refer to http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-08#section-7.

I was tempted to originally write "Is there any reason not to use
that, besides the fact that we all hate it?" Although we all hate
conditional typing for DHCPv4 options, I'm concerned that your
solution will fail to achieve its desired goal in DHCPv4, namely to
actually convey the option. When space runs out, there's not much to
do except leave out some options.

To the guys I've CC:ed: Do you support this for DHCPv4? If so, is my
concern unfounded?

- Bud

---

From: Ted Lemon <[email-masked]>
Date: Fri, 23 Nov 2012 16:28:36 +0000

> To the guys I've CC:ed: Do you support this for DHCPv4? If so, is my

I have never understood why people want to carry FQDNs in DHCP packets in the first place, and given the limited size of DHCPv4 packets, and the compactness of IPv4 addresses, it really seems like a no-brainer to only support IP addresses.   In the case of IPv6 it's more debatable since IPv6 addresses are four times larger.   ntp.example.com is the same number of bytes as an IPv6 address.   Plus DHCPv6 packets aren't as restricted in size.

Having said that, there are always people proposing, and insisting on, FQDNs in DHCP packets.

But here is the core issue to me, and why I oppose this kind of dual encoding: the encoding is subject to interpretation, and encourages bad implementations that have undefined failure modes.   My expectation, and what I've heard from people who advocate sending FQDNs in text strings, is that they'll just hand the string to some library function that will figure out whether it's an IP address or an FQDN, and do the right thing.

To me this sounds like begging for problems in the future.   How do we know the library function will do the right thing?   How do we know there isn't a bug in the way the library function parses these strings?   What are the corner cases?   Do IPv6 addresses need to be sent in brackets?   Etc.

The beauty of "this is an IPv6 address" is that there's no interpretation.   The beauty of "this is an FQDN encoded in the standard wire format" is the same.   Put it in a text string, and you lose that.

So my personal opinion on this is that authors of drafts need to choose: is what you want an FQDN or an IP address?   If you think you want an FQDN, but you sort of want an IP address as well, rethink your desire for the FQDN, since clearly it is not necessary.   If you are happy to give up sending an IP address, then you probably do need an FQDN.   If you are not happy to do that, then you probably need an IP address.   You almost certainly do not need both, although I'm sure you can construct a use case that shows that both would be nice to have.   Nice to have != need.

---

From: Bud Millwood <[email-masked]>
Date: Sat, 24 Nov 2012 00:49:56 +0100

Thanks for responding Ted, I agree with your views.

Mohamed, if you're convinced that your proposal is a good idea, you
may want to re-think whether it should cover DHCPv4.

- Bud

> On Fri, Nov 23, 2012 at 5:28 PM, Ted Lemon <[email-masked]> wrote:

---

From: <[email-masked]>
Date: Mon, 26 Nov 2012 13:14:37 +0100

Dear Bud,

Please see inline. 

Cheers,
Med 

>De : [email-masked] [mailto:[email-masked]] De 
>la part de Bud Millwood
>Envoyé : vendredi 23 novembre 2012 15:09
>Cc : <[email-masked]>; Bernie Volz (volz); Ted Lemon; Andre Kostur

Med: I see your concerns. The recommendation can focus on DHCPv6 options as these are likely to be the majority of options to be defined by the IETF in the future.

>Sounds great, I'm all for it.

Med: Ok, thanks.

>> Med: dhw wg is not in favor of that design; please refer to 
>http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-08#
>section-7.
>

---

From: <[email-masked]>
Date: Mon, 26 Nov 2012 13:38:10 +0100

Hi Ted,

Please see inline. 

Cheers,
Med 

>De : Ted Lemon [mailto:[email-masked]] 
>Envoyé : vendredi 23 novembre 2012 17:29
>À : Bud Millwood
>Cc : BOUCADAIR Mohamed OLNC/OLN; <[email-masked]>; Bernie Volz 
>(volz); Andre Kostur
>I have never understood why people want to carry FQDNs in DHCP 
>packets in the first place, and given the limited size of 
>DHCPv4 packets, and the compactness of IPv4 addresses, it 
>really seems like a no-brainer to only support IP addresses.   
>In the case of IPv6 it's more debatable since IPv6 addresses 
>are four times larger.   ntp.example.com is the same number of 
>bytes as an IPv6 address.   Plus DHCPv6 packets aren't as 
>restricted in size.
>
>But here is the core issue to me, and why I oppose this kind 
>of dual encoding: the encoding is subject to interpretation, 
>and encourages bad implementations that have undefined failure 
>modes.   My expectation, and what I've heard from people who 
>advocate sending FQDNs in text strings, is that they'll just 
>hand the string to some library function that will figure out 
>whether it's an IP address or an FQDN, and do the right thing.
>

Med: Yes, that's the main point. 

>To me this sounds like begging for problems in the future.   
>How do we know the library function will do the right thing?   
>How do we know there isn't a bug in the way the library 

Med: We know the behaviour of current name resolution libraries, so we can define a safe validation procedure for these libraries. Should we speculate on the evolution of these name resolution libraries? IMO, I don't think so. Note, DNS names can be returned in dhcp options but dns is not the only available name resolution service...

>function parses these strings?   What are the corner cases?   
>Do IPv6 addresses need to be sent in brackets?   Etc.

Med: This is part of the validation procedure. The draft can work better this part once the idea of dual encoding is understood.

>
>The beauty of "this is an IPv6 address" is that there's no 
>interpretation.   The beauty of "this is an FQDN encoded in 
>the standard wire format" is the same.   Put it in a text 
>string, and you lose that.
>
>So my personal opinion on this is that authors of drafts need 
>to choose:

Med: We can make a choice/decision but it may not be appropriate for all deployments. This is why I do still think it does not make sense to dictate which option a provider need to support. There are arguments in favour of an IP address and other arguments in favour of FQDN. This is what this draft is trying to achieve in this section: http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-02#section-2.

 is what you want an FQDN or an IP address?   If you 
>think you want an FQDN, but you sort of want an IP address as 
>well, rethink your desire for the FQDN, since clearly it is 
>not necessary.   If you are happy to give up sending an IP 
>address, then you probably do need an FQDN.   If you are not 
>happy to do that, then you probably need an IP address. 

Med: This is exactly what this draft is for: choose what you want to convey in the option: an ip address or a fqdn.

  You 
>almost certainly do not need both,

Med: Agree.

 although I'm sure you can 
>construct a use case that shows that both would be nice to 
>have.   Nice to have != need.

Med: This draft is not advocating for defining two options but:
* it argues both encoding may be needed in different deployment contexts. 
* it proposes one single option to meet both IP/FQDN needs.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Nov 2012 13:46:12 +0000

> Med: We know the behaviour of current name resolution libraries, so we can define a safe validation procedure for these libraries. Should we speculate on the evolution of these name resolution libr…

Right, this is the core of the problem.   The problem is open-ended.   If you just send an IP address, you can put all this complexity on the server, and because it's monolithic, there's no interoperation, and hence no interoperability problems.   Whereas if you use DHCP as a conduit between heterogenous hosts, the server implementation has no way to anticipate what might happen on the client.

> Med: We can make a choice/decision but it may not be appropriate for all deployments. This is why I do still think it does not make sense to dictate which option a provider need to support. There are arguments in favour of an IP address and other arguments in favour of FQDN. This is what this draft is trying to achieve in this section:http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-02#section-2.

There are some good arguments here in favor of using an FQDN.   If these arguments are sufficient to justify requiring a resolver, then you should use an FQDN and not support an IP address.   Otherwise you will have some devices that support the FQDN, and some that do not, and you will run into interoperability problems.

---

From: Kim Kinnear <[email-masked]>
Date: Mon, 26 Nov 2012 10:34:29 -0500

Ted, 

Thank you for stating this so clearly.  I was working up to
trying to say pretty much the same thing, but you beat me to it,
and stated it better as well.

I would add that, having seen real world environments grind to a
halt because they used FQDN's for configuration and DNS servers
were unavailable, I cannot see how anyone could want to use an
FQDN when an IP address would do.

If you absolutely *have* to have an FQDN, then build that into
the draft as the only approach.  If you don't *have* to have an
FQDN, then by all means use an IP address and make that the only
approach.

Regards -- Kim

---

From: Sten Carlsen <[email-masked]>
Date: Mon, 26 Nov 2012 16:38:11 +0100

Just a thought, load balancers and other appliances that may have more
than one IP, would they have any relevance for this? If not, then fine,
forget this.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Nov 2012 15:52:59 +0000

On Nov 26, 2012, at 10:38 AM, Sten Carlsen <[email-masked]> wrote:
> Just a thought, load balancers and other appliances that may have more than one IP, would they have any relevance for this? If not, then fine, forget this.

This is mentioned in the draft Med wrote.    Of course, the DHCP server can also do load balancing; it doesn't have to happen on the client.   But any sort of DNS strategy that does geographical load direction based on a common name would fail, since the DHCP server and DHCP client are in different locations.

However, DHCP makes solving this problem easy as well—give out different information on different networks.   All that is required is that names be chosen for locality, rather than using the same name in all locations and having the DNS server give different answers according to location.

Really, all of the operational issues Med talks about in the draft _can_ be solved with DHCP server configuration; even the double indirection problem can be solved by simply configuring the FQDN on the DHCP server and having the DHCP server hook it up.   The DNS server administrator can change the FQDN, and the DHCP server will quickly start using the new FQDN (assuming an appropriate TTL was chosen).

---

From: Sten Carlsen <[email-masked]>
Date: Mon, 26 Nov 2012 17:08:05 +0100

Ok, Thanks.

-- 
Best regards

Sten Carlsen

---

From: Simon Hobson <[email-masked]>
Date: Mon, 26 Nov 2012 18:50:10 +0000

Ted Lemon wrote:

>But any sort of DNS strategy that does geographical load direction 
>based on a common name would fail, since the DHCP server and DHCP 
>client are in different locations.
>
>However, DHCP makes solving this problem easy as well-give out 
>different information on different networks.   All that is required 
>is that names be chosen for locality, rather than using the same 
>name in all locations and having the DNS server give different 
>answers according to location.

That does mean duplicating config to a certain extent, and in the 
sort of situation where that would be used, there's a good chance 
that the DNS and DHCP are managed by different groups. That's not an 
insurmountable, or even in most cases difficult, problem to work 
round - but it is a situation where using FQDN would avoid a 
different management issue.
Whether this is a significant consideration, I've leave others to argue about !

I've only worked in situation where the DHCP and DNS are managed by 
the same person (usually me), or at least by the same small group.

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Nov 2012 19:04:52 +0000

On Nov 26, 2012, at 1:50 PM, Simon Hobson <[email-masked]> wrote:
> That does mean duplicating config to a certain extent, and in the sort of situation where that would be used, there's a good chance that the DNS and DHCP are managed by different groups. That's not an insurmountable, or even in most cases difficult, problem to work round - but it is a situation where using FQDN would avoid a different management issue.

That's not quite right.   Someone always has to put the information into the DHCP server, and the DHCP server always has to have locality-specific configuration information.   So the question is, should that configuration information include different FQDNs for the same service, or should there be a single non-local FQDN to cover that service, and then some kind of DNS infrastructure that gives different answers based on locality.

The DNS administrator can't change the DHCP server setting, but he or she can trivially change the IP address to which the names refer, so this strikes me as a non-problem—the flexibility required in the dual-administration situation is handled successfully, without any extra steps required.   Furthermore, it's standards-compliant—you are directly following the DHCP specification and the DNS specification, using functionality that's widely available and easy to configure.

The FQDN solution is not standards-based: it requires special nonstandard DNS hacks to return different answers depending on where the user is.   It's not _violating_ any standards, but we're essentially adding features to the DHCP _protocol_ in order to enable a nonstandard DNS _implementation_.

---

From: Stephen Jacob <[email-masked]>
Date: Mon, 26 Nov 2012 15:24:18 -0800

On Mon, Nov 26, 2012 at 03:52:59PM +0000, Ted Lemon wrote:
> > Just a thought, load balancers and other appliances that may
> > have more than one IP, would they have any relevance for this?
> > If not, then fine, forget this.
> 
> This is mentioned in the draft Med wrote.    Of course, the DHCP
> server can also do load balancing; it doesn't have to happen on
> the client.   But any sort of DNS strategy that does geographical
> load direction based on a common name would fail, since the DHCP
> server and DHCP client are in different locations.
> 
> However, DHCP makes solving this problem easy as well?give out
> different information on different networks.   All that is
> required is that names be chosen for locality, rather than using
> the same name in all locations and having the DNS server give
> different answers according to location.
> 
> Really, all of the operational issues Med talks about in the draft
> _can_ be solved with DHCP server configuration; even the double
> indirection problem can be solved by simply configuring the FQDN
> on the DHCP server and having the DHCP server hook it up.   The
> DNS server administrator can change the FQDN, and the DHCP server
> will quickly start using the new FQDN (assuming an appropriate TTL
> was chosen).

It seems to me that there's a couple of other cases where "just use
an IP address" may not always be a good solution for a given
administrative domain but would be fine for others:

1. When some want to convey multiple addresses in an option that
   accepts a single FQDN. Perhaps this just indicates that the
   option should accept a list of IP addresses, but in that case
   you must manage the lists of IP addresses in the DHCP server
   (manually, or by having the server resolve names into [lists of]
   addresses (which sucks for the fast path of the DHCP server)).

2. When you want to convey addresses which change more frequently
   than (or close to as often as) the length of one's DHCP lease.

3. Sort of a special case of #2: In cases where you have DNS servers
   which can hand out lists of addresses that vary depending on the
   'health' of the services running on the servers with those
   addresses. This tends to go hand-in-hand with geolocation, often
   under the moniker "GSLB". In this case, addresses may potentially
   come and go from a name with great frequency.

In any/all of these cases, it may be inconvenient for someone who
doesn't have the needs listed above to use FQDNs, so that seems like
a case for considering providing the option of providing an address.

So, while I have no love for DHCP options that may contain multiple
different data formats, I do see the value in being able to do so.

Regards,
Stephen
-- 
 Stephen Jacob | [email-masked] | +1 650 381 6051
 Nominum, Inc. |  http://www.nominum.com/  | +1 650 381 6000

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Nov 2012 03:35:18 +0000

>   addresses (which sucks for the fast path of the DHCP server)).

This is a simple matter of programming, and it's the way it's always been done.   Are people hard-coding IP addresses into DHCP server configurations to speed up the servers?

>   than (or close to as often as) the length of one's DHCP lease.

It's extraordinarily rare that a consumer of DHCP information even checks to see that it's changed when the lease is renewed.   So yes, if there is a specific application where the DNS TTL needs to be honored, this is a valid point, but I've never heard of anybody actually implementing such a thing.   A use case isn't a valid use case if there isn't anyone who would actually use it—that's what the "use" in "use case" means, and what distinguishes use cases from deployment scenarios.

>   come and go from a name with great frequency.

Again, where's the use case.   Of course one could *imagine* deployment scenarios like that, and they even happen in real life for web services, but where's the crossover with DHCP?

> different data formats, I do see the value in being able to do so.

I would not deny that there is value in providing FQDNs and letting the client sort it out, but you haven't said anything at all here that makes the case for providing both FQDNs and IP addresses.   And "there is value in XXX" is not sufficient justification for doing things two different ways.   It needs to be true that there is a use case that is not addressed by the one of the two choices, and another use case that is not addressed by the other.

---

From: <[email-masked]>
Date: Tue, 27 Nov 2012 10:18:14 +0100

Dear Kim,

Please see inline. 

Cheers,
Med 

>De : [email-masked] [mailto:[email-masked]] De 
>la part de Kim Kinnear
>Envoyé : lundi 26 novembre 2012 16:34
>À : Ted Lemon
>Cc : <[email-masked]>; Andre Kostur; Bud Millwood; Bernie Volz 
>(volz); Kim Kinnear
>were unavailable,

Med: This is deployment-specific. In some deployments (e.g., SIP-based managed services offerings), both the DNS and SIP infrastructures are managed by the same administrative entity. Some motivations to use the fqdn are discussed in the draft. 

 I cannot see how anyone could want to use an
>FQDN when an IP address would do.

Med: I see it from another perspective: Having the same option which allows to switch from returning a name to an IP address would be more adequate as this does not require to standardize a new option (get a codepoint for the ip address option if only the fqdn is specified).

>the draft as the only approach.

Med: I can have a favourite approach (e.g., fqdn) given some deployment constraints but in other deployments the favourite approach would be different.  

  If you don't *have* to have an
>FQDN, then by all means use an IP address and make that the only

Med: IMO, this is difficult to achieve. Having a flexible encoding which allows to return an IP address or a name would be a good compromise. As stated in the I-D:

   o  A DHCP server can be configured to inject one or multiple FQDNs in
      the option.
   o  A DHCP server can be configured to inject one or multiple IP
      addresses in the option
   o  A DHCP server can be configured to resolve the FQDN and inject the
      resolved IP address(es) as IP literals in the option.
   o  A DHCP server can convey in one single option both IPv4 and IPv6
      address literals when serving dual-stack clients.

>> I have never understood why people want to carry FQDNs in 
>DHCP packets in the first place, and given the limited size of 
>> So my personal opinion on this is that authors of drafts 
>need to choose: is what you want an FQDN or an IP address?   
>If you think you want an FQDN, but you sort of want an IP 
>address as well, rethink your desire for the FQDN, since 
>clearly it is not necessary.   If you are happy to give up 
>sending an IP address, then you probably do need an FQDN.   If 
>you are not happy to do that, then you probably need an IP 
>address.   You almost certainly do not need both, although I'm 
>sure you can construct a use case that shows that both would 
>be nice to have.   Nice to have != need.
>>

---

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

Hi Ted,

Please see inline. 

Cheers,
Med 

>Envoyé : lundi 26 novembre 2012 14:46
>Cc : Bud Millwood; <[email-masked]>; Bernie Volz (volz); Andre Kostur
>> Med: We know the behaviour of current name resolution 
>libraries, so we can define a safe validation procedure for 
>these libraries. Should we speculate on the evolution of these 
>name resolution libraries? IMO, I don't think so. Note, DNS 
>names can be returned in dhcp options but dns is not the only 
>available name resolution service...
>
>Right, this is the core of the problem.   The problem is 
>open-ended.   If you just send an IP address, you can put all 
>this complexity on the server, and because it's monolithic, 
>there's no interoperation, and hence no interoperability 
>problems.   Whereas if you use DHCP as a conduit between 
>heterogenous hosts, the server implementation has no way to 
>anticipate what might happen on the client.

Med: That's indeed one possible approach but as discussed in the draft this may not meet the requirements in some deployments. This is the main contribution of this draft: investigate an alternative encoding approach which would allow to meet various deployments.

>
>> Med: We can make a choice/decision but it may not be 
>appropriate for all deployments. This is why I do still think 
>it does not make sense to dictate which option a provider need 
>to support. There are arguments in favour of an IP address and 
>other arguments in favour of FQDN. This is what this draft is 
>trying to achieve in this 
>section:http://tools.ietf.org/html/draft-boucadair-dhc-address-
>name-encoding-02#section-2.
>
>There are some good arguments here in favor of using an FQDN.  
> If these arguments are sufficient to justify requiring a 
>resolver, then you should use an FQDN and not support an IP 
>address.   Otherwise you will have some devices that support 
>the FQDN, and some that do not, and you will run into 
>interoperability problems.

Med: The dns resolved point is discussed in the draft, see http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-02#section-2.1.2.

---

From: <[email-masked]>
Date: Tue, 27 Nov 2012 10:28:09 +0100

Dear Sten,

This point is discussed in http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-02#section-2.2.3. Two modes are discussed in that section:

(1) load-balancing procedure which involves DHCP servers
(2) load-balancing procedure which does not involve dhcp server

The first mode may not be acceptable in some deployments (mainly for operational considerations).

Cheers,
Med

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Sten Carlsen
Envoyé : lundi 26 novembre 2012 16:38
À : [email-masked]
Objet : Re: [dhcwg] IP address vs. FQDN discussion

Ted,

Regards -- Kim

On Nov 23, 2012, at 9:09 AM, Bud Millwood <[email-masked]><mailto:[email-masked]> wrote:

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

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

--
Best regards

Sten Carlsen

---

From: <[email-masked]>
Date: Tue, 27 Nov 2012 10:30:17 +0100

Re-,

Please see inline. 
Cheers,
Med 

>la part de Ted Lemon
>Envoyé : lundi 26 novembre 2012 16:53
>À : Sten Carlsen
>Cc : <[email-masked]>
>This is mentioned in the draft Med wrote.    Of course, the 
>DHCP server can also do load balancing; it doesn't have to 
>happen on the client.   But any sort of DNS strategy that does 
>geographical load direction based on a common name would fail, 
>since the DHCP server and DHCP client are in different locations.
>
>required is that names be chosen for locality, rather than 
>using the same name in all locations and having the DNS server 
>give different answers according to location.
>
>Really, all of the operational issues Med talks about in the 
>draft _can_ be solved with DHCP server configuration; even the 
>double indirection problem can be solved by simply configuring 
>the FQDN on the DHCP server and having the DHCP server hook it 
>up.   The DNS server administrator can change the FQDN, and 
>the DHCP server will quickly start using the new FQDN 
>(assuming an appropriate TTL was chosen).

Med: I fully agree with you this is technically doable. The main issue is operational as mentioned in the draft: 

   Requiring the DHCP server to interface with a DNS-based load
   distributing engine may not be acceptable for operators separating
   the delivery of (basic) network connectivity from service-related
   provisioning.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 28 Nov 2012 23:30:13 +0000

I think there was some discussion that I may have been the cause of all of this? I don't recall the particular email or discussion that might have triggered this, but I do recall several drafts proposing to use two options (or sub-options) - one for carrying the IPv4 address and another an FQDN - for a particular configuration parameter. I also recall some other drafts proposing a type enumerator followed by the data (based on the type enumerator). And, I do recall suggesting that the DHC WG perhaps take this issue up to provide some guidance as to what is the best practice (perhaps in the Options Guideline document). Personally, I do not like the idea of two options (or sub-options) and an enumeration type followed by appropriate data seems less desirable over picking one and living with it.

As already covered in the discussion, the problem is also not that simple because there are many considerations - who will use the information, how soon will it be used, who can manage the information (using an FQDN requires that the name is in DNS), ...

And, perhaps this discussion will leave us where we were with no clear answer; but perhaps more details added to draft-ietf-dhc-option-guidelines to assist people in making a decision (I think Tomek indicated that he has an 09 pending with more to say on this matter).

---

BTW: draft-boucadair-dhc-address-name-encoding-02 isn't that bad as it proposes using strings acceptable to getaddrinfo. Though I am not sure that these strings are that tightly specified. And, there are still cases where an IP address would be required (4-byte or 16-byte option data) - as a DNS resolver might not be available (if bootstrap loader, etc.) or result in a catch-22 (DNS server's list). And others where a FQDN is required.

- Bernie

---

From: <[email-masked]>
Date: Thu, 29 Nov 2012 08:40:17 +0100

Dear Benrie,

Please see inline. 

Cheers,
Med

>De : Bernie Volz (volz) [mailto:[email-masked]] 
>Envoyé : jeudi 29 novembre 2012 00:30
>À : BOUCADAIR Mohamed OLNC/OLN; Ted Lemon
>Cc : <[email-masked]>
>Objet : RE: [dhcwg] IP address vs. FQDN discussion
>
>I think there was some discussion that I may have been the 
>cause of all of this? I don't recall the particular email or 
>discussion that might have triggered this, but I do recall 
>several drafts proposing to use two options (or sub-options) - 
>one for carrying the IPv4 address and another an FQDN - for a 
>particular configuration parameter. I also recall some other 
>drafts proposing a type enumerator followed by the data (based 
>on the type enumerator). And, I do recall suggesting that the 
>DHC WG perhaps take this issue up to provide some guidance as 
>to what is the best practice (perhaps in the Options Guideline 
>document). Personally, I do not like the idea of two options 
>(or sub-options) and an enumeration type followed by 
>appropriate data seems less desirable over picking one and 
>living with it.
>
>As already covered in the discussion, the problem is also not 
>that simple because there are many considerations - who will 
>use the information, how soon will it be used, who can manage 
>the information (using an FQDN requires that the name is in DNS), ...
>
>And, perhaps this discussion will leave us where we were with 
>no clear answer; but perhaps more details added to 
>draft-ietf-dhc-option-guidelines to assist people in making a 
>decision (I think Tomek indicated that he has an 09 pending 
>with more to say on this matter).
>
>---
>
>BTW: draft-boucadair-dhc-address-name-encoding-02 isn't that 
>bad as it proposes using strings acceptable to getaddrinfo. 
>Though I am not sure that these strings are that tightly 
>specified. 

Med: If the WG accepts this draft, we can work better the validation procedure to avoid errors which may be generated by blindly passing a string to a name resolution library (e.g., what to do with IPv4-mapped IPv6 addresses, if we allow the use of the bracket or not, trailing dot mandatory or optional, etc.) 

And, there are still cases where an IP address 
>would be required (4-byte or 16-byte option data) - as a DNS 
>resolver might not be available (if bootstrap loader, etc.) or 
>result in a catch-22 (DNS server's list). And others where a 
>FQDN is required.

Med: One clarification here, draft-boucadair-dhc-address-name-encoding does not propose to generate this format but it focuses only on the following case (see Section 3):

   For contexts where both an IP Address and a FQDN should be supported
   in DHCP, it is RECOMMENDED to define one single option which is
   characterized as follows:

This means:

(1) if option designers think only an IP address is needed, then the format should be designed as an IP-Address
(2) if option designers think only an FQDN is needed, then the format should be designed to convey only FQDN
(3) if option designers think only both an IP address and FQDN are needed, then adopt the format proposed in draft-boucadair-dhc-address-name-encoding.

draft-boucadair-dhc-address-name-encoding can be used also for (1) and (2) but I prefer to restrict the scope to (3) only.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 29 Nov 2012 13:33:54 +0000

I'd like to see the draft specially recommend to use either an address or fqdn if at all possible (hence not use the draft) and only use this option format if there is a "hard" requirement for both.

I haven't tried it but I don't think getaddrinfo allows brackets around v6 addresses? Or are there some implementations that do? 

Sent from my iPad

---

From: Danny Mayer <[email-masked]>
Date: Thu, 29 Nov 2012 08:57:48 -0500

There was already a discussion on this during the drafting of RFC5908. I
wanted to make sure people didn't hardcode IP addresses in configuration
options and instead allow them to be resolved via DNS so that NTP
servers could be controlled better by the people who maintain them and
so that they can change the host server whenever they wanted without
needing to let everyone get involved.

Danny

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Nov 2012 15:37:49 +0000

> (3) if option designers think only both an IP address and FQDN are needed, then adopt the format proposed in draft-boucadair-dhc-address-name-encoding.

The problem I have with this is that most of the time when people say they want both, they can't give a really good reason why they want both—they just want it.   If you ask them for use cases, they can't come up with any.

I would want the document to discourage the use of FQDNs, and to STRONGLY discourage the use of a FQDN+IP address.

In addition, any option that did use FQDN+IP address should be REQUIRED to implement both FQDN and IP address.   But I'm sure you see the problem with this—implementors often take MUST as advisory when it requires something they don't want to have to code, like a DNS resolver.   So if you have an option that uses FQDN+IP, you can count on seeing serious interoperability problems in the field.

---

From: <[email-masked]>
Date: Thu, 29 Nov 2012 16:40:14 +0100

Re-,

Please see inline. 

Cheers,
Med 

>Envoyé : jeudi 29 novembre 2012 14:34
>Cc : Ted Lemon; <[email-masked]>
>I'd like to see the draft specially recommend to use either an 
>address or fqdn if at all possible (hence not use the draft) 
>and only use this option format if there is a "hard" 
>requirement for both.

Med: I updated the text as follows:

OLD:

NEW:

   Documents specifying future DHCP Options SHOULD motivate why an 'IP-
   Address'-only or FQDN-only encoding does not meet the expected
   requirements.

Are you fine with the new text? 

>
>I haven't tried it but I don't think getaddrinfo allows 
>brackets around v6 addresses? Or are there some 
>implementations that do? 

Med: brackets are not allowed. The validation I'm talking about is what the dhcp client need to do when it receives an IPv6 address with bracket: does it reject the option or remove the bracket and pass it to the name resolution library. 

>> Med: If the WG accepts this draft, we can work better the 
>validation procedure to avoid errors which may be generated by 
>blindly passing a string to a name resolution library (e.g., 
>what to do with IPv4-mapped IPv6 addresses, if we allow the 
>use of the bracket or not, trailing dot mandatory or optional, etc.) 
>> 
>> 
>> Med: One clarification here, 
>draft-boucadair-dhc-address-name-encoding does not propose to 
>generate this format but it focuses only on the following case 
>(see Section 3):
>> 
>> (1) if option designers think only an IP address is needed, 
>then the format should be designed as an IP-Address
>> (2) if option designers think only an FQDN is needed, then 
>the format should be designed to convey only FQDN
>> (3) if option designers think only both an IP address and 
>FQDN are needed, then adopt the format proposed in 
>draft-boucadair-dhc-address-name-encoding.
>> 
>> draft-boucadair-dhc-address-name-encoding can be used also 
>for (1) and (2) but I prefer to restrict the scope to (3) only.
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Nov 2012 15:43:15 +0000

> needing to let everyone get involved.

Yup.   RFC5908 should never have been published—it never went through last call in the DHC working group, and you did not take our advice on how the option should work.   Your successful effort to do what you want against the considered advice of the DHC working group is the example I give when I talk about why we need to have expert review of all DHCP options on the way through the IESG.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Nov 2012 15:53:02 +0000

> Are you fine with the new text? 

This is definitely better

> Med: brackets are not allowed. The validation I'm talking about is what the dhcp client need to do when it receives an IPv6 address with bracket: does it reject the option or remove the bracket and…

I would add some text that reads like this:

The DHCP agent decoding an option in this format MUST validate the contents of the option.   If the contents are not valid, the DHCP client MUST silently ignore the option.   The DHCP client MUST NOT attempt to process an invalid option of this type for reasons of compatibility with non-conforming implementations, or for any other reason.

To validate the option, the DHCP client verifies that none of the following conditions are true:

<insert text here, and good luck!>

---

From: <[email-masked]>
Date: Thu, 29 Nov 2012 16:53:59 +0100

Dear Danny,

I updated the draft with a new sub-section to list the argument you raised: 

===
2.2.4.  Avoid Hard-coding IP Addresses

   Another reason to prefer using FQDNs rather than IP addresses is to
   avoid applications to hard-code IP addresses.  Hard-coding the IP
   address(es) is seen as a hurdle to change the configuration of a
   service (server) in a transparent fashion.
===

Thanks.
Cheers,
Med 

>De : Danny Mayer [mailto:[email-masked]] 
>Envoyé : jeudi 29 novembre 2012 14:58
>À : Bernie Volz (volz)
>Cc : BOUCADAIR Mohamed OLNC/OLN; <[email-masked]>; Ted Lemon
>> I'd like to see the draft specially recommend to use either 
>an address or fqdn if at all possible (hence not use the 
>draft) and only use this option format if there is a "hard" 
>requirement for both.
>>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 29 Nov 2012 16:00:33 +0000

Hi:

I'd prefer to have the OLD/NEW text be revised to state that new options SHOULD use either an address or FQDN encoding for the data and if there is a strong requirement to support both that they MUST [SHOULD?] use this encoding and provide the rational for why either an address or FQDN encoding is insufficient.

I don't think DHCP clients should be in the business of validating the syntax. Whatever uses the data should just call getaddrinfo and live with whatever it returns (after all, a valid FQDN may not resolve). This also extends to checking for the trailing dot on an FQDN.

Servers may want to provide validation, but I'm also inclined to recommend against this -- if the administrator configures broken data, they will likely get a lot of support calls. (If the option contained an FQDN, would we expect a server to validate that the FQDN is resolvable before giving it to the client? I suspect not.)

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, November 29, 2012 10:40 AM
To: Bernie Volz (volz)
Cc: Ted Lemon; <[email-masked]>
Subject: RE: [dhcwg] IP address vs. FQDN discussion

Re-,

Please see inline. 

Cheers,
Med 

>De : Bernie Volz (volz) [mailto:[email-masked]] Envoyé : jeudi 29 
>novembre 2012 14:34 À : BOUCADAIR Mohamed OLNC/OLN Cc : Ted Lemon; 
><[email-masked]> Objet : Re: [dhcwg] IP address vs. FQDN discussion
>
>I'd like to see the draft specially recommend to use either an address 
>or fqdn if at all possible (hence not use the draft) and only use this 
>option format if there is a "hard"
>requirement for both.

OLD:

NEW:

>
>I haven't tried it but I don't think getaddrinfo allows brackets around 
>v6 addresses? Or are there some implementations that do?

>>> De : Bernie Volz (volz) [mailto:[email-masked]] Envoyé : jeudi 29 
>>> novembre 2012 00:30 À : BOUCADAIR Mohamed OLNC/OLN; Ted Lemon Cc : 
>>> <[email-masked]> Objet : RE: [dhcwg] IP address vs. FQDN discussion
>>> 
>>> I think there was some discussion that I may have been the cause of 
>>> all of this? I don't recall the particular email or discussion that 
>>> might have triggered this, but I do recall several drafts proposing 
>>> to use two options (or sub-options) - one for carrying the IPv4 
>>> address and another an FQDN - for a particular configuration 
>>> parameter. I also recall some other drafts proposing a type 
>>> enumerator followed by the data (based on the type enumerator). And, 
>>> I do recall suggesting that the DHC WG perhaps take this issue up to 
>>> provide some guidance as to what is the best practice (perhaps in 
>>> the Options Guideline document). Personally, I do not like the idea 
>>> of two options (or sub-options) and an enumeration type followed by 
>>> appropriate data seems less desirable over picking one and living 
>>> with it.
>>> 
>>> As already covered in the discussion, the problem is also not that 
>>> simple because there are many considerations - who will use the 
>>> information, how soon will it be used, who can manage the 
>>> information (using an FQDN requires that the name is in
>DNS), ...
>>> 
>>> And, perhaps this discussion will leave us where we were with no 
>>> clear answer; but perhaps more details added to 
>>> decision (I think Tomek indicated that he has an 09 pending with 
>>> more to say on this matter).
>>> 
>>> ---
>>> 
>>> BTW: draft-boucadair-dhc-address-name-encoding-02 isn't that bad as 
>>> it proposes using strings acceptable to getaddrinfo.
>>> Though I am not sure that these strings are that tightly specified.
>> 
>validation procedure to avoid errors which may be generated by blindly 
>passing a string to a name resolution library (e.g., what to do with 
>IPv4-mapped IPv6 addresses, if we allow the use of the bracket or not, 
>trailing dot mandatory or optional, etc.)
>> 
>> 
>>> result in a catch-22 (DNS server's list). And others where a FQDN is 
>>> required.
>> 
>draft-boucadair-dhc-address-name-encoding does not propose to generate 
>this format but it focuses only on the following case (see Section 3):
>>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 29 Nov 2012 16:02:25 +0000

Seems that Ted and I disagree on whether a client should validate the data. Good luck indeed!

- Bernie

---

From: <[email-masked]>
Date: Thu, 29 Nov 2012 17:12:21 +0100

Re-,

Please see inline. 

Cheers,
Med 

>Envoyé : jeudi 29 novembre 2012 16:53
>Cc : Bernie Volz (volz); <[email-masked]>

Med: Thanks.

>
>> Med: brackets are not allowed. The validation I'm talking 
>about is what the dhcp client need to do when it receives an 
>IPv6 address with bracket: does it reject the option or remove 
>the bracket and pass it to the name resolution library. 
>
>The DHCP agent decoding an option in this format MUST validate 
>the contents of the option.   If the contents are not valid, 
>the DHCP client MUST silently ignore the option.   The DHCP 
>client MUST NOT attempt to process an invalid option of this 
>type for reasons of compatibility with non-conforming 
>implementations, or for any other reason.

Med: I'm fine to add the text you proposed. I propose also to add the following:

"A Name is considered as valid if it is a legitimate UTF-8 string which does not contain any spaces nor nulls."

Is this OK with you?

---

From: <[email-masked]>
Date: Thu, 29 Nov 2012 17:14:13 +0100

Re-,

IMO, the argument raised by D. Mayer makes sense. It is worth documenting it. 

If you think any further clarification is needed to be added to the newly-added sub-section, I will be happy to integrate it into the draft. Thanks.

Cheers,
Med

>Envoyé : jeudi 29 novembre 2012 17:00
>Cc : [email-masked]; Bernie Volz (volz); <[email-masked]>
>On Nov 29, 2012, at 10:53 AM, <[email-masked]>
> wrote:
>The scenario Danny was concerned about is the situation where 
>an IP address is hard-coded into a home gateway (a real 
>problem!).   Unfortunately, using an FQDN doesn't help with 
>this problem, since the problem is that the home gateway 
>vendor didn't use DHCP in the first place to discover an NTP server.
>
>Problems of this sort are better resolved by BBF or Cablelabs 
>requirements docs.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Nov 2012 16:14:14 +0000

> I don't think DHCP clients should be in the business of validating the syntax. Whatever uses the data should just call getaddrinfo and live with whatever it returns (after all, a valid FQDN may not…

This is how bad exploitable bugs happen.   If the client isn't responsible for validation, and we can't hold the library accountable (we definitely can't!), then no piece of code is accountable.   And then you have an attack surface.   Maybe nothing bad will happen, but why take the chance when we can specify that the client does the validation?

> Servers may want to provide validation, but I'm also inclined to recommend against this -- if the administrator configures broken data, they will likely get a lot of support calls. (If the option c…

Validation on the server is a non-issue—my concern at least is that this provides an attack vector, not that it might be accidentally misconfigured.   As you say, that problem will take care of itself.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Nov 2012 16:21:01 +0000

> "A Name is considered as valid if it is a legitimate UTF-8 string which does not contain any spaces nor nulls."

No, the client needs to validate that it's either an IPv6 address or an FQDN.   The above test is certainly a good start, but it's not enough.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Nov 2012 16:23:35 +0000

>>>  service (server) in a transparent fashion.

The problem is that this text doesn't make any sense.   If the DHCP server sends an IP address, or if it sends an FQDN, it's not hard-coded.  The only case where it's hard-coded is when the application doesn't use DHCP at all.   So first of all, the person who needs to read this text isn't reading it, because they aren't doing DHCP.   And secondly, the text is incorrect.

---

From: <[email-masked]>
Date: Thu, 29 Nov 2012 17:26:30 +0100

Re-,

Here another text proposal:

   New DHCP options SHOULD use either an IP-Address or FQDN encoding for
   the data.  If there is a strong requirement to support both an IP-
   Address and FQDN encoding, the option specification MUST use the
   encoding specified in this document and MUST provide the rationale to
   motivate why either an IP-Address or FQDN encoding is insufficient.

Better?

Cheers,
Med 

>Envoyé : jeudi 29 novembre 2012 17:01
>I'd prefer to have the OLD/NEW text be revised to state that 
>new options SHOULD use either an address or FQDN encoding for 
>the data and if there is a strong requirement to support both 
>that they MUST [SHOULD?] use this encoding and provide the 
>rational for why either an address or FQDN encoding is insufficient.
>
>I don't think DHCP clients should be in the business of 
>validating the syntax. Whatever uses the data should just call 
>getaddrinfo and live with whatever it returns (after all, a 
>valid FQDN may not resolve). This also extends to checking for 
>the trailing dot on an FQDN.
>
>Servers may want to provide validation, but I'm also inclined 
>to recommend against this -- if the administrator configures 
>broken data, they will likely get a lot of support calls. (If 
>the option contained an FQDN, would we expect a server to 
>validate that the FQDN is resolvable before giving it to the 
>client? I suspect not.)
>
>- Bernie
>
>an address 
>brackets around 
>cause of 
>generate

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 29 Nov 2012 16:28:34 +0000

Yes, I do like that much better.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, November 29, 2012 11:27 AM
To: Bernie Volz (volz)
Cc: Ted Lemon; <[email-masked]>
Subject: RE: [dhcwg] IP address vs. FQDN discussion

Re-,

Better?

Cheers,
Med 

>novembre 2012 17:01 À : BOUCADAIR Mohamed OLNC/OLN Cc : Ted Lemon; 
>I'd prefer to have the OLD/NEW text be revised to state that new 
>options SHOULD use either an address or FQDN encoding for the data and 
>if there is a strong requirement to support both that they MUST 
>[SHOULD?] use this encoding and provide the rational for why either an 
>address or FQDN encoding is insufficient.
>
>I don't think DHCP clients should be in the business of validating the 
>syntax. Whatever uses the data should just call getaddrinfo and live 
>with whatever it returns (after all, a valid FQDN may not resolve). 
>This also extends to checking for the trailing dot on an FQDN.
>
>Servers may want to provide validation, but I'm also inclined to 
>recommend against this -- if the administrator configures broken data, 
>they will likely get a lot of support calls. (If the option contained 
>an FQDN, would we expect a server to validate that the FQDN is 
>resolvable before giving it to the client? I suspect not.)
>
>- Bernie
>
>Med: brackets are not allowed. The validation I'm talking about is what 
>the dhcp client need to do when it receives an
>IPv6 address with bracket: does it reject the option or remove the 
>bracket and pass it to the name resolution library.
>
>>
>>Sent from my iPad
>>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 29 Nov 2012 16:40:31 +0000

While I think the focus is on IPv6 (DHCPv6), I would hope that whatever we end up with also extends to v4 if there are new options needed there.

I'm still not convinced that validating (on the client side) is worth it.

Are you afraid that if someone sends in some string that they can trick the 'getaddrinfo' routine into doing something bad? Wouldn't other applications then be subject to this and wouldn't it be better to fix 'getaddrinfo'?

(I guess the one benefit of putting in some validation text is that the IESG might be happier to see that? But, I wonder how much that will help as probably the FQDN validation will provide minimal protection - as it requires a dot at least after every 63 characters and there is a limited character set.)

- Bernie

---

From: Danny Mayer <[email-masked]>
Date: Thu, 29 Nov 2012 11:51:18 -0500

On 11/29/2012 10:43 AM, Ted Lemon wrote:
> Yup. RFC5908 should never have been published—it never went through
last call in the DHC working group, and you did not take our advice on
how the option should work. Your successful effort to do what you want
against the considered advice of the DHC working group is the example I
give when I talk about why we need to have expert review of all DHCP
options on the way through the IESG.

There were very good reasons for this.

One reason for this for NTP was because we have had NTP server operators
change the IP address of the server to be used and the old address
continued to be hammered by clients who ignored the change.

In addition we can now have DNS specify multiple addresses for the same
FQSN and the NTP server being provisioned will then be able to be
provisioned to use all of them.

I don't know why the DHC WG wasn't doing expert review. Maybe a
discussion with Ralph Droms would be useful?

Danny

---

From: <[email-masked]>
Date: Thu, 29 Nov 2012 18:01:26 +0100

Re-,

Here is an updated text:

   o  The DHCP client decoding an option in this format MUST validate
      the contents of the option.  If the contents are not valid, the
      DHCP client MUST silently ignore the option.  The DHCP client MUST
      NOT attempt to process an invalid option of this type for reasons
      of compatibility with non-conforming implementations, or for any
      other reason.  A Name is considered as valid if:
      *  It is a legal UTF-8 string which does not contain any spaces
         nor nulls.
      *  It contains IPv4 address in dotted-decimal form (e.g.,
         192.0.2.33), textual representation of an IPv6 address (e.g.,
         2001:db8::1) [RFC2373] [RFC5952] or a domain name (e.g.,
         "myservice.example.com").  Note:
         +  The trailing dot is optional when a domain name is conveyed
            in the option.
         +  IPv4-mapped IPv6 addresses (e.g., ::fff:192.0.2.33) are
            valid IPv6 addresses.
         +  IPv6 addresses MUST NOT be enclosed in brackets.

Cheers,
Med

>Envoyé : jeudi 29 novembre 2012 17:21
>> "A Name is considered as valid if it is a legitimate UTF-8 
>string which does not contain any spaces nor nulls."
>
>No, the client needs to validate that it's either an IPv6 
>address or an FQDN.   The above test is certainly a good 
>start, but it's not enough.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Nov 2012 16:00:15 +0000

>   service (server) in a transparent fashion.

The scenario Danny was concerned about is the situation where an IP address is hard-coded into a home gateway (a real problem!).   Unfortunately, using an FQDN doesn't help with this problem, since the problem is that the home gateway vendor didn't use DHCP in the first place to discover an NTP server.

Problems of this sort are better resolved by BBF or Cablelabs requirements docs.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Nov 2012 17:30:27 +0000

> Are you afraid that if someone sends in some string that they can trick the 'getaddrinfo' routine into doing something bad? Wouldn't other applications then be subject to this and wouldn't it be be…

A better option, IMHO, would be to eliminate getaddrinfo, because it's a bad idea—the code that takes user input should decide whether the user input is an IP address or an FQDN, and then call the appropriate function.   Having a library function that gets unvalidated user data is broken, and if the user data has been validated, the validator knows whether it's an IP address or an FQDN, so there's no need for a function that can handle both. 

My concern is that some version of getaddringo somewhere will have a bug in it which can be used to trigger a buffer overflow.   If invalid data never makes it to that code, the buffer overflow will never be triggered, at least by the DHCP client.   This is not an idle concern—it's happened before in similar situations.

> (I guess the one benefit of putting in some validation text is that the IESG might be happier to see that? But, I wonder how much that will help as probably the FQDN validation will provide minimal…

The problem is that IPv6 addresses aren't valid FQDNs.   So you have to validate the address as an IPv6 address, and validate it as an FQDN.   If it passes either validation, it's okay.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Nov 2012 17:33:58 +0000

> There were very good reasons for this.

I know you believed this, and I don't fault you for it, but you never gave a plausible use case that could motivate the FQDN/IP address switch.   The use cases you mentioned in your reply just now are not plausible use cases, because the first isn't addressed by DHCP, and the second is supported by DHCP with IP addresses.

> discussion with Ralph Droms would be useful?

The discussion already happened a while back.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 29 Nov 2012 17:58:05 +0000

I wasn't saying to validate just as FQDN ... Yes, if you validation you first check for addresses (v6 and/or v4) and then for FQDN.

Sent from my iPad

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 29 Nov 2012 20:14:35 +0100

> The problem I have with this is that most of the time when people say they want both, they can't give a really good reason why they want both—they just want it.   If you ask them for use cases, the…
One good reason is that separating the management of DHCP and other
services like NTP and other servers might be very good from the
organisational point of view.
One other such separation that is in place today is the ability to use
FQDNs in host statements in DHCP.conf, one team can change things
without having to wait for the other team.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Nov 2012 19:20:25 +0000

On Nov 29, 2012, at 2:14 PM, Sten Carlsen <[email-masked]> wrote:
> One other such separation that is in place today is the ability to use FQDNs in host statements in DHCP.conf, one team can change things without having to wait for the other team.

You can already do that.   The DHCP server does the lookup instead of the client.   I don't ever put hard-coded IP addresses in the dhcp config database!   Well, except for defining address ranges and subnets, of course...

(This is a feature on every DHCP server I'm aware of.)

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 29 Nov 2012 20:35:35 +0100

> (This is a feature on every DHCP server I'm aware of.)
I was believing that the lookup only happened when the server was
started? Sending the FQDN would allow for changes without server restart
(or I misunderstood the server operation).

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Nov 2012 19:50:56 +0000

On Nov 29, 2012, at 2:35 PM, Sten Carlsen <[email-masked]> wrote:
> I was believing that the lookup only happened when the server was started? Sending the FQDN would allow for changes without server restart (or I misunderstood the server operation).

No, it happens when the DHCP client asks for a configuration.   There might be brief caching as a performance optimization that would help with frequently-used names, but it's very brief—in general implementations I've been involved in have put a lot of trust on the local caching resolver.   I think the ISC code might cache it as long as a half hour, but that's a decision that—in retrospect—I regret.   It's easy to fix if you're using the ISC server and want a shorter cache time.

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 29 Nov 2012 21:38:30 +0100

> No, it happens when the DHCP client asks for a configuration.   There might be brief caching as a performance optimization that would help with frequently-used names, but it's very brief—in general…
Ok, my other argument would be a name that has multiple IPs - only one
can be carried.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Nov 2012 20:45:18 +0000

On Nov 29, 2012, at 3:38 PM, Sten Carlsen <[email-masked]> wrote:
> Ok, my other argument would be a name that has multiple IPs - only one can be carried.

Again false.   Most DHCP options support multiple IP addresses; if the name resolves to more than one, each one is sent.   The DHCP server can also do load balancing, either by location or by reordering the response, but this is not supported by all implementations (I didn't put any code like that in the ISC server, although someone may have in the ten years since I stopped working on it!).

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 29 Nov 2012 21:48:25 +0100

> Again false.   Most DHCP options support multiple IP addresses; if the name resolves to more than one, each one is sent.   The DHCP server can also do load balancing, either by location or by reord…
Ok, thanks. I keep on learning about much anything.

Clients may not use more than the first or last IP, but that is not
going to improve by putting new text into any standard. I give upafter
two tries.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Nov 2012 20:53:42 +0000

> Ok, thanks. I keep on learning about much anything.

We're here to help!   :)

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Nov 2012 20:59:17 +0000

>         +  IPv6 addresses MUST NOT be enclosed in brackets.

No, it can't contain a dotted quad.   Otherwise everybody and his brother is going to want a DHCPv6 option with this format so they can send IPv4 addresses.   The right document to reference for IP addresses is RFC4291, section 2.2, items 1 and 2.

For domain names, you want ...   Okay, I went and looked for a good reference to use, and couldn't find one.   This is another reason why using a text string to solve this problem is a bad idea.   There is no spec I can point to and say "validate according to _that_."

The regular DNS and IDN specs don't even refer to each other in a useful way.   So in practical terms, there is little chance that a validator would successfully distinguish between the set of all valid domain names and the set of all invalid domain names.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 29 Nov 2012 22:09:27 +0000

While I think validation just gets you into more trouble ... I believe if you require this to be an ASCII formatted FQDN then I think you can validate that there are no more than 63 characters in a label and that the character set is restricted (IDNs use the ACE prefix).

RFC 3490 states:

   An "internationalized label" is a label to which the ToASCII
   operation (see section 4) can be applied without failing (with the
   UseSTD3ASCIIRules flag unset).  This implies that every ASCII label
   that satisfies the [STD13] length restriction is an internationalized
   label.  Therefore the term "internationalized label" is a
   generalization, embracing both old ASCII labels and new non-ASCII
   labels.  Although most Unicode characters can appear in
   internationalized labels, ToASCII will fail for some input strings,
   and such strings are not valid internationalized labels.

   An "internationalized domain name" (IDN) is a domain name in which
   every label is an internationalized label.  This implies that every
   ASCII domain name is an IDN (which implies that it is possible for a
   name to be an IDN without it containing any non-ASCII characters).
   This document does not attempt to define an "internationalized host
   name".  Just as has been the case with ASCII names, some DNS zone
   administrators may impose restrictions, beyond those imposed by DNS
   or IDNA, on the characters or strings that may be registered as
   labels in their zones.  Such restrictions have no impact on the
   syntax or semantics of DNS protocol messages; a query for a name that
   matches no records will yield the same response regardless of the
   reason why it is not in the zone.  Clients issuing queries or
   interpreting responses cannot be assumed to have any knowledge of
   zone-specific restrictions or conventions.

...

   To allow internationalized labels to be handled by existing
   applications, IDNA uses an "ACE label" (ACE stands for ASCII
   Compatible Encoding).  An ACE label is an internationalized label
   that can be rendered in ASCII and is equivalent to an
   internationalized label that cannot be rendered in ASCII.  Given any
   internationalized label that cannot be rendered in ASCII, the ToASCII
   operation will convert it to an equivalent ACE label (whereas an
   ASCII label will be left unaltered by ToASCII).  ACE labels are
   unsuitable for display to users.  The ToUnicode operation will
   convert any label to an equivalent non-ACE label.  In fact, an ACE
   label is formally defined to be any label that the ToUnicode
   operation would alter (whereas non-ACE labels are left unaltered by
   ToUnicode).  Every ACE label begins with the ACE prefix specified in
   section 5.  The ToASCII and ToUnicode operations are specified in
   section 4.

- Bernie

---

From: Danny Mayer <[email-masked]>
Date: Thu, 29 Nov 2012 22:11:26 -0500

On 11/29/2012 12:33 PM, Ted Lemon wrote:
> I know you believed this, and I don't fault you for it, but you
> never
gave a plausible use case that could motivate the FQDN/IP address
switch. The use cases you mentioned in your reply just now are not
plausible use cases, because the first isn't addressed by DHCP, and the
second is supported by DHCP with IP addresses.

Among other things with a FQDN new versions of NTP will requery for IP
addresses if a given address is not responding. You cannot do that if
you just have an IP address. We WANT people to use FQDN's and not IP
addresses to give NTP flexibility.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Thu, 29 Nov 2012 22:14:06 -0500

> going to improve by putting new text into any standard. I give upafter

NTP will use all addresses it can get up to 10 if you use the pool
option but it can only do that with FQDN addresses.

Danny

---

From: <[email-masked]>
Date: Fri, 30 Nov 2012 08:31:23 +0100

Hi Ted,

Please see inline.

Cheers,
Med 

>Envoyé : jeudi 29 novembre 2012 21:59
>No, it can't contain a dotted quad.   Otherwise everybody and 
>his brother is going to want a DHCPv6 option with this format 
>so they can send IPv4 addresses. 

Med: The rationale why I wanted to allow for this is:

(1) Does dhc forbid resolving an FQDN returned in DHCPv6 to an IPv4 address?: No
(2) Since draft-boucadair-* allows a server to resolve an FQDN and then return the result in the proposed option, an ipv4-mapped IPv6 address may be needed to encode the resolved IPv4@
(3) A service can be dual stack: returning both IPv6 and IPv4-mapped IPv6 addresses in one single dhcpv6 option would be appropriate. 

  The right document to 
>reference for IP addresses is RFC4291, section 2.2, items 1 and 2.
>
>For domain names, you want ...   Okay, I went and looked for a 
>good reference to use, and couldn't find one.   This is 
>another reason why using a text string to solve this problem 
>is a bad idea.   There is no spec I can point to and say 
>"validate according to _that_."
>
>The regular DNS and IDN specs don't even refer to each other 
>in a useful way.   So in practical terms, there is little 
>chance that a validator would successfully distinguish between 
>the set of all valid domain names and the set of all invalid 
>domain names.

Med: What about adding a reference to http://tools.ietf.org/html/rfc2181#section-11? In particular:

"The DNS itself places only one restriction on the particular labels
   that can be used to identify resource records.  That one restriction
   relates to the length of the label and the full name.  The length of
   any one label is limited to between 1 and 63 octets.  A full domain
   name is limited to 255 octets (including the separators)."

I'm fine to add this kind of validation text but requiring more than that is not justified IMHO. The name resolution library will have to enforce its validation procedure anyway. If there is an attack vector against the name resolution library, adding more validation at the dhcp client does not mitigate the (claimed) issue as there are other means to force invoking it (embed it in a webpage). We should not forget also dhcp server are required to be configured to return valid names; otherwise access to the service will fail.

---

From: <[email-masked]>
Date: Fri, 30 Nov 2012 08:33:53 +0100

Dear Sten,

This is indeed a valid point.

The draft discusses this point here: http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-02#section-2.2.2

If you think your point is not well-covered in that text, please let me know so that I can cover your point.

Cheers,
Med

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Sten Carlsen
Envoyé : jeudi 29 novembre 2012 20:15
À : [email-masked]
Objet : Re: [dhcwg] IP address vs. FQDN discussion

On Nov 29, 2012, at 2:40 AM, [email-masked]<mailto:[email-masked]> wrote:

The problem I have with this is that most of the time when people say they want both, they can't give a really good reason why they want both-they just want it.   If you ask them for use cases, they can't come up with any.

One good reason is that separating the management of DHCP and other services like NTP and other servers might be very good from the organisational point of view.
One other such separation that is in place today is the ability to use FQDNs in host statements in DHCP.conf, one team can change things without having to wait for the other team.

In addition, any option that did use FQDN+IP address should be REQUIRED to implement both FQDN and IP address.   But I'm sure you see the problem with this-implementors often take MUST as advisory when it requires something they don't want to have to code, like a DNS resolver.   So if you have an option that uses FQDN+IP, you can count on seeing serious interoperability problems in the field.

--
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: <[email-masked]>
Date: Fri, 30 Nov 2012 08:38:43 +0100

Ted,

This is indeed an approach (captured here: http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-02#section-2.1.1) but you may understand this is not acceptable for all contexts/operators (for various reasons including operational, network/service separation reasons, dedicated dns infrastructure per service, etc.). 

Cheers,
Med 

>Envoyé : jeudi 29 novembre 2012 20:20
>À : Sten Carlsen
>Cc : <[email-masked]>
>> One other such separation that is in place today is the 
>ability to use FQDNs in host statements in DHCP.conf, one team 
>can change things without having to wait for the other team.
>
>You can already do that.   The DHCP server does the lookup 
>instead of the client.   I don't ever put hard-coded IP 
>addresses in the dhcp config database!   Well, except for 
>defining address ranges and subnets, of course...
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 30 Nov 2012 10:04:28 +0100

Hi,

> I think there was some discussion that I may have been the cause of all of this? I don't recall the particular email or discussion that might have triggered this, but I do recall several drafts pro…

+25. 

Fewer deployment choices are always better for interoperability. 
Perhaps some discussion around how to choose would be useful.  For
isntance, domain names are useful when you want to push evaluation to
the client, particularly when DNS  TTL semantics may not match those of
DHCP.  However, that can lead to an inconsistent model, where the
manager of the server thinks the client is configured with one address,
when it fact is configured with another.  Some of this discussion might
be helpful to some in making the appropriate decision, in order to help
them make a choice in the protocol, and not at deployment.

However...

If you can't pick one, then I would argue that enumerated typing is best
simply because it makes the parser simpler overall.  Also, there are a
number of specifications out there relating to domain names in
particular that might make it hard to provide general advice.  1035 has
a specification.  So do 5321 and 5322.  If we borrowed from 5321, SRV
domains could not be transported (to give an example).  That may be
appropriate if the option has something to do with mail.  On the other
hand, if we're talking about a SIP server, SRV names are necessary.  
Context will matter.

Eliot

---

From: Bud Millwood <[email-masked]>
Date: Fri, 30 Nov 2012 10:42:35 +0100

> While I think the focus is on IPv6 (DHCPv6), I would hope that whatever we end up with also extends to v4 if there are new options needed there.

I believe people will take the path of least resistance, choosing the
proposed format for their option because it's too hard to think
through whether the option really should be one format or the other.
Furthermore, I think they'll justify this proposed format with the
vague notion that "someone might need FQDN | IP address".

And I doubt the rest of us will get much better at double checking the
nature of proposed options - we're all busy - and the likely outcome
is that this proposed format will become the de-facto standard.

Bernie, my initial concern was that this format uses more space than
the IP address format, and using the format could result in not having
the option in a DHCPv4 response packets at all.

- Bud

---

From: Sten Carlsen <[email-masked]>
Date: Fri, 30 Nov 2012 11:34:31 +0100

Hi

As far as I can read this text is concerned about separating
organisational levels in the same service, I was thinking about a
slightly different situation.

I see dhcp as a delivery vehicle for several different services ntp is
one example, DNS is another. I believe there are many places where each
service has its own maintenance crew, what I suggest is to allow for as
much separation of the people looking after one service from the people
looking after another service as possible. One possible way is IMHO to
allow FQDNs to be passed. I also see that some clients may not be large
enough to handle FQDNs.

As the client includes a list of options it wants, this might be solved
by having FQDNs in one option and IPs in a different one, that way a
client can ask for what it can handle. Surely there are other
disadvantages to this.

On 30/11/12 8:33, [email-masked] wrote:
> The draft discusses this point here:
> http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-02#section-2.2.2
>  
>     ------------------------------------------------------------------------
>     *De :* [email-masked] [mailto:[email-masked]] *De
>     la part de* Sten Carlsen
>     *Envoyé :* jeudi 29 novembre 2012 20:15
>     *À :* [email-masked]
>     *Objet :* Re: [dhcwg] IP address vs. FQDN discussion
>
>
>>     The problem I have with this is that most of the time when people say they want both, they can't give a really good reason why they want both---they just want it.   If you ask them for use cases, they can't come up with any.
>     One good reason is that separating the management of DHCP and
>     other services like NTP and other servers might be very good from
>     the organisational point of view.
>     One other such separation that is in place today is the ability to
>     use FQDNs in host statements in DHCP.conf, one team can change
>     things without having to wait for the other team.
>>     In addition, any option that did use FQDN+IP address should be REQUIRED to implement both FQDN and IP address.   But I'm sure you see the problem with this---implementors often take MUST as advisory when it requires something they don't want to have to code, like a DNS resolver.   So if you have an option that uses FQDN+IP, you can count on seeing serious interoperability problems in the field.
>>

-- 
Best regards

Sten Carlsen

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Nov 2012 14:07:24 +0000

> addresses to give NTP flexibility.

Yes, that was one of the other use cases you presented, but when asked, you didn't say whether any implementations actually did this, nor whether any implementations would even take an update from the DHCP client when the lease was renewed.  In general, the existing DHCP solution of providing more than one IP address so that the client can alternate in the case of an outage, and the process of renewing leases, should adequately address this use case.

My experience has been that when people offer this use case and I ask them for an example of an implementation that does this, the response is "um, uh, let me get back to you."   I would be more convinced if the response was to tell me about a specific implementation that had some chance of seeing widespread deployment.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Nov 2012 14:08:15 +0000

> option but it can only do that with FQDN addresses.

So you can't give it a list of ten IP addresses, but you can give it an FQDN?   If true, this is simply an implementation bug, and requires no protocol action to correct.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Nov 2012 14:41:20 +0000

On Nov 30, 2012, at 4:04 AM, Eliot Lear <[email-masked]> wrote:
> simply because it makes the parser simpler overall. 

+1

(But really, there need to be motivating use cases, not just a personal preference on the part of the author.)

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Nov 2012 14:43:04 +0000

On Nov 30, 2012, at 5:34 AM, Sten Carlsen <[email-masked]> wrote:
> As the client includes a list of options it wants, this might be solved by having FQDNs in one option and IPs in a different one, that way a client can ask for what it can handle. Surely there are other disadvantages to this.

Now the client has to request both, just in case only one is configured on the server, and the server has to be configured with both, in case the client only supports one.   So you've made the problem worse, not better.   We've trod this ground several times before... :}

---

From: Danny Mayer <[email-masked]>
Date: Fri, 30 Nov 2012 12:19:56 -0500

On 11/30/2012 9:07 AM, Ted Lemon wrote:
> Yes, that was one of the other use cases you presented, but when
asked, you didn't say whether any implementations actually did this, nor
whether any implementations would even take an update from the DHCP
client when the lease was renewed. In general, the existing DHCP
solution of providing more than one IP address so that the client can
alternate in the case of an outage, and the process of renewing leases,
should adequately address this use case.
> 
> My experience has been that when people offer this use case and I
> ask
them for an example of an implementation that does this, the response is
"um, uh, let me get back to you." I would be more convinced if the
response was to tell me about a specific implementation that had some
chance of seeing widespread deployment.

The current reference implementation of NTP has it.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Fri, 30 Nov 2012 12:25:42 -0500

On 11/30/2012 9:08 AM, Ted Lemon wrote:
> So you can't give it a list of ten IP addresses, but you can give it
an FQDN? If true, this is simply an implementation bug, and requires no
protocol action to correct.

No that's not true and an assumption on your part. The pool option is an
implementation design and not a protocol issue. If you use the pool DNS
servers (pool.ntp.org) you will get a different list of addresses every
time you ask. Failure of one address will cause it to go out and find
new addresses.

Danny