Subject: Re: Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice

From: S Moonesamy <[email-masked]>
Date: Wed, 21 May 2014 22:23:13 -0700

At 13:42 20-05-2014, The IESG wrote:
>The IESG has received a request from the Internet Architecture Board
>(iab) to consider the following document:
>
>- 'DNS Root Name Service Protocol and Deployment Requirements'
>   <draft-iab-2870bis-01.txt> as Best Current Practice
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2014-06-20. Exceptionally, comments may be

In Section 1:

   "The operational requirements are defined in [RSSAC-001]."

There isn't any document about Service Expectations at
http://www.icann.org/en/groups/rssac  According to a message posted a 
few months ago c.root-servers.net is not reachable on 2001:500:2::c 
from one network.  Section 3 of the draft mentions that the root name 
service must answer queries from any entity with a valid IP 
address.  Could the authors comment about this deployment issue?  An 
old output of a traceroute is provided below:

Route to IPv6 node 2001:500:2::c

   1    25 ms   25 ms   24 ms 2001:470:0:286::1
   2    82 ms   41 ms   50 ms 2001:470:0:270::2
   3    51 ms   48 ms   50 ms 2001:470:0:240::1
   4    74 ms  102 ms   72 ms 2001:470:0:1b4::1
   5    75 ms   74 ms   74 ms 2001:470:0:32::2
   6    *       *       *     ?

RFC 6891 is currently listed as an Internet Standard.  It is not part 
of the protocol requirements specified in Section 2.

During an unrelated discussion with the IESG it was pointed out that 
a document could not be reclassified as Historic if the the IETF 
still believes in what that document says.  The draft mentions that 
it reclassifies RFC 2870 without providing any reason.

My reading of "modern Internet" refers to the present 
Internet.  Wouldn't it be better to explain to the reader that the 
operational requirements are defined by RSSAC instead of arguing that 
it makes more sense to have protocol and some deployment requirements 
in this draft?  Operational requirements usually affect 
deployment.  Section 2 looks more like implementation or operational 
requirements instead of protocol requirements.  A fix could be to 
change the title of the draft to "Requirements for DNS Root Name 
Service".  Section 2 could discuss about the Root Name Service end 
while Section 3 could discuss about the Internet Host end.

In Section 2:

   "MUST support IPv4[RFC0791] and IPv6[RFC2460] transport of DNS
    queries and responses."

The following are reponses from some of the Root servers:

   ; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11395
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

   ;; QUESTION SECTION:
   ;b.root-servers.net.            IN      AAAA

   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34834
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

   ;; QUESTION SECTION:
   ;e.root-servers.net.            IN      AAAA

   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35019
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

   ;; QUESTION SECTION:
   ;g.root-servers.net.            IN      AAAA

The above-mentioned name servers do not support IPv6.

According to the Abstract:

   "The DNS Root Name service is a critical part of the Internet architecture."

It's odd to specify an optional functionality in Section 3 for a 
"critical part of the Internet architecture".

I'll note that there will no longer be an IETF document with the 
following requirement:

   "The root zone MUST be signed by the Internet Assigned Numbers
    Authority (IANA) in accordance with DNSSEC"

Regards,
S. Moonesamy

---

From: Joe Abley <[email-masked]>
Date: Thu, 22 May 2014 12:34:43 -0400

Hi SM,

Some reaction to your comments below, plus a comment of my own. I'll note that I am not a root server operator, although in the past I have played one on TV. My comments on your comments are provided merely as additional thoughts from an innocent bystander.

On 22 May 2014, at 1:23, S Moonesamy <[email-masked]> wrote:

> http://www.icann.org/en/groups/rssac

I understand that RSSAC have made recent progress on that document, and that it will appear soon. I would presume that the RFC Editor would hold final publication of this document, once approved, until that reference showed up, as is the case for references to IETF documents. I don't know whether that's a good presumption though. I just thought I'd mention it as a plausible workflow.

> According to a message posted a few months ago c.root-servers.net is not reachable on 2001:500:2::c from one network.  Section 3 of the draft mentions that the root name service must answer queries from any entity with a valid IP address.

At any time many parts of the Internet are unreachable from other parts of the Internet, for many reasons unrelated to specifications (national issues, cable breaks, failures in particular networks, peering disputes, etc.)

I'll note that the document describes requirements for the *service*, not for any particular component of the service.

So I think this concern is orthogonal to the purpose and contents of this document.

> I'll note that there will no longer be an IETF document with the following requirement:
> 

I actually think that it makes sense to separate the requirements for the root name *service* from the contents of the root zone that is being served. The document requires the service to support DNSSEC (which I think is right and proper), and has nothing to say about the contents of the root zone (which again, I think is right and proper).

I have one comment of my own.

Section 3 specifies that:

> 3.  Deployment Requirements
> 
>    The root name service:
> 
>       MUST answer queries from any entity conforming to [RFC1122] with a
>       valid IP address.

The document does not discuss what "valid" means in this context. In a protocol sense, "valid" presumably means "well-formed", which means that any 32-bit/128-bit integer will do.

The address 10.4.5.6 is a valid IP address in a protocol sense, although use of that address is constrained operationally by RFC 1918. It would be reasonable not to send a response to a query from an address that is known to be unreachable from the point of view of the root server.

