Subject: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00

From: Andrew Sullivan <[email-masked]>
Date: Tue, 30 Aug 2011 12:21:34 -0400

Dear authors of draft-vandergaast-edns-client-subnet-00:

The site http://www.afasterinternet.com came to our attention.

It appears to us that you are undertaking a trial deployment of
draft-vandergaast-edns-client-subnet-00, and that you are soliciting
people to participate in the client portion of this trial.  We think
this is, in effect, a limited public trial on the public Internet.

We would like to urge you, very strongly, to obtain an actual EDNS0
option code assignment from IANA prior to proceeding with this trial.
By failing to obtain such a code, and by releasing your software to
the Internet, you are potentially polluting the EDNS0 option code
space.

We are aware of the obstacles to obtaining such an option code, but we
believe that the benefits of a faster Internet, which you are avowedly
attempting to deliver, will only really be benefits if they don't
break others' software, either now or in the future.  By using a
completely unassigned option code, as you must be doing, you are
risking colliding with another assignment.

In order to obtain the option code, all that is needed is an RFC to be
published.  We stand ready and willing to help you pursue that
publication, particularly since you intend your protocol to be
experimental.  

Best regards,

Andrew and Olafur
(co-chairs of the DNSEXT working group, but speaking only for ourselves.)

-- 
Andrew Sullivan
[email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Wilmer van der Gaast <[email-masked]>
Date: Tue, 30 Aug 2011 22:10:01 +0100

> this is, in effect, a limited public trial on the public Internet.
It's not really a public trial on the public Internet. It's merely a
group of open resolvers and a few CDNs who all implemented support for
edns-client-subnet in their systems and start to use it amongst just
each other. The resolvers use a whitelist to make sure the option only
goes to nameservers that expect it.

Our goal here, speaking as the authors of the I-D, is to get some
real-world numbers on how effective edns-client-subnet really is.
Unfortunately my memories of our conversation at IETF78 (Maastricht)
are pretty vague by now, but IIRC there was some interest for these
numbers.

Unfortunately we got sidetracked by our day jobs and didn't have much
time to work on this data or the I-D in general - but do intend to
allocate more time for it over the next months.

> break others' software, either now or in the future.

I fully agree. By picking 0x50fa instead of a lower value (it looks
like so far EDNS0 options are assigned sequentially) we certainly
tried to avoid any problems of this kind. Our plan was to use this
temporary option code just to gather data, and with that and a
published experimental RFC, get an official number from IANA. Not at
any time did we intend to sidestep the IETF process. Apologies if we
gave that impression.

Our latest I-D <http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-00>
has just expired and we have no updates to it. Also there has been
very little (none, from what I can remember) discussion on dnsext
about it. We welcome any help you can offer to make this I-D suitable
for publication on the experimental track.

Kind regards,

Wilmer van der Gaast,
Carlo Contavalli.

---

From: Alex Bligh <[email-masked]>
Date: Tue, 30 Aug 2011 22:52:41 +0100

--On 30 August 2011 22:10:01 +0100 Wilmer van der Gaast <[email-masked]> 
wrote:

> Our latest I-D
> <http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-00> has
> just expired and we have no updates to it. Also there has been very
> little (none, from what I can remember) discussion on dnsext about it. We
> welcome any help you can offer to make this I-D suitable for publication
> on the experimental track.

Is this substantially different from draft-vandergast-client-ip-01 which
had 239 messages on it? Hardly no discussion. I suspect the reason why
there has been no discussion of draft-vandergast-client-subnet-00 is
because it hasn't (at least according to my archive) ever been announced
on dnsext.

-- 
Alex Bligh

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 30 Aug 2011 15:14:32 -0700

http://www.ietf.org/mail-archive/web/dnsext/current/msg10563.html

-- 
Colm

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 30 Aug 2011 23:12:57 -0400

Hi Wilmer,

Thanks for your reply.  A couple remarks below.  I have not passed
this by Olafur, and as before, I am _not_ speaking in any official
capacity.

> goes to nameservers that expect it.

When you initially suggested you wanted to do some experiments, I took
that to mean that you were going to do some things in a lab.  Because
of the way EDNS0 code points are assigned, I recognized that it would
likely be better if you did things in your lab beforehand.  That was
why I told you that, while it would probably be a little tricky to get
a code point at that early stage, if you ran an experiment with some
code that used a code point clearly not about to be allocated, it was
probably safe enough for those purposes.

What the pages I already cited say, however, is not that you're doing
something in a lab, but that you're doing it on the Internet --
between consenting adults, sure, but on the public Internet
nevertheless.

By using an unassigned code point this way, you run two risks:

    1.  Some of the client code that gets used for this hangs around,
    and continues to set that EDNS0 option.  If the option code point
    gets assigned later, and to something else, you end up setting an
    option that doesn't do what you think it does (and you don't
    behave as a server receiving such an option would expect you to).

    2.  Some server code that gets used for this test hangs around,
    and continues to respond to that EDNS0 option.  This is basically
    the complement of the above case.  It's just as bad.

