Subject: Re: [dhcwg] Call for adoption: draft-boucadair-dhc-address-name-encoding-03

From: <[email-masked]>
Date: Tue, 4 Dec 2012 10:38:07 +0100

Seeing that there are different standards (upcoming) for coding server information in DHCP(v6) messages (FQDN e.g. for AFTR, IP address e.g. for TSV) I would like to have a solution that gives this decision to the one who operates the network. That's why I would like to see this I-D discussed and  adopted within this WG.

Kind regards
	Olaf

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von [email-masked]
Gesendet: Freitag, 30. November 2012 16:23
An: Ted Lemon; [email-masked] WG
Betreff: Re: [dhcwg] Call for adoption: draft-boucadair-dhc-address-name-encoding-03

Re-

FWIW, the latest version of the draft is available here: http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-03

As this is a call for adoption, I would avoid answering the message below from Ted.

Unlike Ted, I strongly support the WG adopting this alternative encoding scheme which is restricted to the following scope: deployment context where both an IP address and FQDN are needed. The proposed approach requires new options to justify why an IP-Address only or FQDN-only option does not meet their requirement. 

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part 
>de Ted Lemon Envoyé : vendredi 30 novembre 2012 16:14 À : 
>[email-masked] WG Objet : Re: [dhcwg] Call for adoption:
>draft-boucadair-dhc-address-name-encoding-03
>
>My response to this call for adoption, wearing my working group 
>participant hat, not my working group chair hat, is that I strongly 
>oppose adoption of this work.
>
>A number of arguments have been raised in favor of doing this work, and 
>I've attempted to state my considered opinion on them below:
>
>The DHC working group long ago decided not to put dual-stack 
>transition technology into DHCPv6.   So if the motivation for 
>using an FQDN is dual-stack transition, this is not a good 
>argument.   And if the motivation for using a text 
>representation of an IPv6 address is dual-stack transition, again this 
>is not a good argument.
>
>Similarly, the argument has been made that the FQDN+IP option format is 
>necessary to support certain deployment strategies that are already 
>adequately addressed by existing technology.
> This again is not a good argument-if the existing standards already 
>support the functionality that is needed, then there is no need to 
>extend the standards.
>
>A specific use case has been raised where the same domain name returns 
>different results (that is to say, completely different sets of 
>addresses) depending on the location from
>which the query is done.   And that we have to extend DHCPv6 
>to support this use case.   But this isn't a valid use case at 
>all, because standards-compliant DNS does not return 
>completely different values depending on location.   If it 
>did, this would break all kinds of things-DNSSEC, tunnels, 
>standards-compliant local caching servers.
>
>I know that this sort of thing is done all the time in CDNs, but the 
>fact that people do it in the wild is not a reason to put it in an IETF 
>standard.
>
>With regard to validation, the author referred to RFC2181, 
>which says the content of labels is not restricted.   But this 
>doesn't help, because we are not talking about the content of labels-we 
>are talking about a human-readable presentation of the content of 
>labels, with an undefined transform between the
>one and the other.   No document defines this transformation.  
> This is why we chose to use the wire-format representation for FQDNs 
>in DHCP.
>
>So the bottom line is that there are a lot of really weak 
>arguments for adding this complexity to DHCP.   But this 
>proposal adds significant complexity.   I spent an hour 
>yesterday doing a fairly thorough review of the existing documents that 
>talk about the text representation for DNS, and was unable to identify 
>a document that specifies how to validate the text representation of a 
>domain name, although many different documents talk about aspects of 
>how domain names are represented as text.
>
>So this proposal adds a very real attack surface to any service that 
>uses this option format.  There's no standard for validation that, if 
>followed, would eliminate that attack surface.  And there's no 
>compelling use case to motivate adding it.
>
>This is why I do not support this work.
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg
>
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Dec 2012 13:19:26 +0000

> Seeing that there are different standards (upcoming) for coding server information in DHCP(v6) messages (FQDN e.g. for AFTR, IP address e.g. for TSV) I would like to have a solution that gives this…

Olaf, as I said in the CFA message, the question before the working group is not whether we would like an option to send either FQDN or IP address.   The question is whether we would like to do it in the way that Med proposes.   There is already a way to do it, which the NTP option uses.   Med's proposal is to do it using a text string rather than a clearly defined format.

So I'll take it that you are in favor of having some way of allowing the operator to choose; could you tell me whether you specifically prefer Med's proposal and want it adopted, or whether you just want *some* proposal to be adopted?

---

From: <[email-masked]>
Date: Tue, 4 Dec 2012 15:17:16 +0100

I personally like the approach of a providing a string that can be passed directy to to the getaddrinfo. (As described by Med's I-D.)