Inbound queries with source addresses for which there is no corresponding return route, similarly, cannot be usefully replied to. Individual root servers with (e.g.) unicast RPF configured upstream will not receive those queries. In this category are addresses that have not been allocated by an RIR or are not announced on the Internet for some other reason (perhaps they are used in disconnected networks which are leaking).

Individual root servers have in the past mitigated attack traffic (e.g. reflection attacks) using techniques such as Response Rate Limiting. There is good reason to believe that such techniques do a good job at allowing legitimate queries to be answered whilst preventing responses that might otherwise enable (e.g.) a reflection attack.

Taken at face value, this MUST requires individual root server operators to do things that, operationally, are undesirable. I suggest some qualification, e.g. of the form "the root name service MAY refuse to answer particular queries to mitigate operational events that might otherwise threaten its stability and availability".

Joe

---

From: SM <[email-masked]>
Date: Thu, 22 May 2014 11:56:47 -0700

Hi Joe,
At 09:34 22-05-2014, Joe Abley wrote:
>Some reaction to your comments below, plus a comment of my own. I'll 
>note that I am not a root server operator, although in the past I 
>have played one on TV. My comments on your

Ok. :-)

>I understand that RSSAC have made recent progress on that document, 
>and that it will appear soon. I would presume that the RFC Editor 
>would hold final publication of this document, once approved, until 
>that reference showed up, as is the case for references to IETF 
>documents. I don't know whether that's a good presumption though. I 
>just thought I'd mention it as a plausible workflow.

I would usually be okay with the workflow.  The referenced document 
is currently a forward-looking statement.  I suggest delaying the 
IESG approval until that document is available or else changing the 
text in the draft to reflect the current state of affairs.

>At any time many parts of the Internet are unreachable from other 
>parts of the Internet, for many reasons unrelated to specifications 
>(national issues, cable breaks, failures in particular networks, 
>peering disputes, etc.)
>
>I'll note that the document describes requirements for the 
>*service*, not for any particular component of the service.

Yes.

>So I think this concern is orthogonal to the purpose and contents of 

I mentioned this as long-running problems provides material for 
non-technical arguments.

>I actually think that it makes sense to separate the requirements 
>for the root name *service* from the contents of the root zone that 
>is being served. The document requires the service to support DNSSEC 
>(which I think is right and proper), and has nothing to say about 
>the contents of the root zone (which again, I think is right and proper).

Section 3 broaches the topic of "contents of the Root Zone".  I read 
some past comments from the IAB about DNSSEC.  The terms used were 
"implementation" and "deployment".  It looks like the requirement 
fits in this draft.

Regards,
S. Moonesamy

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 24 May 2014 09:47:46 -0700

This message covers a procedural problem with draft-iab-2870bis obsoleting RFC 2870.

> I understand that RSSAC have made recent progress on that document, and that it will appear soon. I would presume that the RFC Editor would hold final publication of this document, once approved, u…

From the draft:

   The operational requirements are defined in [RSSAC-001].
. . .
   This document and [RSSAC-001] together functionally replace [RFC2870].

Note that it is only this draft that obsoletes RFC 2870. RFC 2870 (which is a BCP) has protocol, deployment, and operational requirements, but it's title says only "Operational". This draft explicitly has no "operational" requirements: those are in a different, as-yet unpublished, non-RFC-track document.

This IETF LC is asking us to obsolete a BCP with a draft that is arguably on a different topic, with the real replacement not yet published, and that will not even be published as an RFC. How can we decide whether or not the important parts of RFC 2870 are dealt with?

