IPv6 Address Specific BGP Extended Community Attribute
draft-ietf-l3vpn-v6-ext-communities-02

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    l3vpn mailing list <l3vpn@ietf.org>, 
    l3vpn chair <l3vpn-chairs@tools.ietf.org>
Subject: Protocol Action: 'IPv6 Address Specific BGP Extended Communities Attribute' to Proposed Standard

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

Ballot Text

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.

RFC Editor Note