Re: [Idr] [Fwd: I-D ACTION:draft-ietf-idr-as4bytes-13.txt]
John Leslie <john@jlc.net> Thu, 08 February 2007 00:28 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEx8x-000181-H1; Wed, 07 Feb 2007 19:28:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEx8v-00017w-Pr for idr@ietf.org; Wed, 07 Feb 2007 19:28:05 -0500
Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEx8u-0001ed-CG for idr@ietf.org; Wed, 07 Feb 2007 19:28:05 -0500
Received: by mailhost.jlc.net (Postfix, from userid 104) id D36F71CC1E; Wed, 7 Feb 2007 19:28:02 -0500 (EST)
Date: Wed, 07 Feb 2007 19:28:02 -0500
From: John Leslie <john@jlc.net>
To: Enke Chen <enkechen@cisco.com>
Subject: Re: [Idr] [Fwd: I-D ACTION:draft-ietf-idr-as4bytes-13.txt]
Message-ID: <20070208002802.GD2308@verdi>
References: <45CA4A4B.4040108@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <45CA4A4B.4040108@cisco.com>
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c
Cc: idr@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org
Enke Chen <enkechen@cisco.com> wrote: > > Please note these changes to the attribute names (the type codes are > unchanged): > > NEW_AS_PATH ---> AS4_PATH > NEW_AGGREGATOR ---> AS4_AGGREGATOR I attach an abbreviated diff with context for changes other than those. Note in Section 4.1 "MAY advertise" becomes "SHOULD advertise", and in Section 6 "SHOULD NOT use AS_TRANS" becomes "MUST NOT use AS_TRANS". Section 7 now includes actual assigned values, and explicitly disclaims any intent to modify allocation policies and procedures. Section 8 adds a Security Consideration, which deserves to be read carefully. -------------------------------- cut here -------------------------------- 3. Protocol Extensions attribute has the same semantics as the AGGREGATOR attribute, except < that it carries 4-octet AS numbers. --- attribute has the same semantics as the AGGREGATOR attribute, except > that it carries a 4-octet AS number. **** Currently assigned 2-octet Autonomous System numbers are converted < into 4-octet Autonomous System numbers by setting the high-order 2 octets of the 4-octet field to zero. Such a 4-octet AS number is said --- Currently assigned 2-octet Autonomous System numbers are converted > 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 **** 4.1. Interaction Between NEW BGP Speakers < A BGP speaker that supports 4-octet Autonomous System numbers MAY advertise this to its peers using the BGP Capability Advertisements. --- > A BGP speaker that supports 4-octet Autonomous System numbers SHOULD advertise this to its peers using the BGP Capability Advertisements. **** 6. Transition < An OLD BGP speaker SHOULD NOT use AS_TRANS as its Autonomous System number. --- > An OLD BGP speaker MUST NOT use AS_TRANS as its Autonomous System number. **** 7. IANA Considerations < This document makes the four-octet, unsigned integers larger than < 65535 available for allocation as AS numbers. These AS numbers need < to be managed by the IANA "Autonomous System Numbers" registry. --- > This document expands the pool for AS numbers from 0 - 65535 to 0 - > 4294967295. The AS numbers are managed by the IANA "Autonomous > 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 < speaker supports the 4-octet AS numbers. The Capability code has been assigned by IANA per RFC 2842. --- This document uses a BGP Capability code to indicate that a BGP > speaker supports the 4-octet AS numbers. The Capability Code 65 has been assigned by IANA per RFC 2842. **** In addition, this document introduces two new BGP optional transitive < attributes. The first is the NEW_AS_PATH attribute, which preserves < the AS path information with 4-octet AS numbers across old BGP < speakers. The second is the NEW_AGGREGATOR attribute, which is < similar in use to the current AGGREGATOR attribute but it carries < 4-octet AS numbers. The Type Codes for these attributes have been < assigned by IANA. --- In addition, this document introduces two new BGP optional transitive > attributes, and their type codes have been assigned by the IANA. The > first one is the AS4_PATH attribute, value 17, which preserves the AS > path information with 4-octet AS numbers across old BGP speakers. The > second one is the AS4_AGGREGATOR attribute, value 18, which is > similar in use to the current AGGREGATOR attribute but it carries a > 4-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. --- Finally, this document introduces a reserved 2-octet AS number - > AS_TRANS. The AS number 23456 has been assigned by the IANA for > AS_TRANS. **** 8. Security Considerations This extension to BGP does not change the underlying security issues < inherent in the existing BGP. --- This extension to BGP does not change the underlying security issues > 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 > coule be exploited by an attacker. **** 9. Acknowledgments The authors would like to thank Yakov Rekhter, Chaitanya Kodeboyina, and Jeffrey Haas for the numerous discussions which went into the < making of this draft. --- The authors would like to thank Yakov Rekhter, Chaitanya Kodeboyina, and Jeffrey Haas for the numerous discussions which went into the > making of this document. **** 10. Normative References [BGP] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway Protocol < 4 (BGP-4)", draft-ietf-idr-bgp4-26.txt, October 2004. --- [BGP] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway Protocol > 4 (BGP-4)", RFC 4271, January 2006. **** 12. Authors' Information Quaizar Vohra < Juniper Networks < 1194 N. Mathilda Ave < Sunnyvale, CA 94089 < < Email: qv@juniper.net --- Quaizar Vohra > Nuova Systems > 2600 San Tomas Expressway > Santa Clara, CA 95051 > > Email: qv@nuovasystems.com -------------------------------- cut here -------------------------------- -- John Leslie <john@jlc.net> _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr
- [Idr] I-D ACTION:draft-ietf-idr-as4bytes-13.txt Internet-Drafts
- [Idr] [Fwd: I-D ACTION:draft-ietf-idr-as4bytes-13… Enke Chen
- Re: [Idr] [Fwd: I-D ACTION:draft-ietf-idr-as4byte… John Leslie
- Re: [Idr] [Fwd: I-D ACTION:draft-ietf-idr-as4byte… Erik Romijn
- Re: [Idr] [Fwd: I-D ACTION:draft-ietf-idr-as4byte… Enke Chen
- Re: [Idr] [Fwd: I-D ACTION:draft-ietf-idr-as4byte… Geoff Huston