To be clear: draft-iab-2870bis covers the relevant protocol and deployment requirements. (There are some issues with those short lists; I'll cover those in a separate message.) But that is not sufficient for *this draft* to obsolete a BCP like RFC 2870 unless we know that the operational parts of RFC 2870 are covered somewhere else.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 24 May 2014 11:38:13 -0700

|   The root name service:
|
|      . . .
|
|      MUST support IPv4[RFC0791] and IPv6[RFC2460] transport of DNS
|      queries and responses.

This needs an addition: "Some servers in the root name service might not support IPv4, and some might not support IPv6." Without that, some people might think that each server must respond on both layer 3 technologies, but they do not.

|      MUST support UDP[RFC0768] and TCP[RFC0793] transport of DNS
|      queries and responses.

This also needs an addition, but I am not sure what it should say. Must every server in the service respond correctly on TCP? If so, what does "correctly" mean in the anycast world that most of them live in?

|      MUST generate checksums when sending UDP datagrams and MUST verify
|      checksums when receiving UDP datagrams containing a non-zero
|      checksum.

If "MUST verify checksums" means that if the request has a broken checksum, the server should not reply, that needs to be explicit. If that's the intention, better wording would be:

MUST generate checksums when sending UDP datagrams.
MUST not respond to UDP datagrams containing a
non-zero checksum if that checksum does not verify.

If that's not what was intended by "MUST verify checksums", this still needs clarification.

|      MUST answer queries from any entity conforming to [RFC1122] with a
|      valid IP address.

Joe brought up this question, and it's important. Is this BCP preventing "the root name service" from rate-limiting during DoS attacks?

|      MAY also serve the root-servers.net zone, and the zone for the
|      .arpa top-level domain [ARPAZONE],[RFC3172].

A "MAY" is not a requirement, and thus does not belong in this document. The service "may" do all sorts of things that are not listed here.

--Paul Hoffman

---

From: David Conrad <[email-masked]>
Date: Sat, 24 May 2014 13:55:25 -0700

Hi,

General comments:

* Given RSSAC-001 has not (to my knowledge) been published, I do not feel this document should be in last call, particularly given it is to move an existing BCP to historic (a bit more on this below).

* The sections on requirements is overly minimalistic. A bit of explanation about those requirements would be useful.

Specific comments:

* Section 1, 2nd paragraph:

   They currently also serve the root-
   servers.net zone and the zone for the .arpa top-level
   domain[ARPAZONE].

The "J" root server does not serve .ARPA.  Perhaps:

"They currently also serve the root-servers.net zone and some root servers serve the .arpa zone."

* Section 1.1, 2nd sentence:

   This document and [RSSAC-001] together functionally replace
   [RFC2870].

Given the IETF does not maintain change control of RSSAC-001, I'm unsure if it is appropriate to reference it as a component of something that is obsoleting 2870.  

* Section 3, title:

I feel this section is talking more about root zone publication requirements. "Deployment Requirements" suggests to me a discussion of the requirements for deploying root servers (e.g., geographical distribution, anycast routing, etc.)

* Section 3, 2nd sentence:

This requires the root servers to not use any form of response rate limiting, nor impose any sort of sanity checks to where responses will be sent. I believe this is risky and inappropriate in the world of spoofed source address DDoS.

* Section 3, 3rd sentence:

    MUST serve the unique [RFC2826] root zone[ROOTZONE].

As far as I understand, RFC 2826 talks about why a unique root zone is required, it doesn't actually talk about the Internet's root zone.   Perhaps something more along the lines of "MUST, as a result of the technical considerations documented in [RFC2826], serve the Internet's unique root zone[ROOTZONE]." 

This would also probably be place to mention that the unique root zone MUST be published without modification.

* Section 3, 3rd sentence:

      MAY also serve the root-servers.net zone, and the zone for the
      .arpa top-level domain [ARPAZONE],[RFC3172].

Section 3 is talking about requirements, so it isn't clear to me that a "MAY" should be in this section.

* Section 5

I believe it would be appropriate to document that IANA has a responsibility to publish [ROOTZONE], update the root hints, and ensure the root zone trust anchor is published.

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Sun, 25 May 2014 09:05:36 +1000

In message <[email-masked]>, Paul Hoffman writes:
> This needs an addition: "Some servers in the root name service might not
> support IPv4, and some might not support IPv6." Without that, some people
> might think that each server must respond on both layer 3 technologies,
> but they do not.
>
> This also needs an addition, but I am not sure what it should say. Must
> every server in the service respond correctly on TCP?

Yes.

> If so, what does
> "correctly" mean in the anycast world that most of them live in?

It means that they respond to TCP packets they see.

> If "MUST verify checksums" means that if the request has a broken
> checksum, the server should not reply, that needs to be explicit. If
> that's the intention, better wording would be:
>
> Joe brought up this question, and it's important. Is this BCP preventing
> "the root name service" from rate-limiting during DoS attacks?
>
> A "MAY" is not a requirement, and thus does not belong in this document.
> The service "may" do all sorts of things that are not listed here.
>
> --Paul Hoffman

I would also add MUST fragment IPv6 UDP at network MTU (1280).  MUST
NOT send IPv6 TCP segments bigger than network MTU.  Both of these
rules are to avoid triggering PMTU discovery in IPv6. 

For IPv4 MUST NOT set DF.

With anycast servers the PTB response may got to the wrong instance.

The ORG servers are configured to not send IPv6 UDP EDNS responses
bigger than what will fit in a 1280 octet packet.  This results in
lots of unnecessary TCP connections as the client needs to fallback
to TCP.  The servers then send maximum sized TCP segments which
don't make it through tunnels and the PTB handling is marginal.

There is no need to avoid fragmenting UDP packets.  If the client's
path doesn't let through fragmented packets they will adapt their
query or they will fix the path.  All it does is penalise clients
which have working paths as they then need to fallback to TCP.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Joe Abley <[email-masked]>
Date: Tue, 27 May 2014 15:27:07 +0300

On 24 May 2014, at 23:55, David Conrad <[email-masked]> wrote:

> The "J" root server does not serve .ARPA.

The J-Root server does serve ARPA.

There was a time when all servers but J served IN-ADDR.ARPA, which is perhaps what you are remembering. Today, none of the root servers serve IN-ADDR.ARPA.

[walrus:~]% dig @J.root-servers.net arpa soa +norec

; <<>> DiG 9.9.5 <<>> @J.root-servers.net arpa soa +norec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2202
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 12, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;arpa.				IN	SOA

;; ANSWER SECTION:
arpa.			86400	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2014052700 1800 900 604800 86400

;; AUTHORITY SECTION:
arpa.			518400	IN	NS	a.root-servers.net.
arpa.			518400	IN	NS	b.root-servers.net.
arpa.			518400	IN	NS	c.root-servers.net.
arpa.			518400	IN	NS	d.root-servers.net.
arpa.			518400	IN	NS	e.root-servers.net.
arpa.			518400	IN	NS	f.root-servers.net.
arpa.			518400	IN	NS	g.root-servers.net.
arpa.			518400	IN	NS	h.root-servers.net.
arpa.			518400	IN	NS	i.root-servers.net.
arpa.			518400	IN	NS	k.root-servers.net.
arpa.			518400	IN	NS	l.root-servers.net.
arpa.			518400	IN	NS	m.root-servers.net.

;; Query time: 292 msec
;; SERVER: 2001:503:c27::2:30#53(2001:503:c27::2:30)
;; WHEN: Tue May 27 15:26:05 EAT 2014
;; MSG SIZE  rcvd: 299

[walrus:~]% 

Joe

---

From: David Conrad <[email-masked]>
Date: Tue, 27 May 2014 09:09:48 -0700

Joe,

> The J-Root server does serve ARPA.

% dig @a.root-servers.net +short arpa ns | grep -i j
% whois -h whois.iana.org arpa | grep -i j.root-servers.net
% 

Regards,
-drc

---

From: Joe Abley <[email-masked]>
Date: Wed, 28 May 2014 12:46:52 +0300

> % whois -h whois.iana.org arpa | grep -i j.root-servers.net

Ah yes, perhaps my memory is faulty. ARPA is served by J-Root, but is not delegated to J-Root. Your suggested text is indeed compatible with the current observed state of things, sorry for suggesting otherwise.

Joe

---

From: Russ Housley <[email-masked]>
Date: Wed, 28 May 2014 12:29:50 -0400

Paul:

You have asked a question in a manner that assumes a technical assessment can be made.  I do not think that is the situation.  Instead, I think the question is whether the IETF is the proper organization to write a BCP about protocol requirements for root servers and RSSAC is the right organization to write a document about operational requirements for root servers.  In short, this more of a political question than a technical one.  Back when RFC 2870 was written, the IETF (rightly or wrongly) included both requirement sets in the same document.

From my perspective, IETF is the proper organization to write a BCP about protocol requirements.

RSSAC has been going through a restructuring process.  Assuming that a functional organization emerges from that process, RSSAC will be a fine organization to handle the operational requirements.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 28 May 2014 12:32:26 -0400

> This needs an addition: "Some servers in the root name service might not support IPv4, and some might not support IPv6." Without that, some people might think that each server must respond on both…

I would like to see each and every root server support both IPv4 and IPv6.  Of course, if the server gets a query on IPv4, it answers that query on IPv4.  Likewise, if the server gets a query on IPv6, it answers that query on IPv6. 

Russ

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 28 May 2014 09:47:34 -0700

On May 28, 2014, at 9:29 AM, Russ Housley <[email-masked]> wrote:

> You have asked a question in a manner that assumes a technical assessment can be made.  

Correct. You (the IAB) are asking the IETF to obsolete a BCP (which means it has the same requirements as a standards-track document). The BCP asserts some technical properties; the IETF should be able to determine whether or not the new technical properties are an appropriate replacement for the old ones.

> I do not think that is the situation.  Instead, I think the question is whether the IETF is the proper organization to write a BCP about protocol requirements for root servers and RSSAC is the right organization to write a document about operational requirements for root servers.  In short, this more of a political question than a technical one.  Back when RFC 2870 was written, the IETF (rightly or wrongly) included both requirement sets in the same document.

That seems fine, as long as the new document says that, which it does not. If the IETF is going to replace this BCP with one that has a smaller scope, it should say that up front and *not* refer to a document that we cannot yet read and may, in fact, have very different properties than the one in the references in this draft.

Current:
   The operational requirements are defined in [RSSAC-001].  This
   document defines the protocol requirements and some deployment
   requirements.

Proposed:
   This document only defines the protocol requirements and some
   deployment requirements; the operational requirements that were
   defined in RFC 2870 are removed. It is expected that ICANN's
   RSSAC [RSSAC] will define the operational requirements.

   [RSSAC] DNS Root Server System Advisory Committee,
           http://www.icann.org/en/groups/rssac

>> From my perspective, IETF is the proper organization to write a BCP about protocol requirements.

Yes, definitely.

> RSSAC has been going through a restructuring process.  Assuming that a functional organization emerges from that process, RSSAC will be a fine organization to handle the operational requirements.

Yep. But that doesn't mean that this BCP should have a reference to a document we can't evaluate.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 28 May 2014 09:49:09 -0700

On May 28, 2014, at 9:32 AM, Russ Housley <[email-masked]> wrote:

> I would like to see each and every root server support both IPv4 and IPv6.  

So would I. But is that a *requirement*, particularly given that the root service seems to run just fine today without it?

I propose that the addition is still needed, despite what you and I would like to see.

--Paul Hoffman

---

From: Russ Housley <[email-masked]>
Date: Wed, 28 May 2014 13:09:54 -0400

> I propose that the addition is still needed, despite what you and I would like to see.

If a root server does not support both IPv4 and IPv6 then it does not comply with the proposed BCP.

Russ

---

From: Michael Richardson <[email-masked]>
Date: Wed, 28 May 2014 15:18:02 -0400

Paul Hoffman <[email-masked]> wrote:
    >>> This needs an addition: "Some servers in the root name service might
    >>>not support IPv4, and some might not support IPv6." Without that, some
    >>>people might think that each server must respond on both layer 3
    >>>technologies, but they do not.

    > So would I. But is that a *requirement*, particularly given that the
    > root service seems to run just fine today without it?

I would like every A-M.root-servers.net have an A and AAAA record.

I don't care how the root-server operators decide to partition to workload
among hardware.  Over time we will need more v6 responders and fewer v4
responders.
I don't think that there is, or should be, any requirement that v4 and v6 be
answered by the same system, and given anycast, they might even be in
different locations.

I think that the current text captures this just fine:

   The root name service:
      ...
      MUST support IPv4[RFC0791] and IPv6[RFC2460] transport of DNS
      queries and responses.

because it focuses on the root name *service* from an external functional
point of view, and not from a design point of view.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: David Conrad <[email-masked]>
Date: Wed, 28 May 2014 12:43:23 -0700

Hi,

I've been biting my tongue a bit on this discussion, but have lost the battle.

> I would like every A-M.root-servers.net have an A and AAAA record.
[...]
>      MUST support IPv4[RFC0791] and IPv6[RFC2460] transport of DNS

And if they don't?

Just for clarity, the root server operators are under no obligation to do anything. The whole "MUST" bit is actually sort of misplaced since it isn't like people are going to wave a RFC (BCP or otherwise) at the root operators and change will magically happen. Root server operators will do what they want according to their own requirements/business drivers. In an ideal world, what the community wants and what the root server operators' requirements/business drivers are correspond, but people shouldn't be under any illusion that an RFC will make this happen.

> point of view, and not from a design point of view.

This is probably backwards. A design document is probably a better goal since it is aspirational. A document that attempts to define root service isn't particularly useful if there is no practical way to enforce that definition.

Regards,
-drc

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 29 May 2014 11:41:39 +0200

> Just for clarity, the root server operators are under no obligation to do anything. The whole "MUST" bit is actually sort of misplaced since it isn't like people are going to wave a RFC (BCP or oth…

But that is not the problem of the IETF. If the IETF come to conclusion that root server services "must" support IPv4 and IPv6, so be it. It should be in the RFC. It is then up to whoever is policing the services (the root server operator themselves, their owner, the regulator in the jurisdiction they are within or whatever) to do the policing.

Policing will not happen without a spec that services can be compared against.

And lack of policing (which seems to be what you talk about) is I think a separate issue.

I think IETF should do a darn good job here. As IETF can do. And then other open issues have to be taken care of elsewhere.

Sure, it might be that some of the requirements are hard to enforce, and that IETF will be frustrated, but that is not worse than support for new RR Types, IPv6, DNSSEC and about a thousand other things IETF think is very important.

IETF should lead. Not follow.

I think personally a lot of the discussions for example in ICANN related to the new gTLDs would have been easier if IETF had had a clear lead on various issues related to the root zone. Like charset, strings etc that "are ok". Now a lot of that discussion has happened elsewhere, and even if of course some of that is more policy/business (and because of that fit in ICANN environment) it would have been easier if that discussion had a stable solid technical ground to stand on.

   Patrik

---

From: manning <[email-masked]>
Date: Wed, 28 May 2014 12:17:11 -0700

the odd thing is, since document is cobbled together as both a floor wax and a dessert topping it can do neither well, certainly NOT as a BCP.

It might be realistic of the IETF to talk about the protocol requirements for running a DNS server (the roots are not special in this regard).
It beggars the imagination to think the IETF can or should dictate operational considerations to any organization or organizations that use
its protocols.   First blush,  the pace of operational requirement changes can’t easily mesh with the pace of IETF document standardization.. Not even 
with a SyncroMesh(tm) Transmission.

Perhaps it might be better to move RFC 2870 to historic and admit the IETF does;t dictate operational requirements, instead choosing to focus on
it core competencies.

/bill

---

From: Jari Arkko <[email-masked]>
Date: Thu, 29 May 2014 11:24:02 +0300

> among hardware.

Yes, that is my view as well.

> Over time we will need more v6 responders and fewer v4
> responders.

Agreed.

Jari

---

From: David Conrad <[email-masked]>
Date: Thu, 29 May 2014 11:29:39 -0700

Patrik,

On May 29, 2014, at 2:41 AM, Patrik Fältström <[email-masked]> wrote:
>> Just for clarity, the root server operators are under no obligation to do anything.
> But that is not the problem of the IETF.

True, which is sort of my point.

> If the IETF come to conclusion that root server services "must" support IPv4 and IPv6, so be it. It should be in the RFC.

BCP177 would appear to cover the IETF's interest in ensuring both IPv4 and IPv6 is supported. 

> Policing will not happen without a spec that services can be compared against.

My impression is that the IETF hasn't been particularly effective in coming up with operational service specifications.

> And lack of policing (which seems to be what you talk about) is I think a separate issue.

That's not really what I'm talking about.  What I am saying is that it I don't really see the point in the IETF attempted to demand stuff outside of its control. In most standardization/protocol definition contexts, the IETF specifying "MUST" or "MUST NOT" usually makes sense since folks generally have a choice in obtaining equipment/software/service that is implementing those standards. 

This is NOT the case with the root servers. 

By and large, the Internet community gets what the root server operators deem at their sole discretion (perhaps informed by outside-the-IETF contractual or other obligations) within their interests to provide, nothing more and nothing less. 

In April 2012, the IETF, via BCP177, already stated "IPv6 is required" yet B, E, and G still do not support IPv6 (yes, I'm sure there are reasons, that's not the point). RFC 2010 was published in 1996 and was mostly ignored by the root server operators. RFC 2870 was published in 2000 and was mostly ignored by the root server operators. What has changed that makes you believe a new RFC is going to have a different impact?

Regards,
-drc

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 29 May 2014 21:12:07 +0200

> In April 2012, the IETF, via BCP177, already stated "IPv6 is required" yet B, E, and G still do not support IPv6 (yes, I'm sure there are reasons, that's not the point). RFC 2010 was published in 1…

I do not think it has a different impact. I am more nervous over what the impact will be if IETF stop saying IPv6 is required. If IETF do not say so it is impossible to say that B, E and G does not live up to whatever requirement IETF set.

I.e. I do not think it is wrong that IETF require what IETF want to require. The error is elsewhere.

   Patrik

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Thu, 29 May 2014 17:18:03 -0300

I think there is enough consensus saying that root server operators MUST
support IPv6. I think it's hard to argue that the Internet needs this to
move to IPv6, as otherwise we'll be saying that it'll be ok for future
networks to not be able to access some root servers, or putting the
burden of supporting all IPv6 on a subset of root servers.

If you add that not all root server operators offer anycast copies, or
do it in a limited way, well, we could be putting the IPv6 internet in a
fragile position.

IMO, setting this requirement is well within the core competencies of
the IETF.

Then comes the question what to do (if anything) with those root server
operators who chose to ignore this MUST.

IMO, This is probably outside the IETF's sphere, and it should be
possible to even say so in the proposed document.

cheers!

~Carlos

---

From: manning bill <[email-masked]>
Date: Thu, 29 May 2014 13:41:58 -0700

apparently there is not “enough consensus”, since several roots don’t have published v6 addresses.
there -might- be rough consensus in a narrow slice of the technical community that has an axe to grind.
end of the day, the IETF has no say on how people operate their networks/services.

if you think it should, i’d like to see a resolution of the DMARC deployment that requires all SMTP
servers to require, per IETF mandate to support DMARC.

Engineering is not Operations.   This is not the IOTF.

/bill
Neca eos omnes.  Deus suos agnoscet.

---

From: David Conrad <[email-masked]>
Date: Thu, 29 May 2014 13:48:29 -0700

Patrik,

>> In April 2012, the IETF, via BCP177, already stated "IPv6 is required" yet B, E, and G still do not support IPv6 (yes, I'm sure there are reasons, that's not the point).
> I am more nervous over what the impact will be if IETF stop saying IPv6 is required.

I don't believe anyone is proposing moving BCP177 to historic.

> If IETF do not say so it is impossible to say that B, E and G does not live up to whatever requirement IETF set.

The requirement for IPv6 appears to have been set in 2012 ("IPv6 Support Required for All IP-Capable Nodes") if not before. I'm disappointed that people would argue that Yet Another IETF RFC is required to get folks to do stuff they already know they should be doing.

Regards,
-drc

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Thu, 29 May 2014 18:11:24 -0300

Hi

> end of the day, the IETF has no say on how people operate their networks/services.

I meant consensus here, not in the root server operator community.

I believe that there is a limit on the argument of operational
independence. If you agree to provide a service the whole Internet
depends on, well, it's reasonable that you need to comply with certain
requirements.

If an operator can't / won't comply with the requirements set by the
IETF, they can ask to be relieved of their duty.

> Engineering is not Operations.   This is not the IOTF.

DMARC/mailing lists are hardly critical infrastructure. This is not even
remotely comparable to the root server issue in terms of impact.

~Carlos

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Thu, 29 May 2014 18:13:43 -0300

I need to clarify something here (thanks TM for spotting this).

I didn't mean to say that the IETF should require all root server
operators to provide anycast copies. I'd very much would like them to,
but there yes, I don't think the IETF can/should require that.

My comment about 'this requirement is well within...' was only intended
to apply to the IPv6 issue.

regards,

~Carlos

---

From: manning bill <[email-masked]>
Date: Thu, 29 May 2014 14:24:20 -0700

and why not require anycast?  if your going to meddle in other companies operations, be bold!

/bill

---

From: manning bill <[email-masked]>
Date: Thu, 29 May 2014 14:21:56 -0700

/bill

> I meant consensus here, not in the root server operator community.

	root server operator community and their clients  v.   a subset of folks in the IETF - which was my point

> depends on, well, it's reasonable that you need to comply with certain

	what they clients demand is the base requirement.

> IETF, they can ask to be relieved of their duty.

	by whom?

> remotely comparable to the root server issue in terms of impact.

	the topic was/is operations.  not “critical” infrastructure.
	and the fallout for a few folks adopting DMARC has vastly outweighed
	the fallout of a gradual, measured migration to IPV6 and the perhaps
	eventual termination of v4 services.   Again, the clients/users of the
	operational systems matter more than the pontification of some engineers.

	if you insist on only using pure v6, then you have the power to do so.
	telling another entity how to run their operations is rife with legal entanglements

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 30 May 2014 08:38:42 +0200

On 29 maj 2014, at 22:48, David Conrad <[email-masked]> wrote:

> I'm disappointed that people would argue that Yet Another IETF RFC is required to get folks to do stuff they already know they should be doing.

Aha, then here is where I think we have different opinion.

I do not see this draft be anything people think will change things. I see personally this be an updated version of the RFC stating what IETF do believe should be implemented.

Once again, the enforcement is somewhere else.

But if whatever the enforcement is to refer to is not correct, then it is absolutely for certain the enforcement will not happen.

So, phew, I do not think we are very far away from each other this time either. ;-)

   Patrik

