Inter-Domain Routing Working Group K.Fang Internet Draft Cisco Systems Document: draft-zhiyfang-ivi-aware-bgp-00.txt July 2010 Expires: Jan 2011 IVI xlate rules aware in BGP Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on Jan 10, 2011. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. K.Fang Expires Jan.18 2011 [Page 1] Internet-Draft IVI xlate rules aware in BGP July 2010 Abstract This memo defines MP-BGP-4 to support IVI [1] to make IVI services aware in whole internet domain and trigger double IVI to save the ALG (Application Layer Gateway) resource , also use dIVI as a tunnel to provide full meshed softwire. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .3 1.1. Motivation. . . . . . . . . . . . . . . . . . . . . . . .3 1.2. Potential Benefits . . . . . . . . . . . . . . . . . . .3 1.2.1. Easy for dIVI support . . . . . . . . . . . . . .3 1.2.2. dIVI build up full mesh tunnel. . . . . . . . . .3 1.2.3. IVI service aware for Intra-domain routing. . . .4 1.2.4. Easy for fallback to single IVI . . . . . . . . .4 2. Definition & implementation . . . . . . . . . . . . . . . . . .4 2.1. MP-BGP Signaling flow Without IVI aware . . . . . . . . .4 2.2. MP-BGP Signaling flow With IVI aware. . . . . . . . . . .4 2.2.1. Option-1: Carrier IVI info in new attribute . . .5 2.2.1.1. Attribute definition . . . . . . . . . . . .5 2.2.1.2. Update in IPv4 Domain. . . . . . . . . . . .5 2.2.1.3. Update in IPv6 Domain. . . . . . . . . . . .5 2.2.2. Option-2: Introduce a new IVI SAFI. . . . . . . .6 2.2.2.1. SAFI definition. . . . . . . . . . . . . . .6 2.2.2.2. NLRI Encapsulation . . . . . . . . . . . . .6 2.2.2.3. NEXT-HOP . . . . . . . . . . . . . . . . . .6 2.2.2.4. IVI SAFI Signaling flow. . . . . . . . . . .6 2.3. Implementation analysis . . . . . . . . . . . . . . . . .7 3. Route decision . . . . . . . . . . . . . . . . . . . . . . . .7 3.1. Process UPDATE . . . . . . . . . . . . . . . . . . . . .7 3.2. Best route lookup . . . . . . . . . . . . . . . . . . . .7 3.3. Route advertisement . . . . . . . . . . . . . . . . . . .7 4. Packet flow . . . . . . . . . . . . . . . . . . . . . . . . . .8 4.1. IPv4 packet received. . . . . . . . . . . . . . . . . . .8 4.1.1. IPv4 RIB has available route . . . . . . . . . .8 4.1.2. IPv4 RIB check failure and IVI not enable. . . .8 4.1.3. IPv4 RIB check failure and IVI enable. . . . . .8 4.2. IPv6 packet received. . . . . . . . . . . . . . . . . . .9 4.2.1. IPv6 RIB has available route . . . . . . . . . .9 4.2.2. IPv6 RIB check failure and IVI not enable. . . .9 4.2.3. IPv6 RIB check failure and IVI enable. . . . . .9 4.3. Double IVI. . . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. Benefit for dIVI migrate softwire. . . . . . . 10 4.3.2. Backward capability. . . . . . . . . . . . . . 10 5. IPv4 to IPv6 migration. . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Reference . . . . . . . . . . . . . . . . . . . . . . . . . . 11 K.Fang Expires Jan.18 2011 [Page 2] Internet-Draft IVI xlate rules aware in BGP July 2010 1. Introduction This section explains the reasoning for BGP-4[RFC4271] aware IVI xlate rulesimplementation. 1.1. Motivation The experiences for the IPv6 deployment in the past 10 years strongly indicate to communicate with IPv4 and IPv6 address families, Since IVI use Stateless mapping, but currently IVI proposal is send Ipv4 and Ipv6 route update independency to different routing domain like below: <------IPv4 update----(IVI-Router)----IPv6 update -------> (192.168.1.0/24) (2001:ABCD::/64) Figure 1: Independent Routing info update in each domain Address Mapping rules are offered by DNS64 services which will cause some interworking issue. But it is also important to announce the IVI based Static mapping rules to other internet router to build up a global based v4/v6 xlate RIB. 1.2. Potential Benefits With the IVI xlate rules aware in MP-BGP4, it will provide many benefits. 1.2.1 Easy for dIVI support There are two potential deployment scenario for dIVI: +-+ IPv4 +--+ IPv6 Transit Core +--+ IPv4 +-+ |S|-->--//-->--|R1|=====>=====//=====>=====|R2|-->--//-->--|D| +-+ +--+ +--+ +-+ (IVI 1:1 xlate) (IVI 1:1 xlate) +-+ IPv6 +--+ IPv4 Transit Core +--+ IPv6 +-+ |S|-->--//-->--|R1|=====>=====//=====>=====|R3|-->--//-->--|D| +-+ +--+ +--+ +-+ (IVI 1:1 xlate) (IVI 1:1 xlate) Figure 2: dIVI for 4over6 and 6over4 tunnel The router on remote side if aware the local router's IVI xlate rules, both router will aware the IVI services are available , Then it will trigger both router running under Double IVI mode without any 6to4 ALG(Application Layer Gateway to check address translate deep in packet payload) function to save the resource. K.Fang Expires Jan.18 2011 [Page 3] Internet-Draft IVI xlate rules aware in BGP July 2010 1.2.2 dIVI build up full mesh tunnel dIVI will not use any ALG function since aware the remote router's serviceability , it's a high performance solution to migrate the 6over4 and 4over6 tunnel services to unified IVI services.With BGP announcement,IVI service info can be aware in all internet BGP speakers, and all routers can easily build up full meshed dIVI based "tunnel". 1.2.3 IVI service aware for Intra-domain routing With iBGP propagation all intra-domain router can be aware for IVI service, and Service Provider can setup a IVI service-router farm to handle all v4/v6 xlate service.IVI service can be easily centralized or distribute deploy in SP routing domain. 1.2.4 Easy for fallback to single IVI When remote router withdraw the IVI xlate rules advertisement in BGP-4. Local BGP Speaker still can trigger IVI xlate service by using single IVI and involve ALG function together. 2. Definition & implementation 2.1 MP-BGP Signaling flow Without IVI aware +-+ IPv4 +--+ IPv6 Transit Core +--+ IPv4 +-+ |S|-->--//-->--|R1|=====>=====/R2/=====>=====|R3|-->--//-->--|D| +-+ +--+ +--+ +-+ IVI 1:1 xlate IVI xlate <--10.1.0.0/24---BGPd---------2001:ABCD:ABCD::/40------> [Note: R1 xlate rule: 10.1.0.0/24<-- --> 2001:ABCD:ABCD::/40] Figure 3: IVI deployment without BGP IVI xlate rules propagation Previously IVI draft use independent RIB update. R1 will only send IPv6 SAFI to R2. and downstream router will lost xlate-rules from upstream router. Then both R1 and R3 will trigger ALG function to handle the 4<-->6 translation. 2.2 MP-BGP Signaling flow With IVI aware With MP-BGP protocol extensions to support IVI , Router can be aware The remote IVI mapping rules, There are two potential implementation to support IVI service aware in BGP domain. Option-1: Carrier IVI xlate rules in an optional transitive attribute Option-2: Develop a new SAFI for IVI service K.Fang Expires Jan.18 2011 [Page 4] Internet-Draft IVI xlate rules aware in BGP July 2010 2.2.1 Option-1: Carrier IVI info in new attribute 2.2.1.1 Attribute definition A new optional transitive attribute introduced to store the IVI xlate information. Definition as follows: Attribute-name : IVI_XLATE Attribute-TypeCode: 27 (if IANA approved) Attribute-Category: Optional transitive Path Segment Type: 1- carrier IPv6 prefix and propagation in IPv4 domain 2- carrier IPv4 prefix and propagation in IPv6 domain 3- Origin Router with IPv4 format 4- Origin Router with IPv6 format 2.2.1.2 Update in IPv4 Domain When IVI router send update message to IPv4 AFI, it will add a new optional transitive attribute (IVI_XLATE) include the IPv6 prefix in IVI xlate rules. It will notice all the other IPv4 BGP routers to use R1 as remote handle IVI translator. This would be let IPv4 domain aware single IVI services and trigger single IVI on R1. Signaling flow describe in Figure 4: +-+ IPv4 +--+ IPv6 +--+ +-+ |S|-->--//----->------|R1|=====//=========>|R3|--//-->--|D| +-+ +--+ +--+ +-+ IVI 1:1 xlate <--10.1.0.0/24-------- | IVI_XLATE, Optional transitive attribute | | Prefix: 2001:ABCD:ABCD::/40 | | OriginRouter: R1's IPv4 address | Figure 4: Update in IPv4 Domain 2.2.1.3 Update in IPv6 Domain Same as update in IPv4 domain, IVI router will also carrier IPv4 subnet info in an optional transitive attribute, Signaling flow describe in Figure 5 +-+ IPv4 +--+ IPv6 +--+ +-+ |S|-->--//----->------|R1|=====//=========>|R3|--//-->--|D| +-+ +--+ +--+ +-+ IVI 1:1 xlate ----------2001:ABCD:ABCD::/40---> | IVI_XLATE, Optional transitive attribute | | Prefix: 10.1.0.0/24 | | OriginRouter: R1's IPv6 address | Figure 5: Update in IPv6 Domains K.Fang Expires Jan.18 2011 [Page 5] Internet-Draft IVI xlate rules aware in BGP July 2010 2.2.2 Option-2: Introduce a new IVI SAFI When BGP speaker try to send out MP_REACH_NLRI update to remote router with new SAFI, the format of these update is should be followed in this section. 2.2.2.1 SAFI definition The AFI and SAFI assignment for IVI xlate rules will be used ( if IANA approved) like below: * AFI = 2(IPv6) * SAFI = 70(IVI xlate rules) 2.2.2.2 NLRI Encapsulation Base on IVI address format, IPv4 and IPv6 prefix for xlate rule can be store in a 128bit field. NLRI encapsulation defined as follows: +--------------------------------------------+-----------------+ | IPv6 Prefix | IPv4 Prefix | +--------------------------------------------+-----------------+ 0 96 128 Figure 6: NLRI encapsulation 2.2.2.3 NEXT-HOP Next-hop attribute calculate algorithm still follow the [RFC4271] in Section 5.1.3. 2.2.2.4 IVI SAFI Signaling flow With new SAFI, detailed signaling flow defined as follows: +-+ IPv4 +--+ IPv6 +--+ +-+ |S|-->--//----->------|R1|=====//=========>|R3|--//-->--|D| +-+ +--+ +--+ +-+ IVI 1:1 xlate IPv4 <--10.1.0.0/24-------- Nhop : R1's IPv4 address IVI <---------------------- +---------------------+ | Encapsulation NLRI | | 2001:ABCD:ABCD::/40 | | 10.1.0.0/24 | +---------------------+ Nhop : R1's IPv4 address K.Fang Expires Jan.18 2011 [Page 6] Internet-Draft IVI xlate rules aware in BGP July 2010 ----------2001:ABCD:ABCD::/40---> IPv6 --------------------------------> IVI +---------------------+ | Encapsulation NLRI | | 2001:ABCD:ABCD::/40 | | 10.1.0.0/24 | +---------------------+ Nhop : R1's IPv6 address Figure 7: SAFI based IVI update 2.3 Implementation analysis Option-2 introduce a new SAFI, and it will request all the transit Router in the forwarding path to upgrade the BGP software to be IVI aware Router. Option-1 use "Optional transitive attribute" that no need require router upgrade the BGP software. Option-1 MUST support for IVI service aware in BGP, Option-2 is an alternative option for IVI service aware in BGP. 3. Route decision 3.1 Process UPDATE When update message include "IVI_XLATE" attribute, it will copy the NLRI prefix with the prefix in IVI_XLATE attribute together in IVI xlate RIB, and also copy "IVI_XLATE origin router" value as next_hop. All the other Path attribute will also copy to IVI xlate RIB. If Router implement with Option-2 IVI SAFI, it will follow the general work flow which defined in [RFC4271]. 3.2 Best route lookup During the route decision, best routes lookup prefer the original AFI/SAFI RIB. If the router does not enable IVI xlate service, the packets MUST be dropped and not ALLOW to trigger IVI xlate RIB lookup. If the original RIB does not have available next-hop, it will trigger IVI xlate RIB lookup. IVI xlate RIB route decision will also based on "Path Attribute" and follow the RFC4271. 3.3 Route advertisement If local Router defined IVI xlate service, it will trigger the local xlate rules add into IVI xlate RIB. K.Fang Expires Jan.18 2011 [Page 7] Internet-Draft IVI xlate rules aware in BGP July 2010 All best route in IVI xlate RIB will advertise to the other Speakers, it will automatic add as "IVI_XLATE" attribute during update the IPv4 and IPv6 SAFI, detailed signaling flow defined in Section 2.2.1. 4. Packet flow 4.1 IPv4 packet received 4.1.1 IPv4 RIB has available route When an IPv4 packet received, if it has available route in IPv4 RIB, the detailed forwarding procedure describe as bellow: 4.1.2 IPv4 RIB check failure and IVI not enable When an IPv4 packet received, and IPv4 RIB check failure, if IVI not enable on local router , packets will dropped . 4.1.3 IPv4 RIB check failure and IVI enable When an IPv4 packet received, and IPv4 RIB check failure, if IVI enabled, it will trigger IVI xlate RIB lookup. When received packet's destination address is in local xlate prefix, it will trigger the source address lookup in IVI xlate RIB. If source address also can be found in IVI xlate RIB, it will trigger dIVI process without ALG function involved, detailed implementation defined in Section 4.3. If source address not in xlate RIB , it will trigger normal ALG involved IVI translation. +-+ IPv4 +--+ IPv6 +--+ +-+ |S|-->--//----->------|R1|=====//=========>|R3|--//-->--|D| +-+ +--+ +--+ +-+ -----Recv Ipv4 pkts-----> Step.1 ---Check R1 Ipv4 RIB-------> [Check result: failure] Step.2 ---Check R1 IVI xlate RI---> [dst.ip in local xlate prefix] Step.3 ------check src.ip in IVI xlate RIB--> If ( src.ip in xlate RIB ) { ALG_invovle == OFF } else { ALG_invovle == ON } Step.4 ------ IVI xlate ---------> -----Send IPv6 pkts ---------> Figure 8: packet flow for received ipv4 packets and nhop available in IVI xlate RIB K.Fang Expires Jan.18 2011 [Page 8] Internet-Draft IVI xlate rules aware in BGP July 2010 If destination address lookup failure in xlate RIB, packet directly dropped. 4.2 IPv6 packet received 4.2.1 IPv6 RIB has available route When an IPv6 packet received, if it has available route in IPv6 RIB, the detailed forwarding procedure describe as bellow: 4.2.2 IPv6 RIB check failure and IVI not enable When an IPv6 packet received, and IPv6 RIB check failure, if IVI not enable on local router , packets will dropped . 4.2.3 IPv6 RIB check failure and IVI enable When an IPv6 packet received, and IPv6 RIB check failure, if IVI enabled, it will trigger IVI xlate RIB lookup. When received packet's destination address is in local xlate prefix, it will trigger the source address lookup in IVI xlate RIB. If source address also can be found in IVI xlate RIB, it will trigger dIVI process without ALG function involved, detailed implementation defined in Section 4.3. If source address not in xlate RIB , it will trigger normal ALG involved IVI translation. +-+ IPv6 +--+ IPv4 +--+ +-+ |S|-->--//----->------|R1|=====//=========>|R3|--//-->--|D| +-+ +--+ +--+ +-+ -----Recv Ipv6 pkts-----> Step.1 ---Check R1 Ipv6 RIB-------> [Check result: failure] Step.2 ---Check R1 IVI xlate RI---> [dst.ip in local xlate prefix] Step.3 ------check src.ip in IVI xlate RIB--> If ( src.ip in xlate RIB ) { ALG_invovle == OFF } else { ALG_invovle == ON } Step.4 ------ IVI xlate ---------> -----Send IPv4 pkts ---------> Figure 9: packet flow for received ipv6 packets and nhop available IVI xlate RIB If destination address lookup failure in xlate RIB, packet directly dropped. K.Fang Expires Jan.18 2011 [Page 9] Internet-Draft IVI xlate rules aware in BGP July 2010 4.3 Double IVI If local router and remote router generate the IVI xlate rules on both side and also be propagation in BGP domain. It's easy for local router aware and trigger dIVI function without ALG involved. 2 scenario for dIVI usage which defined in Figure 2. This is an alternative way to migrate 6over4 and 4over6 tunnel to IVI framework. 4.3.1 Benefit for dIVI migrate softwire With [RFC5747] and 6over4 softwire implementation, propagation tunnel info in BGP domain need all router upgrade to aware the new SAFI. But with IVI aware in BGP, it's easy to remain the transit router stay on old BGP software. dIVI also has same auto full mesh capability with the BGP advertisement. 4.3.2 Backward capability Another potential benefit is dIVI solution support backward capability to single IVI, but when one router fallback to none-support version, the softwire tunnel will shutdown. 5. IPv4 to IPv6 migration With IVI aware BGP support, the ipv4 to ipv6 migration procedure defined like below: Step.1 : Migrate current tunnel based services to dIVI to setup unified IVI framework. +----- dIVI based Tunnel-----+ | | +-+ IPv4 +--+ IPv6 Transit Core +--+ IPv4 +-+ |S|-->--//-->--|R1|=====>=====//=====>=====|R2|-->--//-->--|D| +-+ +--+ +--+ +-+ (IVI 1:1 xlate) (IVI 1:1 xlate) Figure 10: dIVI based tunnel Step.2 : IPv4 network connect to IPv6 island use single IVI +-+ IPv4 +-----------+ IPv6 +--+ +-+ |S|-->--//----->------|R1(1:1 IVI)|=====//=======>|R3|--//-->--|D| +-+ +-----------+ +--+ +-+ Figure 11: singe IVI Step.3 : Upgrade AS internal network to IPv6, and withdraw relative prefix advertisement in IVI xlate rules. Since IVI backward capability descripts in Section 4.3.2, Withdraw the IVI xlate rules will not break the traffic forwarding. K.Fang Expires Jan.18 2011 [Page 10] Internet-Draft IVI xlate rules aware in BGP July 2010 +-+ IPv6 +--+ IPv6 +--+ +-+ |S|-->--//----->------|R1|=====//=========>|R3|--//-->--|D| +-+ +--+ +--+ +-+ Withdraw IVI xlate rules Fallback to single IVI | +-+ IPv6 +--+ IPv6 Transit Core +--+ IPv4 +-+ |S|-->--//-->--|R1|=====>=====//=====>=====|R2|-->--//-->--|D| +-+ +--+ +--+ +-+ Withdraw IVI xlate rules (Remain IVI 1:1 xlate) Figure 12: upgrade AS internal link and withdraw IVI xlate rules Step.4 : Upgrade all link to IPv6 remote and disable all IVI service. 6. Security Considerations With IVI aware xlate in BGP, the basic forwarding and route decision mechanism still follow the general MP-BGP procedure. BGP peering may be maintained over IPsec or SSL or other secure communications. 7. IANA Considerations This document defines a new BGP Attribute like below: Attribute-name : IVI_XLATE Attribute-TypeCode: 27 Attribute-Category: Optional transitive Defination: See Section 2.2.1.1 With Option-2 IVI SAFI implementation it required new SAFI definition like below: * AFI = 2(IPv6) * SAFI = 70(IVI xlate rules) Detailed definition See Section 2.2.2.1 8. Reference [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC5747] J. Wu, Y. Cui, X. Li, M. Xu, C. Metz," 4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions", RFC 5747, March 2010. K.Fang Expires Jan.18 2011 [Page 11] Internet-Draft IVI xlate rules aware in BGP July 2010 [1] X. Li, C. Bao , F. Baker, K. Yin, "IVI Update to SIIT and NAT-PT", draft-baker-behave-ivi-01, Sept.16.2008 [2] X. Li, C. Bao , F. Baker, K. Yin, "Framework for IPv4/IPv6 Translation", draft-ietf-behave-v6v4-framework-09, May 18, 2010 Authors' Addresses Kevin Fang Cisco Systems EMail: zhiyfang&cisco.com K.Fang Expires Jan.18 2011 [Page 12]