draft-ietf-idr-bgp4-experience-protocol-04.txt   draft-ietf-idr-bgp4-experience-protocol-05.txt 
INTERNET-DRAFT Danny McPherson INTERNET-DRAFT Danny McPherson
Arbor Networks Arbor Networks
Keyur Patel Keyur Patel
Cisco Systems Cisco Systems
Category Informational Category Informational
Expires: November 2004 May 2004 Expires: March 2005 September 2004
Experience with the BGP-4 Protocol Experience with the BGP-4 Protocol
<draft-ietf-idr-bgp4-experience-protocol-04.txt> <draft-ietf-idr-bgp4-experience-protocol-05.txt>
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material 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/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
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.
The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document is an individual submission. Comments are solicited and
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this should be addressed to the author(s).
document are to be interpreted as described in RFC 2119 [RFC 2119].
This document is a product of an individual. Comments are solicited
and should be addressed to the author(s).
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
=0C
Abstract Abstract
The purpose of this memo is to document how the requirements for The purpose of this memo is to document how the requirements for
advancing a routing protocol from Draft Standard to full Standard advancing a routing protocol from Draft Standard to full Standard
have been satisfied by Border Gateway Protocol version 4 (BGP-4). have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for "the second report", as This report satisfies the requirement for "the second report", as
described in Section 6.0 of RFC 1264. In order to fulfill the described in Section 6.0 of RFC 1264. In order to fulfill the
requirement, this report augments RFC 1773 and describes additional requirement, this report augments RFC 1773 and describes additional
knowledge and understanding gained in the time between when the knowledge and understanding gained in the time between when the
protocol was made a Draft Standard and when it was submitted for protocol was made a Draft Standard and when it was submitted for
Standard. Standard.
=0C
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. BGP-4 Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 2. BGP-4 Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. A Border Gateway Protocol . . . . . . . . . . . . . . . . . 4 2.1. A Border Gateway Protocol . . . . . . . . . . . . . . . . . 4
3. Management Information Base (MIB). . . . . . . . . . . . . . . 5 3. Management Information Base (MIB). . . . . . . . . . . . . . . 5
4. Implementation Information . . . . . . . . . . . . . . . . . . 5 4. Implementation Information . . . . . . . . . . . . . . . . . . 5
5. Operational Experience . . . . . . . . . . . . . . . . . . . . 5 5. Operational Experience . . . . . . . . . . . . . . . . . . . . 5
6. TCP Awareness. . . . . . . . . . . . . . . . . . . . . . . . . 6 6. TCP Awareness. . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
skipping to change at page 3, line 35 skipping to change at page 3, line 34
12. Update Packing. . . . . . . . . . . . . . . . . . . . . . . . 12 12. Update Packing. . . . . . . . . . . . . . . . . . . . . . . . 12
13. Limit Rate Updates. . . . . . . . . . . . . . . . . . . . . . 13 13. Limit Rate Updates. . . . . . . . . . . . . . . . . . . . . . 13
13.1. Consideration of TCP Characteristics . . . . . . . . . . . 14 13.1. Consideration of TCP Characteristics . . . . . . . . . . . 14
14. Ordering of Path Attributes . . . . . . . . . . . . . . . . . 14 14. Ordering of Path Attributes . . . . . . . . . . . . . . . . . 14
15. AS_SET Sorting. . . . . . . . . . . . . . . . . . . . . . . . 15 15. AS_SET Sorting. . . . . . . . . . . . . . . . . . . . . . . . 15
16. Control over Version Negotiation. . . . . . . . . . . . . . . 15 16. Control over Version Negotiation. . . . . . . . . . . . . . . 15
17. Security Considerations . . . . . . . . . . . . . . . . . . . 15 17. Security Considerations . . . . . . . . . . . . . . . . . . . 15
17.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . . 16 17.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . . 16
17.2. BGP Over IPSEC . . . . . . . . . . . . . . . . . . . . . . 16 17.2. BGP Over IPSEC . . . . . . . . . . . . . . . . . . . . . . 16
17.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . 17 17.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . 17
17.4. PTOMAINE and GROW. . . . . . . . . . . . . . . . . . . . . 17 18. PTOMAINE and GROW . . . . . . . . . . . . . . . . . . . . . . 17
17.5. Internet Routing Registries (IRRs) . . . . . . . . . . . . 17 19. Internet Routing Registries (IRRs). . . . . . . . . . . . . . 17
17.6. Regional Internet Registries (RIRs) and IRRs, 20. Regional Internet Registries (RIRs) and IRRs, A
A Bit of History . . . . . . . . . . . . . . . . . . . . . . . . 18 Bit of History. . . . . . . . . . . . . . . . . . . . . . . . . . 18
17.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 19 21. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 19
18. References. . . . . . . . . . . . . . . . . . . . . . . . . . 20 22. References. . . . . . . . . . . . . . . . . . . . . . . . . . 20
19. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 21 22.1. Normative References . . . . . . . . . . . . . . . . . . . 20
20. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 22 22.2. Informative References . . . . . . . . . . . . . . . . . . 21
23. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 21
=0C
1. Introduction 1. Introduction
The purpose of this memo is to document how the requirements for The purpose of this memo is to document how the requirements for
advancing a routing protocol from Draft Standard to full Standard advancing a routing protocol from Draft Standard to full Standard
have been satisfied by Border Gateway Protocol version 4 (BGP-4). have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for "the second report", as This report satisfies the requirement for "the second report", as
described in Section 6.0 of RFC 1264. In order to fulfill the described in Section 6.0 of RFC 1264. In order to fulfill the
requirement, this report augments RFC 1773 and describes additional requirement, this report augments RFC 1773 and describes additional
skipping to change at page 4, line 39 skipping to change at page 4, line 37
pruned and some policy decisions at the AS level may be enforced. pruned and some policy decisions at the AS level may be enforced.
The initial version of the BGP protocol was published in RFC 1105. The initial version of the BGP protocol was published in RFC 1105.
Since then BGP Versions 2, 3, and 4 have been developed and are Since then BGP Versions 2, 3, and 4 have been developed and are
specified in [RFC 1163], [RFC 1267], and [RFC 1771], respectively. specified in [RFC 1163], [RFC 1267], and [RFC 1771], respectively.
Changes since BGP-4 went to Draft Standard [RFC 1771] are listed in Changes since BGP-4 went to Draft Standard [RFC 1771] are listed in
Appendix N of [BGP4]. Appendix N of [BGP4].
2.1. A Border Gateway Protocol 2.1. A Border Gateway Protocol
The Initial Version of BGP [RFC 1105]. BGP version 2 is defined in The Initial Version of BGP protocol was published in [RFC 1105]. BGP
[RFC 1163]. BGP version 3 is defined in [RFC 1267]. BGP version 4 version 2 is defined in [RFC 1163]. BGP version 3 is defined in [RFC
is defined in [RFC 1771] and [BGP4]. Appendices A, B, C, and D of 1267]. BGP version 4 is defined in [RFC 1771] and [BGP4].
[BGP4] provide summaries of the changes between each iteration of the Appendices A, B, C, and D of [BGP4] provide summaries of the changes
BGP specification. between each iteration of the BGP specification.
=0C
3. Management Information Base (MIB) 3. Management Information Base (MIB)
The BGP-4 Management Information Base (MIB) has been published [BGP- The BGP-4 Management Information Base (MIB) has been published [BGP-
MIB]. The MIB was updated from previous versions documented in [RFC MIB]. The MIB was updated from previous versions documented in [RFC
1657] and [RFC 1269], respectively. 1657] and [RFC 1269], respectively.
Apart from a few system variables, the BGP MIB is broken into two Apart from a few system variables, the BGP MIB is broken into two
tables: the BGP Peer Table and the BGP Received Path Attribute Table. tables: the BGP Peer Table and the BGP Received Path Attribute Table.
skipping to change at page 6, line 4 skipping to change at page 6, line 4
This section discusses operational experience with BGP and BGP-4. This section discusses operational experience with BGP and BGP-4.
BGP has been used in the production environment since 1989, BGP-4 BGP has been used in the production environment since 1989, BGP-4
since 1993. Production use of BGP includes utilization of all since 1993. Production use of BGP includes utilization of all
significant features of the protocol. The present production significant features of the protocol. The present production
environment, where BGP is used as the inter-autonomous system routing environment, where BGP is used as the inter-autonomous system routing
protocol, is highly heterogeneous. In terms of the link bandwidth it protocol, is highly heterogeneous. In terms of the link bandwidth it
varies from 56 Kbps to 10 Gbps. In terms of the actual routers that varies from 56 Kbps to 10 Gbps. In terms of the actual routers that
run BGP, it ranges from a relatively slow performance general purpose run BGP, it ranges from a relatively slow performance general purpose
CPUs to very high performance RISC network processors, and includes CPUs to very high performance RISC network processors, and includes
=0C
both special purpose routers and the general purpose workstations both special purpose routers and the general purpose workstations
running various UNIX derivatives and other operating systems. running various UNIX derivatives and other operating systems.
In terms of the actual topologies it varies from very sparse to quite In terms of the actual topologies it varies from very sparse to quite
dense. The requirement for full-mesh IBGP topologies has been dense. The requirement for full-mesh IBGP topologies has been
largely remedied by BGP Route Reflection, Autonomous System largely remedied by BGP Route Reflection, Autonomous System
Confederations for BGP, and often some mix of the two. BGP Route Confederations for BGP, and often some mix of the two. BGP Route
Reflection was initially defined in [RFC 1966] and subsequently Reflection was initially defined in [RFC 1966] and subsequently
updated in [RFC 2796]. Autonomous System Confederations for BGP were updated in [RFC 2796]. Autonomous System Confederations for BGP were
initially defined in [RFC 1965] and subsequently updated in [RFC initially defined in [RFC 1965] and subsequently updated in [RFC
skipping to change at page 7, line 4 skipping to change at page 7, line 4
BGP employs TCP [RFC 793] as it's Transport Layer protocol. As such, BGP employs TCP [RFC 793] as it's Transport Layer protocol. As such,
all characteristics inherent to TCP are inherited by BGP. all characteristics inherent to TCP are inherited by BGP.
For example, due to TCP's behavior, bandwidth capabilities may not be For example, due to TCP's behavior, bandwidth capabilities may not be
realized due to TCP's slow start algorithms, and slow-start restarts realized due to TCP's slow start algorithms, and slow-start restarts
of connections, etc.. of connections, etc..
7. Metrics 7. Metrics
This section discusses different metrics used within the BGP This section discusses different metrics used within the BGP
=0C
protocol. BGP has a separate metric parameter for IBGP and EBGP. This protocol. BGP has a separate metric parameter for IBGP and EBGP. This
allows policy based metrics to overwrite the distance based metrics; allows policy based metrics to overwrite the distance based metrics;
allowing each autonomous systems to define their independent policies allowing each autonomous systems to define their independent policies
in Intra-AS as well as Inter-AS. BGP Multi Exit Discriminator (MED) in Intra-AS as well as Inter-AS. BGP Multi Exit Discriminator (MED)
is used as a metric by EBGP peers (i.e., inter-domain) while Local is used as a metric by EBGP peers (i.e., inter-domain) while Local
Preference (LOCAL_PREF) is used by IBGP peers (i.e., intra-domain). Preference (LOCAL_PREF) is used by IBGP peers (i.e., intra-domain).
7.1. MULTI_EXIT_DISC (MED) 7.1. MULTI_EXIT_DISC (MED)
BGP version 4 re-defined the old INTER-AS metric as a MULTI_EXIT_ BGP version 4 re-defined the old INTER-AS metric as a MULTI_EXIT_
skipping to change at page 8, line 4 skipping to change at page 8, line 4
generated from multiple locations in an AS in order to accommodate generated from multiple locations in an AS in order to accommodate
stability, redundancy and other network design goals. When MEDs are stability, redundancy and other network design goals. When MEDs are
derived from IGP metrics associated with said aggregates the MED derived from IGP metrics associated with said aggregates the MED
value advertised to peers can result in very suboptimal routing. value advertised to peers can result in very suboptimal routing.
The MED was purposely designed to be a "weak" metric that would only The MED was purposely designed to be a "weak" metric that would only
be used late in the best-path decision process. The BGP working be used late in the best-path decision process. The BGP working
group was concerned that any metric specified by a remote operator group was concerned that any metric specified by a remote operator
would only affect routing in a local AS if no other preference was would only affect routing in a local AS if no other preference was
specified. A paramount goal of the design of the MED was to ensure specified. A paramount goal of the design of the MED was to ensure
=0C
that peers could not "shed" or "absorb" traffic for networks that that peers could not "shed" or "absorb" traffic for networks that
they advertise. they advertise.
7.1.1. MEDs and Potatoes 7.1.1. MEDs and Potatoes
In a situation where traffic flows between a pair of destinations, In a situation where traffic flows between a pair of destinations,
each connected to two transit networks, each of the transit networks each connected to two transit networks, each of the transit networks
has the choice of either sending the traffic to the closest peering has the choice of either sending the traffic to the closest peering
to other transit provider or passing traffic to the peering which to other transit provider or passing traffic to the peering which
advertises the least cost through the other provider. The former advertises the least cost through the other provider. The former
method is called "hot potatoe routing" because like a hot potatoe method is called "hot potato routing" because like a hot potato held
held in bare hands, whoever has it tries to get rid of it quickly. in bare hands, whoever has it tries to get rid of it quickly. Hot
Hot potatoe routing is accomplished by not passing the EGBP learned potato routing is accomplished by not passing the EGBP learned MED
MED into IBGP. This minimizes transit traffic for the provider into IBGP. This minimizes transit traffic for the provider routing
routing the traffic. Far less common is "cold potatoe routing" where the traffic. Far less common is "cold potato routing" where the
the transit provider uses their own transit capacity to get the transit provider uses their own transit capacity to get the traffic
traffic to the point in the adjacent transit provider advertised as to the point in the adjacent transit provider advertised as being
being closest to the destination. Cold potatoe routing is closest to the destination. Cold potato routing is accomplished by
accomplished by passing the EBGP learned MED into IBGP. passing the EBGP learned MED into IBGP.
If one transit provider uses hot potatoe routing and another uses If one transit provider uses hot potato routing and another uses cold
cold potatoe, traffic between the two tends to be symetric. potato, traffic between the two tends to be symetric. Depending on
Depending on the business relationships, if one provider has more the business relationships, if one provider has more capacity or a
capacity or a significantly less congested transit network, then that significantly less congested transit network, then that provider may
provider may use cold potatoe routing. An example of widespread use use cold potato routing. An example of widespread use of cold potato
of cold potatoe routing was the NSF funded NSFNET backbone and NSF routing was the NSF funded NSFNET backbone and NSF funded regional
funded regional networks in the mid 1990s. networks in the mid 1990s.
In some cases a provider may use hot potatoe routing for some In some cases a provider may use hot potato routing for some
destinations for a given peer AS and cold potatoe routing for others. destinations for a given peer AS and cold potato routing for others.
An example of this is the different treatment of commercial and An example of this is the different treatment of commercial and
research traffic in the NSFNET in the mid 1990s. Then again, this research traffic in the NSFNET in the mid 1990s. Then again, this
might best be described as 'mashed potatoe routing', a term which might best be described as 'mashed potato routing', a term which
reflects the complexity of router configurations in use at the time. reflects the complexity of router configurations in use at the time.
Seemingly more intuitive references that fall outside the vegetable Seemingly more intuitive references that fall outside the vegetable
kingdom refer to cold potatoe routing as "best exit routing", and hot kingdom refer to cold potato routing as "best exit routing", and hot
potatoe routing as "closest exit routing", though vegetable. potato routing as "closest exit routing".
7.1.2. Sending MEDs to BGP Peers 7.1.2. Sending MEDs to BGP Peers
[BGP4] allows MEDs received from any EBGP peers by a BGP speaker to [BGP4] allows MEDs received from any EBGP peers by a BGP speaker to
=0C
be passed to its IBGP peers. Although advertising MEDs to IBGP peers be passed to its IBGP peers. Although advertising MEDs to IBGP peers
is not a required behavior, it is a common default. MEDs received is not a required behavior, it is a common default. MEDs received
from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP from EBGP peers by a BGP speaker SHOULD NOT be sent to other EBGP
peers. peers.
Note that many implementations provide a mechanism to derive MED Note that many implementations provide a mechanism to derive MED
values from IGP metrics in order to allow BGP MED information to values from IGP metrics in order to allow BGP MED information to
reflect the IGP topologies and metrics of the network when reflect the IGP topologies and metrics of the network when
propagating information to adjacent autonomous systems. propagating information to adjacent autonomous systems.
7.1.3. MED of Zero Versus No MED 7.1.3. MED of Zero Versus No MED
[BGP4] requires that an implementation must provide a mechanism that [BGP4] requires that an implementation must provide a mechanism that
skipping to change at page 10, line 4 skipping to change at page 10, line 4
non-deterministic behavior, and as such, may often be undesirable. non-deterministic behavior, and as such, may often be undesirable.
8. Local Preference 8. Local Preference
The LOCAL_PREF attribute was added so a network operator could easily The LOCAL_PREF attribute was added so a network operator could easily
configure a policy that overrode the standard best path determination configure a policy that overrode the standard best path determination
mechanism without independently configuring local preference policy mechanism without independently configuring local preference policy
on each router. on each router.
One shortcoming in the BGP-4 specification was a suggestion for a One shortcoming in the BGP-4 specification was a suggestion for a
=0C
default value of LOCAL_PREF to be assumed if none was provided. default value of LOCAL_PREF to be assumed if none was provided.
Defaults of 0 or the maximum value each have range limitations, so a Defaults of 0 or the maximum value each have range limitations, so a
common default would aid in the interoperation of multi-vendor common default would aid in the interoperation of multi-vendor
routers in the same AS (since LOCAL_PREF is a local administration routers in the same AS (since LOCAL_PREF is a local administration
attribute, there is no interoperability drawback across AS attribute, there is no interoperability drawback across AS
boundaries). boundaries).
[BGP4] requires that LOCAL_PREF be sent to IBGP Peers and must not be [BGP4] requires that LOCAL_PREF be sent to IBGP Peers and must not be
sent to EBGP Peers. Although no default value for LOCAL_PREF is sent to EBGP Peers. Although no default value for LOCAL_PREF is
defined, the common default value is 100. defined, the common default value is 100.
skipping to change at page 11, line 4 skipping to change at page 11, line 4
paramount concern, avoiding extensive hand configuration of routing paramount concern, avoiding extensive hand configuration of routing
policies needs to be examined more carefully in future BGP-like policies needs to be examined more carefully in future BGP-like
protocols. protocols.
9. Internal BGP In Large Autonomous Systems 9. Internal BGP In Large Autonomous Systems
While not strictly a protocol issue, one other concern has been While not strictly a protocol issue, one other concern has been
raised by network operators who need to maintain autonomous systems raised by network operators who need to maintain autonomous systems
with a large number of peers. Each speaker peering with an external with a large number of peers. Each speaker peering with an external
router is responsible for propagating reachability and path router is responsible for propagating reachability and path
=0C
information to all other transit and border routers within that AS. information to all other transit and border routers within that AS.
This is typically done by establishing internal BGP connections to This is typically done by establishing internal BGP connections to
all transit and border routers in the local AS. all transit and border routers in the local AS.
Note that the number of BGP peers that can be fully meshed depends on Note that the number of BGP peers that can be fully meshed depends on
a number of factors, to include number of prefixes in the routing a number of factors, to include number of prefixes in the routing
system, number of unique path, stability of the system, and perhaps system, number of unique path, stability of the system, and perhaps
most importantly, implementation efficiency. As a result, although most importantly, implementation efficiency. As a result, although
it's difficult to define "a large number of peers", there is always it's difficult to define "a large number of peers", there is always
some practical limit. some practical limit.
skipping to change at page 12, line 4 skipping to change at page 12, line 4
BGP Route Flap Damping is defined in [RFC 2439]. BGP Route Flap BGP Route Flap Damping is defined in [RFC 2439]. BGP Route Flap
Damping defines a mechanism to help reduce the amount of routing Damping defines a mechanism to help reduce the amount of routing
information passed between BGP peers, and subsequently, the load on information passed between BGP peers, and subsequently, the load on
these peers, without adversely affecting route convergence time for these peers, without adversely affecting route convergence time for
relatively stable routes. relatively stable routes.
None of the current implementations of BGP Route Flap Damping store None of the current implementations of BGP Route Flap Damping store
route history by unique NRLI and AS Path although it is listed as route history by unique NRLI and AS Path although it is listed as
mandatory in RFC 2439. A potential result of failure to consider mandatory in RFC 2439. A potential result of failure to consider
=0C
each AS Path separately is an overly aggressive suppression of each AS Path separately is an overly aggressive suppression of
destinations in a densely meshed network, with the most severe destinations in a densely meshed network, with the most severe
consequence being suppression of a destination after a single consequence being suppression of a destination after a single
failure. Because the top tier autonomous systems in the Internet are failure. Because the top tier autonomous systems in the Internet are
densely meshed, these adverse consequences are observed. densely meshed, these adverse consequences are observed.
Route changes are announced using BGP UPDATE messages. The greatest Route changes are announced using BGP UPDATE messages. The greatest
overhead in advertising UPDATE messages happens whenever route overhead in advertising UPDATE messages happens whenever route
changes to be announced are inefficiently packed. As discussed in a changes to be announced are inefficiently packed. As discussed in a
later section, announcing routing changes sharing common attributes later section, announcing routing changes sharing common attributes
skipping to change at page 13, line 4 skipping to change at page 13, line 4
It may be desirable for an implementation to provide a knob that It may be desirable for an implementation to provide a knob that
permits advertisement of "inactive" BGP routes. permits advertisement of "inactive" BGP routes.
It may be also desirable for an implementation to provide a knob that It may be also desirable for an implementation to provide a knob that
allows a BGP speaker to advertise BGP routes that were not selected allows a BGP speaker to advertise BGP routes that were not selected
by decision process. by decision process.
12. Update Packing 12. Update Packing
Multiple unfeasible routes can be advertised in a single BGP Update Multiple unfeasible routes can be advertised in a single BGP Update
=0C
message. In addition, one or more feasible routes can be advertised message. In addition, one or more feasible routes can be advertised
in a single Update message so long as all prefixes share a common in a single Update message so long as all prefixes share a common
attribute set. attribute set.
The BGP4 protocol permits advertisement of multiple prefixes with a The BGP4 protocol permits advertisement of multiple prefixes with a
common set of path attributes to be advertised in a single update common set of path attributes to be advertised in a single update
message, this is commonly referred to as "update packing". When message, this is commonly referred to as "update packing". When
possible, update packing is recommended as it provides a mechanism possible, update packing is recommended as it provides a mechanism
for more efficient behavior in a number of areas, to include: for more efficient behavior in a number of areas, to include:
skipping to change at page 14, line 5 skipping to change at page 14, line 5
parameter that determines the minimum time that must be elapse parameter that determines the minimum time that must be elapse
between the advertisement of routes to a particular destination from between the advertisement of routes to a particular destination from
a single BGP speaker. This value is set on a per BGP peer basis. a single BGP speaker. This value is set on a per BGP peer basis.
Due to the fact that BGP relies on TCP as the Transport protocol, TCP Due to the fact that BGP relies on TCP as the Transport protocol, TCP
can prevent transmission of data due to empty windows. As a result, can prevent transmission of data due to empty windows. As a result,
multiple Updates may be spaced closer together than orginally queued. multiple Updates may be spaced closer together than orginally queued.
Although this is not a common occurrence, implementations should be Although this is not a common occurrence, implementations should be
aware of this. aware of this.
=0C
13.1. Consideration of TCP Characteristics 13.1. Consideration of TCP Characteristics
If a TCP receiver is processing input more slowly than the sender or If a TCP receiver is processing input more slowly than the sender or
if the TCP connection rate is the limiting factor, a form of if the TCP connection rate is the limiting factor, a form of
backpressure is observed by the TCP sending application. When the backpressure is observed by the TCP sending application. When the
TCP buffer fills, the sending application will either block on the TCP buffer fills, the sending application will either block on the
write or receive an error on the write. Common errors in either write or receive an error on the write. Common errors in either
early implementations or an occasional naive new implementation are early implementations or an occasional naive new implementation are
to either set options to block on the write or set options for non- to either set options to block on the write or set options for non-
blocking writes and then treat the errors due to a full buffer as blocking writes and then treat the errors due to a full buffer as
skipping to change at page 15, line 5 skipping to change at page 15, line 5
instability. instability.
14. Ordering of Path Attributes 14. Ordering of Path Attributes
The BGP protocol suggests that BGP speakers sending multiple prefixes The BGP protocol suggests that BGP speakers sending multiple prefixes
per an UPDATE message should sort and order path attributes according per an UPDATE message should sort and order path attributes according
to Type Codes. This would help their peers to quickly identify sets to Type Codes. This would help their peers to quickly identify sets
of attributes from different update messages which are semantically of attributes from different update messages which are semantically
different. different.
=0C
Implementers may find it useful to order path attributes according to Implementers may find it useful to order path attributes according to
Type Code so that sets of attributes with identical semantics can be Type Code so that sets of attributes with identical semantics can be
more quickly identified. more quickly identified.
15. AS_SET Sorting 15. AS_SET Sorting
AS_SETs are commonly used in BGP route aggregation. They reduce the AS_SETs are commonly used in BGP route aggregation. They reduce the
size of AS_PATH information by listing AS numbers only once size of AS_PATH information by listing AS numbers only once
regardless of any number of times it might appear in process of regardless of any number of times it might appear in process of
aggregation. AS_SETs are usually sorted in increasing order to aggregation. AS_SETs are usually sorted in increasing order to
skipping to change at page 16, line 5 skipping to change at page 16, line 5
BGP a provides flexible and extendable mechanism for authentication BGP a provides flexible and extendable mechanism for authentication
and security. The mechanism allows to support schemes with various and security. The mechanism allows to support schemes with various
degree of complexity. BGP sessions are authenticated based on the IP degree of complexity. BGP sessions are authenticated based on the IP
address of a peer. In addition, all BGP sessions are authenticated address of a peer. In addition, all BGP sessions are authenticated
based on the autonomous system number advertised by a peer. based on the autonomous system number advertised by a peer.
Since BGP runs over TCP and IP, BGP's authentication scheme may be Since BGP runs over TCP and IP, BGP's authentication scheme may be
augmented by any authentication or security mechanism provided by augmented by any authentication or security mechanism provided by
either TCP or IP. either TCP or IP.
=0C
17.1. TCP MD5 Signature Option 17.1. TCP MD5 Signature Option
[RFC 2385] defines a way in which the TCP MD5 signature option can be [RFC 2385] defines a way in which the TCP MD5 signature option can be
used to validate information transmitted between two peers. This used to validate information transmitted between two peers. This
method prevents any third party from injecting information (e.g., a method prevents any third party from injecting information (e.g., a
TCP Reset) into the datastream, or modifying the routing information TCP Reset) into the datastream, or modifying the routing information
carried between two BGP peers. carried between two BGP peers.
TCP MD5 is not ubiquitously deployed at the moment, especially in TCP MD5 is not ubiquitously deployed at the moment, especially in
inter- domain scenarios, largely because of key distribution issues. inter- domain scenarios, largely because of key distribution issues.
skipping to change at page 17, line 5 skipping to change at page 17, line 5
IPSEC does, however, offer several options for exchanging session IPSEC does, however, offer several options for exchanging session
keys, which may be useful on inter-domain configurations. These keys, which may be useful on inter-domain configurations. These
options are being explored in many deployments, although no options are being explored in many deployments, although no
definitive solution has been reached on the issue of key exchange for definitive solution has been reached on the issue of key exchange for
BGP in IPSEC. BGP in IPSEC.
It should be noted that since BGP runs over TCP and IP, BGP is It should be noted that since BGP runs over TCP and IP, BGP is
vulnerable to the same denial of service or authentication attacks vulnerable to the same denial of service or authentication attacks
that are present in any other TCP based protocol. that are present in any other TCP based protocol.
=0C
17.3. Miscellaneous 17.3. Miscellaneous
Another issue any routing protocol faces is providing evidence of the Another issue any routing protocol faces is providing evidence of the
validity and authority of the routing information carried within the validity and authority of the routing information carried within the
routing system. This is currently the focus of several efforts at routing system. This is currently the focus of several efforts at
the moment, including efforts to define the threats which can be used the moment, including efforts to define the threats which can be used
against this routing information in BGP [draft-murphy, attack tree], against this routing information in BGP [draft-murphy, attack tree],
and efforts at developing a means to provide validation and authority and efforts at developing a means to provide validation and authority
for routing information carried within BGP [SBGP] [soBGP]. for routing information carried within BGP [SBGP] [soBGP].
In addition, the Routing Protocol Security Requirements (RPSEC) In addition, the Routing Protocol Security Requirements (RPSEC)
working group has been chartered within the Routing Area of the IETF working group has been chartered within the Routing Area of the IETF
in order to discuss and assist in addressing issues surrounding in order to discuss and assist in addressing issues surrounding
routing protocol security. It is the intent that this work within routing protocol security. It is the intent that this work within
RPSEC will result in feedback to BGPv4 and future enhancements to the RPSEC will result in feedback to BGPv4 and future enhancements to the
protocol where appropriate. protocol where appropriate.
17.4. PTOMAINE and GROW 18. PTOMAINE and GROW
The Prefix Taxonomy (PTOMAINE) working group, recently replaced by The Prefix Taxonomy (PTOMAINE) working group, recently replaced by
the Global Routing Operations (GROW) working group, is chartered to the Global Routing Operations (GROW) working group, is chartered to
consider and measure the problem of routing table growth, the effects consider and measure the problem of routing table growth, the effects
of the interactions between interior and exterior routing protocols, of the interactions between interior and exterior routing protocols,
and the effect of address allocation policies and practices on the and the effect of address allocation policies and practices on the
global routing system. Finally, where appropriate, GROW will also global routing system. Finally, where appropriate, GROW will also
document the operational aspects of measurement, policy, security and document the operational aspects of measurement, policy, security and
VPN infrastructures. VPN infrastructures.
One such item GROW is currently studying is the effects of route One such item GROW is currently studying is the effects of route
aggregation and the inability to aggregate over multiple provider aggregation and the inability to aggregate over multiple provider
boundaries due to inadequate provider coordination. boundaries due to inadequate provider coordination.
It is the intent that this work within GROW will result in feedback It is the intent that this work within GROW will result in feedback
to BGPv4 and future enhancements to the protocol as necessary. to BGPv4 and future enhancements to the protocol as necessary.
17.5. Internet Routing Registries (IRRs) 19. Internet Routing Registries (IRRs)
Many organizations register their routing policy and prefix Many organizations register their routing policy and prefix
origination in the various distributed databases of the Internet origination in the various distributed databases of the Internet
Routing Registry. These databases provide access to the information Routing Registry. These databases provide access to the information
using the RPSL language as defined in [RFC 2622]. While registered using the RPSL language as defined in [RFC 2622]. While registered
=0C
information may be maintained and correct for certain providers, the information may be maintained and correct for certain providers, the
lack of timely or correct data in the various IRR databases has lack of timely or correct data in the various IRR databases has
prevented wide-spread use of this resource. prevented wide-spread use of this resource.
17.6. Regional Internet Registries (RIRs) and IRRs, A Bit of History 20. Regional Internet Registries (RIRs) and IRRs, A Bit of History
The NSFNET program used EGP and then BGP to provide external routing The NSFNET program used EGP and then BGP to provide external routing
information. It was the NSF policy of offering differing pricing and information. It was the NSF policy of offering differing pricing and
providing a different level of support to the Research and Education providing a different level of support to the Research and Education
(RE) networks and the Commercial (CO) networks that led to BGP's (RE) networks and the Commercial (CO) networks that led to BGP's
initial policy requirements. CO networks were not able to use the initial policy requirements. CO networks were not able to use the
NSFNET backbone to reach other CO networks, in addition to being NSFNET backbone to reach other CO networks, in addition to being
charged more. The rationelle was that commercial users of the NSFNET charged more. The rationale was that commercial users of the NSFNET
with business with research entities should subsidize the RE with business with research entities should subsidize the RE
community. Recognition that the Internet was evolving away from a community. Recognition that the Internet was evolving away from a
hierarchical network to a mesh of peers led to changes from EGP and hierarchical network to a mesh of peers led to changes from EGP and
BGP-1 that eliminated any assumptions of hierarchy. BGP-1 that eliminated any assumptions of hierarchy.
Enforcement of NSF policy was accomplished through maintenance of the Enforcement of NSF policy was accomplished through maintenance of the
NSF Policy Routing Database (PRDB). The PRDB not only contained each NSF Policy Routing Database (PRDB). The PRDB not only contained each
networks designation as CO or RE, but also contained a list of the networks designation as CO or RE, but also contained a list of the
preferred exit points to the NSFNET to reach each network. This was preferred exit points to the NSFNET to reach each network. This was
the basis for setting what would later be called BGP LOCAL_PREF on the basis for setting what would later be called BGP LOCAL_PREF on
skipping to change at page 19, line 4 skipping to change at page 19, line 4
networking community had long seen the PRDB as too US centric. networking community had long seen the PRDB as too US centric.
Through Reseaux IP Europeens (RIPE) the Europeans had created an open Through Reseaux IP Europeens (RIPE) the Europeans had created an open
format in RIPE-181 and had been maintaining an open database used for format in RIPE-181 and had been maintaining an open database used for
address and AS registry more than policy. The initial conversion of address and AS registry more than policy. The initial conversion of
the PRDB was to RIPE-181 format and tools were converted to make use the PRDB was to RIPE-181 format and tools were converted to make use
of this format. The collection of databases was termed the Internet of this format. The collection of databases was termed the Internet
Routing Registry, with the RIPE database and US NSF funded Routing Routing Registry, with the RIPE database and US NSF funded Routing
Arbitrator (RA) being the inital components of the IRR. Arbitrator (RA) being the inital components of the IRR.
A need to extend RIPE-181 was recognized and RIPE agreed to allow the A need to extend RIPE-181 was recognized and RIPE agreed to allow the
=0C
extensions to be defined within the IETF in the RPS WG. The result extensions to be defined within the IETF in the RPS WG. The result
was the RPSL language. Other work products of the RPS WG provided an was the RPSL language. Other work products of the RPS WG provided an
authentication framework and means to widely distribute the database authentication framework and means to widely distribute the database
in a controlled manner and synchronize the many repositories. Freely in a controlled manner and synchronize the many repositories. Freely
available tools were provided primarily by RIPE, Merit, and ISI, the available tools were provided primarily by RIPE, Merit, and ISI, the
most comprehensive set from ISI. The efforts of the IRR participants most comprehensive set from ISI. The efforts of the IRR participants
has been severely hampered by providers unwilling to keep information has been severely hampered by providers unwilling to keep information
in the IRR up to date. The larger of these providers have been in the IRR up to date. The larger of these providers have been
vocal, claiming that the database entry, simple as it may be, are an vocal, claiming that the database entry, simple as it may be, are an
administrative burden and some acknowledge that doing so provides a administrative burden and some acknowledge that doing so provides a
skipping to change at page 19, line 28 skipping to change at page 19, line 26
of the Internet to routing based attack or accidental injection of of the Internet to routing based attack or accidental injection of
faulty routing information. faulty routing information.
There have been numerous cases of accidental disruption of Internet There have been numerous cases of accidental disruption of Internet
routing which were avoided by providers using the IRR but highly routing which were avoided by providers using the IRR but highly
detrimental to non-users. As filters have had to be relaxed due to detrimental to non-users. As filters have had to be relaxed due to
the erosion of the IRR to less complete coverage, these types of the erosion of the IRR to less complete coverage, these types of
disruptions have continued to occur very infrequently, but have had disruptions have continued to occur very infrequently, but have had
increasingly widespread impact. increasingly widespread impact.
17.7. Acknowledgements 21. Acknowledgements
We would like to thank Paul Traina and Yakov Rekhter for authoring We would like to thank Paul Traina and Yakov Rekhter for authoring
previous versions of this document and providing valuable input on previous versions of this document and providing valuable input on
this update as well. We would also like to explicitly acknowledge this update as well. We would also like to explicitly acknowledge
Curtis Villamizar for providing both text and thorough reviews. Curtis Villamizar for providing both text and thorough reviews.
Thanks to Russ White, Jeffrey Haas, Sean Mentzer, Mitchell Erblich Thanks to Russ White, Jeffrey Haas, Sean Mentzer, Mitchell Erblich
and Jude Ballard for supplying their usual keen eye. and Jude Ballard for supplying their usual keen eye.
Finally, we'd like to think the IDR WG for general and specific input Finally, we'd like to think the IDR WG for general and specific input
that contributed to this document. that contributed to this document.
=0C 22. References
18. References
[RFC 793] Postel, J., "Transmission Control Protocol", RFC 793,
September 1981.
[RFC 1105] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol
BGP", RFC 1105, June 1989.
[RFC 1163] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol
BGP", RFC 1105, June 1990.
[RFC 1264] Hinden, R., "Internet Routing Protocol Standardization
Criteria", RFC 1264, October 1991.
[RFC 1267] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol 3
(BGP-3)", RFC 1105, October 1991.
[RFC 1269] Willis, S., and Burruss, J., "Definitions of Managed 22.1. Normative References
Objects for the Border Gateway Protocol (Version 3)",
RFC 1269, October 1991.
[RFC 1519] Fuller, V., Li. T., Yu J., and K. Varadhan, "Classless [RFC 1519] Fuller, V., Li. T., Yu J., and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): an Address Assignment and Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", RFC 1519, September 1993. Aggregation Strategy", RFC 1519, September 1993.
[RFC 1656] Traina, P., "BGP-4 Protocol Document Roadmap and
Implementation Experience", RFC 1656, July 1994.
[RFC 1657] Willis, S., Burruss, J., Chu, J., " Definitions of
Managed Objects for the Fourth Version of the Border
Gateway Protocol (BGP-4) using SMIv2", RFC 1657, July
1994.
[RFC 1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC 1772] Rekhter, Y., and P. Gross, Editors, "Application of the
Border Gateway Protocol in the Internet", RFC 1772, March
1995.
[RFC 1773] Traina, P., "Experience with the BGP-4 protocol", RFC
1773, March 1995.
[RFC 1966] Bates, T., Chandra, R., "BGP Route Reflection: An [RFC 1966] Bates, T., Chandra, R., "BGP Route Reflection: An
alternative to full mesh IBGP", RFC 1966, June 1996. alternative to full mesh IBGP", RFC 1966, June 1996.
[RFC 2385] Heffernan, A., "Protection of BGP Sessions via the TCP [RFC 2385] Heffernan, A., "Protection of BGP Sessions via the TCP
=0C
MD5 Signature Option", RFC 2385, August 1998. MD5 Signature Option", RFC 2385, August 1998.
[RFC 2439] Villamizar, C. and Chandra, R., "BGP Route Flap Damping", [RFC 2439] Villamizar, C. and Chandra, R., "BGP Route Flap Damping",
RFC 2439, November 1998. RFC 2439, November 1998.
[RFC 2622] C. Alaettinoglu et al., "Routing Policy Specification
Language", RFC 2622, June 1999.
[RFC 2796] Bates, T., Chandra, R., and Chen, E, "Route Reflection - [RFC 2796] Bates, T., Chandra, R., and Chen, E, "Route Reflection -
An Alternative to Full Mesh IBGP", RFC 2796, April 2000. An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[RFC 3065] Traina, P., McPherson, D., and Scudder, J, "Autonomous [RFC 3065] Traina, P., McPherson, D., and Scudder, J, "Autonomous
System Confederations for BGP", RFC 3065, Febuary 2001. System Confederations for BGP", RFC 3065, Febuary 2001.
[RFC 3345] McPherson, D., Gill, V., Walton, D., and Retana, A, "BGP [RFC 3345] McPherson, D., Gill, V., Walton, D., and Retana, A, "BGP
Persistent Route Oscillation Condition", RFC 3345, Persistent Route Oscillation Condition", RFC 3345,
August 2002. August 2002.
[BGP4-ANALYSIS] "BGP-4 Protocol Analysis", Internet-Draft, Work in [BGP4-ANALYSIS] "BGP-4 Protocol Analysis", Internet-Draft, Work in
Progress. Progress.
[BGP4-IMPL] "BGP 4 Implementation Report ", Internet-Draft, Work [BGP4-IMPL] "BGP 4 Implementation Report ", Internet-Draft, Work
in Progress. in Progress.
[BGP4] Rekhter, Y., T. Li., and Hares. S, Editors, "A Border [BGP4] Rekhter, Y., T. Li., and Hares. S, Editors, "A Border
Gateway Protocol 4 (BGP-4)", BGP Draft, Work in Progress. Gateway Protocol 4 (BGP-4)", BGP Draft, Work in Progress.
[RFC 1657] Willis, S., Burruss, J., Chu, J., " Definitions of
Managed Objects for the Fourth Version of the Border
Gateway Protocol (BGP-4) using SMIv2", RFC 1657, July
1994.
[SBGP] "Secure BGP", Internet-Draft, Work in Progress. [SBGP] "Secure BGP", Internet-Draft, Work in Progress.
[soBGP] "Secure Origin BGP", Internet-Draft, Work in Progress. [soBGP] "Secure Origin BGP", Internet-Draft, Work in Progress.
19. Authors' Addresses [RFC 793] Postel, J., "Transmission Control Protocol", RFC 793,
September 1981.
22.2. Informative References
[RFC 1105] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol
BGP", RFC 1105, June 1989.
[RFC 1163] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol
BGP", RFC 1105, June 1990.
[RFC 1264] Hinden, R., "Internet Routing Protocol Standardization
Criteria", RFC 1264, October 1991.
[RFC 1267] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol 3
(BGP-3)", RFC 1105, October 1991.
[RFC 1269] Willis, S., and Burruss, J., "Definitions of Managed
Objects for the Border Gateway Protocol (Version 3)",
RFC 1269, October 1991.
[RFC 1656] Traina, P., "BGP-4 Protocol Document Roadmap and
Implementation Experience", RFC 1656, July 1994.
[RFC 1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC 1772] Rekhter, Y., and P. Gross, Editors, "Application of the
Border Gateway Protocol in the Internet", RFC 1772, March
1995.
[RFC 1773] Traina, P., "Experience with the BGP-4 protocol", RFC
1773, March 1995.
[RFC 2622] C. Alaettinoglu et al., "Routing Policy Specification
Language", RFC 2622, June 1999.
23. Authors' Addresses
Danny McPherson Danny McPherson
Arbor Networks Arbor Networks
Email: danny@arbor.net Email: danny@arbor.net
Keyur Patel Keyur Patel
Cisco Systems Cisco Systems
Email: keyupate@cisco.com Email: keyupate@cisco.com
=0C Intellectual Property Statement
20. Full Copyright Statement The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copyright (C) The Internet Society (2004). All Rights Reserved. Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
This document and translations of it may be copied and furnished to The IETF invites any interested party to bring to its attention any
others, and derivative works that comment on or otherwise explain it copyrights, patents or patent applications, or other proprietary
or assist in its implementation may be prepared, copied, published rights that may cover technology that may be required to implement
and distributed, in whole or in part, without restriction of any this standard. Please address the information to the IETF at
kind, provided that the above copyright notice and this paragraph are ietf-ipr@ietf.org.
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 Disclaimer of Validity
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document
is subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain all
their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/