---

From: Joe Abley <[email-masked]>
Date: Fri, 30 May 2014 12:49:54 +0300

> If a root server does not support both IPv4 and IPv6 then it does not comply with the proposed BCP.

The current text talks about the service, not individual servers.

The service (as provided by thirteen root servers) is available over both IPv6 and IPv4 today, and hence complies with the proposed BCP.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 May 2014 06:59:15 -0700

> The service (as provided by thirteen root servers) is available over both IPv6 and IPv4 today, and hence complies with the proposed BCP.

Exactly. If someone like Russ and Jari reading the document can jump from "the service" to "all of the servers", others reading it will as well. Thus, my proposed addition.

--Paul Hoffman

---

From: manning bill <[email-masked]>
Date: Fri, 30 May 2014 07:20:58 -0700

the problem here is that rarely has the IETF managed to actually map its expectations to operational reality.
RFC 2010 did, for about 60 days.   RFC 2870 never did.  And neither does this document.
the trend line is away from credibility, which is not really where I think the ietf should be headed, but ymmv.

if this document were to be recast as “Protocol Requirements for DNS Servers” - that would be a valuable 
document.  in its current form, not so much.

/bill

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Fri, 30 May 2014 12:56:11 -0300

Actually, you got me thinking. Why not require anycast, indeed. I think
at some point it will become necessary. Maybe as a SHOULD this time.

The argument of 'operational autonomy' cannot be sacrosanct. If you
agree to provide a service that the whole internet depends on, then you
need to comply with a few requirements. If you can't / won't, well...
you can opt out.

Operating a root server is not a god-given right or burden. Just opt out
if you cannot fulfil the requirements the whole Internet needs. Some
things just come with the territory.

If, on the other hand, you operate some random email server out there,
then yes, I agree you are pretty much the king of your castle. You are
free to not do DMARC if you don't want to.

I do agree with Patrik that the enforcement part is not the IETF's
responsibility. That lies elsewhere. But past failures in enforcement
should not deter the IETF of setting the requirements the IETF deems
necessary for the correct operation of the Internet.

~Carlos

---

From: manning bill <[email-masked]>
Date: Fri, 30 May 2014 09:09:51 -0700

then you won’t mind if the IETF write RFCs to dictate operational policies to RIRs?

/bill

---

From: David Conrad <[email-masked]>
Date: Fri, 30 May 2014 10:17:55 -0700

Carlos,

On May 30, 2014, at 8:56 AM, Carlos M. Martinez <[email-masked]> wrote:
> If you
> need to comply with a few requirements.

That might be nice, but that isn't how the root server system works.

The root server operators provide a voluntary service for their own reasons using their own resources. History has shown that no one other than the folks that pay to root server operators' bills gets to impose requirements on how that service is provided. The IETF, IESG, IAB, ICANN, and/or random people off the street can make suggestions on how that service can be provided, but there should be no illusions about whether those suggestions are going to be followed.

