--- 1/draft-ietf-grow-anycast-03.txt 2006-07-10 22:12:23.000000000 +0200 +++ 2/draft-ietf-grow-anycast-04.txt 2006-07-10 22:12:23.000000000 +0200 @@ -1,19 +1,19 @@ Network Working Group J. Abley -Internet-Draft ISC -Expires: July 28, 2006 K. Lindqvist +Internet-Draft Afilias Canada +Expires: July 5, 2006 K. Lindqvist Netnod Internet Exchange - January 24, 2006 + January 2006 Operation of Anycast Services - draft-ietf-grow-anycast-03 + draft-ietf-grow-anycast-04 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,82 +24,83 @@ 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. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on July 28, 2006. + This Internet-Draft will expire on July 5, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely. Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Anycast Service Distribution . . . . . . . . . . . . . . . . . 5 - 3.1. General Description . . . . . . . . . . . . . . . . . . . 5 - 3.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 4. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.1. Protocol Suitability . . . . . . . . . . . . . . . . . . . 7 - 4.2. Node Placement . . . . . . . . . . . . . . . . . . . . . . 7 - 4.3. Routing Systems . . . . . . . . . . . . . . . . . . . . . 8 - 4.3.1. Anycast within an IGP . . . . . . . . . . . . . . . . 8 - 4.3.2. Anycast within the Global Internet . . . . . . . . . . 9 - 4.4. Routing Considerations . . . . . . . . . . . . . . . . . . 9 - 4.4.1. Signalling Service Availability . . . . . . . . . . . 9 - 4.4.2. Covering Prefix . . . . . . . . . . . . . . . . . . . 10 - 4.4.3. Equal-Cost Paths . . . . . . . . . . . . . . . . . . . 10 - 4.4.4. Route Dampening . . . . . . . . . . . . . . . . . . . 12 - 4.4.5. Reverse Path Forwarding Checks . . . . . . . . . . . . 13 - 4.4.6. Propagation Scope . . . . . . . . . . . . . . . . . . 13 - 4.4.7. Other Peoples' Networks . . . . . . . . . . . . . . . 14 - 4.4.8. Aggregation Risks . . . . . . . . . . . . . . . . . . 14 - 4.5. Addressing Considerations . . . . . . . . . . . . . . . . 15 - 4.6. Data Synchronisation . . . . . . . . . . . . . . . . . . . 15 - 4.7. Node Autonomy . . . . . . . . . . . . . . . . . . . . . . 16 - 4.8. Multi-Service Nodes . . . . . . . . . . . . . . . . . . . 17 - 4.8.1. Multiple Covering Prefixes . . . . . . . . . . . . . . 17 - 4.8.2. Pessimistic Withdrawal . . . . . . . . . . . . . . . . 17 - 4.8.3. Intra-Node Interior Connectivity . . . . . . . . . . . 18 - 5. Service Management . . . . . . . . . . . . . . . . . . . . . . 19 - 5.1. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 19 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 - 6.1. Denial-of-Service Attack Mitigation . . . . . . . . . . . 20 - 6.2. Service Compromise . . . . . . . . . . . . . . . . . . . . 20 - 6.3. Service Hijacking . . . . . . . . . . . . . . . . . . . . 20 - 7. Protocol Considerations . . . . . . . . . . . . . . . . . . . 21 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 - Appendix A. Change History . . . . . . . . . . . . . . . . . . . 27 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 - Intellectual Property and Copyright Statements . . . . . . . . . . 29 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Anycast Service Distribution . . . . . . . . . . . . . . . . . 6 + 3.1. General Description . . . . . . . . . . . . . . . . . . . 6 + 3.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.1. Protocol Suitability . . . . . . . . . . . . . . . . . . . 8 + 4.2. Node Placement . . . . . . . . . . . . . . . . . . . . . . 8 + 4.3. Routing Systems . . . . . . . . . . . . . . . . . . . . . 9 + 4.3.1. Anycast within an IGP . . . . . . . . . . . . . . . . 9 + 4.3.2. Anycast within the Global Internet . . . . . . . . . . 10 + 4.4. Routing Considerations . . . . . . . . . . . . . . . . . . 10 + 4.4.1. Signalling Service Availability . . . . . . . . . . . 10 + 4.4.2. Covering Prefix . . . . . . . . . . . . . . . . . . . 11 + 4.4.3. Equal-Cost Paths . . . . . . . . . . . . . . . . . . . 11 + 4.4.4. Route Dampening . . . . . . . . . . . . . . . . . . . 13 + 4.4.5. Reverse Path Forwarding Checks . . . . . . . . . . . . 14 + 4.4.6. Propagation Scope . . . . . . . . . . . . . . . . . . 14 + 4.4.7. Other Peoples' Networks . . . . . . . . . . . . . . . 15 + 4.4.8. Aggregation Risks . . . . . . . . . . . . . . . . . . 15 + 4.5. Addressing Considerations . . . . . . . . . . . . . . . . 16 + 4.6. Data Synchronisation . . . . . . . . . . . . . . . . . . . 16 + 4.7. Node Autonomy . . . . . . . . . . . . . . . . . . . . . . 17 + 4.8. Multi-Service Nodes . . . . . . . . . . . . . . . . . . . 18 + 4.8.1. Multiple Covering Prefixes . . . . . . . . . . . . . . 18 + 4.8.2. Pessimistic Withdrawal . . . . . . . . . . . . . . . . 18 + 4.8.3. Intra-Node Interior Connectivity . . . . . . . . . . . 19 + 4.9. Node Identification by Clients . . . . . . . . . . . . . . 19 + 5. Service Management . . . . . . . . . . . . . . . . . . . . . . 20 + 5.1. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 20 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 + 6.1. Denial-of-Service Attack Mitigation . . . . . . . . . . . 21 + 6.2. Service Compromise . . . . . . . . . . . . . . . . . . . . 21 + 6.3. Service Hijacking . . . . . . . . . . . . . . . . . . . . 21 + 7. Protocol Considerations . . . . . . . . . . . . . . . . . . . 23 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 26 + Appendix A. Change History . . . . . . . . . . . . . . . . . . . 29 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 + Intellectual Property and Copyright Statements . . . . . . . . . . 31 1. Introduction To distribute a service using anycast, the service is first associated with a stable set of IP addresses, and reachability to those addresses is advertised in a routing system from multiple, independent service nodes. Various techniques for anycast deployment of services are discussed in [RFC1546], [ISC-TN-2003-1] and [ISC-TN- 2004-1]. @@ -116,28 +117,30 @@ years. The use of anycast is not limited to the DNS, although the use of anycast imposes some additional limitations on the nature of the service being distributed, including transaction longevity, transaction state held on servers and data synchronisation capabilities. Although anycast is conceptually simple, its implementation introduces some pitfalls for operation of services. For example, monitoring the availability of the service becomes more difficult; the observed availability changes according to the location of the - client within the network, and the client catchment of individual - anycast nodes is neither static, nor reliably deterministic. + client within the network, and the population of clients using + individual anycast nodes is neither static, nor reliably + deterministic. This document will describe the use of anycast for both local scope distribution of services using an Interior Gateway Protocol (IGP) and - global distribution using BGP [RFC1771]. Many of the issues for - monitoring and data synchronisation are common to both, but - deployment issues differ substantially. + global distribution using the Border Gateway Protocol (BGP) + [RFC4271]. Many of the issues for monitoring and data + synchronisation are common to both, but deployment issues differ + substantially. 2. Terminology Service Address: an IP address associated with a particular service (e.g. the destination address used by DNS resolvers to reach a particular authority server). Anycast: the practice of making a particular Service Address available in multiple, discrete, autonomous locations, such that datagrams sent are routed to one of several available locations. @@ -203,41 +206,42 @@ Load-balancing between Anycast Nodes is typically difficult to achieve (load distribution between nodes is generally unbalanced in terms of request and traffic load). Distribution of load between nodes for the purposes of reliability, and coarse-grained distribution of load for the purposes of making popular services scalable can often be achieved, however. The scale of the routing system through which a service is anycast can vary from a small Interior Gateway Protocol (IGP) connecting a small handful of components, to the Border Gateway Protocol (BGP) - [RFC1771] connecting the global Internet, depending on the nature of + [RFC4271] connecting the global Internet, depending on the nature of the service distribution that is required. 3.2. Goals A service may be anycast for a variety of reasons. A number of common objectives are: 1. Coarse ("unbalanced") distribution of load across nodes, to allow infrastructure to scale to increased numbers of queries and to accommodate transient query peaks; 2. Mitigation of non-distributed denial of service attacks by localising damage to single anycast nodes; 3. Constraint of distributed denial of service attacks or flash - crowds to local regions around anycast nodes (perhaps restricting - query traffic to local peering links, rather than paid transit - circuits); + crowds to local regions around anycast nodes. Anycast + distribution of a service provides the opportunity for traffic to + be handled closer to its source, perhaps using high-performance + peering links rather than oversubscribed, paid transit circuits; - 4. To provide additional information to help locate location of - traffic sources in the case of attack (or query) traffic which + 4. To provide additional information to help identify the location + of traffic sources in the case of attack (or query) traffic which incorporates spoofed source addresses. This information is derived from the property of anycast service distribution that the selection of the Anycast Node used to service a particular query may be related to the topological source of the request. 5. Improvement of query response time, by reducing the network distance between client and server with the provision of a local Anycast Node. The extent to which query response time is improved depends on the way that nodes are selected for the clients by the routing system. Topological nearness within the @@ -510,40 +514,42 @@ described in [RFC2439]. A dampened path will be suppressed by routers for an interval which increases according to the frequency of the observed oscillation; a suppressed path will not propagate. Hence a single router can prevent the propagation of a flapping prefix to the rest of an autonomous system, affording other routers in the network protection from the instability. Some implementations of flap dampening penalise oscillating - advertisements based on the observed AS_PATH, and not on the NLRI. - For this reason, network instability which leads to route flapping - from a single anycast node ought not to cause advertisements from - other nodes (which have different AS_PATH attributes) to be dampened. + advertisements based on the observed AS_PATH, and not on Network + Layer Reachability Information (NLRI; see [RFC4271]). For this + reason, network instability which leads to route flapping from a + single anycast node will not generally cause advertisements from + other nodes (which have different AS_PATH attributes) to be dampened + by these implementations. To limit the opportunity of such implementations to penalise advertisements originating from different Anycast Nodes in response to oscillations from just a single node, care should be taken to arrange that the AS_PATH attributes on routes from different nodes are as diverse as possible. For example, Anycast Nodes should use the same origin AS for their advertisements, but might have different upstream ASes. Where different implementations of flap dampening are prevalent, individual nodes' instability may result in stable nodes becoming unavailable. In mitigation, the following measures may be useful: 1. Judicious deployment of Local Nodes in combination with especially stable Global Nodes (with high inter-AS path splay, - redundant hardware, power, etc) may help limit oscillation + redundant hardware, power, etc.) may help limit oscillation problems to the Local Nodes' limited regions of influence; 2. Aggressive flap-dampening of the service prefix close to the origin (e.g. within an Anycast Node, or in adjacent ASes of each Anycast Node) may also help reduce the opportunity of remote ASes to see oscillations at all. 4.4.5. Reverse Path Forwarding Checks Reverse Path Forwarding (RPF) checks, first described in [RFC2267], are commonly deployed as part of ingress interface packet filters on @@ -670,21 +676,21 @@ For an IPv4-numbered service deployed within a private network, a locally-unused [RFC1918] address might be chosen, and reachability to that address might be signalled using a (32-bit) host route. For IPv6-numbered services, Anycast Addresses are not scoped differently from unicast addresses. As such the guidelines presented for IPv4 with respect to address suitability follow for IPv6. Note that historical prohibitions on anycast distribution of services over IPv6 have been removed from the IPv6 addressing specification in - [I-D.ietf-ipv6-addr-arch-v4]. + [RFC4291]. 4.6. Data Synchronisation Although some services have been deployed in localised form (such that clients from particular regions are presented with regionally- relevant content) many services have the property that responses to client requests should be consistent, regardless of where the request originates. For a service distributed using anycast, that implies that different Anycast Nodes must operate in a consistent manner and, where that consistent behaviour is based on a data set, that the data @@ -717,21 +723,21 @@ The possibility of cascading failure due to load can also be reduced by the deployment of both Global and Local Nodes for a single service, since the effective fail-over path of traffic is, in general, from Local Node to Global Node; traffic that might sink one Local Node is unlikely to sink all Local Nodes, except in the most degenerate cases. The chance of cascading failure due to a software defect in an operating system or server can be reduced in many cases by deploying nodes running different implementations of operating system, server - software, routing protocol software, etc, such that a defect which + software, routing protocol software, etc., such that a defect which appears in a single component does not affect the whole system. It should be noted that these approaches to increase node autonomy are, to varying degrees, contrary to the practical goals of making a deployed service straightforward to operate. A service which is over-complex is more likely to suffer from operator error than a service which is more straightforward to run. Careful consideration should be given to all of these aspects so that an appropriate balance may be found. @@ -794,20 +800,45 @@ In the event that some local services in a node are down and the node is disconnected from other nodes, continued advertisement of the covering prefix might cause requests to become black-holed. This approach allows reasonable address utilisation of the netblock covered by the announced prefix, at the expense of reduced autonomy of individual nodes; the IGP in which all nodes participate can be viewed as a single point of failure. +4.9. Node Identification by Clients + + From time to time, all clients of deployed services experience + problems, and those problems require diagnosis. A service + distributed using anycast imposes an additional variable on the + diagnostic process over a simple, unicast service -- the particular + anycast node which is handling a client's request. + + In some cases, common network-level diagnostic tools such as + traceroute may be sufficient to identify the node being used by a + client. However, the use of such tools may be beyond the abilities + of users at the client side of a transaction, and in any case network + conditions at the time of the problem may change by the time such + tools are exercised. + + Troubleshooting problems with anycast services is greatly facilitated + if mechanisms to determine the identity of a node are designed in to + the protocol. Examples of such mechanisms include the NSID option in + DNS [I-D.ietf-dnsext-nsid] and the common inclusion of hostname + information in SMTP servers' initial greeting at session initiation + [RFC2821]. + + Provision of such in-band mechanisms for node identification is + strongly recommended for services to be distributed using anycast. + 5. Service Management 5.1. Monitoring Monitoring a service which is distributed is more complex than monitoring a non-distributed service, since the observed accuracy and availability of the service is, in general, different when viewed from clients attached to different parts of the network. When a problem is identified, it is also not always obvious which node served the request, and hence which node is malfunctioning. @@ -820,24 +851,25 @@ DNS. Monitoring the routing system (from a variety of places, in the case of routing systems where perspective is relevant) can also provide useful diagnostics for troubleshooting service availability. This can be achieved using dedicated probes, or public route measurement facilities on the Internet such as the RIPE NCC Routing Information Service [2] and the University of Oregon Route Views Project [3]. Monitoring the health of the component devices in an Anycast - deployment of a service (hosts, routers, etc) is straightforward, and - can be achieved using the same tools and techniques commonly used to - manage other network-connected infrastructure, without the additional - complexity involved in monitoring Anycast service addresses. + deployment of a service (hosts, routers, etc.) is straightforward, + and can be achieved using the same tools and techniques commonly used + to manage other network-connected infrastructure, without the + additional complexity involved in monitoring Anycast service + addresses. 6. Security Considerations 6.1. Denial-of-Service Attack Mitigation This document describes mechanisms for deploying services on the Internet which can be used to mitigate vulnerability to attack: 1. An Anycast Node can act as a sink for attack traffic originated within its sphere of influence, preventing nodes elsewhere from @@ -868,20 +900,30 @@ doing so capture legitimate request traffic or process requests in a manner which compromises the service (or both). A rogue Anycast Node might be difficult to detect by clients or by the operator of the service. The risk of service hijacking by manipulation of the routing system exists regardless of whether a service is distributed using anycast. However, the fact that legitimate Anycast Nodes are observable in the routing system may make it more difficult to detect rogue nodes. + Many protocols which incorporate authentication or integrity + protection provide those features in a robust fashion, e.g. using + periodic re-authentication within a single session, or integrity + protection at either the channel (e.g. [RFC2845], [RFC2487]) or + message (e.g. [RFC4033], [RFC2311]) levels. Protocols which are + less robust may be more vulnerable to session hijacking. Given the + greater opportunity for undetected session hijack with anycast + services, the use of robust protocols is recommended for anycast + services that require authentication or integrity protection. + 7. Protocol Considerations This document does not impose any protocol considerations. 8. IANA Considerations This document requests no action from IANA. 9. Acknowledgements @@ -889,61 +931,63 @@ participants of the grow working group, and in particular Geoff Huston, Pekka Savola, Danny McPherson, Ben Black and Alan Barrett. This work was supported by the US National Science Foundation (research grant SCI-0427144) and DNS-OARC. 10. References 10.1. Normative References - [I-D.ietf-ipv6-addr-arch-v4] - Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", draft-ietf-ipv6-addr-arch-v4-04 (work in - progress), May 2005. - [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. - [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 - (BGP-4)", RFC 1771, March 1995. - [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. + [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway + Protocol 4 (BGP-4)", RFC 4271, January 2006. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + 10.2. Informative References [Allman2000] Allman, M. and E. Blanton, "On Making TCP More Robust to Packet Reordering", January 2000, . [Fomenkov2004] Fomenkov, M., Keys, K., Moore, D., and k. claffy, "Longitudinal Study of Internet Traffic from 1999-2003", January 2004, . + [I-D.ietf-dnsext-nsid] + Austein, R., "DNS Name Server Identifier Option (NSID)", + draft-ietf-dnsext-nsid-02 (work in progress), June 2006. + [ISC-TN-2003-1] Abley, J., "Hierarchical Anycast for Global Service Distribution", March 2003, . [ISC-TN-2004-1] Abley, J., "A Software Approach to Distributing Requests for DNS Service using GNU Zebra, ISC BIND 9 and FreeBSD", March 2004, . @@ -954,67 +998,94 @@ September 2000, . [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. [RFC2267] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2267, January 1998. + [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and + L. Repka, "S/MIME Version 2 Message Specification", + RFC 2311, March 1998. + + [RFC2487] Hoffman, P., "SMTP Service Extension for Secure SMTP over + TLS", RFC 2487, January 1999. + + [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, + April 2001. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. + [RFC3765] Huston, G., "NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control", RFC 3765, April 2004. + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + URIs [1] [2] [3] Appendix A. Change History This section should be removed before publication. + Intended category: BCP. + draft-kurtis-anycast-bcp-00: Initial draft. Discussed at IETF 61 in the grow meeting and adopted as a working group document shortly afterwards. draft-ietf-grow-anycast-00: Missing and empty sections completed; some structural reorganisation; general wordsmithing. Document discussed at IETF 62. draft-ietf-grow-anycast-01: This appendix added; acknowledgements section added; commentary on RFC3513 prohibition of anycast on hosts removed; minor sentence re-casting and related jiggery- pokery. This revision published for discussion at IETF 63. - draft-ietf-grow-anycast-02: Normative reference to [I-D.ietf-ipv6- - addr-arch-v4] added (in the RFC editor's queue at the time of - writing; reference should be updated to an RFC number when - available). Added commentary on per-packet load balancing. + draft-ietf-grow-anycast-02: Normative reference to + draft-ietf-ipv6-addr-arch-v4" added (in the RFC editor's queue at + the time of writing; reference should be updated to an RFC number + when available). Added commentary on per-packet load balancing. draft-ietf-grow-anycast-03: Editorial changes and language clean-up at the request of the IESG. + draftt-ietf-grow-anycast-04: Replaced reference to RFC1771 with a + reference to RFC4271. Replaced reference to + draft-ietf-ipv6-addr-arch-v4 with a reference to RFC 4291. + Changed author address for Abley. Wordsmithing in response to + Gen-ART review by Sharon Chrisholm and Secdir review by Rob + Austein. Added Section 4.9 at the suggestion of Rob Austein. + Authors' Addresses Joe Abley - Internet Systems Consortium, Inc. - 950 Charter Street - Redwood City, CA 94063 - USA + Afilias Canada, Corp. + 204 - 4141 Yonge Street + Toronto, ON M2P 2A8 + Canada - Phone: +1 650 423 1317 - Email: jabley@isc.org - URI: http://www.isc.org/ + Phone: +1 416 673 4176 + Email: jabley@ca.afilias.info + URI: http://afilias.info/ Kurt Erik Lindqvist Netnod Internet Exchange Bellmansgatan 30 118 47 Stockholm Sweden Email: kurtis@kurtis.pp.se URI: http://www.netnod.se/