> any time did we intend to sidestep the IETF process. Apologies if we

I actually don't care about the IETF process.  What I do care about is
the potential for interoperability headaches later because of
undocumented collisions in EDNS0 option code interpretation.  Avoiding
that sort of headache is the exact reason we have a registry.  

Best regards,

A

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 30 Aug 2011 20:23:51 -0700

> that sort of headache is the exact reason we have a registry.

How would you feel about proposing more relaxed registry criteria to
IANA (by way of an RFC), similar to how the ports registry works?

EDNS0 option codes don't appear to be in much demand, so exhaustion
isn't as much of a concern.

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 30 Aug 2011 20:47:06 -0700

> that sort of headache is the exact reason we have a registry.

I suggested in April 2010 that part of the EDNS0 option code space be
reserved for private use, but it received very little feedback
(positive response from Colm MacCárthaigh, slightly negative from Paul
Vixie, and some meta discussion about how strictly IANA follows its
instructions on allocating numbers):

http://www.ietf.org/mail-archive/web/dnsext/current/msg07768.html
http://tools.ietf.org/html/draft-dempsky-edns0-options-for-private-use-00

Reserving a code point for public (i.e., general, unnegotiated) use
doesn't make sense until the protocol has solidified.  For a private
test (even a large scale one conducted across the Internet between
multiple organizations), it seems appropriate to use a private use
code so long as the participants have agreed a priori what the code
means in transactions between their DNS servers.

I don't see anything wrong with (e.g.) privately negotiating to use
65300 to mean draft-vandergaast-edns-client-subnet-00 when querying
Google's DNS servers but to then mean draft-xxx-something-else when
querying someone else's.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 31 Aug 2011 00:01:58 -0400

> http://tools.ietf.org/html/draft-dempsky-edns0-options-for-private-use-00

From the peanut gallery, having a private use range seems like a
no-brainer.  What is Paul suggesting: don't test EDNS0 options at all
before publishing the RFC?

-- 
Matt

---

From: Alex Bligh <[email-masked]>
Date: Wed, 31 Aug 2011 07:23:55 +0100

> http://www.ietf.org/mail-archive/web/dnsext/current/msg10563.html

Apologies - I searched for draft-vandergaast-edns-client-subnet-00 (i.e.
with the 'draft-'.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 31 Aug 2011 07:25:39 +0100

--On 31 August 2011 00:01:58 -0400 Matt McCutchen <[email-masked]> 
wrote:

> no-brainer.

+1

---

From: Jim Reid <[email-masked]>
Date: Wed, 31 Aug 2011 08:41:03 +0100

> IANA (by way of an RFC), similar to how the ports registry works?

Sounds like a good idea.

> isn't as much of a concern.

A process comparable to the one for RRtype code assignment could take  
care of this. The expert review would provide a sanity check and rate  
limiter in case we started burning through EDNS option codes. What if  
marketroids were to decide these are more valuable for vanity purposes  
than new gTLDs?

It's a pity RFC6195 didn't ring-fence some of the EDNS OPT code (and  
Extended RCODE?) number space for private use and/or experiments just  
like it did for the RRtype, CLASS and RCODE spaces.

---

From: SM <[email-masked]>
Date: Wed, 31 Aug 2011 00:15:22 -0700

Hi Wilmer,
>published experimental RFC, get an official number from IANA. Not at

You are running a trial over the Internet.  Someone out there will 
think that it is a good idea and write some code for it.  Such code 
generally lingers around for some time.

The above qualifies as an experiment and there was a time when it was 
documented through an Experimental RFC.  The code point was part of 
the book-keeping, i.e. the person is going to run the experiment no 
matter what and it is better to have a record of that code point 
being in use.  The number from IANA does not mean that the experiment 
or even proposed standard specification is a good idea.

Assuming that the assignment of code points is always sequential 
encourages "counter-measures" such as non-sequential assignments to 
make life difficult for people who make such assumptions.  There was 
a time when conventional wisdom was that the world would not run out 
of 32-bit numbers.  Some people looked at the way the assignments 
were made and decided that 1.1.1.1 could be used safely.

If it takes an Experimental RFC (published) to get that number, it is 
up to the IETF to see it wants to make it difficult for you to get 
it.  I doubt that people would refrain from using the technology if 
it makes an "Internet" faster.

Regards,
-sm

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 31 Aug 2011 07:47:28 -0400

> IANA (by way of an RFC), similar to how the ports registry works?

In my personal, no-hat opinion, the registry rule could be made
first-come, first-served until (say) 50% of the code space was used
up.  I see no reason not to do this.

The current edns0-bis draft actually moves things in the opposite
direction: whereas now the rule is RFC Required, the current draft
makes things Standards Action.  In my opinion (again no hat), this is
the wrong direction to be moving.

> isn't as much of a concern.

Right.  And we could solve that worry by making the relaxed rule
automatically tighten after a certain number of the codes are gone
anyway, just the way we did for the DNSSEC algorithm numbers.

A

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 31 Aug 2011 12:39:21 +0000

There's always a registration path similar to ENUMservices, a la RFC 6117.
This allows for both an RFC-published path and non-RFC path to
registration. http://tools.ietf.org/html/rfc6117

Jason

---

From: Wilmer van der Gaast <[email-masked]>
Date: Wed, 31 Aug 2011 14:43:59 +0100

+1

> the wrong direction to be moving.
Which draft are you reading here exactly? It's entirely possible that
I'm misreading, but
http://tools.ietf.org/html/draft-ietf-dnsext-rfc2671bis-edns0-05#section-9
seems to say Standards Action is required for:

* new RCODEs
* new EDNS0 flags
* new EDNSx versions

For a new option code, only expert review will be required: "Expert
Review is required for allocation of an EDNS Option Code."

I'm also definitely in favour of the private-range idea. If for
example 0xff00-0xff7f could be reserved for experiments, I'll happily
get everyone on the edns-client-subnet experiment to switch. I'm even
willing to leave out backward compatibility on our end to encourage
switching ASAP. :-)

Cheers,

-- 
Wilmer van der Gaast, Traffic SRE/Google Public DNS team.
Google Ireland.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Wilmer van der Gaast <[email-masked]>
Date: Wed, 31 Aug 2011 15:18:40 +0100

Hello Jaidev,

2011/8/31 Jaidev Sridhar <[email-masked]>:
>
> Reading through the draft, I have a question about the NAT section which
> says:
> [..]

I just realised, after looking through our revision history, that we
haven't made any changes to the NAT section since edns-client-ip-00
(i.e. January 2010). Since then we have made some changes to
transitive behaviour so there are definitely some contradictions to be
found here.

The original purpose of the section was to sum up some things that may
seem clever but should not be done.

> I understand why one wouldn't want NAT devices to change a client subnet
> address (testing, anonymizer, etc.) but why does the draft say a NAT
> device _MUST_ not add a client subnet option?
>
I think the original idea here was "the recursive resolver will, if it
wants, add an edns-client-subnet option using the source IP it sees"
-=> there should be no need for a NAT device to do it, and generally I
do still think a NAT device shouldn't try to be smarter than
necessary.