> If you can't / won't, well... you can opt out.

Ignoring for the moment the fact that there still is no succession plan if a root server actually were to opt out, there simply is no incentive for a root server operator to opt out. As such, suggesting that as an option is ... of debatable value.

> But past failures in enforcement

I guess I just don't see the point. I suppose it doesn't really do any harm, but as Patrik states, it isn't going to have any impact so why bother? 

Regards,
-drc

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Fri, 30 May 2014 14:20:37 -0300

Maybe you can better explain to us where you draw the line of
'operational practices' vs 'requirements'

Requiring IPv6, or anycast, or feature X is, in my opinion, a just that,
a requirement.

Operational practice would dictate HOW you fulfill the IPv6, or anycast,
or X requirement.

~Carlos

---

From: David Conrad <[email-masked]>
Date: Fri, 30 May 2014 10:24:00 -0700

> The service (as provided by thirteen root servers) is available over both IPv6 and IPv4 today, and hence complies with the proposed BCP.

So, to reduce this to the absurd, if a single root server operator provided IPv6 DNS service via a dust-covered 8088 PC connected over a 300 bps nailed up SLIP line, the proposed BCP would be met?

BCP177 would appear to be a significantly better answer here.

Regards,
-drc

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 30 May 2014 19:26:33 +0200

