The IESG has approved the following document: - 'IPv6 Address Specific BGP Extended Communities Attribute ' <draft-ietf-l3vpn-v6-ext-communities-02.txt> as a Proposed Standard This document is the product of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Ross Callon and Adrian Farrel. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-v6-ext-communities-02.txt Technical Summary Current specifications of BGP Extended Communities [RFC4360] support IPv4 Address Specific Extended Community, but do not support IPv6 Address Specific Extended Community. The lack of IPv6 Address Specific Extended Community may be a problem when an application uses IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment. This document defines a new BGP attribute, IPv6 Address Specific Extended Community that addresses this problem. The IPv6 Address Specific Extended Community is similar to the IPv4 Address Specific Extended Community, except that it carries an IPv6 address rather than an IPv4 address. Working Group Summary No dissent reported (see PROTO writeup by Danny McPherson in the I.D. tracker). This was last called in both L3VPN and IDR working groups. Document Quality The equivalent capability for IPv4 is implemented and widely deployed. This is a quite straightforward extension of this same capability for use in IPv6 networks. Personnel Danny McPherson is the Document Shepherd for this document. Ross Callon is the Responsible Area Director. RFC Editor Note Section 1, paragraph 1, spelling "Addres" should be "Address". Please replace the existing security considerations section with the following: 4. Security Considerations This document does not add new security issues. All the security considerations for BGP Extended Communities apply here. At the time that this document was written there were significant efforts underway to improve the security properties of BGP. For examples of documents that have been produced up to this time of publication, see [RFC4593] and [SIDR]. There is a potential serious issue if a malformed optional transitive attribute is received. This issue and the steps to avoid it are discussed in [OPT_TRANS]. Please add to section 7 (Non-Normative references): [OPT_TRANS] Scudder, Chen, "Error Handling for Optional Transitive BGP Attributes", work in progress, draft-ietf-idr-optional-transitive, April 2009. [RFC4593] Barbir, Murphy, Yang, "Generic Threats to Routing Protocols", RFC4593, October 2006. [SIDR] Lepinski, Kent, "An Infrastructure to Support Secure Internet Routing", work in progress, draft-ietf-sidr-arch-08.txt, July, 2009. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
