draft-ietf-idr-as4bytes-12.txt | draft-ietf-idr-as4bytes-13.txt | |||
---|---|---|---|---|
Network Working Group Quaizar Vohra | Network Working Group Quaizar Vohra | |||
Internet Draft Juniper Networks | Internet Draft Nuova Systems | |||
Expiration Date: May 2006 Enke Chen | Expiration Date: July 2007 Enke Chen | |||
Cisco Systems | Cisco Systems | |||
BGP Support for Four-octet AS Number Space | BGP Support for Four-octet AS Number Space | |||
draft-ietf-idr-as4bytes-12.txt | draft-ietf-idr-as4bytes-13.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | 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 | 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. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
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 | |||
skipping to change at page 2, line 15 | skipping to change at page 2, line 15 | |||
1. Introduction | 1. Introduction | |||
Currently the Autonomous System number is encoded as a two-octet | Currently the Autonomous System number is encoded as a two-octet | |||
entity in BGP [BGP]. To prepare for the anticipated exhaustion of | entity in BGP [BGP]. To prepare for the anticipated exhaustion of | |||
the two-octet AS numbers, this document describes extensions to BGP | the two-octet AS numbers, this document describes extensions to BGP | |||
to carry the Autonomous System number as a four-octet entity. | to carry the Autonomous System number as a four-octet entity. | |||
More specifically, this document defines a new BGP capability, Four- | More specifically, this document defines a new BGP capability, Four- | |||
octet AS Number Capability, that can be used by a BGP speaker to | octet AS Number Capability, that can be used by a BGP speaker to | |||
indicate its support for the four-octet AS numbers. Two new | indicate its support for the four-octet AS numbers. Two new | |||
attributes, NEW_AS_PATH and NEW_AGGREGATOR, are introduced that can | attributes, AS4_PATH and AS4_AGGREGATOR, are introduced that can be | |||
be used to propagate four-octet based AS path information across BGP | used to propagate four-octet based AS path information across BGP | |||
speakers that do not support the four-octet AS numbers. This document | speakers that do not support the four-octet AS numbers. This document | |||
also specifies mechanisms for constructing the AS path information | also specifies mechanisms for constructing the AS path information | |||
from the AS_PATH attribute and the NEW_AS_PATH attribute. | from the AS_PATH attribute and the AS4_PATH attribute. | |||
The extensions proposed in this document allow a gradual transition | The extensions proposed in this document allow a gradual transition | |||
from 2-octet AS numbers to 4-octet AS numbers. | from 2-octet AS numbers to 4-octet AS numbers. | |||
2. Specification of Requirements | 2. Specification of Requirements | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
skipping to change at page 3, line 16 | skipping to change at page 3, line 16 | |||
NEW BGP speakers carry AS path information expressed in terms of | NEW BGP speakers carry AS path information expressed in terms of | |||
4-octet Autonomous Systems numbers by using the existing AS_PATH | 4-octet Autonomous Systems numbers by using the existing AS_PATH | |||
attribute, except that each AS number in this attribute is encoded | attribute, except that each AS number in this attribute is encoded | |||
not as a 2-octet, but as a 4-octet entity. The same applies to the | not as a 2-octet, but as a 4-octet entity. The same applies to the | |||
AGGREGATOR attribute - NEW BGP speakers use the same attribute, | AGGREGATOR attribute - NEW BGP speakers use the same attribute, | |||
except that the AS carried in this attribute is encoded as a 4-octet | except that the AS carried in this attribute is encoded as a 4-octet | |||
entity. | entity. | |||
To preserve AS path information with 4-octet AS numbers across OLD | To preserve AS path information with 4-octet AS numbers across OLD | |||
BGP speakers, this document defines a new AS path attribute, called | BGP speakers, this document defines a new AS path attribute, called | |||
NEW_AS_PATH. This is an optional transitive attribute that contains | AS4_PATH. This is an optional transitive attribute that contains the | |||
the AS path encoded with 4-octet AS numbers. The NEW_AS_PATH | AS path encoded with 4-octet AS numbers. The AS4_PATH attribute has | |||
attribute has the same semantics as the AS_PATH attribute, except | the same semantics as the AS_PATH attribute, except that it is | |||
that it is optional transitive, and it carries 4-octet AS numbers. | optional transitive, and it carries 4-octet AS numbers. | |||
To prevent the possible propagation of confederation path segments | To prevent the possible propagation of confederation path segments | |||
outside of a confederation, the path segment types AS_CONFED_SEQUENCE | outside of a confederation, the path segment types AS_CONFED_SEQUENCE | |||
and AS_CONFED_SET [RFC3065] are declared invalid for the NEW_AS_PATH | and AS_CONFED_SET [RFC3065] are declared invalid for the AS4_PATH | |||
attribute. | attribute. | |||
Similarly, this document defines a new aggregator attribute called | Similarly, this document defines a new aggregator attribute called | |||
NEW_AGGREGATOR, which is optional transitive. The NEW_AGGREGATOR | AS4_AGGREGATOR, which is optional transitive. The AS4_AGGREGATOR | |||
attribute has the same semantics as the AGGREGATOR attribute, except | attribute has the same semantics as the AGGREGATOR attribute, except | |||
that it carries 4-octet AS numbers. | that it carries a 4-octet AS number. | |||
Currently assigned 2-octet Autonomous System numbers are converted | Currently assigned 2-octet Autonomous System numbers are converted | |||
into 4-octet Autonomous System numbers by setting the high-order 2 | into 4-octet Autonomous System numbers by setting the two high-order | |||
octets of the 4-octet field to zero. Such a 4-octet AS number is said | octets of the 4-octet field to zero. Such a 4-octet AS number is said | |||
to be mappable to a 2-octet AS number. | to be mappable to a 2-octet AS number. | |||
To represent 4-octet AS numbers (which are not mapped from 2-octets) | To represent 4-octet AS numbers (which are not mapped from 2-octets) | |||
as 2-octet AS numbers in the AS path information encoded with 2-octet | as 2-octet AS numbers in the AS path information encoded with 2-octet | |||
AS numbers, this document reserves a 2-octet AS number. We denote | AS numbers, this document reserves a 2-octet AS number. We denote | |||
this special AS number as AS_TRANS for ease of description in the | this special AS number as AS_TRANS for ease of description in the | |||
rest of this specification. This AS number is also placed in the "My | rest of this specification. This AS number is also placed in the "My | |||
Autonomous System" field of the OPEN message originated by a NEW BGP | Autonomous System" field of the OPEN message originated by a NEW BGP | |||
speaker if the speaker does not have a (globally unique) 2-octet AS | speaker if the speaker does not have a (globally unique) 2-octet AS | |||
number. | number. | |||
4. Operations | 4. Operations | |||
4.1. Interaction Between NEW BGP Speakers | 4.1. Interaction Between NEW BGP Speakers | |||
A BGP speaker that supports 4-octet Autonomous System numbers MAY | A BGP speaker that supports 4-octet Autonomous System numbers SHOULD | |||
advertise this to its peers using the BGP Capability Advertisements. | advertise this to its peers using the BGP Capability Advertisements. | |||
A BGP speaker that advertises such capability to a particular peer, | A BGP speaker that advertises such capability to a particular peer, | |||
and receives from that peer the advertisement of such capability MUST | and receives from that peer the advertisement of such capability MUST | |||
encode Autonomous System numbers as 4-octet entities in both the | encode Autonomous System numbers as 4-octet entities in both the | |||
AS_PATH and the AGGREGATOR attributes in the updates it sends to the | AS_PATH and the AGGREGATOR attributes in the updates it sends to the | |||
peer, and MUST assume that these attributes in the updates received | peer, and MUST assume that these attributes in the updates received | |||
from the peer encode Autonomous System numbers as 4-octet entities. | from the peer encode Autonomous System numbers as 4-octet entities. | |||
The new attributes, NEW_AS_PATH and NEW_AGGREGATOR SHOULD NOT be | The new attributes, AS4_PATH and AS4_AGGREGATOR SHOULD NOT be carried | |||
carried in the UPDATE messages between NEW BGP peers. A NEW BGP | in the UPDATE messages between NEW BGP peers. A NEW BGP speaker that | |||
speaker that receives the NEW_AS_PATH and NEW_AGGREGATOR path | receives the AS4_PATH and AS4_AGGREGATOR path attributes in an UPDATE | |||
attributes in an UPDATE message from a NEW BGP speaker SHOULD discard | message from a NEW BGP speaker SHOULD discard these path attributes | |||
these path attributes and continue processing the UPDATE message. | and continue processing the UPDATE message. | |||
4.2. Interaction Between NEW and OLD BGP Speakers | 4.2. Interaction Between NEW and OLD BGP Speakers | |||
4.2.1. BGP Peering | 4.2.1. BGP Peering | |||
Note that peering between a NEW BGP speaker and an OLD one is | Note that peering between a NEW BGP speaker and an OLD one is | |||
possible only if the NEW BGP speaker has a 2-octet AS number. | possible only if the NEW BGP speaker has a 2-octet AS number. | |||
However, this document does not assume that an Autonomous System with | However, this document does not assume that an Autonomous System with | |||
NEW speakers has to have a globally unique 2-octet AS number - | NEW speakers has to have a globally unique 2-octet AS number - | |||
AS_TRANS could be used instead (even if multiple Autonomous System | AS_TRANS could be used instead (even if multiple Autonomous System | |||
would use it). | would use it). | |||
4.2.2. Generating Updates | 4.2.2. Generating Updates | |||
When communicating with an OLD BGP speaker, a NEW speaker MUST send | When communicating with an OLD BGP speaker, a NEW speaker MUST send | |||
the AS path information in the AS_PATH attribute encoded with 2-octet | the AS path information in the AS_PATH attribute encoded with 2-octet | |||
AS numbers. The NEW speaker also MUST send the AS path information in | AS numbers. The NEW speaker also MUST send the AS path information in | |||
the NEW_AS_PATH attribute (encoded with 4-octet AS numbers), except | the AS4_PATH attribute (encoded with 4-octet AS numbers), except for | |||
for the case where the entire AS path information is composed of | the case where the entire AS path information is composed of 2-octet | |||
2-octet AS numbers only. In this case the NEW speaker SHOULD NOT send | AS numbers only. In this case the NEW speaker SHOULD NOT send the | |||
the NEW_AS_PATH attribute. | AS4_PATH attribute. | |||
In the AS_PATH attribute encoded with 2-octet AS numbers, non- | In the AS_PATH attribute encoded with 2-octet AS numbers, non- | |||
mappable 4-octet AS numbers are represented by the well known 2-octet | mappable 4-octet AS numbers are represented by the well known 2-octet | |||
AS number, AS_TRANS. This will preserve the path length property of | AS number, AS_TRANS. This will preserve the path length property of | |||
the AS path information; and will also help in updating the AS path | the AS path information; and will also help in updating the AS path | |||
information received on a NEW BGP speaker from an OLD speaker, as | information received on a NEW BGP speaker from an OLD speaker, as | |||
explained in the next section. | explained in the next section. | |||
The NEW speaker constructs the NEW_AS_PATH attribute from the | The NEW speaker constructs the AS4_PATH attribute from the | |||
information carried in the AS_PATH attribute. In the case where the | information carried in the AS_PATH attribute. In the case where the | |||
AS_PATH attribute contains either AS_CONFED_SEQUENCE or AS_CONFED_SET | AS_PATH attribute contains either AS_CONFED_SEQUENCE or AS_CONFED_SET | |||
path segments, the NEW speaker, when constructing the NEW_AS_PATH | path segments, the NEW speaker, when constructing the AS4_PATH | |||
attribute from the AS_PATH attribute, MUST exclude such path | attribute from the AS_PATH attribute, MUST exclude such path | |||
segments. The NEW_AS_PATH attribute will be carried across a series | segments. The AS4_PATH attribute will be carried across a series of | |||
of OLD BGP speakers without modification and will help preserve the | OLD BGP speakers without modification and will help preserve the | |||
truly 4-octet AS numbers in the AS path information. | truly 4-octet AS numbers in the AS path information. | |||
Similarly, if the NEW speaker has to send the AGGREGATOR attribute, | Similarly, if the NEW speaker has to send the AGGREGATOR attribute, | |||
and if the aggregating Autonomous System's AS number is truly | and if the aggregating Autonomous System's AS number is truly | |||
4-octets, the speaker constructs the NEW_AGGREGATOR attributes by | 4-octets, the speaker constructs the AS4_AGGREGATOR attributes by | |||
taking the attribute length and attribute value from the AGGREGATOR | taking the attribute length and attribute value from the AGGREGATOR | |||
attribute and placing them into the attribute length and attribute | attribute and placing them into the attribute length and attribute | |||
value of the NEW_AGGREGATOR attribute, and sets the AS number field | value of the AS4_AGGREGATOR attribute, and sets the AS number field | |||
in the existing AGGREGATOR attribute to the reserved AS number, | in the existing AGGREGATOR attribute to the reserved AS number, | |||
AS_TRANS. Note that if the AS number is 2-octets only, then the | AS_TRANS. Note that if the AS number is 2-octets only, then the | |||
NEW_AGGREGATE attribute SHOULD NOT be sent. | AS4_AGGREGATOR attribute SHOULD NOT be sent. | |||
4.2.3. Processing Received Updates | 4.2.3. Processing Received Updates | |||
When a NEW BGP speaker receives an update from an OLD one, it should | When a NEW BGP speaker receives an update from an OLD one, it should | |||
be prepared to receive the NEW_AS_PATH attribute along with the | be prepared to receive the AS4_PATH attribute along with the existing | |||
existing AS_PATH attribute. If the NEW_AS_PATH attribute is also | AS_PATH attribute. If the AS4_PATH attribute is also received, both | |||
received, both the attributes will be used to construct the exact AS | the attributes will be used to construct the exact AS path | |||
path information, and therefore the information carried by both the | information, and therefore the information carried by both the | |||
attributes will be considered for AS path loop detection. | attributes will be considered for AS path loop detection. | |||
Note that a route may have traversed a series of autonomous systems | Note that a route may have traversed a series of autonomous systems | |||
with 2-octet AS numbers and OLD BGP speakers only. In that case, if | with 2-octet AS numbers and OLD BGP speakers only. In that case, if | |||
the route carries the NEW_AS_PATH attribute, this attribute must have | the route carries the AS4_PATH attribute, this attribute must have | |||
remained unmodified since the route left the last NEW BGP speaker. | remained unmodified since the route left the last NEW BGP speaker. | |||
The trailing AS path information (representing autonomous systems | The trailing AS path information (representing autonomous systems | |||
with 2-octet AS numbers and OLD BGP speakers only) is contained only | with 2-octet AS numbers and OLD BGP speakers only) is contained only | |||
in the current AS_PATH attribute (encoded in the leading part of the | in the current AS_PATH attribute (encoded in the leading part of the | |||
AS_PATH attribute). | AS_PATH attribute). | |||
Under certain conditions it may not be possible to reconstruct the | Under certain conditions it may not be possible to reconstruct the | |||
entire AS path information from the AS_PATH and the NEW_AS_PATH | entire AS path information from the AS_PATH and the AS4_PATH | |||
attributes of a route. This occurs when two or more routes that carry | attributes of a route. This occurs when two or more routes that carry | |||
the NEW_AS_PATH attribute are aggregated by an OLD BGP speaker, and | the AS4_PATH attribute are aggregated by an OLD BGP speaker, and the | |||
the NEW_AS_PATH attribute of at least one of these routes carries at | AS4_PATH attribute of at least one of these routes carries at least | |||
least one 4-octet AS number (as oppose to a 2-octet AS number that is | one 4-octet AS number (as oppose to a 2-octet AS number that is | |||
encoded in 4 octets). Depending on the implementation, either the | encoded in 4 octets). Depending on the implementation, either the | |||
NEW_AS_PATH attribute would be lost during route aggregation, or both | AS4_PATH attribute would be lost during route aggregation, or both | |||
the AS_PATH attribute and the NEW_AS_PATH attribute would contain | the AS_PATH attribute and the AS4_PATH attribute would contain valid, | |||
valid, partial information that can not be combined seamlessly, | partial information that can not be combined seamlessly, resulting in | |||
resulting in incomplete AS path information in these cases. | incomplete AS path information in these cases. | |||
A NEW BGP speaker should also be prepared to receive the | A NEW BGP speaker should also be prepared to receive the | |||
NEW_AGGREGATOR attribute along with the AGGREGATOR attribute from an | AS4_AGGREGATOR attribute along with the AGGREGATOR attribute from an | |||
OLD BGP speaker. When both the attributes are received, if the AS | OLD BGP speaker. When both the attributes are received, if the AS | |||
number in the AGGREGATOR attribute is not AS_TRAN, then the | number in the AGGREGATOR attribute is not AS_TRANS, then the | |||
NEW_AGGREGATOR attribute and the NEW_AS_PATH attribute SHALL be | AS4_AGGREGATOR attribute and the AS4_PATH attribute SHALL be ignored, | |||
ignored, and the AGGREGATOR attribute SHALL be taken as the | and the AGGREGATOR attribute SHALL be taken as the information about | |||
information about the aggregating node, and the AS_PATH attribute | the aggregating node, and the AS_PATH attribute SHALL be taken as the | |||
SHALL be taken as the AS path information; otherwise the AGGREGATOR | AS path information; otherwise the AGGREGATOR attribute SHALL be | |||
attribute SHALL be ignored, and the NEW_AGGREGATOR attribute SHALL be | ignored, and the AS4_AGGREGATOR attribute SHALL be taken as the | |||
taken as the information about the aggregating node, and the AS path | information about the aggregating node, and the AS path information | |||
information would need to be constructed, as in all other cases. | would need to be constructed, as in all other cases. | |||
In order to construct the AS path information, it would be necessary | In order to construct the AS path information, it would be necessary | |||
to first calculate the number of AS numbers in the AS_PATH attribute | to first calculate the number of AS numbers in the AS_PATH attribute | |||
and in the NEW_AS_PATH attribute using the method specified in Sect. | and in the AS4_PATH attribute using the method specified in Sect. | |||
9.1.2.2 [BGP] and [RFC3065] for route selection. | 9.1.2.2 [BGP] and [RFC3065] for route selection. | |||
If the number of AS numbers in the AS_PATH attribute is less than the | If the number of AS numbers in the AS_PATH attribute is less than the | |||
number of AS numbers in the NEW_AS_PATH attribute, then the | number of AS numbers in the AS4_PATH attribute, then the AS4_PATH | |||
NEW_AS_PATH attribute SHALL be ignored, and the AS_PATH attribute | attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken | |||
SHALL be taken as the AS path information. | as the AS path information. | |||
If the number of AS numbers in the AS_PATH attribute is larger than | If the number of AS numbers in the AS_PATH attribute is larger than | |||
or equal to the number of AS numbers in the NEW_AS_PATH attribute, | or equal to the number of AS numbers in the AS4_PATH attribute, then | |||
then the AS path information SHALL be constructed by taking as many | the AS path information SHALL be constructed by taking as many AS | |||
AS numbers and path segments as necessary from the leading part of | numbers and path segments as necessary from the leading part of the | |||
the AS_PATH attribute, and then prepending them to the NEW_AS_PATH | AS_PATH attribute, and then prepending them to the AS4_PATH attribute | |||
attribute so that the AS path information has an identical number of | so that the AS path information has an identical number of AS numbers | |||
AS numbers as the AS_PATH attribute. Note that a valid | as the AS_PATH attribute. Note that a valid AS_CONFED_SEQUENCE or | |||
AS_CONFED_SEQUENCE or AS_CONFED_SET path segment SHALL be prepended | AS_CONFED_SET path segment SHALL be prepended if it is either the | |||
if it is either the leading path segment or adjacent to a path | leading path segment or adjacent to a path segment that is prepended. | |||
segment that is prepended. | ||||
5. Handling BGP Communities | 5. Handling BGP Communities | |||
As specified in [RFC1997], when the high-order two-octets of the | As specified in [RFC1997], when the high-order two-octets of the | |||
community attribute is neither 0x0000 nor 0xffff, these two octets | community attribute is neither 0x0000 nor 0xffff, these two octets | |||
encode the Autonomous System number. Quite clearly this would not | encode the Autonomous System number. Quite clearly this would not | |||
work for BGP speakers that use 4-octets Autonomous System numbers. | work for BGP speakers that use 4-octets Autonomous System numbers. | |||
Such BGP speakers should use the Four-octet AS Specific Extended | Such BGP speakers should use the Four-octet AS Specific Extended | |||
Communities [AS-EXT-COMM] instead. | Communities [AS-EXT-COMM] instead. | |||
skipping to change at page 7, line 25 | skipping to change at page 7, line 25 | |||
The scheme described in this document allows a gradual transition | The scheme described in this document allows a gradual transition | |||
from 2-octet AS numbers to 4-octet AS numbers. One can upgrade one | from 2-octet AS numbers to 4-octet AS numbers. One can upgrade one | |||
Autonomous System or one BGP speaker at a time. | Autonomous System or one BGP speaker at a time. | |||
To simplify transition this document assumes that an Autonomous | To simplify transition this document assumes that an Autonomous | |||
System could start using a 4-octet AS number only after all the BGP | System could start using a 4-octet AS number only after all the BGP | |||
speakers within that Autonomous System have been upgraded to support | speakers within that Autonomous System have been upgraded to support | |||
4-octet AS numbers. | 4-octet AS numbers. | |||
An OLD BGP speaker SHOULD NOT use AS_TRANS as its Autonomous System | An OLD BGP speaker MUST NOT use AS_TRANS as its Autonomous System | |||
number. | number. | |||
A non-mappable 4-octet AS number can not be used as a "Member AS | A non-mappable 4-octet AS number can not be used as a "Member AS | |||
Number" of a BGP Confederation until all the BGP speakers within the | Number" of a BGP Confederation until all the BGP speakers within the | |||
Confederation have transitioned to support 4-octet AS numbers. | Confederation have transitioned to support 4-octet AS numbers. | |||
In an environment where an Autonomous System that has OLD BGP | In an environment where an Autonomous System that has OLD BGP | |||
speakers peers with two or more Autonomous Systems that have NEW BGP | speakers peers with two or more Autonomous Systems that have NEW BGP | |||
speakers and use AS_TRANS (rather than having a globally unique AS | speakers and use AS_TRANS (rather than having a globally unique AS | |||
number), use of Multi-Exit Discriminators by the Autonomous System | number), use of Multi-Exit Discriminators by the Autonomous System | |||
with the OLD speakers may result in a situation where Multi-Exit | with the OLD speakers may result in a situation where Multi-Exit | |||
Discriminator will influence route selection among the routes that | Discriminator will influence route selection among the routes that | |||
were received from different neighboring Autonomous Systems. | were received from different neighboring Autonomous Systems. | |||
Under certain conditions it may not be possible to reconstruct the | Under certain conditions it may not be possible to reconstruct the | |||
entire AS path information from the AS_PATH and the NEW_AS_PATH | entire AS path information from the AS_PATH and the AS4_PATH | |||
attributes of a route. This occurs when two or more routes that carry | attributes of a route. This occurs when two or more routes that carry | |||
the NEW_AS_PATH attribute are aggregated by an OLD BGP speaker, and | the AS4_PATH attribute are aggregated by an OLD BGP speaker, and the | |||
the NEW_AS_PATH attribute of at least one of these routes carries at | AS4_PATH attribute of at least one of these routes carries at least | |||
least one 4-octet AS number (as oppose to a 2-octet AS number that is | one 4-octet AS number (as oppose to a 2-octet AS number that is | |||
encoded in 4 octets). When such aggregation results in creating a | encoded in 4 octets). When such aggregation results in creating a | |||
route that is less specific than any of the component routes, (route | route that is less specific than any of the component routes, (route | |||
whose NLRI covers NLRI of all the component routes), loss of the AS | whose NLRI covers NLRI of all the component routes), loss of the AS | |||
path information does not create a risk of a routing loop. In all | path information does not create a risk of a routing loop. In all | |||
other cases loss of the AS path information does create a risk of a | other cases loss of the AS path information does create a risk of a | |||
routing loop. | routing loop. | |||
7. IANA Considerations | 7. IANA Considerations | |||
This document makes the four-octet, unsigned integers larger than | This document expands the pool for AS numbers from 0 - 65535 to 0 - | |||
65535 available for allocation as AS numbers. These AS numbers need | 4294967295. The AS numbers are managed by the IANA "Autonomous | |||
to be managed by the IANA "Autonomous System Numbers" registry. | System Numbers" registry. Other than expanding the AS number pool, | |||
this document does not propose any modifications to the existing | ||||
policies and procedures pertaining to the AS number allocation. | ||||
This document uses a BGP Capability code to indicate that a BGP | This document uses a BGP Capability code to indicate that a BGP | |||
speaker supports the 4-octet AS numbers. The Capability code has | speaker supports the 4-octet AS numbers. The Capability Code 65 has | |||
been assigned by IANA per RFC 2842. | been assigned by IANA per RFC 2842. | |||
In addition, this document introduces two new BGP optional transitive | In addition, this document introduces two new BGP optional transitive | |||
attributes. The first is the NEW_AS_PATH attribute, which preserves | attributes, and their type codes have been assigned by the IANA. The | |||
the AS path information with 4-octet AS numbers across old BGP | first one is the AS4_PATH attribute, value 17, which preserves the AS | |||
speakers. The second is the NEW_AGGREGATOR attribute, which is | path information with 4-octet AS numbers across old BGP speakers. The | |||
similar in use to the current AGGREGATOR attribute but it carries | second one is the AS4_AGGREGATOR attribute, value 18, which is | |||
4-octet AS numbers. The Type Codes for these attributes have been | similar in use to the current AGGREGATOR attribute but it carries a | |||
assigned by IANA. | 4-octet AS number. | |||
Finally, this document introduces a reserved 2-octet AS number - | Finally, this document introduces a reserved 2-octet AS number - | |||
AS_TRANS. The AS number for AS_TRANS has been assigned by the IANA. | AS_TRANS. The AS number 23456 has been assigned by the IANA for | |||
AS_TRANS. | ||||
8. Security Considerations | 8. Security Considerations | |||
This extension to BGP does not change the underlying security issues | This extension to BGP does not change the underlying security issues | |||
inherent in the existing BGP. | inherent in the existing BGP, except for the following: | |||
The inconsistency between the AS_PATH attribute and the AS4_PATH | ||||
attribute can create loss of the AS path information, and potential | ||||
routing loops in certain cases as discussed in the document. This | ||||
could be exploited by an attacker. | ||||
9. Acknowledgments | 9. Acknowledgments | |||
The authors would like to thank Yakov Rekhter, Chaitanya Kodeboyina, | The authors would like to thank Yakov Rekhter, Chaitanya Kodeboyina, | |||
and Jeffrey Haas for the numerous discussions which went into the | and Jeffrey Haas for the numerous discussions which went into the | |||
making of this draft. | making of this document. | |||
10. Normative References | 10. Normative References | |||
[BGP] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway Protocol | [BGP] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway Protocol | |||
4 (BGP-4)", draft-ietf-idr-bgp4-26.txt, October 2004. | 4 (BGP-4)", RFC 4271, January 2006. | |||
[RFC1997] Chandra, R., Traina, P. and Li, T., "BGP Communities | [RFC1997] Chandra, R., Traina, P. and Li, T., "BGP Communities | |||
Attribute", RFC 1997, August 1996. | Attribute", RFC 1997, August 1996. | |||
[RFC2842] Chandra, R., and Scudder, J., "Capabilities Advertisement | [RFC2842] Chandra, R., and Scudder, J., "Capabilities Advertisement | |||
with BGP-4", RFC 2842, May 2000. | with BGP-4", RFC 2842, May 2000. | |||
[RFC3065] Traina, P., McPherson, D., Scudder, J., "Autonomous System | [RFC3065] Traina, P., McPherson, D., Scudder, J., "Autonomous System | |||
Confederations for BGP", RFC 3065, February 2001. | Confederations for BGP", RFC 3065, February 2001. | |||
skipping to change at page 9, line 17 | skipping to change at page 9, line 31 | |||
11. Non-normative References | 11. Non-normative References | |||
[AS-EXT-COM] Rekhter, Y., Ramachandra, S., and Tappan, D. "Four- | [AS-EXT-COM] Rekhter, Y., Ramachandra, S., and Tappan, D. "Four- | |||
octet AS Specific BGP Extended Community", draft-rekhter-as4octet- | octet AS Specific BGP Extended Community", draft-rekhter-as4octet- | |||
ext-community-00.txt, October 2005. | ext-community-00.txt, October 2005. | |||
12. Authors' Information | 12. Authors' Information | |||
Quaizar Vohra | Quaizar Vohra | |||
Juniper Networks | Nuova Systems | |||
1194 N. Mathilda Ave | 2600 San Tomas Expressway | |||
Sunnyvale, CA 94089 | Santa Clara, CA 95051 | |||
Email: qv@juniper.net | Email: qv@nuovasystems.com | |||
Enke Chen | Enke Chen | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
170 W. Tasman Dr. | 170 W. Tasman Dr. | |||
San Jose, CA 95134 | San Jose, CA 95134 | |||
Email: enkechen@cisco.com | Email: enkechen@cisco.com | |||
13. Intellectual Property Considerations | 13. Intellectual Property Considerations | |||
skipping to change at page 10, line 11 | skipping to change at page 10, line 31 | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at ietf- | this standard. Please address the information to the IETF at ietf- | |||
ipr@ietf.org. | ipr@ietf.org. | |||
14. Full Copyright Notice | 14. Full Copyright Notice | |||
Copyright (C) The Internet Society (2005). | Copyright (C) The IETF Trust (2007). | |||
This document is subject to the rights, licenses and restrictions | This document is subject to the rights, licenses and restrictions | |||
contained in BCP 78, and except as set forth therein, the authors | contained in BCP 78, and except as set forth therein, the authors | |||
retain all their rights. | retain all their rights. | |||
This document and the information contained herein are provided on an | This document and the information contained herein are provided on an | |||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | |||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | |||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | |||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
End of changes. 42 change blocks. | ||||
94 lines changed or deleted | 101 lines changed or added | |||
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |