Skip to main content

Reverse DNS in IPv6 for Internet Service Providers
draft-ietf-dnsop-isp-ip6rdns-07

Revision differences

Document history

Date Rev. By Action
2018-11-26
07 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2018-11-13
07 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2018-11-12
07 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2018-10-02
07 (System) RFC Editor state changed to EDIT
2018-10-02
07 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-10-02
07 (System) Announcement was received by RFC Editor
2018-10-01
07 (System) IANA Action state changed to No IANA Actions from In Progress
2018-10-01
07 (System) IANA Action state changed to In Progress
2018-10-01
07 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2018-10-01
07 Amy Vezza IESG has approved the document
2018-10-01
07 Amy Vezza Closed "Approve" ballot
2018-10-01
07 Amy Vezza Ballot approval text was generated
2018-09-27
07 Cindy Morgan IESG state changed to Approved-announcement to be sent from Waiting for AD Go-Ahead
2018-09-27
07 Alissa Cooper [Ballot comment]
Please respond to the Gen-ART reviewer. He had valuable comments.
2018-09-27
07 Alissa Cooper Ballot comment text updated for Alissa Cooper
2018-09-27
07 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-09-27
07 Benjamin Kaduk
[Ballot comment]
Thanks for the well-written document!  I wrote down some thoughts
I had while reading, but they should be treated as very weak suggestions …
[Ballot comment]
Thanks for the well-written document!  I wrote down some thoughts
I had while reading, but they should be treated as very weak suggestions
and no pressure to apply them is implied.

Section 2.1

                                            DNS administrators should
  consider the uses for reverse DNS records and the number of services
  affecting the number of users when evaluating this option.

nit: maybe this could be qualified as "number of services relying on PTR
records", as otherwise it can be read as a bit of a non sequitur.

Section 2.3

  Administrators may want to consider user creativity if they provide
  host names, as described in Section 5.4 "User Creativity."

Perhaps "the risks of user creativity"?

Section 2.3.1

                                    This option may be scalable,
  although registration following an outage may cause significant load,
  and hosts using privacy extensions [RFC4941] may update records
  daily.  [...]

I think I've heard of deployments that update more often than daily, though
it's unclear that there's a need for this document to mention such
possibilities.

Section 4

  There are six common uses for PTR lookups:

I'm a little uncomfortable asserting this as a complete and exhaustive
listing in an Informational document, but I also can't dispute its
veracity.  I'll trust that the authors and WG have done sufficient research
and not request any change here.

                                                For residential users,
  if these four use cases are important to the ISP, the administrator
  will then need to consider how to provide PTR records.

... but I do have to wonder which four of the six the ISPs are supposed to
be considering.

                        A valid negative response (such as NXDOMAIN) is
  a valid response, if the four cases above are not essential;
  delegation where no name server exists should be avoided.

... and similarly here.

Section 5.1

  Providing location information in PTR records is useful for
  troubleshooting, law enforcement, and geolocation services, but for
  the same reasons can be considered sensitive information.

It may be worth clarifying that the sensitive nature is an argument for not
publishing, since there aren't really well-established schemes for
filtering access to the relevant DNS records.

Section 5.3

Maybe say something about "for use in other protocols" if we're not trying
to limit to DNSKEY and friends?
2018-09-27
07 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2018-09-27
07 Tero Kivinen Request for Telechat review by SECDIR Completed: Ready. Reviewer: Derek Atkins.
2018-09-27
07 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-09-26
07 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2018-09-26
07 Suresh Krishnan
[Ballot comment]
* Section 1.2.

"and may be short-lived."

Maybe worth adding a reference to RFC4941 here (already in the references). "and may be short-lived. …
[Ballot comment]
* Section 1.2.

"and may be short-lived."

Maybe worth adding a reference to RFC4941 here (already in the references). "and may be short-lived. e.g. temporary addresses from [RFC4941]"

* Section 2.3.1. and 2.3.2.

RFC6106 has been obsoleted. Replace with reference to RFC8106
2018-09-26
07 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-09-26
07 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2018-09-26
07 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-09-26
07 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2018-09-26
07 Lee Howard New version available: draft-ietf-dnsop-isp-ip6rdns-07.txt
2018-09-26
07 (System) New version approved
2018-09-26
07 (System) Request for posting confirmation emailed to previous authors: Lee Howard
2018-09-26
07 Lee Howard Uploaded new revision
2018-09-26
06 Ben Campbell [Ballot comment]
Abstract: Can "commonly provide IN-ADDR-ARPA information" be stated more conceptually in the abstract?
2018-09-26
06 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-09-26
06 Alexey Melnikov
[Ballot comment]
I feel a bit underwhelmed by this document: it defines problems, list some solutions, but doesn't always provide an advice. Statements like "The …
[Ballot comment]
I feel a bit underwhelmed by this document: it defines problems, list some solutions, but doesn't always provide an advice. Statements like "The string of inferences is questionable, and may become unneeded if other means for evaluating trustworthiness (such as positive reputations) become predominant in IPv6." are true, but doesn't really help me if I need to solve the problem.

