draft-ietf-grow-unique-origin-as-00.txt   draft-ietf-grow-unique-origin-as-01.txt 
INTERNET-DRAFT Danny McPherson INTERNET-DRAFT Danny McPherson
Ryan Donnelly Ryan Donnelly
Frank Scalzo Frank Scalzo
VeriSign, Inc. Verisign, Inc.
Expires: May 2011 November 15, 2010 Expires: January 2012 July 2, 2011
Intended Status: Best Current Practice Intended Status: Best Current Practice
Unique Per-Node Origin ASNs for Globally Anycasted Services Unique Per-Node Origin ASNs for Globally Anycasted Services
<draft-ietf-grow-unique-origin-as-00.txt> <draft-ietf-grow-unique-origin-as-01.txt>
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Copyright (c) 2010 IETF Trust and the persons identified as the document
authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info) Relating to IETF Documents (http://trustee.ietf.org/license-info)
in effect on the date of publication of this document. Please in effect on the date of publication of this document. Please
review these documents carefully, as they describe your rights and review these documents carefully, as they describe your rights and
restrictions with respect to this document. Code Components restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License extracted from this document must include Simplified BSD License
text as described in Section 4.e of the Trust Legal Provisions and text as described in Section 4.e of the Trust Legal Provisions and
are provided without warranty as described in the Simplified BSD are provided without warranty as described in the Simplified BSD
License. License.
skipping to change at page 2, line 8 skipping to change at page 2, line 7
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (C) (2010) The IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
Abstract Abstract
This document makes recommendations regarding the use of per-node This document makes recommendations regarding the use of unique
unique origin ASNs for globally anycasted critical infrastructure origin autonomous system numbers per node for globally anycasted
services in order to provide routing system discriminators for a critical infrastructure services in order to provide routing system
given anycasted prefix. Network managment and monitoring techniques, discriminators for a given anycasted prefix. Network management and
or other operational mechanisms may employ this new discriminator in monitoring techniques, or other operational mechanisms may employ
whatever manner fits their operating environment. this new discriminator in whatever manner best accommodates their
operating environment.
Table of Contents Table of Contents
1. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Recommendation for Unique Origin ASNs. . . . . . . . . . . . . 6 3. Recommendation for Unique Origin ASNs. . . . . . . . . . . . . 7
4. Additional Recommendations for Globally Anycasted 4. Additional Recommendations for Globally Anycasted
Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 8
6. Deployment Considerations. . . . . . . . . . . . . . . . . . . 9 6. Deployment Considerations. . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References. . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References. . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References. . . . . . . . . . . . . . . . . . . 11 9.2. Informative References. . . . . . . . . . . . . . . . . . . 11
10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 11 10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 12
1. Terminology 1. Terminology
This document employs much of the following terminology, which was This document employs much of the following terminology, which was
taken in full from Section 2 of [RFC 4786]. taken in full from Section 2 of [RFC 4786].
Anycast: the practice of making a particular Service Address Anycast: the practice of making a particular Service Address
available in multiple, discrete, autonomous locations, such that available in multiple, discrete, autonomous locations, such that
datagrams sent are routed to one of several available locations. datagrams sent are routed to one of several available locations.
skipping to change at page 5, line 5 skipping to change at page 4, line 49
Global-Scope Anycast: reachability information for the anycast Global-Scope Anycast: reachability information for the anycast
Service Address is propagated through a routing system in such a Service Address is propagated through a routing system in such a
way that a particular anycast node is potentially visible to the way that a particular anycast node is potentially visible to the
whole routing system. whole routing system.
Service Address: an IP address associated with a particular service Service Address: an IP address associated with a particular service
(e.g., the destination address used by DNS resolvers to reach a (e.g., the destination address used by DNS resolvers to reach a
particular authority server). particular authority server).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
2. Introduction 2. Introduction
IP anycasting [RFC 4786] has been deployed for an array of network IP anycasting [RFC 4786] has been deployed for an array of network
services since the early 1990s. It provides a mechanism for a given services since the early 1990s. It provides a mechanism for a given
network resource to be available in a more distributed manner, network resource to be available in a more distributed manner,
locally and/or globally, with a more robust and resilient footprint, locally and/or globally, with a more robust and resilient footprint,
commonly yielding better localization and absorption of systemic commonly yielding better localization and absorption of systemic
query loads, as well as better protections in the face of DDoS query loads, as well as better protections in the face of DDoS
attacks, network partitions, and other similar incidents. A large attacks, network partitions, and other similar incidents. A large
part of the Internet root DNS infrastructure, as well as many other part of the Internet root DNS infrastructure, as well as many other
skipping to change at page 6, line 20 skipping to change at page 6, line 20
given anycasted service address is, the more difficult it becomes for given anycasted service address is, the more difficult it becomes for
network operators to detect operational and security issues that network operators to detect operational and security issues that
affect that service. Some examples of such security and operational affect that service. Some examples of such security and operational
issues include BGP route leaks affecting the anycasted service, rogue issues include BGP route leaks affecting the anycasted service, rogue
anycast nodes appearing for the service, or the emergence of other anycast nodes appearing for the service, or the emergence of other
aberrant behavior in either the routing system, the forward query aberrant behavior in either the routing system, the forward query
datapath, or query response datapath. Diagnosis of the routing datapath, or query response datapath. Diagnosis of the routing
system issues is complicated by the fact that no unique system issues is complicated by the fact that no unique
discriminators exist in the routing system to identify a given local discriminators exist in the routing system to identify a given local
or global anycast node. Furthermore, both datapath and routing or global anycast node. Furthermore, both datapath and routing
system problem identification is compounded by the fact that either system problem identification is compounded by the fact that these
incident type can be topologically-dependent. incident types can be topologically-dependent, and only observable
between a given client-server set.
Additionally, while it goes without saying that anycasted services Additionally, while it goes without saying that many anycasted
should always strive for exact synchronization across all instances services strive for exact synchronization across all instances of an
of an anycasted service address, if local policies or data plane anycasted service address, if local policies or data plane response
response manipulation techniques were to "influence" responses within manipulation techniques were to "influence" responses within a given
a given region in such a way that those response are no longer region in such a way that those responses are no longer authentic or
authentic or that they diverge from what other nodes within an that they diverge from what other nodes within an anycasted service
anycasted service were providing, then it should be an absolute were providing, then it should be an absolute necessity that those
necessity that those modified resources only be utilized by service modified resources only be utilized by service consumers within that
consumers within that region or influencer's jurisdiction. region or influencer's jurisdiction.
Mechanisms should exist at both the network and service layer to make Mechanisms should exist at both the network and service layer to make
it abundantly apparent to operators and users alike whether any of it abundantly apparent to operators and users alike whether any of
the query responses are not authentic. For DNS, DNSSEC [RFC 4033] the query responses are not authentic. For DNS, DNSSEC [RFC 4033]
provides this capability at the service layer with object level provides this capability at the service layer with object level
integrity, assuming validation is being enforced by recursive name integrity, assuming validation is being performed by recursive name
servers, and DNSSEC deployment at the root and top level domain (TLD) servers, and DNSSEC deployment at the root and top level domain (TLD)
levels is well underway [DNSSEC-DEPLOY]. Furthermore, control plane levels is well underway [DNSSEC-DEPLOY]. Furthermore, control plane
discriminators should exist to enable operators to know toward which discriminators should exist to enable operators to know toward which
of a given set of instances a query is being directed, and to enable of a given set of instances a query is being directed, and to enable
detection and alerting capabilities when this changes. Such detection and alerting capabilities when this changes. Such
discriminators may also be employed to enable anycast node preference discriminators may also be employed to enable anycast node preference
or filtering keys, should local operational policy require it. or filtering keys, should local operational policy require it.
3. Recommendation for Unique Origin ASNs 3. Recommendation for Unique Origin ASNs
In order to be able to better detect changes to routing information In order to be able to better detect changes to routing information
associated with crtical anycasted resources, globally anycasted associated with critical anycasted resources, globally anycasted
services with partitioned origin ASNs SHOULD utilize a unique origin services with partitioned origin ASNs SHOULD utilize a unique origin
ASN per node where possible. ASN per node where possible, if appropriate in their operating
environment and service model.
Discrete origin ASNs per node provide a discriminator in the routing Discrete origin ASNs per node provide a discriminator in the routing
system that would enable detection of leaked or hijacked instances system that would enable detection of leaked or hijacked instances
more quickly, and would also enable operators that so choose to more quickly, and would also enable operators that so choose to
proactively develop routing policies that express preferences or proactively develop routing policies that express preferences or
avoidance for a given node or set of nodes associated with an avoidance for a given node or set of nodes associated with an
anycasted service. This is particularly useful when it is observed anycasted service. This is particularly useful when it is observed
that local policy or known issues exist with the performance or that local policy or known issues exist with the performance or
authenticity of responses returned from a specific anycast node, or authenticity of responses returned from a specific anycast node, or
that enacted policies meant to affect service within a particular that enacted policies meant to affect service within a particular
skipping to change at page 7, line 39 skipping to change at page 7, line 44
resources, in particular those associated with critical resources, in particular those associated with critical
infrastructure-enabling services such as root and TLD name servers, infrastructure-enabling services such as root and TLD name servers,
SHOULD warrant special consideration with regard to AS number SHOULD warrant special consideration with regard to AS number
allocation practices during policy development by the constituents of allocation practices during policy development by the constituents of
those responsible organizations (e.g., the Regional Internet those responsible organizations (e.g., the Regional Internet
Registries). Additionally, defining precisely what constitutes Registries). Additionally, defining precisely what constitutes
"critical infrastructure services" or "special consideration" (e.g., "critical infrastructure services" or "special consideration" (e.g.,
some small range of 32-bit AS numbers might be provided) is left to some small range of 32-bit AS numbers might be provided) is left to
the constituents of those organizations. Additionally, critical the constituents of those organizations. Additionally, critical
infrastructure employment of 32-bit ASNs for new nodes might well infrastructure employment of 32-bit ASNs for new nodes might well
help to foster adoption of native 32-bit ASN support by network help to foster more rapid adoption of native 32-bit ASN support by
operators. network operators.
One additional benefit of unique origin AS numbers per anycast node One additional benefit of unique origin AS numbers per anycast node
is that Resource PKI (RPKI) Secure Inter-domain Routing [SIDR] is that Resource PKI (RPKI) Secure Inter-domain Routing [SIDR]
machinery, and in particular, that of Route Origin Authorizations machinery, and in particular, that of Route Origin Authorizations
(ROAs), and routing policies that may be derived based on those ROAs, (ROAs), and routing policies that may be derived based on those ROAs,
can be employed with per anycast node resolution, rather than relying can be employed with per anycast node resolution, rather than relying
on a single ROA and common origin AS to cover all instantiations of on a single ROA and common origin AS to cover all instantiations of
an anycasted prefix (possibly hundreds) within the global routing an anycasted prefix (possibly hundreds) within the global routing
system. For example, deployments that incorporate partitioned ASN system. For example, deployments that incorporate partitioned ASN
anycast models that have a single ASN bound to all nodes but cross anycast models that have a single ASN bound to all nodes but cross
organizational or political boundaries, a situation may arise where organizational or political boundaries, a situation may arise where
nobody would be deemed appropriate to hold the key for the ROA. nobody would be deemed appropriate to hold the key for the ROA.
Additionally, a globally anycasted service within a given IP prefix Additionally, a globally anycasted service within a given IP prefix
that shares a common ASN might be taken totally offline because of that shares a common ASN might be taken totally offline because of
the revocation of a ROA for that origin. the revocation of a ROA for that origin ASN. The RPKI model today
already inherently accommodates issuance of multiple ROAs with unique
origins for a given prefix.
4. Additional Recommendations for Globally Anycasted Services 4. Additional Recommendations for Globally Anycasted Services
Two additional recommendations for globally anycasted critical Two additional recommendations for globally anycasted critical
infrastructure services are related to publication of information infrastructure services are related to publication of information
associated with a given node's physical location, and which adjacent associated with a given node's physical location, and which adjacent
upstream ASNs an origin AS interconnects with. The former would upstream ASNs an origin AS interconnects with. The former would
allow operators to better define and optimize preferences associated allow operators to better define and optimize preferences associated
with a given node to align with local policy and service with a given node to align with local policy and service
optimizations. The latter would allow expression through policy such optimizations. The latter would allow expression through policy such
as Routing Policy Specification Language [RFC 4012] specified in as Routing Policy Specification Language [RFC 4012] specified in
Internet Routing Registries (IRRs) in a manner that illustrates a Internet Routing Registries (IRRs) in a manner that illustrates a
discrete set of upstream ASNs for each anycast node, rather than the discrete set of upstream ASNs for each anycast node, rather than the
current model where all upstream ASNs associated with a common origin current model where all upstream ASNs associated with a common origin
AS may or may not be expressed. This information would provide an AS may or may not be expressed. This information would provide an
additional level of static AS path validation or monitoring and additional level of static routing policy or monitoring and detection
detection models by network operators, and perhaps explicit network models by network operators, and perhaps explicit network layer
layer source address validation in the datapath. source address validation in the datapath.
5. Security Considerations 5. Security Considerations
The recommendations made in this memo aim to provide more flexibility The recommendations made in this memo aim to provide more flexibility
for network operators hoping to better monitor and prevent issues for network operators hoping to better monitor and prevent issues
related to globally anycasted critical infrastructure resources. related to globally anycasted critical infrastructure resources.
Anycast itself provides considerable benefit in the face of certain Anycast itself provides considerable benefit in the face of certain
attacks, yet if a given instance of a service can appear at many attacks, yet if a given instance of a service can appear at many
points in the routing system and legitimate instances are difficult points in the routing system and legitimate instances are difficult
to distinguish from malicious ones, then anycast expands the to distinguish from malicious ones, then anycast expands the
skipping to change at page 9, line 12 skipping to change at page 9, line 19
more easily detect or scope the impact of a particular incident are more easily detect or scope the impact of a particular incident are
illustrated in [RENESYS-BLOG]. illustrated in [RENESYS-BLOG].
Furthermore, while application layer protection mechanisms such as Furthermore, while application layer protection mechanisms such as
DNSSEC provide object level integrity and authentication, they often DNSSEC provide object level integrity and authentication, they often
do so at the cost of introducing more failure conditions. For do so at the cost of introducing more failure conditions. For
example, if a recursive name server is performing DNSSEC validator example, if a recursive name server is performing DNSSEC validator
functions and receives a bogus response to a given query as a result functions and receives a bogus response to a given query as a result
of a man-in-the-middle (MITM) or injected spoofed response packet of a man-in-the-middle (MITM) or injected spoofed response packet
such as a cache poisoning attempt, the possibility might exist that such as a cache poisoning attempt, the possibility might exist that
that packet is processed by the server and results in some temporal the response packet is processed by the server and results in some
or persistent DoS condition on the recursuve name server and for its temporal or persistent DoS condition on the recursive name server and
customer set. The unique origin AS mechanism outlined in this for its client set. The unique origin AS mechanism outlined in this
document provides the capability for network operators to expressly document provides the capability for network operators to expressly
avoid anycast node catchments known to regularly elicit bogus avoid anycast node catchments known to regularly elicit bogus
responses, while allowing the anycasted service address to remain responses, while allowing the anycasted service address to remain
available otherwise. available otherwise.
6. Deployment Considerations 6. Deployment Considerations
Maintenance of unique ASNs for each node within an anycasted service Maintenance of unique ASNs for each node within an anycasted service
may be challenging for some critical infrastructure service operators may be challenging for some critical infrastructure service operators
initially, but for globally anycasted resources there needs to be initially, but for globally anycasted resources there needs to be
some type of per-node discriminator in the control plane to enable some type of per-node discriminator in the control plane to enable
detection, remediation, and optimally, preventative controls for detection, remediation, and optimally, preventative controls for
dealing with routing system anomalies that are intensified by the dealing with routing system anomalies that are intensified by the
application of IP anycasting. Additionally, this technique sets the application of IP anycasting. Additionally, this technique sets the
stage to employ RPKI-enabled machinery and more secure and explicit stage to employ RPKI-enabled machinery and more secure and explicit
routing policies, which all network operators should be considering. routing policies, which all network operators should be considering.
The granularity of data publication related to anycast node location The granularity of data publication related to anycast node location
should be left to the devises of each services operator, but some should be left to the devises of each services operator, and the
reasonable level of detail to enable operators to make informed value of this mechanism in each operators unique environment, but
decisions that align with their security and operational objectives some reasonable level of detail to enable operators and service
as outlined herein should be provided by each critical services consumers to make informed decisions that align with their security
operator. and operational objectives as outlined herein should be provided by
each critical services operator.
Adjacent AS information for a given origin AS can be obtained through Adjacent AS information for a given origin AS can be obtained through
careful routing system analysis already when prefixes are advertised careful routing system analysis already when prefixes are advertised
via a given set of AS adjacencies, and therefore should present no via a given set of AS adjacencies, and therefore should present no
new threat. However, network interconnection and peering policies new threat. However, network interconnection and peering policies
may well present some challenges in this area. For example, if a may well present some challenges in this area. For example, if a
technique such as unique origin AS per node is employed then a single technique such as unique origin AS per node is employed then a single
orgnaizaton may no longer have a single AS for interconnection at organizaton may no longer have a single AS for interconnection at
each location, and interconnection policies should expressly consider each location, and interconnection policies should expressly consider
this. That said, interconnection with networks that provide critical this. That said, interconnection with networks that provide critical
infrastructure services should certainly be given due consideration infrastructure services should certainly be given due consideration
as such by network operators when evaluating interconnection as such by network operators when evaluating interconnection
strategies. strategies.
Some root and TLD operators today identify erroneous anycast prefix Some root and TLD operators today identify erroneous anycast prefix
announcements by detecting prefix announcements with an origin AS announcements by detecting prefix announcements with an origin AS
other than the common origin AS shared via all nodes. This detection other than the common origin AS shared via all nodes. This detection
model would need to be expanded to account for unique origin ASNs per model would need to be expanded to account for unique origin ASNs per
node if a given service operators chooses to employ such as a model, node if a given service operators chooses to employ such a model, and
and given that AS paths are trivial to manipulate, the above given that AS paths are trivial to manipulate in the current system,
technique would only assist in the event of unintentional the above technique would only assist in the event of unintentional
configuration errors that reoriginate the route (e.g., it doesn't configuration errors that reoriginate the route (e.g., it doesn't
even detect leaks that preserve the initial path elements). even detect leaks that preserve the initial path elements). In that
case, work underway on routing security origin and path validation in
the SIDR working group and beyond should be consulted.
Finally, anycast node presence at exchange points that employs route While local policy based on any BGP attributes, to include AS path
information, can influence policy within a local administrative
domain and possibly downstream, there exists a possibly that upstream
nodes continue to use a route deemed undesirable by the local admin
once data packets reach that network. Network operators must
understand the implications of this property in their operating
environment, as it is inherent in all Interent routing.
Finally, anycast node presence at exchange points that employ route
servers may make enumeration of adjacent ASNs for a given node servers may make enumeration of adjacent ASNs for a given node
challenging. While this is understood, service operators should make challenging. While this is understood, service operators should make
every effort to enumerate the set of adjacent ASNs associated with a every effort to enumerate the set of adjacent ASNs associated with a
given anycast node's origin AS. Without express understanding of given anycast node's origin AS. Without express understanding of
legitimate AS interconnection and authorized origin AS information, legitimate AS interconnection and authorized origin AS information,
more secure routing is difficult to acheive. more secure routing is difficult to achieve.
7. Acknowledgements 7. Acknowledgements
Thanks to David Conrad, Steve Kent, Mark Kosters, Andrei Robachevsky, Thanks to David Conrad, Steve Kent, Mark Kosters, Andrei Robachevsky,
Paul Vixie, Brad Verd, Andrew Herrmann, Gaurab Raj Upadhaya, Joe Paul Vixie, Brad Verd, Andrew Herrmann, Gaurab Raj Upadhaya, Joe
Abley, Benson Schliesser, Shane Amante, and Randy Bush for review and Abley, Benson Schliesser, Shane Amante, Hugo Salgado, and Randy Bush
comments on this concept. for review and comments on this concept.
Others? Your name could be here.......
8. IANA Considerations 8. IANA Considerations
This document requires no direct IANA actions, although it does This document requires no direct IANA actions, although it does
provide general guidance to number resource allocation and policy provide general guidance to number resource allocation and policy
development organizations, and in particular Regional Internet development organizations, and in particular Regional Internet
Registries, regarding allocation of AS numbers for globally anycasted Registries, regarding allocation of AS numbers for globally anycasted
services. services.
9. References 9. References
skipping to change at page 12, line 4 skipping to change at page 12, line 10
[RENESYS-BLOG] Zmijewski, E., "Accidentally Importing Censorship", [RENESYS-BLOG] Zmijewski, E., "Accidentally Importing Censorship",
Renesys Blog, March 30, 2010. Renesys Blog, March 30, 2010.
<http://www.renesys.com/blog/2010/03/fouling-the-global-nest.shtml> <http://www.renesys.com/blog/2010/03/fouling-the-global-nest.shtml>
[SIDR] Lepinski, M., Kent, S., "An Infrastructure to Support Secure [SIDR] Lepinski, M., Kent, S., "An Infrastructure to Support Secure
Internet Routing", October 2009, Internet-Draft, "Work in Internet Routing", October 2009, Internet-Draft, "Work in
Progress". Progress".
10. Authors' Addresses 10. Authors' Addresses
Danny McPherson Danny McPherson
Verisign, Inc. Verisign, Inc.
21345 Ridgetop Circle
Dulles, VA USA 20166
Phone: +1 703.948.3200
Email: dmcpherson@verisign.com Email: dmcpherson@verisign.com
Ryan Donnelly Ryan Donnelly
Verisign, Inc. Verisign, Inc.
21345 Ridgetop Circle
Dulles, VA USA 20166
Phone: +1 703.948.3200
Email: rdonnelly@verisign.com Email: rdonnelly@verisign.com
Frank Scalzo Frank Scalzo
Verisign, Inc. Verisign, Inc.
21345 Ridgetop Circle
Dulles, VA USA 20166
Phone: +1 703.948.3200
Email: fscalzo@verisign.com Email: fscalzo@verisign.com
Copyright Statement Copyright Statement
Copyright (C) (2010) The IETF Trust and the persons Copyright (C) (2011) The IETF Trust and the persons
identified as the document authors. All rights reserved. identified as the 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. respect to this document.
 End of changes. 30 change blocks. 
56 lines changed or deleted 84 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/