draft-ietf-dnsop-isp-ip6rdns-07.txt   rfc8501.txt 
Network Working Group L. Howard
Internet-Draft Retevia Internet Engineering Task Force (IETF) L. Howard
Intended status: Informational September 26, 2018 Request for Comments: 8501 Retevia
Expires: March 30, 2019 Category: Informational November 2018
ISSN: 2070-1721
Reverse DNS in IPv6 for Internet Service Providers Reverse DNS in IPv6 for Internet Service Providers
draft-ietf-dnsop-isp-ip6rdns-07
Abstract Abstract
In IPv4, Internet Service Providers (ISPs) commonly provide IN- In IPv4, Internet Service Providers (ISPs) commonly provide
ADDR.ARPA information for their customers by prepopulating the zone IN-ADDR.ARPA information for their customers by prepopulating the
with one PTR record for every available address. This practice does zone with one PTR record for every available address. This practice
not scale in IPv6. This document analyzes different approaches and does not scale in IPv6. This document analyzes different approaches
considerations for ISPs in managing the IP6.ARPA zone. and considerations for ISPs in managing the IP6.ARPA zone.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on March 30, 2019. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8501.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 12 skipping to change at page 2, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Reverse DNS in IPv4 . . . . . . . . . . . . . . . . . . . 3 1.1. Reverse DNS in IPv4 . . . . . . . . . . . . . . . . . . . 3
1.2. Reverse DNS Considerations in IPv6 . . . . . . . . . . . 4 1.2. Reverse DNS Considerations in IPv6 . . . . . . . . . . . 4
2. Alternatives in IPv6 . . . . . . . . . . . . . . . . . . . . 4 2. Alternatives in IPv6 . . . . . . . . . . . . . . . . . . . . 4
2.1. Negative Response . . . . . . . . . . . . . . . . . . . . 4 2.1. Negative Response . . . . . . . . . . . . . . . . . . . . 4
2.2. Wildcard match . . . . . . . . . . . . . . . . . . . . . 5 2.2. Wildcard Match . . . . . . . . . . . . . . . . . . . . . 5
2.3. Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1. Dynamic DNS from Individual Hosts . . . . . . . . . . 6 2.3.1. Dynamic DNS from Individual Hosts . . . . . . . . . . 6
2.3.2. Dynamic DNS through Residential Gateways . . . . . . 6 2.3.2. Dynamic DNS through Residential Gateways . . . . . . 7
2.3.3. Automatic DNS Delegations . . . . . . . . . . . . . . 7 2.3.3. Automatic DNS Delegations . . . . . . . . . . . . . . 7
2.3.4. Generate Dynamic Records . . . . . . . . . . . . . . 8 2.3.4. Generate Dynamic Records . . . . . . . . . . . . . . 8
2.3.5. Populate from DHCP Server . . . . . . . . . . . . . . 8 2.3.5. Populate from DHCP Server . . . . . . . . . . . . . . 8
2.3.6. Populate from RADIUS Server . . . . . . . . . . . . . 8 2.3.6. Populate from RADIUS Server . . . . . . . . . . . . . 8
2.4. Delegate DNS . . . . . . . . . . . . . . . . . . . . . . 8 2.4. Delegate DNS . . . . . . . . . . . . . . . . . . . . . . 9
2.5. Dynamically Generate PTR When Queried ('On the Fly') . . 9 2.5. Dynamically Generate PTR When Queried ("On the Fly") . . 9
3. Manual User Updates . . . . . . . . . . . . . . . . . . . . . 9 3. Manual User Updates . . . . . . . . . . . . . . . . . . . . . 10
4. Considerations and Recommendations . . . . . . . . . . . . . 10 4. Considerations and Recommendations . . . . . . . . . . . . . 10
5. Security and Privacy Considerations . . . . . . . . . . . . . 11 5. Security and Privacy Considerations . . . . . . . . . . . . . 11
5.1. Using Reverse DNS for Security . . . . . . . . . . . . . 11 5.1. Using Reverse DNS for Security . . . . . . . . . . . . . 11
5.2. DNS Security with Dynamic DNS . . . . . . . . . . . . . . 11 5.2. DNS Security with Dynamic DNS . . . . . . . . . . . . . . 11
5.3. Considerations for Other Uses of the DNS . . . . . . . . 11 5.3. Considerations for Other Uses of the DNS . . . . . . . . 12
5.4. Privacy Considerations . . . . . . . . . . . . . . . . . 11 5.4. Privacy Considerations . . . . . . . . . . . . . . . . . 12
5.5. User Creativity . . . . . . . . . . . . . . . . . . . . . 12 5.5. User Creativity . . . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
[RFC1912] recommended that "every internet-reachable host should have [RFC1912] recommended that "every Internet-reachable host should have
a name" and says "Failure to have matching PTR and A records can a name" and says "Failure to have matching PTR and A records can
cause loss of Internet services similar to not being registered in cause loss of Internet services similar to not being registered in
the DNS at all." While the need for a PTR record and for it to match the DNS at all". While the need for a PTR record and for it to match
is debatable as a best practice, some network services [see is debatable as a best practice, some network services (see
Section 4] still do rely on PTR lookups, and some check the source Section 4) still do rely on PTR lookups, and some check the source
address of incoming connections and verify that the PTR and A records address of incoming connections and verify that the PTR and A records
match before providing service. match before providing service.
Individual Internet users in the residential or consumer scale, Individual Internet users on the residential or consumer scale,
including small and home businesses, are constantly joining or moving including small and home businesses, are constantly connecting to or
on the Internet. For large Internet service providers who serve moving around the Internet. For large ISPs who serve residential
residential users, maintenance of individual PTR records is users, maintenance of individual PTR records is impractical.
impractical. Administrators at ISPs should consider whether customer
PTR records are needed, and if so, evaluate methods for responding to Administrators at ISPs should consider whether customer PTR records
reverse DNS queries in IPv6. are needed, and if so, evaluate methods for responding to reverse DNS
queries in IPv6.
1.1. Reverse DNS in IPv4 1.1. Reverse DNS in IPv4
ISPs that provide access to many residential users typically assign ISPs that provide access to many residential users typically assign
one or a few IPv4 addresses to each of those users, and populate an one or a few IPv4 addresses to each of those users and populate an
IN-ADDR.ARPA zone with one PTR record for every IPv4 address. Some IN-ADDR.ARPA zone with one PTR record for every IPv4 address. Some
ISPs also configure forward zones with matching A records, so that ISPs also configure forward zones with matching A records so that
lookups match. For instance, if an ISP Example.com aggregated lookups match. For instance, if an ISP Example.com aggregated
192.0.2.0/24 at a network hub in one region, the reverse zone might 192.0.2.0/24 at a network hub in one region, the reverse zone might
look like: look like:
1.2.0.192.IN-ADDR.ARPA. IN PTR 1.string.region.example.com. 1.2.0.192.IN-ADDR.ARPA. IN PTR 1.string.region.example.com.
2.2.0.192.IN-ADDR.ARPA. IN PTR 2.string.region.example.com. 2.2.0.192.IN-ADDR.ARPA. IN PTR 2.string.region.example.com.
3.2.0.192.IN-ADDR.ARPA. IN PTR 3.string.region.example.com. 3.2.0.192.IN-ADDR.ARPA. IN PTR 3.string.region.example.com.
skipping to change at page 4, line 13 skipping to change at page 4, line 13
customers, and many create the matching A record. customers, and many create the matching A record.
1.2. Reverse DNS Considerations in IPv6 1.2. Reverse DNS Considerations in IPv6
A sample entry for 2001:0db8:0f00:0000:0012:34ff:fe56:789a might be: A sample entry for 2001:0db8:0f00:0000:0012:34ff:fe56:789a might be:
a.9.8.7.6.5.e.f.f.f.4.3.2.1.0.0.0.0.0.0.0.0.f.0.8.b.d.0.1.0.0.2 a.9.8.7.6.5.e.f.f.f.4.3.2.1.0.0.0.0.0.0.0.0.f.0.8.b.d.0.1.0.0.2
.IP6.ARPA. IN PTR 1.string.region.example.com. .IP6.ARPA. IN PTR 1.string.region.example.com.
ISPs will often delegate an IPv6 prefix to their customers. Since ISPs will often delegate an IPv6 prefix to their customers. Since
2^^80 possible addresses could be configured in an single /48 zone 2^^80 possible addresses could be configured in a single /48 zone
alone, even with automation it is impractical to write a zone with alone, it is impractical to write a zone with every possible address
every possible address entered. If 1000 entries could be written per entered, even with automation. If 1000 entries could be written per
second, the zone would still not be complete after 38 trillion years. second, the zone would still not be complete after 38 trillion years.
Furthermore, it is often impossible to associate host names and Furthermore, it is often impossible to associate hostnames and
addresses, since the 64 bits in the Interface Identifier portion of addresses, since the 64 bits in the Interface Identifier portion of
the address are frequently assigned using SLAAC (StateLess Address the address are frequently assigned using Stateless Address
Auto-Configuration) [RFC4862] when the host comes online, and may be Autoconfiguration (SLAAC) [RFC4862] when the host comes online, and
short-lived. they may be short-lived.
[RFC1912] is an informational document that says "PTR records must [RFC1912] is an Informational RFC that says "PTR records must point
point back to a valid A record" and further that the administrator back to a valid A record" and further that the administrator should
should "Make sure your PTR and A records match." This document "Make sure your PTR and A records match." Herein are considerations
considers how to follow this advice for AAAA and PTR records. for how to follow this advice for AAAA and PTR records.
2. Alternatives in IPv6 2. Alternatives in IPv6
Several options exist for providing reverse DNS in IPv6. All of Several options exist for providing reverse DNS in IPv6. All of
these options also exist for IPv4, but the scaling problem is much these options also exist for IPv4, but the scaling problem is much
less severe in IPv4. Each option should be evaluated for its scaling less severe in IPv4. Each option should be evaluated for its scaling
ability, its compliance with existing standards and best practices, ability, compliance with existing standards and best practices, and
and its availability in common systems. availability in common systems.
2.1. Negative Response 2.1. Negative Response
Some ISP DNS administrators may choose to provide only a NXDOMAIN Some ISP DNS administrators may choose to provide only an NXDOMAIN
response to PTR queries for subscriber addresses. In some ways, this response to PTR queries for subscriber addresses. In some ways, this
is the most accurate response, since no name information is known is the most accurate response, since no name information is known
about the host. Providing a negative response in response to PTR about the host. However, providing a negative response to PTR
queries does not satisfy the expectation in [RFC1912] for entries to queries does not satisfy the expectation in [RFC1912] for entries to
match. Users of services which are dependent on a successful lookup match. Users of services that are dependent on a successful lookup
will have a poor experience. For instance, some web services and SSH will have a poor experience. For instance, some web services and
connections wait for a DNS response, even NXDOMAIN, before Secure Shell (SSH) connections wait for a DNS response, even
responding. For best user experience, then, it is important to NXDOMAIN, before responding. For the best user experience, then, it
return a response, rather than time out with no answer. On the other is important to return a response, rather than time out with no
hand, external mail servers are likely to reject connections, which answer. On the other hand, external mail servers are likely to
might be an advantage in fighting spam. DNS administrators should reject connections, which might be an advantage in fighting spam.
consider the uses for reverse DNS records and the number of services
affecting the number of users when evaluating this option.
2.2. Wildcard match When evaluating this option, DNS administrators should consider the
uses for reverse DNS records and the number of services affecting the
number of users.
2.2. Wildcard Match
The use of wildcards in the DNS is described in [RFC4592], and their The use of wildcards in the DNS is described in [RFC4592], and their
use in IPv6 reverse DNS is described in [RFC4472]. use in IPv6 reverse DNS is described in [RFC4472].
While recording all possible addresses is not scalable, it may be While recording all possible addresses is not scalable, it may be
possible to record a wildcard entry for each prefix assigned to a possible to record a wildcard entry for each prefix assigned to a
customer. Consider also that "inclusion of wildcard NS RRSets in a customer. Consider also that "inclusion of wildcard NS RRSets in a
zone is discouraged, but not barred." [RFC4035] zone is discouraged, but not barred". [RFC4592]
This solution generally scales well. However, since the response This solution generally scales well. However, since the response
will match any address in the wildcard range (/48, /56, /64, etc.), a will match any address in the wildcard range (/48, /56, /64, etc.), a
forward DNS lookup on that response given will not be able to return forward DNS lookup on the response given will not be able to return
the same hostname. This method therefore fails the expectation in the same hostname. This method therefore fails the expectation in
[RFC1912] for forward and reverse to match. DNSSEC [RFC4035] [RFC1912] that forward and reverse will match. DNSSEC [RFC4035]
scalability is limited to signing the wildcard zone, which may be scalability is limited to signing the wildcard zone, which may be
satisfactory. satisfactory.
2.3. Dynamic DNS 2.3. Dynamic DNS
One way to ensure forward and reverse records match is for hosts to One way to ensure that forward and reverse records match is for hosts
update DNS servers dynamically, once interface configuration (whether to update DNS servers dynamically once interface configuration is
SLAAC, DHCPv6, or other means) is complete, as described in complete (whether by SLAAC, DHCPv6, or other means), as described in
[RFC4472]. Hosts would need to provide both AAAA and PTR updates, [RFC4472]. Hosts would need to provide both AAAA and PTR updates and
and would need to know which servers would accept the information. would need to know which servers would accept the information.
This option should scale as well or as poorly as IPv4 dynamic DNS This option should scale as well or as poorly as IPv4 dynamic DNS
(dDNS) does. Dynamic DNS may not scale effectively in large ISP (DDNS) does. Dynamic DNS may not scale effectively in large ISP
networks which have no single master name server, but a single master networks that have no single master name server, but a single master
server is not best practice. The ISP's DNS system may provide a server is not best practice. The ISP's DNS system may provide a
point for Denial of Service attacks, including many attempted dDNS point for Denial-of-Service attacks, including many attempted DDNS
updates. Accepting updates only from authenticated sources may updates. Accepting updates only from authenticated sources may
mitigate this risk, but only if authentication itself does not mitigate this risk, but only if authentication itself does not
require excessive overhead. No authentication of dynamic DNS updates require excessive overhead. No authentication of dynamic DNS updates
is inherently provided; implementers should consider use of TSIG is inherently provided. Implementers should therefore consider use
[RFC2845], or at least ingress filtering so updates are only accepted of TSIG [RFC2845], or at least ingress filtering, so that updates are
from customer address space from internal network interfaces, rate only accepted from customer address space from internal network
limit the number of updates from a customer per second, and consider interfaces. They should also rate limit the number of updates from a
impacts on scalability. UDP is allowed per [RFC2136] so connection customer per second and consider impacts on scalability. UDP is
reliabilty is not assured, though the host should expect an ERROR or allowed per [RFC2136], so connection reliability is not assured,
NOERROR message from the server; TCP provides transmission control, though the host should expect an ERROR or NOERROR message from the
but the updating host would need to be configured to use TCP. server; TCP provides transmission control, but the updating host
would need to be configured to use TCP.
Administrators may want to consider user creativity if they provide Administrators may want to consider user creativity if they provide
host names, as described in Section 5.4 "User Creativity." hostnames, as described in Section 5.5, "User Creativity".
There is no assurance of uniqueness if multiple hosts try to update There is no assurance of uniqueness if multiple hosts try to update
with the same name ("mycomputer.familyname.org"). There is no with the same name ("mycomputer.familyname.org"). There is no
standard way to indicate to a host what server it should send dDNS standard way to indicate to a host what server it should send DDNS
updates to; the master listed in the SOA is often assumed to be a updates to; the master listed in the SOA is often assumed to be a
dDNS server, but this may not scale. DDNS server, but this may not scale.
2.3.1. Dynamic DNS from Individual Hosts 2.3.1. Dynamic DNS from Individual Hosts
In the simplest case, a residential user will have a single host In the simplest case, a residential user will have a single host
connected to the ISP. Since the typical residential user cannot connected to the ISP. Since the typical residential user cannot
configure IPv6 addresses and resolving name servers on their hosts, configure IPv6 addresses or resolving name servers on their hosts,
the ISP should provide address information conventionally (i.e., the ISP should provide address information conventionally -- i.e.,
their normal combination of Router Advertisements (RAs), DHCP, etc.), using their normal combination of Router Advertisements (RAs), DHCP,
and should provide a DNS Recursive Name Server and Domain Search List etc. The ISP should also provide a DNS Recursive Name Server and
as described in [RFC3646] or [RFC6106]. In determining its FQDN Domain Search List as described in [RFC3646] or [RFC8106]. In
(Fully Qualified Domain Name), a host will typically use a domain determining its Fully Qualified Domain Name (FQDN), a host will
from the Domain Search List. This is an overloading of the typically use a domain from the Domain Search List. This is an
parameter; multiple domains could be listed, since hosts may need to overloading of the parameter; multiple domains could be listed, since
search for unqualified names in multiple domains, without necessarily hosts may need to search for unqualified names in multiple domains
being a member of those domains. Administrators should consider without necessarily being a member of those domains. Administrators
whether the domain search list actually provides an appropriate DNS should consider whether the Domain Search List actually provides an
suffix(es) when considering use of this option. For purposes of appropriate DNS suffix(es) when considering use of this option. For
dynamic DNS, the host would concatenate its local hostname (e.g., the purposes of dynamic DNS, the host would concatenate its local
"hostname") plus the domain(s) in the Domain Search List (e.g., hostname (e.g., "hostname") plus the domain(s) in the Domain Search
"customer.example.com"), as in "hostname.customer.example.com." List (e.g., "customer.example.com"), as in
"hostname.customer.example.com".
Once it learns its address, and has a resolving name server, the host Once it learns its address and has a resolving name server, the host
must perform an SOA lookup on the IP6.ARPA record to be added, to must perform an SOA lookup on the IP6.ARPA record to be added in
find the owner, eventually to find the server authoritative for the order to find the owner and eventually the server that is
zone (which might accept dynamic updates). Several recursive lookups authoritative for the zone (which might accept dynamic updates).
may be required to find the longest prefix which has been delegated. Several recursive lookups may be required to find the longest prefix
The DNS administrator must designate the Primary Master Server for that has been delegated. The DNS administrator must designate the
the longest match required. Once found, the host sends dynamic AAAA Primary Master Server for the longest match required. Once found,
and PTR updates using the concatenation defined above the host sends dynamic AAAA and PTR updates using the concatenation
("hostname.customer.example.com"). defined above ("hostname.customer.example.com").
In order to use this alternative, hosts must be configured to use In order to use this alternative, hosts must be configured to use
dynamic DNS. This is not default behavior for many hosts, which is dynamic DNS. This is not default behavior for many hosts, which is
an inhibitor for the large ISP. This option may be scalable, an inhibitor for a large ISP. This option may be scalable, although
although registration following an outage may cause significant load, registration following an outage may cause significant load, and
and hosts using privacy extensions [RFC4941] may update records hosts using privacy extensions [RFC4941] may update records daily.
daily. It is up to the host to provide matching forward and reverse It is up to the host to provide matching forward and reverse records
records, and to update them when the address changes. and update them when the address changes.
2.3.2. Dynamic DNS through Residential Gateways 2.3.2. Dynamic DNS through Residential Gateways
Residential customers may have a gateway, which may provide DHCPv6 Residential customers may have a gateway, which may provide DHCPv6
service to hosts from a delegated prefix. ISPs should provide a DNS service to hosts from a delegated prefix. ISPs should provide a DNS
Recursive Name Server and Domain Search List to the gateway, as Recursive Name Server and Domain Search List to the gateway, as
described above and in [RFC3646] and [RFC6106]. There are two described above and in [RFC3646] and [RFC8106]. There are two
options for how the gateway uses this information. The first option options for how the gateway uses this information. The first option
is for the gateway to respond to DHCPv6 requests with the same DNS is for the gateway to respond to DHCPv6 requests with the same DNS
Recursive Name Server and Domain Search List provided by the ISP. Recursive Name Server and Domain Search List provided by the ISP.
The alternate option is for the gateway to relay dynamic DNS updates The alternate option is for the gateway to relay dynamic DNS updates
from hosts to the servers and domain provided by the ISP. Host from hosts to the servers and domain provided by the ISP. Host
behavior is unchanged; the host sends the same dynamic updates, behavior is unchanged; the host sends the same dynamic updates,
either to the ISP's server (as provided by the gateway), or to the either to the ISP's server (as provided by the gateway) or to the
gateway for it to forward. The gateway would need to be capable of gateway for it to forward. The gateway would need to be capable of
and configured to use dynamic DNS. and configured to use dynamic DNS.
2.3.3. Automatic DNS Delegations 2.3.3. Automatic DNS Delegations
An ISP may delegate authority for a subdomain such as An ISP may delegate authority for a subdomain, such as
"customer12345.town.AW.customer.example.com" or "customer12345.town.AW.customer.example.com" or
"customer12345.example.com" to the customer's gateway. Each domain "customer12345.example.com", to the customer's gateway. Each domain
thus delegated must be unique within the DNS. The ISP may also then thus delegated must be unique within the DNS. The ISP may also then
delegate the IP6.ARPA zone for the prefix delegated to the customer, delegate the IP6.ARPA zone for the prefix delegated to the customer,
as in (for 2001:db8:f00::/48) "0.0.f.0.8.b.d.0.1.0.0.2.IP6.ARPA." as in (for 2001:db8:f00::/48) "0.0.f.0.8.b.d.0.1.0.0.2.IP6.ARPA".
Then the customer could provide updates to their own gateway, with Then, the customer could provide updates to their own gateway, with
forward and reverse. However, individual hosts connected directly to forward and reverse. However, individual hosts connected directly to
the ISP rarely have the capability to run DNS for themselves; the ISP rarely have the capability to run DNS for themselves;
therefore, an ISP can only delegate to customers with gateways therefore, an ISP can only delegate to customers with gateways
capable of being authoritative name servers. If a device requests a capable of being authoritative name servers. If a device requests a
DHCPv6 Prefix Delegation, that may be considered a reasonably DHCPv6 Prefix Delegation, that may be considered a reasonably
reliable indicator that it is a gateway, rather than an individual reliable indicator that it is a gateway, rather than an individual
host. It is not necessarily an indicator that the gateway is capable host. It is not necessarily an indicator that the gateway is capable
of providing DNS services, and therefore cannot be relied upon as a of providing DNS services and therefore cannot be relied upon as a
way to test whether this option is feasible. In fact, this kind of way to test whether this option is feasible. In fact, this kind of
delegation will not work for devices complying with [RFC6092], which delegation will not work for devices complying with [RFC6092], which
includes the requirement, "By DEFAULT, inbound DNS queries received includes the requirement, "By DEFAULT, inbound DNS queries received
on exterior interfaces MUST NOT be processed by any integrated DNS on exterior interfaces MUST NOT be processed by any integrated DNS
resolving server." resolving server".
If the customer's gateway is the name server, it provides its own If the customer's gateway is the name server, it provides its own
information to hosts on the network, as often done for enterprise information to hosts on the network, as described in [RFC2136], which
networks, and as described in [RFC2136]. is often done for enterprise networks.
An ISP could provide authoritative responses as a secondary server to An ISP could provide authoritative responses as a secondary server to
the customer's master server. For instance, the home gateway name the customer's master server. For instance, the home gateway name
server could be the master server, with the ISP providing the only server could be the master server, with the ISP providing the only
published NS authoritative servers. published NS authoritative servers.
To implement this alternative, users' residential gateways must be To implement this alternative, users' residential gateways must be
capable of acting as authoritative name servers capable of dynamic capable of acting as authoritative name servers capable of dynamic
DNS updates. There is no mechanism for an ISP to dynamically DNS updates. There is no mechanism for an ISP to dynamically
communicate to a user's equipment that a zone has been delegated, so communicate to a user's equipment that a zone has been delegated, so
user action would be required. Most users have neither the equipment user action would be required. Most users have neither the equipment
nor the expertise to run DNS servers, so this option is unavailable nor the expertise to run DNS servers, so this option is unavailable
to the residential ISP. to the residential ISP.
2.3.4. Generate Dynamic Records 2.3.4. Generate Dynamic Records
An ISP's name server that receives a dynamic forward or reverse DNS An ISP's name server that receives a dynamic forward or reverse DNS
update may create a matching entry. Since a host capable of updating update may create a matching entry. Since a host capable of updating
one is generally capable of updating the other, this should not be one is generally capable of updating the other, this should not be
required, but redundant record creation will ensure a record exists. required, but redundant record creation will ensure that a record
ISPs implementing this method should check whether a record already exists. ISPs implementing this method should check whether a record
exists before accepting or creating updates. already exists before accepting or creating updates.
This method is also dependent on hosts being capable of providing This method is also dependent on hosts being capable of providing
dynamic DNS updates, which is not default behavior for many hosts. dynamic DNS updates, which is not default behavior for many hosts.
2.3.5. Populate from DHCP Server 2.3.5. Populate from DHCP Server
A ISP's DHCPv6 server may populate the forward and reverse zones when An ISP's DHCPv6 server may populate the forward and reverse zones
the DHCP request is received, if the request contains enough when the DHCP request is received if the request contains enough
information. [RFC4704] information [RFC4704].
However, this method will only work for a single host address However, this method will only work for a single host address
(IA_NA); the ISP's DHCP server would not have enough information to (IA_NA); the ISP's DHCP server would not have enough information to
update all records for a prefix delegation. If the zone authority is update all records for a prefix delegation. If the zone authority is
delegated to a home gateway which used this method, the gateway could delegated to a home gateway that used this method, the gateway could
update records for residential hosts. To implement this alternative, update records for residential hosts. To implement this alternative,
users' residential gateways would have to support the FQDN DHCP users' residential gateways would have to support the FQDN DHCP
option, and would have to either have the zones configured, or send option and would have to either have the zones configured or send
dDNS messages to the ISP's name server. DDNS messages to the ISP's name server.
2.3.6. Populate from RADIUS Server 2.3.6. Populate from RADIUS Server
A user may receive an address or prefix from a RADIUS [RFC2865] A user may receive an address or prefix from a RADIUS server
server, the details of which may be recorded via RADIUS Accounting [RFC2865], the details of which may be recorded via RADIUS Accounting
[RFC2866] data. The ISP may populate the forward and reverse zones data [RFC2866]. The ISP may populate the forward and reverse zones
from the accounting data if it contains enough information. This from the accounting data if it contains enough information. This
solution allows the ISP to populate data concerning allocated solution allows the ISP to populate data concerning allocated
prefixes (as per 2.2 (wildcards)) and CPE (customer premise prefixes as per Section 2.2 (wildcards) and customer premise
equipment) endpoints, but as with 2.3.5 does not allow the ISP to equipment (CPE) endpoints. However, as with Section 2.3.5, it does
populate information concerning individual hosts. not allow the ISP to populate information concerning individual
hosts.
2.4. Delegate DNS 2.4. Delegate DNS
For customers who are able to run their own DNS servers, such as For customers who are able to run their own DNS servers, such as
commercial customers, often the best option is to delegate the commercial customers, often the best option is to delegate the
reverse DNS zone to them, as described in [RFC2317] (for IPv4). reverse DNS zone to them, as described in [RFC2317] (for IPv4).
However, since most residential users have neither the equipment nor However, since most residential users have neither the equipment nor
the expertise to run DNS servers, this method is unavailable to the expertise to run DNS servers, this method is unavailable to
residential ISPs. residential ISPs.
This is a general case of the specific case described in This is a general case of the specific case described in
Section 2.3.3. All of the same considerations still apply. Section 2.3.3. All of the same considerations still apply.
2.5. Dynamically Generate PTR When Queried ('On the Fly') 2.5. Dynamically Generate PTR When Queried ("On the Fly")
Common practice in IPv4 is to provide PTR records for all addresses, Common practice in IPv4 is to provide PTR records for all addresses,
regardless of whether a host is actually using the address. In IPv6, regardless of whether a host is actually using the address. In IPv6,
ISPs may generate PTR records for all IPv6 addresses as the records ISPs may generate PTR records for all IPv6 addresses as the records
are requested. Several DNS servers are capable of this. are requested. Several DNS servers are capable of this.
An ISP using this option should generate a PTR record on demand, and An ISP using this option should generate a PTR record on demand and
cache or prepopulate the forward (AAAA) entry for the duration of the cache or prepopulate the forward (AAAA) entry for the duration of the
time-to-live of the PTR. Similarly, the ISP would prepopulate the Time to Live of the PTR. Similarly, the ISP would prepopulate the
PTR following a AAAA query. To reduce exposure to a denial of PTR following a AAAA query. To reduce exposure to a Denial-of-
service attack, state or storage should be limited. Alternatively, Service attack, state or storage should be limited. Alternatively,
if an algorithm is used to generate unique name, it can be employed if an algorithm is used to generate a unique name, it can be employed
on the fly in both directions. This option has the advantage of on the fly in both directions. This option has the advantage of
assuring matching forward and reverse entries, while being simpler assuring matching forward and reverse entries while being simpler
than dynamic DNS. Administrators should consider whether the lack of than dynamic DNS. Administrators should consider whether the lack of
user-specified hostnames is a drawback. It may be possible to allow user-specified hostnames is a drawback. It may be possible to allow
user-specified hostnames for some records and generate others on the user-specified hostnames for some records and generate others on the
fly; looking up a record before generating on the fly may slow fly; looking up a record before generating on the fly may slow
responses or may not scale well. responses or may not scale well.
DNSSEC [RFC4035] signing records on the fly may increase load; DNSSEC [RFC4035] signing records on the fly may increase load;
unsigned records can indicate that these records are less trusted, unsigned records can indicate that these records are less trusted,
which might be acceptable. which might be acceptable.
skipping to change at page 9, line 46 skipping to change at page 10, line 9
record must be the same on all servers for a zone. In other words, record must be the same on all servers for a zone. In other words,
any server for the zone must produce the same response for a given any server for the zone must produce the same response for a given
query. Administrators managing a variety of rules within a zone query. Administrators managing a variety of rules within a zone
might find it difficult to keep those rules synchronized on all might find it difficult to keep those rules synchronized on all
servers. servers.
3. Manual User Updates 3. Manual User Updates
It is possible to create a user interface, such as a web page, that It is possible to create a user interface, such as a web page, that
would allow end users to enter a hostname to associate with an would allow end users to enter a hostname to associate with an
address. Such an interface would need to be authenticated (only the address. Such an interface would need to be authenticated; only the
authorized user could add/change/delete entries). It would need to authorized user could add/change/delete entries. If the ISP changes
specify only the host bits if the ISP changes prefixes assigned to prefixes assigned to customers, the interface would need to specify
customers, and the back end would therefore need to be integrated only the host bits. The backend would therefore need to be
with prefix assignments, so that when a new prefix was assigned to a integrated with prefix assignments so that when a new prefix was
customer, the DNS service would look up user-generated hostnames and assigned to a customer, the DNS service would look up user-generated
delete the old record and create the new one. hostnames, delete the old record, and create the new one.
Considerations about some records being static and others dynamic or Considerations about some records being static and others dynamic or
dynamically generated (section 2.5) and the creativity of users dynamically generated (Section 2.5) and the creativity of users
(section 5.4) still apply. (Section 5.5) still apply.
4. Considerations and Recommendations 4. Considerations and Recommendations
There are six common uses for PTR lookups: There are six common uses for PTR lookups:
Rejecting mail: A PTR with a certain string or missing may indicate Rejecting mail: A PTR with a certain string may indicate "This host
"This host is not a mail server," which may be useful for rejecting is not a mail server", which may be useful for rejecting probable
probable spam. The absence of a PTR leads to the desired behavior. spam. The absence of a PTR leads to the desired behavior.
Serving ads: "This host is probably in town.province." An ISP that Serving ads: "This host is probably in town.province." An ISP that
does not provide PTR records might affect somebody else's geolocation does not provide PTR records might affect somebody else's geolocation
(also see privacy consideration about location). (also see privacy consideration about location).
Accepting SSH connections: The presence of a PTR may be inferred to Accepting SSH connections: The presence of a PTR may be inferred to
mean "This host has an administrator with enough clue to set up mean "This host has an administrator with enough clue to set up
forward and reverse DNS." This is a poor inference. forward and reverse DNS". This is a poor inference.
Log files: Many systems will record the PTR of remote hosts in their Log files: Many systems will record the PTR of remote hosts in their
log files, to make it easier to see what network the remote host uses log files to make it easier when reading logs later to see what
when reading logs later. network the remote host uses.
Traceroute: The ability to identify an interface and name of any Traceroute: The ability to identify an interface and name of any
intermediate node or router is important for troubleshooting. intermediate node or router is important for troubleshooting.
Service discovery: [RFC6763] specifies "DNS-based Service Discovery" Service discovery: [RFC6763] specifies "DNS-Based Service Discovery",
and section 11 specifically describes how PTRs are used. and Section 11 specifically describes how PTRs are used.
As a general guideline, when address assignment and name are under As a general guideline, when address assignment and name are under
the same authority, or when a host has a static address and name, the same authority, or when a host has a static address and name,
AAAA and PTR records should exist and match. For residential users, AAAA and PTR records should exist and match. For residential users,
if these four use cases are important to the ISP, the administrator if these use cases are important to the ISP, the administrator will
will then need to consider how to provide PTR records. then need to consider how to provide PTR records.
The best accuracy would be achieved if ISPs delegate authority along The best accuracy would be achieved if ISPs delegated authority along
with address delegation, but residential users rarely have domain with address delegation, but residential users rarely have domain
names or authoritative name servers. names or authoritative name servers.
Dynamic DNS updates can provide accurate data, but there is no Dynamic DNS updates can provide accurate data, but there is no
standard way to indicate to residential devices where to send standard way to indicate to residential devices where to send
updates, if the hosts support it, and if it scales. updates, whether the hosts support DDNS, or whether it scales.
An ISP has no knowledge of its residential users' hostnames, and An ISP has no knowledge of its residential users' hostnames and
therefore can either provide a wildcard response or a dynamically therefore can either provide a wildcard response or a dynamically
generated response. A valid negative response (such as NXDOMAIN) is generated response. A valid negative response (such as NXDOMAIN) is
a valid response, if the four cases above are not essential; a valid response if the four cases above are not essential;
delegation where no name server exists should be avoided. delegation where no name server exists should be avoided.
5. Security and Privacy Considerations 5. Security and Privacy Considerations
5.1. Using Reverse DNS for Security 5.1. Using Reverse DNS for Security
Some people think the existence of reverse DNS records, or matching Some people think the existence of reverse DNS records, or matching
forward and reverse DNS records, provides useful information about forward and reverse DNS records, provides useful information about
the hosts with those records. For example, one might infer that the the hosts with those records. For example, one might infer that the
administrator of a network with properly configured DNS records was administrator of a network with properly configured DNS records was
better-informed, and by further inference more responsible, than the better informed, and by further inference more responsible, than the
administrator of a less-thoroughly configured network. For instance, administrator of a less thoroughly configured network. For instance,
most email providers will not accept incoming connections on port 25 most email providers will not accept incoming connections on port 25
unless forward and reverse DNS entries match. If they match, but unless forward and reverse DNS entries match. If they match, but
information higher in the stack (for instance, mail source) is information higher in the stack (for instance, mail source) is
inconsistent, the packet is questionable. These records may be inconsistent, the packet is questionable. However, these records may
easily forged though, unless DNSSEC or other measures are taken. The be easily forged unless DNSSEC or other measures are taken. The
string of inferences is questionable, and may become unneeded if string of inferences is questionable and may become unneeded if other
other means for evaluating trustworthiness (such as positive means for evaluating trustworthiness (such as positive reputations)
reputations) become predominant in IPv6. become predominant in IPv6.
Providing location information in PTR records is useful for Providing location information in PTR records is useful for
troubleshooting, law enforcement, and geolocation services, but for troubleshooting, law enforcement, and geolocation services, but for
the same reasons can be considered sensitive information. the same reasons, it can be considered sensitive information.
5.2. DNS Security with Dynamic DNS 5.2. DNS Security with Dynamic DNS
Security considerations of using dynamic DNS are described in The security considerations for using dynamic DNS are described in
[RFC3007]. DNS Security Extensions are documented in [RFC4033]. [RFC3007]. DNS Security Extensions are documented in [RFC4033].
Interactions with DNSSEC are described throughout this document. Interactions with DNSSEC are described throughout this document.
5.3. Considerations for Other Uses of the DNS 5.3. Considerations for Other Uses of the DNS
Several methods exist for providing encryption keys in the DNS. Any Several methods exist for providing encryption keys in the DNS. Any
of the options presented here may interfere with these key of the options presented here may interfere with these key
techniques. techniques.
5.4. Privacy Considerations 5.4. Privacy Considerations
Given considerations in [hostname], hostnames that provide Given the considerations in [RFC8117], hostnames that provide
information about a user compromises that user's privacy. Some users information about a user compromise that user's privacy. Some users
may want to identify their hosts using user-specified hostnames, but may want to identify their hosts using user-specified hostnames, but
the default behavior should not be to identify a user, their the default behavior should not be to identify a user, their
location, their connectivity, or other information in a PTR record. location, their connectivity, or other information in a PTR record.
5.5. User Creativity 5.5. User Creativity
Though not precisely a security consideration, administrators may Though not precisely a security consideration, administrators may
want to consider what domain will contain the records, and who will want to consider what domain will contain the records and who will
provide the names. If subscribers provide hostnames, they may provide the names. If subscribers provide hostnames, they may
provide inappropriate strings. Consider "ihate.example.com" or provide inappropriate strings. Consider "ihate.example.com" or
"badword.customer.example.com" or "badword.customer.example.com" or
"celebrityname.committed.illegal.acts.example.com." "celebrityname.committed.illegal.acts.example.com".
6. Acknowledgements
The author would like to thank Alain Durand, JINMEI Tatuya, David
Freedman, Andrew Sullivan, Chris Griffiths, Darryl Tanner, Ed Lewis,
John Brzozowski, Chris Donley, Wes George, Jason Weil, John Spence,
Ted Lemon, Stephan Lagerholm, Steinar Haug, Mark Andrews, Chris
Roosenraad, Fernando Gont, John Levine, and many others who discussed
and provided suggestions for this document.
7. IANA Considerations
There are no IANA considerations or implications that arise from this 6. IANA Considerations
document.
8. References This document has no IANA actions.
8.1. Normative References 7. References
[RFC1033] Lottor, M., "Domain Administrators Operators Guide", 7.1. Normative References
November 1987.
[RFC1912] Barr, D., "Common DNS Operational and Configuration [RFC1912] Barr, D., "Common DNS Operational and Configuration
Errors", February 1996. Errors", RFC 1912, DOI 10.17487/RFC1912, February 1996,
<https://www.rfc-editor.org/info/rfc1912>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1917. "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>.
[RFC2845] "Secret Key Transaction Authentication for DNS (TSIG)". [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and
B. Wellington, "Secret Key Transaction Authentication for
DNS (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
<https://www.rfc-editor.org/info/rfc2845>.
[RFC2865] "Remote Authentication Dial In User Service (RADIUS)". [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>.
[RFC2866] "RADIUS Accounting". [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
DOI 10.17487/RFC2866, June 2000,
<https://www.rfc-editor.org/info/rfc2866>.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", November 2000. Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
<https://www.rfc-editor.org/info/rfc3007>.
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic
Configuration Protocol for IPv6 (DHCPv6)", December 2003. Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
DOI 10.17487/RFC3646, December 2003,
<https://www.rfc-editor.org/info/rfc3646>.
[RFC4033] "DNS Security Introduction and Requirements". [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and
S. Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and
Rose, "Protocol Modifications for the DNS Security Extensions", March S. Rose, "Protocol Modifications for the DNS Security
2005. Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", July 2006. System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
<https://www.rfc-editor.org/info/rfc4592>.
[RFC4704] Stapp, M., Volz, Y., and Y. Rekhter, "The Dynamic Host [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Domain Name (FQDN) Option". Option", RFC 4704, DOI 10.17487/RFC4704, October 2006,
<https://www.rfc-editor.org/info/rfc4704>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", September 2007. Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC4941] "Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
in IPv6". Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>.
[RFC6106] "IPv6 Router Advertisement Options for DNS Configuration". [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>.
[RFC6763] Cheshire, S., and Krochmal, M., "DNS-Based Service [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
Discovery", February 2013. "IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017,
<https://www.rfc-editor.org/info/rfc8106>.
8.2. Informative References 7.2. Informative References
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless
ADDR.ARPA delegation", March 1998. IN-ADDR.ARPA delegation", BCP 20, RFC 2317,
DOI 10.17487/RFC2317, March 1998,
<https://www.rfc-editor.org/info/rfc2317>.
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", April 2006. Considerations and Issues with IPv6 DNS", RFC 4472,
DOI 10.17487/RFC4472, April 2006,
<https://www.rfc-editor.org/info/rfc4472>.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security
Customer Premises Equipment (CPE) for Providing Residential IPv6 Capabilities in Customer Premises Equipment (CPE) for
Internet Service", January 2011. Providing Residential IPv6 Internet Service", RFC 6092,
DOI 10.17487/RFC6092, January 2011,
<https://www.rfc-editor.org/info/rfc6092>.
[inaddr-reqd] Senie, D., "draft-ietf-dnsop-inaddr-required-07", [RFC8117] Huitema, C., Thaler, D., and R. Winter, "Current Hostname
August 2005. Practice Considered Harmful", RFC 8117,
DOI 10.17487/RFC8117, March 2017,
<https://www.rfc-editor.org/info/rfc8117>.
[rmap-consider] Senie, D. and A. Sullivan, "draft-ietf-dnsop- Acknowledgements
reverse-mapping-considerations-06", March 2008.
[hostname] Huitema, C., Thaler, D., and R. Winter, "draft-ietf- The author would like to thank Alain Durand, JINMEI Tatuya, David
intarea-hostname-practice", February 2017. Freedman, Andrew Sullivan, Chris Griffiths, Darryl Tanner, Ed Lewis,
John Brzozowski, Chris Donley, Wes George, Jason Weil, John Spence,
Ted Lemon, Stephan Lagerholm, Steinar Haug, Mark Andrews, Chris
Roosenraad, Fernando Gont, John Levine, and many others who discussed
and provided suggestions for this document.
Author's Address Author's Address
Lee Howard Lee Howard
Retevia Retevia
Fairfax, VA 22032 Fairfax, VA 22032
USA United States of America
Email: lee.howard@retevia.net Email: lee.howard@retevia.net
 End of changes. 101 change blocks. 
251 lines changed or deleted 282 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/