Nit: CPE acronym is used without being defined.
2018-09-26
06 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2018-09-25
06 Adam Roach
[Ballot comment]
Thanks for the thought and work that went into this well-written document. I
have only two relatively minor comments.

---------------------------------------------------------------------------

§2.1:

>  For …
[Ballot comment]
Thanks for the thought and work that went into this well-written document. I
have only two relatively minor comments.

---------------------------------------------------------------------------

§2.1:

>  For best user experience, then, it is important to
>  return a response, rather than have a lame delegation.

In light of [1] (and its ensuing thread) and [2], the authors may wish to
consider a different term than "lame" for this description.

____
[1] https://mailarchive.ietf.org/arch/msg/ietf/W6wSh3TDfetVY6eeDAu8FNcCKeA
[2] https://en.wikipedia.org/wiki/List_of_disability-related_terms_with_negative_connotations

---------------------------------------------------------------------------

§2.5:

If I read things correctly, A naïve implementation of what is described in
this section would result in the nameserver using some amount of state for
each IPv6 PTR record that was queried, for the duration of the TTL. Given the
extraordinary expanse of IPv6 space that such a server is likely delegated, it
seems that there's an attack in here whereby an attacker asks for an arbitrary
number of PTR records within a single server's range, each resulting in
additional memory consumption for whatever time period the TTL represents.

There probably should be some text in here warning implementations to guard
against such attacks either by limiting such storage, or by generating such
names in a deterministic way such that they don't require cacheing or
pre-populating AAAA records (instead generating them on the fly)
2018-09-25
06 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2018-09-25
06 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-09-25
06 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2018-09-21
06 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Susan Hares
2018-09-21
06 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Susan Hares
2018-09-20
06 Mirja Kühlewind
[Ballot comment]
One comment on terminology: I don't think "transmission control" is actually a well-defined term, besides that TCP stands for transmission control protocol. However, …
[Ballot comment]
One comment on terminology: I don't think "transmission control" is actually a well-defined term, besides that TCP stands for transmission control protocol. However, the services TCP provides are usually called connection-orientation and reliability (and flow and congestion control aso.). I guess what's most import in your case is reliability….
2018-09-20
06 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-09-18
06 Amanda Baber (Via drafts-eval@iana.org):
2018-09-14
06 Dan Romascanu Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Dan Romascanu. Sent review to list.
2018-09-13
06 Jean Mahoney Request for Telechat review by GENART is assigned to Dan Romascanu
2018-09-13
06 Jean Mahoney Request for Telechat review by GENART is assigned to Dan Romascanu
2018-09-13
06 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2018-09-13
06 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-dnsop-isp-ip6rdns-06, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-dnsop-isp-ip6rdns-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-09-12
06 Tero Kivinen Request for Telechat review by SECDIR is assigned to Derek Atkins
2018-09-12
06 Tero Kivinen Request for Telechat review by SECDIR is assigned to Derek Atkins
2018-09-11
06 Cindy Morgan Placed on agenda for telechat - 2018-09-27
2018-09-11
06 Cindy Morgan IANA Review state changed to IANA - Review Needed
2018-09-11
06 Cindy Morgan
The following Last Call announcement was sent out (ends 2018-09-25):

From: The IESG
To: IETF-Announce
CC: tjw.ietf@gmail.com, draft-ietf-dnsop-isp-ip6rdns@ietf.org, dnsop-chairs@ietf.org, Benno Overeinder , …
The following Last Call announcement was sent out (ends 2018-09-25):

From: The IESG
To: IETF-Announce
CC: tjw.ietf@gmail.com, draft-ietf-dnsop-isp-ip6rdns@ietf.org, dnsop-chairs@ietf.org, Benno Overeinder , dnsop@ietf.org, Tim Wicinski , Suzanne Woolf , warren@kumari.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Reverse DNS in IPv6 for Internet Service Providers) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Reverse DNS in IPv6 for
Internet Service Providers'
  as Informational RFC

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
ietf@ietf.org mailing lists by 2018-09-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  In IPv4, Internet Service Providers (ISPs) commonly provide IN-
  ADDR.ARPA information for their customers by prepopulating the zone
  with one PTR record for every available address.  This practice does
  not scale in IPv6.  This document analyzes different approaches and
  considerations for ISPs in managing the IP6.ARPA zone.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/ballot/


No IPR declarations have been submitted directly on this I-D.




2018-09-11
06 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2018-09-11
06 Warren Kumari Changed consensus to Yes from Unknown
2018-09-11
06 Warren Kumari Last call was requested
2018-09-11
06 Warren Kumari Last call announcement was generated
2018-09-11
06 Warren Kumari IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2018-09-11
06 Warren Kumari Ballot has been issued
2018-09-11
06 Warren Kumari Ballot approval text was generated
2018-09-11
06 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2018-09-11
06 Warren Kumari Created "Approve" ballot
2018-09-11
06 Warren Kumari Ballot writeup was changed
2018-09-05
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-09-05
06 Lee Howard New version available: draft-ietf-dnsop-isp-ip6rdns-06.txt
2018-09-05
06 (System) New version approved
2018-09-05
06 (System) Request for posting confirmation emailed to previous authors: Lee Howard
2018-09-05
06 Lee Howard Uploaded new revision
2018-08-26
05 Warren Kumari https://www.ietf.org/mail-archive/web/dnsop/current/msg24018.html

(forgot to update substate when completing AD review)
2018-08-26
05 Warren Kumari IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2018-07-21
05 Warren Kumari IESG state changed to AD Evaluation from Publication Requested
2018-07-18
05 Tim Wicinski
1. Summary

Review of draft-ietf-dnsop-isp-ip6rdns

Document Shepherd: Tim Wicinski 
Area Director:    Warren Kumari

Document Type: This document is intended to be Informational.  It intends …
1. Summary

Review of draft-ietf-dnsop-isp-ip6rdns

Document Shepherd: Tim Wicinski 
Area Director:    Warren Kumari

Document Type: This document is intended to be Informational.  It intends
to give guidance to Internet Service Providers (ISPs) on how to manage
PTR records with IPv6.

2. Review and Consensus

This document was reviewed pretty extensively.  There were several
issues brought up during the document, which the authors and the
working group were able to resolve over time.  Since the
document presents operational guidance, there is no specific
implementations needed.

3. Intellectual Property

There is no IPR related to this document.

4. Other Points

There are no downard references in this document.

There are no IANA considerations for this document.

The only Nit with the document is this:

    The document seems to lack a both a reference to RFC 2119 and the
    recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
    keywords.

    RFC 2119 keyword, line 322: '...erior interfaces MUST NOT be processed...'
-----
Checklist

This section is not meant to be submitted, but is here as a useful
checklist of things the document shepherd is expected to have verified
before publication is requested from the responsible Area Director. If
the answers to any of these is "no", please explain the situation in
the body of the writeup.

X Does the shepherd stand behind the document and think the document is
  ready for publication?

X Is the correct RFC type indicated in the title page header?

X Is the abstract both brief and sufficient, and does it stand alone as
  a brief summary?

X Is the intent of the document accurately and adequately explained in
  the introduction?

X Have all required formal reviews (MIB Doctor, Media Type, URI, etc.)
  been requested and/or completed?

X Has the shepherd performed automated checks -- idnits (see
  http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist),
  checks of BNF rules, XML code and schemas, MIB definitions, and so
  on -- and determined that the document passes the tests? (In general,
  nits should be fixed before the document is sent to the IESG.  If there
  are reasons that some remain (false positives, perhaps, or abnormal
  things that are necessary for this particular document), explain them.)

X Has each author stated that their direct, personal knowledge of any
  IPR related to this document has already been disclosed, in conformance
  with BCPs 78 and 79?

X Have all references within this document been identified as either
  normative or informative, and does the shepherd agree with how they
  have been classified?

N/A - Are all normative references made to documents that are ready for
  advancement and are otherwise in a clear state?

N/A - If publication of this document changes the status of any existing
  RFCs, are those RFCs listed on the title page header, and are the
  changes listed in the abstract and discussed (explained, not just
  mentioned) in the introduction?

N/A - If this is a "bis" document, have all of the errata been considered?