> I guess I just don't see the point. I suppose it doesn't really do any harm, but as Patrik states, it isn't going to have any impact so why bother? 

Because without documents like these there will be no chance what so ever of having someone hitting the root server operator(s?) in the head with it.

   Patrik

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Fri, 30 May 2014 14:47:18 -0300

David,

> That might be nice, but that isn't how the root server system works.

I understand. However, my point is that this shouldn't be a
consideration when setting requirements. The requirements need to match
what the Internet needs now and will need for the next 5, 10, 15 years.

The discussion about how to fulfill the requirements starts when the
requirements are set.

> The root server operators provide a voluntary service for their own reasons using their own resources. History has shown that no one other than the folks that pay to root server operators' bills ge…

I do thank them for doing that. Some of them have been doing this for
decades. I'm pretty sure that some of them actually took a risk
accepting this responsibility back at the time. They deserve praise.

However, my point above remains. Requirement setting should be based on
actual current and future needs, not on the hows and whys things were
managed in the past.

> Ignoring for the moment the fact that there still is no succession plan if a root server actually were to opt out, there simply is no incentive for a root server operator to opt out. As such, sugge…

The fact that there is no succession plan is actually something that is
broken in the IG arena. IMO, it's not the IETF's fault, nor the IETF's
responsibility to correct; but it's broken nonetheless.

This fact was noticed during NetMundial in at least two meetings I
attended. It was awkward. I think 'We the Internet as we know it' need
to pay attention to this and fix it before 'others' think they need to
fix it for us.

> I guess I just don't see the point. I suppose it doesn't really do any harm, but as Patrik states, it isn't going to have any impact so why bother? 

