draft-ietf-idr-rfc4893bis-04.txt   draft-ietf-idr-rfc4893bis-05.txt 
Network Working Group Q. Vohra Network Working Group Q. Vohra
Internet Draft Juniper Networks Internet Draft Juniper Networks
Obsoletes: 4893 (if approved) E. Chen Obsoletes: 4893 (if approved) E. Chen
Intended Status: Standards Track Cisco Systems Intended Status: Standards Track Cisco Systems
Expiration Date: Jan 12, 2012 July 11, 2011 Expiration Date: Oct 14, 2012 April 13, 2012
BGP Support for Four-octet AS Number Space BGP Support for Four-octet AS Number Space
draft-ietf-idr-rfc4893bis-04.txt draft-ietf-idr-rfc4893bis-05.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.
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/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
This Internet-Draft will expire on January 12, 2012. This Internet-Draft will expire on October 14, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. 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 respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract Abstract
The Autonomous System (AS) number is encoded as a two-octet entity in The Autonomous System (AS) number is encoded as a two-octet entity in
the base BGP specification. This document describes extensions to BGP the base BGP specification. This document describes extensions to BGP
to carry the Autonomous System numbers as four-octet entities. to carry the Autonomous System numbers as four-octet entities. This
document obsoletes RFC 4893.
1. Introduction 1. Introduction
In the base BGP specification [RFC4271] the Autonomous System number In the base BGP specification [RFC4271] the Autonomous System number
is encoded as a two-octet entity. To prepare for the anticipated is encoded as a two-octet entity. To prepare for the anticipated
exhaustion of the two-octet AS numbers, this document describes exhaustion of the two-octet AS numbers, this document describes
extensions to BGP to carry the Autonomous System numbers as four- extensions to BGP to carry the Autonomous System numbers as four-
octet entities. octet entities.
More specifically, this document defines a BGP capability, "support More specifically, this document defines a BGP capability, "support
skipping to change at page 3, line 24 skipping to change at page 3, line 24
4. 4.
The AS path information exchanged between NEW BGP speakers are The AS path information exchanged between NEW BGP speakers are
carried in the existing AS_PATH attribute, except that each AS number carried in the existing AS_PATH attribute, except that each AS number
in the attribute is encoded as a 4-octet entity (instead of a 2-octet in the attribute is encoded as a 4-octet entity (instead of a 2-octet
entity). The same applies to the AGGREGATOR attribute - the same entity). The same applies to the AGGREGATOR attribute - the same
attribute is used between NEW BGP speakers, except that the AS number attribute is used between NEW BGP speakers, except that the AS number
carried in the attribute is encoded as a 4-octet entity. carried in the attribute is encoded as a 4-octet entity.
The AS_PATH attribute and the AGGREGATOR attribute carried between a The AS_PATH attribute and the AGGREGATOR attribute carried between a
NEW BGP speaker and an OLD BGP speaker will continue to contain 2- NEW BGP speaker and an OLD BGP speaker will continue to contain
octet AS numbers. 2-octet AS numbers.
To preserve the AS path information with 4-octet AS numbers across To preserve the AS path information with 4-octet AS numbers across
OLD BGP speakers, this document defines a new AS path attribute, OLD BGP speakers, this document defines a new AS path attribute,
called AS4_PATH. This is an optional transitive attribute that called AS4_PATH. This is an optional transitive attribute that
contains the AS path encoded with 4-octet AS numbers. The AS4_PATH contains the AS path encoded with 4-octet AS numbers. The AS4_PATH
attribute has the same semantics as the AS_PATH attribute, except attribute has the same semantics as the AS_PATH attribute, except
that it is optional transitive, and it carries 4-octet AS numbers. that it is 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
skipping to change at page 5, line 11 skipping to change at page 5, line 11
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 a multiple Autonomous System AS_TRANS could be used instead (even if a 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 MUST also send the AS path information AS numbers. The NEW speaker MUST also send the AS path information
in the AS4_PATH attribute (encoded with 4-octet AS numbers), except in the AS4_PATH attribute (encoded with 4-octet AS numbers), except
for the case where the entire AS path information is composed of 2- for the case where the entire AS path information is composed of
octet AS numbers only. In this case, the NEW speaker MUST NOT send 2-octet AS numbers only. In this case, the NEW speaker MUST NOT send
the AS4_PATH attribute. the 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 also help in updating the AS path the AS path information and 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 AS4_PATH attribute from the AS path The NEW speaker constructs the AS4_PATH attribute from the AS path
skipping to change at page 10, line 17 skipping to change at page 10, line 17
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, except for the following: inherent in the existing BGP, except for the following:
The inconsistency between the AS_PATH attribute and the AS4_PATH The inconsistency between the AS_PATH attribute and the AS4_PATH
attribute can create loss of the AS path information, and potential attribute can create loss of the AS path information, and potential
routing loops in certain cases as discussed in the document. This routing loops in certain cases as discussed in the document. This
could be exploited by an attacker. could be exploited by an attacker.
It is a misconfiguration to assign a non-mappable 4-octet AS number It is a misconfiguration to assign a non-mappable 4-octet AS number
as the "Member AS Number" in a BGP confederation before all the BGP as the "Member AS Number" in a BGP confederation before all the BGP
speakers within the confederation have transitioned to support 4- speakers within the confederation have transitioned to support
octet AS numbers. Such a misconfiguration would weaken the AS path 4-octet AS numbers. Such a misconfiguration would weaken the AS path
loop detection within a confederation. loop detection within a confederation.
10. Acknowledgments 10. 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 that went into the and Jeffrey Haas for the numerous discussions that went into the
making of this document. making of this document.
The authors would also like to thank members of the IDR Working Group The authors would also like to thank members of the IDR Working Group
for their review and comments. for their review and comments.
skipping to change at page 11, line 7 skipping to change at page 11, line 7
System Confederations for BGP", RFC 5065, August 2007. System Confederations for BGP", RFC 5065, August 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5668] Rekhter, Y., Ramachandra, S., and D. Tappan, "4-Octet AS [RFC5668] Rekhter, Y., Ramachandra, S., and D. Tappan, "4-Octet AS
Specific BGP Extended Community", RFC 5668, October 2009. Specific BGP Extended Community", RFC 5668, October 2009.
Appendix A. Comparison with RFC 4893 Appendix A. Comparison with RFC 4893
This document includes several editorial changes, and specifies the This document includes several clarifications and editorial changes,
error handling for the new attributes. and specifies the error handling for the new attributes.
12. Authors' Addresses 12. Authors' Addresses
Quaizar Vohra Quaizar Vohra
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
EMail: quaizar.vohra@gmail.com EMail: quaizar.vohra@gmail.com
 End of changes. 10 change blocks. 
14 lines changed or deleted 15 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/