N/A - IANA Considerations:
    - Are the IANA Considerations clear and complete? Remember that IANA
      have to understand unambiguously what's being requested, so they
      can perform the required actions.
    - Are all protocol extensions that the document makes associated
      with the appropriate reservations in IANA registries?
    - Are all IANA registries referred to by their exact names (check
      them in http://www.iana.org/protocols/ to be sure)?
    - Have you checked that any registrations made by this document
      correctly follow the policies and procedures for the appropriate
      registries?
    - For registrations that require expert review (policies of Expert
      Review or Specification Required), have you or the working group
      had any early review done, to make sure the requests are ready
      for last call?
    - For any new registries that this document creates, has the working
      group actively chosen the allocation procedures and policies and
      discussed the alternatives? Have reasonable registry names been
      chosen (that will not be confused with those of other registries),
      and have the initial contents and valid value ranges been clearly
      specified?
2018-07-18
05 Tim Wicinski Responsible AD changed to Warren Kumari
2018-07-18
05 Tim Wicinski IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2018-07-18
05 Tim Wicinski IESG state changed to Publication Requested
2018-07-18
05 Tim Wicinski IESG process started in state Publication Requested
2018-07-18
05 Tim Wicinski
Notification list changed to "Tim Wicinski" <tjw.ietf@gmail.com>, "Suzanne Woolf" <suzworldwide@gmail.com>, Benno Overeinder <benno@NLnetLabs.nl>, Tim Wicinski <tjw.ietf@gmail.com> from …
Notification list changed to "Tim Wicinski" <tjw.ietf@gmail.com>, "Suzanne Woolf" <suzworldwide@gmail.com>, Benno Overeinder <benno@NLnetLabs.nl>, Tim Wicinski <tjw.ietf@gmail.com> from "Tim Wicinski" <tjw.ietf@gmail.com>, "Suzanne Woolf" <suzworldwide@gmail.com>, Benno Overeinder <benno@NLnetLabs.nl>
2018-07-18
05 Tim Wicinski Document shepherd changed to Tim Wicinski
2018-07-18
05 Tim Wicinski Changed document writeup
2018-04-25
05 Lee Howard New version available: draft-ietf-dnsop-isp-ip6rdns-05.txt
2018-04-25
05 (System) New version approved
2018-04-25
05 (System) Request for posting confirmation emailed to previous authors: Lee Howard , dnsop-chairs@ietf.org
2018-04-25
05 Lee Howard Uploaded new revision
2018-04-18
04 Tim Wicinski IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2018-04-18
04 Tim Wicinski
Notification list changed to "Tim Wicinski" <tjw.ietf@gmail.com>, "Suzanne Woolf" <suzworldwide@gmail.com>, Benno Overeinder <benno@NLnetLabs.nl> from "Tim Wicinski" <tjw.ietf@gmail.com>, …
Notification list changed to "Tim Wicinski" <tjw.ietf@gmail.com>, "Suzanne Woolf" <suzworldwide@gmail.com>, Benno Overeinder <benno@NLnetLabs.nl> from "Tim Wicinski" <tjw.ietf@gmail.com>, "Suzanne Woolf" <suzworldwide@gmail.com>
2018-04-18
04 Tim Wicinski Document shepherd changed to Benno Overeinder
2017-11-14
04 Lee Howard New version available: draft-ietf-dnsop-isp-ip6rdns-04.txt
2017-11-14
04 (System) New version approved
2017-11-14
04 (System) Request for posting confirmation emailed to previous authors: Lee Howard
2017-11-14
04 Lee Howard Uploaded new revision
2017-09-16
03 (System) Document has expired
2017-03-15
03 Lee Howard New version available: draft-ietf-dnsop-isp-ip6rdns-03.txt
2017-03-15
03 (System) Forced post of submission
2017-03-04
03 (System) Request for posting confirmation emailed to previous authors: dnsop-chairs@ietf.org, Lee Howard
2017-03-04
03 Lee Howard Uploaded new revision
2017-01-19
02 (System) Document has expired
2016-07-18
02 Lee Howard New version available: draft-ietf-dnsop-isp-ip6rdns-02.txt
2016-05-24
01 Tim Wicinski IETF WG state changed to In WG Last Call from WG Document
2016-04-25
01 Tim Wicinski Notification list changed to "Tim Wicinski" <tjw.ietf@gmail.com>, "Suzanne Woolf" <suzworldwide@gmail.com> from "Tim Wicinski" <tjw.ietf@gmail.com>
2016-04-25
01 Tim Wicinski Document shepherd changed to Suzanne Woolf
2015-12-22
01 Lee Howard New version available: draft-ietf-dnsop-isp-ip6rdns-01.txt
2015-12-02
00 Tim Wicinski Notification list changed to "Tim Wicinski" <tjw.ietf@gmail.com>
2015-12-02
00 Tim Wicinski Document shepherd changed to Tim Wicinski
2015-10-16
00 Tim Wicinski Intended Status changed to Informational from None
2015-10-16
00 Tim Wicinski This document now replaces draft-howard-isp-ip6rdns instead of None
2015-10-16
00 Lee Howard New version available: draft-ietf-dnsop-isp-ip6rdns-00.txt