>   Note that Authoritative Nameservers or Recursive Resolvers can still
>   provide an optimized reply by looking at the source IP of the query.
>
> When the recursive resolver is behind NAT, the authoritative nameserver
> will only know the address of the NAT device, which will not be useful
> for geo-location at all with big-bad-NATs.
>
> Any reason for NAT being excluded this way?
>
See the explanation above. Thank you for your reminder here, not
updating the NAt section at all was definitely an oversight, we'll
rewrite it for edns-client-subnet-01.

The big-bad-NAT use case is also not a scenario we thought of so far.
It's also a pretty hard one to support without putting a lot of
additional intelligence into resolvers (i.e. a mapping of internal IP
addresses to their external equivalents). I'd like to know if any
implementor is actually willing to implement that.

Cheers,

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 31 Aug 2011 10:25:58 -0400

On Wed, Aug 31, 2011 at 02:43:59PM +0100, Wilmer van der Gaast wrote:

> Which draft are you reading here exactly? 

> Review is required for allocation of an EDNS Option Code."

Oh, phew, and stupid me.  I was really really surprised when I
(thought I) saw what I did when I checked it earlier.  That'll teach
me to do such readings in a hurry.

You're quite right.  And (again no hat) expert review is, IMO, better
than RFC required, but I'd still prefer FCFS.

A

---

From: Wilmer van der Gaast <[email-masked]>
Date: Wed, 31 Aug 2011 15:57:55 +0100

> than RFC required, but I'd still prefer FCFS.
Agreed.

