draft-ietf-dnsop-hardie-shared-root-server-07.txt   rfc3258.txt 
IETF DNSOPS working group T. Hardie Network Working Group T. Hardie
Internet draft Nominum, Inc Request for Comments: 3258 Nominum, Inc.
Category: Work-in-progress January, 2002 Category: Informational April 2002
draft-ietf-dnsop-hardie-shared-root-server-07.txt
Distributing Authoritative Name Servers via Shared Unicast Addresses Distributing Authoritative Name Servers via Shared Unicast Addresses
Status of this memo Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see This memo provides information for the Internet community. It does
http://www.ietf.org/shadow.html. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 1999. All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This memo describes a set of practices intended to enable an This memo describes a set of practices intended to enable an
authoritative name server operator to provide access to a single authoritative name server operator to provide access to a single
named server in multiple locations. The primary motivation for the named server in multiple locations. The primary motivation for the
development and deployment of these practices is to increase the development and deployment of these practices is to increase the
distribution of DNS servers to previously under-served areas of the distribution of Domain Name System (DNS) servers to previously
network topology and to reduce the latency for DNS query responses under-served areas of the network topology and to reduce the latency
in those areas. This document presumes a one-to-one mapping between for DNS query responses in those areas.
named authoritative servers and administrative entities (operators).
This document contains no guidelines or recommendations for caching
name servers. The shared unicast system described here is specific
to IPv4; applicability to IPv6 is an area for further study. It
should also be noted that the system described here is related to
that described in [ANYCAST], but it does not require dedicated
address space, routing changes, or the other elements of a full
anycast infrastructure which that document describes.
1. Architecture 1. Introduction
1.1 Server Requirements This memo describes a set of practices intended to enable an
authoritative name server operator to provide access to a single
named server in multiple locations. The primary motivation for the
development and deployment of these practices is to increase the
distribution of DNS servers to previously under-served areas of the
network topology and to reduce the latency for DNS query responses in
those areas. This document presumes a one-to-one mapping between
named authoritative servers and administrative entities (operators).
This document contains no guidelines or recommendations for caching
name servers. The shared unicast system described here is specific
to IPv4; applicability to IPv6 is an area for further study. It
should also be noted that the system described here is related to
that described in [ANYCAST], but it does not require dedicated
address space, routing changes, or the other elements of a full
anycast infrastructure which that document describes.
Operators of authoritative name servers may wish to refer to 2. Architecture
[SECONDARY] and [ROOT] for general guidance on appropriate practice
for authoritative name servers. In addition to proper configuration
as a standard authoritative name server, each of the hosts
participating in a shared-unicast system should be configured with
two network interfaces. These interfaces may be either two physical
interfaces or one physical interface mapped to two logical
interfaces. One of the network interfaces should use the IPv4
shared unicast address associated with the authoritative name
server. The other interface, referred to as the administrative
interface below, should use a distinct IPv4 address specific to that
host. The host should respond to DNS queries only on the
shared-unicast interface. In order to provide the most consistent
set of responses from the mesh of anycast hosts, it is good practice
to limit responses on that interface to zones for which the host is
authoritative.
1.2 Zone file delivery 2.1 Server Requirements
In order to minimize the risk of man-in-the-middle attacks, zone Operators of authoritative name servers may wish to refer to
files should be delivered to the administrative interface of the [SECONDARY] and [ROOT] for general guidance on appropriate practice
servers participating in the mesh. Secure file transfer methods and for authoritative name servers. In addition to proper configuration
strong authentication should be used for all transfers. If the hosts as a standard authoritative name server, each of the hosts
in the mesh make their zones available for zone transfer, the administrative participating in a shared-unicast system should be configured with
interfaces should be used for those transfers as well, in order to avoid two network interfaces. These interfaces may be either two physical
the problems with potential routing changes for TCP traffic interfaces or one physical interface mapped to two logical
noted in section 1.5 below. interfaces. One of the network interfaces should use the IPv4 shared
unicast address associated with the authoritative name server. The
other interface, referred to as the administrative interface below,
should use a distinct IPv4 address specific to that host. The host
should respond to DNS queries only on the shared-unicast interface.
In order to provide the most consistent set of responses from the
mesh of anycast hosts, it is good practice to limit responses on that
interface to zones for which the host is authoritative.
1.3 Synchronization 2.2 Zone file delivery
Authoritative name servers may be loosely or tightly synchronized, In order to minimize the risk of man-in-the-middle attacks, zone
depending on the practices set by the operating organization. As files should be delivered to the administrative interface of the
noted below in section 3.1.2, lack of synchronization among servers servers participating in the mesh. Secure file transfer methods and
using the same shared unicast address could create problems for some strong authentication should be used for all transfers. If the hosts
users of this service. In order to minimize that risk, switch-overs in the mesh make their zones available for zone transfer, the
from one data set to another data set should be coordinated as much administrative interfaces should be used for those transfers as well,
as possible. The use of synchronized clocks on the participating in order to avoid the problems with potential routing changes for TCP
hosts and set times for switch-overs provides a basic level of traffic noted in section 2.5 below.
coordination. A more complete coordination process would involve:
a) receipt of zones at a distribution host 2.3 Synchronization
b) confirmation of the integrity of zones received
c) distribution of the zones to all of the servers in the
mesh
d) confirmation of the integrity of the zones at each server
e) coordination of the switchover times for the servers in the
mesh
f) institution of a failure process to ensure that servers that
did not receive correct data or could not switchover to the
new data ceased to respond to incoming queries until the
problem could be resolved.
Depending on the size of the mesh, the distribution host may also be Authoritative name servers may be loosely or tightly synchronized,
a participant; for authoritative servers, it may also be the host on depending on the practices set by the operating organization. As
which zones are generated. noted below in section 4.1.2, lack of synchronization among servers
using the same shared unicast address could create problems for some
users of this service. In order to minimize that risk, switch-overs
from one data set to another data set should be coordinated as much
as possible. The use of synchronized clocks on the participating
hosts and set times for switch-overs provides a basic level of
coordination. A more complete coordination process would involve:
This document presumes that the usual DNS failover methods are the a) receipt of zones at a distribution host
only ones used to ensure reachability of the data for clients. It b) confirmation of the integrity of zones received
does not advise that the routes be withdrawn in the case of failure; c) distribution of the zones to all of the servers in the mesh
it advises instead the the DNS process shutdown so that servers on d) confirmation of the integrity of the zones at each server
other addresses are queried. This recommendation reflects a choice e) coordination of the switchover times for the servers in the
between performance and operational complexity. While it would be mesh
possible to have some process withdraw the route for a specific f) institution of a failure process to ensure that servers that
server instance when it is not available, there is considerable did not receive correct data or could not switchover to the new
operational complexity involved in ensuring that this occurs data ceased to respond to incoming queries until the problem
reliably. Given the existing DNS failover methods, the marginal could be resolved.
improvement in performance will not be sufficient to justify
the additional complexity for most uses.
1.4 Server Placement Depending on the size of the mesh, the distribution host may also be
a participant; for authoritative servers, it may also be the host on
which zones are generated.
Though the geographic diversity of server placement helps reduce the This document presumes that the usual DNS failover methods are the
effects of service disruptions due to local problems, it is only ones used to ensure reachability of the data for clients. It
diversity of placement in the network topology which is the driving does not advise that the routes be withdrawn in the case of failure;
force behind these distribution practices. Server placement should it advises instead that the DNS process shutdown so that servers on
emphasize that diversity. Ideally, servers should be placed other addresses are queried. This recommendation reflects a choice
topologically near the points at which the operator exchanges routes between performance and operational complexity. While it would be
and traffic with other networks. possible to have some process withdraw the route for a specific
server instance when it is not available, there is considerable
operational complexity involved in ensuring that this occurs
reliably. Given the existing DNS failover methods, the marginal
improvement in performance will not be sufficient to justify the
additional complexity for most uses.
1.5 Routing 2.4 Server Placement
The organization administering the mesh of servers sharing a unicast Though the geographic diversity of server placement helps reduce the
address must have an autonomous system number and speak BGP to its effects of service disruptions due to local problems, it is diversity
peers. To those peers, the organization announces a route to the of placement in the network topology which is the driving force
network containing the shared-unicast address of the name server. behind these distribution practices. Server placement should
The organization's border routers must then deliver the traffic emphasize that diversity. Ideally, servers should be placed
destined for the name server to the nearest instantiation. Routing topologically near the points at which the operator exchanges routes
to the administrative interfaces for the servers can use the normal and traffic with other networks.
routing methods for the administering organization.
One potential problem with using shared unicast addresses is that 2.5 Routing
routers forwarding traffic to them may have more than one available
route, and those routes may, in fact, reach different instances of
the shared unicast address. Applications like the DNS, whose
communication typically consists of independent request-response
messages each fitting in a single UDP packet presents no problem.
Other applications, in which multiple packets must reach the same
endpoint (e.g., TCP) may fail or present unworkable performance
characteristics in some circumstances. Split-destination failures
may occur when a router does per-packet (or round-robin) load
sharing, a topology change occurs that changes the relative metrics
of two paths to the same anycast destination, etc.
Four things mitigate the severity of this problem. The first is The organization administering the mesh of servers sharing a unicast
that UDP is a fairly high proportion of the query traffic to name address must have an autonomous system number and speak BGP to its
servers. The second is that the aim of this proposal is to peers. To those peers, the organization announces a route to the
diversify topological placement; for most users, this means that the network containing the shared-unicast address of the name server.
coordination of placement will ensure that new instances of a name The organization's border routers must then deliver the traffic
server will be at a significantly different cost metric from destined for the name server to the nearest instantiation. Routing
existing instances. Some set of users may end up in the middle, but to the administrative interfaces for the servers can use the normal
that should be relatively rare. The third is that per packet load routing methods for the administering organization.
sharing is only one of the possible load sharing mechanisms, and
other mechanisms are increasing in popularity.
Lastly, in the case where the traffic is TCP, per packet load One potential problem with using shared unicast addresses is that
sharing is used, and equal cost routes to different instances of a routers forwarding traffic to them may have more than one available
name server are available, any DNS implementation which measures the route, and those routes may, in fact, reach different instances of
performance of servers to select a preferred server will quickly the shared unicast address. Applications like the DNS, whose
prefer a server for which this problem does not occur. For the DNS communication typically consists of independent request-response
failover mechanisms to reliably avoid this problem, however, those messages each fitting in a single UDP packet present no problem.
using shared unicast distribution mechanisms must take care that all Other applications, in which multiple packets must reach the same
of the servers for a specific zone are not participants in the same endpoint (e.g., TCP) may fail or present unworkable performance
shared-unicast mesh. To guard even against the case where multiple characteristics in some circumstances. Split-destination failures
meshes have a set of users affected by per packet load sharing along may occur when a router does per-packet (or round-robin) load
equal cost routes, organizations implementing these practices should sharing, a topology change occurs that changes the relative metrics
always provide at least one authoritative server which is not a of two paths to the same anycast destination, etc.
participant in any shared unicast mesh. Those deploying
shared-unicast meshes should note that any specific host may become
unreachable to a client should a server fail, a path fail, or the
route to that host be withdrawn. These error conditions are,
however, not specific to shared-unicast distributions, but would
occur for standard unicast hosts.
Since ICMP response packets might go to a different member of the Four things mitigate the severity of this problem. The first is that
mesh than that sending a packet, packets sent with a shared unicast UDP is a fairly high proportion of the query traffic to name servers.
source address should also avoid using path MTU discovery. The second is that the aim of this proposal is to diversify
topological placement; for most users, this means that the
coordination of placement will ensure that new instances of a name
server will be at a significantly different cost metric from existing
instances. Some set of users may end up in the middle, but that
should be relatively rare. The third is that per packet load sharing
is only one of the possible load sharing mechanisms, and other
mechanisms are increasing in popularity.
Appendix A. contains an ASCII diagram of a example of a simple Lastly, in the case where the traffic is TCP, per packet load sharing
implementation of this system. In it, the odd numbered routers is used, and equal cost routes to different instances of a name
deliver traffic to the shared-unicast interface network and filter server are available, any DNS implementation which measures the
traffic from the administrative network; the even numbered routers performance of servers to select a preferred server will quickly
deliver traffic to the administrative network and filter traffic prefer a server for which this problem does not occur. For the DNS
from the shared-unicast network. These are depicted as separate failover mechanisms to reliably avoid this problem, however, those
routers for the ease this gives in explanation, but they could using shared unicast distribution mechanisms must take care that all
easily be separate interfaces on the same router. Similarly, a of the servers for a specific zone are not participants in the same
local NTP source is depicted for synchronization, but the level of shared-unicast mesh. To guard even against the case where multiple
synchronization needed would not require that source to be either meshes have a set of users affected by per packet load sharing along
local or a stratum one NTP server. equal cost routes, organizations implementing these practices should
always provide at least one authoritative server which is not a
participant in any shared unicast mesh. Those deploying shared-
unicast meshes should note that any specific host may become
unreachable to a client should a server fail, a path fail, or the
route to that host be withdrawn. These error conditions are,
however, not specific to shared-unicast distributions, but would
occur for standard unicast hosts.
2. Administration Since ICMP response packets might go to a different member of the
mesh than that sending a packet, packets sent with a shared unicast
source address should also avoid using path MTU discovery.
2.1 Points of Contact Appendix A. contains an ASCII diagram of an example of a simple
implementation of this system. In it, the odd numbered routers
deliver traffic to the shared-unicast interface network and filter
traffic from the administrative network; the even numbered routers
deliver traffic to the administrative network and filter traffic from
the shared-unicast network. These are depicted as separate routers
for the ease this gives in explanation, but they could easily be
separate interfaces on the same router. Similarly, a local NTP
source is depicted for synchronization, but the level of
synchronization needed would not require that source to be either
local or a stratum one NTP server.
3. Administration
3.1 Points of Contact
A single point of contact for reporting problems is crucial to the A single point of contact for reporting problems is crucial to the
correct administration of this system. If an external user of the correct administration of this system. If an external user of the
system needs to report a problem related to the service, there must system needs to report a problem related to the service, there must
be no ambiguity about whom to contact. If internal monitoring does be no ambiguity about whom to contact. If internal monitoring does
not indicate a problem, the contact may, of course, need to work not indicate a problem, the contact may, of course, need to work with
with the external user to identify which server generated the the external user to identify which server generated the error.
error.
3. Security Considerations 4. Security Considerations
As a core piece of Internet infrastructure, authoritative name As a core piece of Internet infrastructure, authoritative name
servers are common targets of attack. The practices outlined here servers are common targets of attack. The practices outlined here
increase the risk of certain kinds of attack and reduce the risk of increase the risk of certain kinds of attacks and reduce the risk of
others. others.
3.1 Increased Risks 4.1 Increased Risks
3.1.1 Increase in physical servers 4.1.1 Increase in physical servers
The architecture outlined in this document increases the number of The architecture outlined in this document increases the number of
physical servers, which could increase the possibility that a physical servers, which could increase the possibility that a server
server mis-configuration will occur which allows for a security mis-configuration will occur which allows for a security breach. In
breach. In general, the entity administering a mesh should ensure general, the entity administering a mesh should ensure that patches
that patches and security mechanisms applied to a single member of and security mechanisms applied to a single member of the mesh are
the mesh are appropriate for and applied to all of the members of a appropriate for and applied to all of the members of a mesh.
mesh. "Genetic diversity" (code from different code bases) can be "Genetic diversity" (code from different code bases) can be a useful
a useful security measure in avoiding attacks based on security measure in avoiding attacks based on vulnerabilities in a
vulnerabilities in a specific code base; in order to ensure specific code base; in order to ensure consistency of responses from
consistency of responses from a single named server, however, that a single named server, however, that diversity should be applied to
diversity should be applied to different shared-unicast meshes or different shared-unicast meshes or between a mesh and a related
between a mesh and a related unicast authoritative server. unicast authoritative server.
3.1.2 Data synchronization problems 4.1.2 Data synchronization problems
The level of systemic synchronization described above should be The level of systemic synchronization described above should be
augmented by synchronization of the data present at each of the augmented by synchronization of the data present at each of the
servers. While the DNS itself is a loosely coupled system, servers. While the DNS itself is a loosely coupled system, debugging
debugging problems with data in specific zones would be far more problems with data in specific zones would be far more difficult if
difficult if two different servers sharing a single unicast address two different servers sharing a single unicast address might return
might return different responses to the same query. For example, different responses to the same query. For example, if the data
if the data associated with www.example.com has changed and the associated with www.example.com has changed and the administrators of
administrators of the domain are testing for the changes at the the domain are testing for the changes at the example.com
example.com authoritative name servers, they should not need to authoritative name servers, they should not need to check each
check each instance of a named root server. The use of ntp to instance of a named authoritative server. The use of NTP to provide
provide a synchronized time for switch-over eliminates some aspects a synchronized time for switch-over eliminates some aspects of this
of this problem, but mechanisms to handle failure during the problem, but mechanisms to handle failure during the switchover are
switchover are required. In particular, a server which cannot make required. In particular, a server which cannot make the switchover
the switchover must not roll-back to a previous version; it must must not roll-back to a previous version; it must cease to respond to
cease to respond to queries so that other servers are queried. queries so that other servers are queried.
3.1.3 Distribution risks 4.1.3 Distribution risks
If the mechanism used to distribute zone files among the servers is If the mechanism used to distribute zone files among the servers is
not well secured, a man-in-the-middle attack could result in the not well secured, a man-in-the-middle attack could result in the
injection of false information. Digital signatures will alleviate injection of false information. Digital signatures will alleviate
this risk, but encrypted transport and tight access lists are a this risk, but encrypted transport and tight access lists are a
necessary adjunct to them. Since zone files will be distributed to necessary adjunct to them. Since zone files will be distributed to
the administrative interfaces of meshed servers, the access control the administrative interfaces of meshed servers, the access control
list for distribution of the zone files should include the list for distribution of the zone files should include the
administrative interface of the server or servers, rather than administrative interface of the server or servers, rather than their
their shared unicast addresses. shared unicast addresses.
3.2 Decreased Risks 4.2 Decreased Risks
The increase in number of physical servers reduces the likelihood The increase in number of physical servers reduces the likelihood
that a denial-of-service attack will take out a significant portion that a denial-of-service attack will take out a significant portion
of the DNS infrastructure. The increase in servers also reduces of the DNS infrastructure. The increase in servers also reduces the
the effect of machine crashes, fiber cuts, and localized disasters effect of machine crashes, fiber cuts, and localized disasters by
by reducing the number of users dependent on a specific machine. reducing the number of users dependent on a specific machine.
4. Full copyright statement
Copyright (C) The Internet Society 1999. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
5. Acknowledgments 5. Acknowledgments
Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak, Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak,
Mark Andrews, Robert Elz, Geoff Houston, Bill Norton, Akira Kato, Mark Andrews, Robert Elz, Geoff Huston, Bill Norton, Akira Kato,
Suzanne Woolf, Scott Tucker, Bernard Aboba, Casey Ajalat and Gunnar Suzanne Woolf, Bernard Aboba, Casey Ajalat, and Gunnar Lindberg all
Lindberg all provided input and commentary on this work. provided input and commentary on this work. The editor wishes to
remember in particular the contribution of the late Scott Tucker,
whose extensive systems experience and plain common sense both
contributed greatly to the editor's own deployment experience and are
missed by all who knew him.
6. References 6. References
[SECONDARY] "Selection and Operation of Secondary Name Servers". [SECONDARY] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection
R. Elz, R. Bush, S Bradner, M. Patton, BCP0016. and Operation of Secondary DNS Servers", BCP 16, RFC
2182, July 1997.
[ROOT] "Root Name Server Operational Requirements". R. Bush, [ROOT] Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root
D. Karrenberg, M. Kosters, R. Plzak, BCP0040. Name Server Operational Requirements", BCP 40, RFC 2870,
June 2000.
[ANYCAST] "Host Anycasting Service". C. Patridge, T. Mendez, W. Milliken, [ANYCAST] Patridge, C., Mendez, T. and W. Milliken, "Host
RFC1546. Anycasting Service", RFC 1546, November 1993.
7. Editor's address Appendix A.
__________________
Peer 1-| |
Peer 2-| |
Peer 3-| Switch |
Transit| | _________ _________
etc | |--|Router1|---|----|----------|Router2|---WAN-|
| | --------- | | --------- |
| | | | |
| | | | |
------------------ [NTP] [DNS] |
|
|
|
|
__________________ |
Peer 1-| | |
Peer 2-| | |
Peer 3-| Switch | |
Transit| | _________ _________ |
etc | |--|Router3|---|----|----------|Router4|---WAN-|
| | --------- | | --------- |
| | | | |
| | | | |
------------------ [NTP] [DNS] |
|
|
|
|
__________________ |
Peer 1-| | |
Peer 2-| | |
Peer 3-| Switch | |
Transit| | _________ _________ |
etc | |--|Router5|---|----|----------|Router6|---WAN-|
| | --------- | | --------- |
| | | | |
| | | | |
------------------ [NTP] [DNS] |
|
|
|
|
__________________ |
Peer 1-| | |
Peer 2-| | |
Peer 3-| Switch | |
Transit| | _________ _________ |
etc | |--|Router7|---|----|----------|Router8|---WAN-|
| | --------- | | ---------
| | | |
| | | |
------------------ [NTP] [DNS]
7. Editor's Address
Ted Hardie Ted Hardie
Nominum, Inc. Nominum, Inc.
950 Charter St. 2385 Bay Road.
Redwood City, CA 94063 Redwood City, CA 94063
Ted.Hardie@nominum.com
Tel: 1.650.381.6226
Appendix A. Phone: 1.650.381.6226
EMail: Ted.Hardie@nominum.com
__________________ 8. Full Copyright Statement
Peer 1-| |
Peer 2-| | Copyright (C) The Internet Society (2002). All Rights Reserved.
Peer 3-| Switch |
Transit| | _________ _________ This document and translations of it may be copied and furnished to
etc | |--|Router1|---|----|--------------|Router2|---WAN-| others, and derivative works that comment on or otherwise explain it
| | --------- | | --------- | or assist in its implementation may be prepared, copied, published
| | | | | and distributed, in whole or in part, without restriction of any
| | | | | kind, provided that the above copyright notice and this paragraph are
------------------ [NTP] [DNS] | included on all such copies and derivative works. However, this
| document itself may not be modified in any way, such as by removing
| the copyright notice or references to the Internet Society or other
| Internet organizations, except as needed for the purpose of
| developing Internet standards in which case the procedures for
__________________ | copyrights defined in the Internet Standards process must be
Peer 1-| | | followed, or as required to translate it into languages other than
Peer 2-| | | English.
Peer 3-| Switch | |
Transit| | _________ _________ | The limited permissions granted above are perpetual and will not be
etc | |--|Router3|---|----|--------------|Router4|---WAN-| revoked by the Internet Society or its successors or assigns.
| | --------- | | --------- |
| | | | | This document and the information contained herein is provided on an
| | | | | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
------------------ [NTP] [DNS] | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
| BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
| HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
| MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
__________________ | Acknowledgement
Peer 1-| | |
Peer 2-| | | Funding for the RFC Editor function is currently provided by the
Peer 3-| Switch | | Internet Society.
Transit| | _________ _________ |
etc | |--|Router5|---|----|--------------|Router6|---WAN-|
| | --------- | | --------- |
| | | | |
| | | | |
------------------ [NTP] [DNS] |
|
|
|
|
__________________ |
Peer 1-| | |
Peer 2-| | |
Peer 3-| Switch | |
Transit| | _________ _________ |
etc | |--|Router7|---|----|--------------|Router8|---WAN-|
| | --------- | | ---------
| | | |
| | | |
------------------ [NTP] [DNS]
 End of changes. 47 change blocks. 
258 lines changed or deleted 279 lines changed or added

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