Maybe I like having guidance. A requirements document would provide
useful guidance. Maybe it should not be a BCP, I don't know. But having
written requirements provides useful basis for further discussion on how
to implement them.

My main fear is actually what you perfectly described in another email.
If we leave requirements like IPv6 and anycast and feature X, out, and
leave them just to the good will of some organizations, well, we risk
the scenario where some might say 'why should I do it if no one is doing
it'.

regards,

~Carlos

---

From: Russ Housley <[email-masked]>
Date: Fri, 30 May 2014 14:30:52 -0400

> BCP177 would appear to be a significantly better answer here.

Speaking for myself.  That is, no hats.

BCP 177 is a very good thing.  It represents the IETF consensus that IPv6 is the future of the Internet.

I think that draft-iab-2870bis-01.txt should become a BCP as well.  I think it is important for the IETF to say that each of the root servers -- all 13 of them -- need to support IPv4 and IPv6.  This could be done with dual-stack or it an be done with different hardware.  The client can't tell, so we should not impose a specific configuration.  By including this requirement in 2870bis, the IETF is holding strong in its commitment to IPv6 on every node.  The root servers are critical infrastructure, and in my view, they should lead the way to IPv6.

Russ

---

From: David Conrad <[email-masked]>
Date: Fri, 30 May 2014 12:06:26 -0700

> Because without documents like these there will be no chance what so ever of having someone hitting the root server operator(s?) in the head with it.

And that has worked so well in the past with root service? As mentioned, the IETF has published other documents on root server operational behavior with less than stellar results. I personally do not see much value in the IETF repeatedly writing documents that are simply ignored (the opposite, actually).

This is not to say that I feel documenting recommendations (not requirements) aren't of value, particularly if those recommendations are objectively justified (e.g., "IPv6 should be supported to ensure IPv6-only service operates on par with IPv4-only service" or something). Draft-iab-2870bis-01.txt doesn't do this. Draft-iab-2870bis-01.txt pretends the IETF (IAB?) has the ability to dictate how an operational service MUST be provided without any explanation or rationale.

Regards,
-drc

P.S. I also find it odd this is coming out of the IAB. Why this isn't a DNSOP document? It is sort of related to DNS Operations, no?

---

From: David Conrad <[email-masked]>
Date: Fri, 30 May 2014 12:06:26 -0700

Regards,
-drc

---

From: Russ Housley <[email-masked]>
Date: Fri, 30 May 2014 15:34:44 -0400

> I also find it odd this is coming out of the IAB. Why this isn't a DNSOP document? It is sort of related to DNS Operations, no?

The IAB is involved because of the liaison relationship wth RSSAC.  The split in responsibility between IETF and RSSAC is the biggest change happening in this document.

Russ

---

From: David Conrad <[email-masked]>
Date: Fri, 30 May 2014 12:38:24 -0700

Russ,

On May 30, 2014, at 11:30 AM, Russ Housley <[email-masked]> wrote:
> I think it is important for the IETF to say that each of the root servers -- all 13 of them -- need to support IPv4 and IPv6.  

Assuming root servers are "IP-Capable Nodes", the IETF has already done that via BCP177 and yet 3 root servers still do not provide IPv6 service. I fail to see how yet another document is going to change this, particularly when you have two root server operators either saying explicitly or implying that the proposed BCP will have no impact.

> The root servers are critical infrastructure, and in my view, they should lead the way to IPv6.

The main impedance mismatch I'm having here is that in the vast majority of other cases, a document published by the IETF saying "Thou Shalt" can be used by folks to go to vendors or service providers and say "if you do not obey the IETF's Thou Shalts, I shall take my money elsewhere". This obviously does not apply to the root server system or individual root server operators. As such, I feel 2119 language is just silly, particularly given the root server operators presumably already know the community wants them to do stuff like support IPv6.

If this is just a "feel good" exercise like some odd Twitter hashtag campaign, then I suppose publishing the document probably won't hurt.  I just think it'd be a mistake to assume it actually does anything.

Regards,
-drc

---

From: manning bill <[email-masked]>
Date: Fri, 30 May 2014 13:14:18 -0700

if the document stayed in the protocol space (e.g. this v4/v6 thread), I’d be with you 75% of the way.   
But the root servers are not special in this regard.  If BCP177 is correct, then you want this document to 
refer to -ALL- DNS servers (particularly the authoritative and caching servers) …  then I’m behind this 100%.

But a small set of the IETF wanting to dictate operational / business models to folks is a bridge too far.

/bill

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Fri, 30 May 2014 17:46:12 -0300

Hello,

> But a small set of the IETF wanting to dictate operational / business models to folks is a bridge too far.

I still don´t get this. How is this requirement different from other
requirements ? If the document said 'provide ipv6 in this and such way'
I'd understand your concern.

But if the document just says 'root servers must answer queries over
ipv6' I simply don't get your concern, or how this is 'telling folks how
to operate their networks'.

Every network design is a response to a set of requirements. Usually
these set of requirements that answer a set of needs from a group of users.

How is this different? Here the user group is the Internet as a whole.
The Internet as a whole needs IPv6. As pointed out, other documents
already exist that already say this. I could even argue that *the
requirement already exists in the current BCP corpus*, I´m just saying
here that it does no harm to make it explicit for root server operators.

Now, how they solve it, that is operational, and that is the realm of
each operators.

Carlos