However, we're still quoting an I-D here and not an RFC. I assume we
need this draft published before the policy can be followed. (But
please do correct me if I'm wrong.) From the last discussion about it
(May 2011) it looks to me like the author is still working on a -06 so
we're not there yet.

Which means that for now edns-client-subnet needs to be published as
an experimental RFC, which I assume can't be done in just a few
weeks.. We really would like to proceed with the experiment because we
need to collect data to decide if edns-client-subnet is worth
implementing. This can't be done in a closed lab.

By the way, I noticed not all EDNS0 option codes on
http://www.iana.org/assignments/dns-parameters have RFC numbers behind
them. Under what condition were these option codes assigned, and would
it be possible to assign one to edns-client-subnet under similar
conditions?

Cheers,

---

From: Ted Hardie <[email-masked]>
Date: Wed, 31 Aug 2011 09:00:07 -0700

> than RFC required, but I'd still prefer FCFS.

I think FCFS works fine for unbounded spaces, but I'm nervous about
a blended model where there are easy registrations up until exhaustion
looks likely, then
it gets restricted.  We have lots of evidence that this causes grumpiness
in the IP allocation side of the house. Expert review, with clear
instructions to reviewer
(e.g. that this is not duplicate functionality) seems more likely to
get what you want.

The trick is in the clear instructions to the reviewer, especially
when the reviewer
is actually a list with changing membership....

regards,

TEd

---

From: Ted Hardie <[email-masked]>
Date: Wed, 31 Aug 2011 09:03:34 -0700

As a question to the chairs, the new draft is kind enough to list the
changes since the previous version, and one of the authors previously
summarized this to the list as:

* Rewrote origination sections to clarify that normally only recursive
resolvers generate edns-client-subnet options.
* Discussion on whitelisting or automatically detecting if an
authority supports edns-client-subnet.
* More precisely specifying (optional) transitive behaviour.
* Minor revisions to improve clarity and correctness w.r.t. other RFCs.

None of these changes seem to address the balance of discussion of the
previous two versions.  Do the chairs intend to open this for full discussion
again, or is it your opinion that the code point allocation in an Experimental
RFC does not need to address these issues?

regards,

Ted Hardie

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 31 Aug 2011 12:27:45 -0400

> (May 2011) it looks to me like the author is still working on a -06 so

Exactly correct.

> weeks.

Probably not a few weeks, no.

> it be possible to assign one to edns-client-subnet under similar

Yes.  I have no idea how those were assigned, but when I asked IANA
about it they said they have to follow the rule.  Perhaps previous
IANA administration had a different approach or something; I don't
know.

A

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 31 Aug 2011 13:30:43 -0400

> RFC does not need to address these issues?

Olafur and I consulted over this, and here is our opinion as chairs.
Note that we've been wrong before.

As a pure matter of the rules, it is our opinion that the code point
allocation does not need to address any objections to the idea.  The
rule is only "RFC Required".  An Experimental track RFC is an RFC, and
therefore it would qualify.  One might take issue with the experiment
itself, and one might take issue with what the experiment is
attempting to prove, but none of that would be reason to refuse to
publish the RFC nor to deny the allocation of a code point.

So, any RFC will do.  Even an RFC that simply says, "IANA
considerations: IANA allocate EDNS0 option NETMASK code TBD.  The
option is a text string of one of the following formats:
'IP4_addr/mask' or 'IPv6_addr/mask'", along with perhaps a section
that says by way of introduction, "This document specifies the NETMASK
EDNS0 option, but does not specify its use."

Taking my hat off, I note that, if this opinion is correct, RFC
Required appears to become a lower bar than Expert Review.  I am not
sure that the IESG would agree with our interpretation, therefore.

A

---

From: Ted Hardie <[email-masked]>
Date: Wed, 31 Aug 2011 11:23:17 -0700

> sure that the IESG would agree with our interpretation, therefore.

Traditionally expert review has been a lower bar than RFC required
because you have to convince someone that it's a good idea to publish
the RFC (The independent stream editor, some working group, some AD).
That's not been trivial, and it usual comes with questions about the
track.  An experimental RFC, for example, might be tasked with
describing the experiment and what results would constitute success.
I can't really see the internet-draft text you cite above passing IETF
last call without a few questions.  We have seen some docs where the
registration document is recognition of a de facto use that is being
codified to avoid collision, but even those describe what's going on.
Doing that too often with code points that aren't unlimited has, of
course, obvious failure conditions.

You and Olafur previously said (as individuals)  "We stand ready and
willing to help
you pursue that publication, particularly since you intend your
protocol to be experimental.".
Since this was evidently not through the working group, did you intend
AD sponsorship or an
independent stream submission?

regards,

Ted Hardie

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 31 Aug 2011 14:51:07 -0400

> describing the experiment and what results would constitute success.

Right.

> independent stream submission?

I can't speak for Olafur, but I am prepared to do whatever the authors
want.  To my mind, it is considerably more valuable that we have
stable documentation of the use of this option code than it is that we
do things in this or that way.  To me, if the experiment goes ahead as
is currently planned, we have to mark the option code as used anyway.

A

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 01 Sep 2011 04:21:37 +0900

>> for geo-location at all with big-bad-NATs.

Wrong.

NAT, in this case, is only as bad as a DHCP server with a large
number of clients, addresses of which are assigned randomly
and dynamically.

It is dynamic assignment of addresses or addresses and port
numbers which makes geo-location (and address based black
listing) not very useful.

NAT with fixed port forwarding is fine, as long as geo-location
is based on not only addresses but also port numbers.

The problem of NAT against client-subnet option is that DNS
messages with strange options may be destroyed on some
implementations of NAT.

					Masataka Ohta

---

From: Alex Bligh <[email-masked]>
Date: Wed, 31 Aug 2011 23:08:47 +0100

> sure that the IESG would agree with our interpretation, therefore.

Concentrating on the practical results of our deliberations rather than the
way we got there, and speaking as someone who is sceptical about the draft
in question, it seems to me that it would be a bad thing if a draft like
this (which whilst I might not like it, is certainly not entirely
speculative) neither can get a RFC1918-style allocation, nor relatively
easily achieve a 'proper' allocation; it's only going to encourage people
to self-allocate, and we are hardly short of code points.

Given there has to be some hurdle to getting a real allocation, I think
we should do both - assigning 256 code points to RFC1918-style use (i.e.
'beware - your number may clash with other RFC1918-style stuff but won't
clash with a real allocation') seems to me a no-brainer.