Presentation is loading. Please wait.

Presentation is loading. Please wait.

Nov. 8, 2006IDR WG Meeting1 IPv6 Next Hop for IPv4 Prefix In BGP Updates, NH not necessarily of same address family as NLRI Currently deployed examples:

Similar presentations


Presentation on theme: "Nov. 8, 2006IDR WG Meeting1 IPv6 Next Hop for IPv4 Prefix In BGP Updates, NH not necessarily of same address family as NLRI Currently deployed examples:"— Presentation transcript:

1 Nov. 8, 2006IDR WG Meeting1 IPv6 Next Hop for IPv4 Prefix In BGP Updates, NH not necessarily of same address family as NLRI Currently deployed examples: –VPN-IPv4 family has IPv4 NH though with bizarre encoding to make it syntactically “look like” a VPN-IPv4 address –IPv6 address family can have IPv4 next hop using "IPv4-mapped IPv6 address", defined in RFC 4291 as an address of an IPv4 node Might become typical deployment scenario in dual stack core, so that single BGP session running on IPv4 carries v4 and v6 prefixes. –Other special purpose address families (l2vpn, rt-constraint) have been defined with IP NHs, usually allowing the NH to be either v4 or v6, depending on its length.

2 Nov. 8, 2006IDR WG Meeting2 Problem IPv4 AFI/SAFI: –unique, no obvious encoding trick allowing one to use NH of a different AF –Softwire WG requirement: carry IPv4 routing over IPv6-only single stack core v4 routing at border routers, not in core –Softwire solution: IBGP sessions running over v6, carrying v4 NLRI v4 NLRI need v6 NHs (data plane uses IPv6 or MPLS encaps)

3 Nov. 8, 2006IDR WG Meeting3 Solution Modify IPv4 address family definition: – to allow that NH can be either IPv4 or IPv6, –use length field to distinguish –use BGP capability to determine whether a peer can support this

4 Nov. 8, 2006IDR WG Meeting4 Rejected Alternatives Use TLV Encoding instead of length field –In general, a better solution, but –Simpler not to introduce a new type –Given existing deployment of strange encoding solutions for all cases but 4-over-6, hardly seems worthwhile to have a “purer” solution for this one case New AFI/SAFI for 4/6 case –More complicated Operationally Update for given NLRI would change AFI/SAFI as it travels, introducing all kinds of corner cases to track down.

5 Nov. 8, 2006IDR WG Meeting5 Is It Needed? Why not just force NH and NLRI to be same? –Support “v4-free core” as a overlay topology of v6 tunnels. –Run additional BGP sessions, on v4, over the overlay Softwire rather than IDR problem, but even so: –additional BGP sessions a complication –overlay topology a complication –not much to be said for this alternative

6 Nov. 8, 2006IDR WG Meeting6 Not Without Cost Simple solution, but not without cost: –when installing v4 route, need to go to v6 routing table to validate next hop –an implementation complexity But: –already done in VPN support –operational simplicity trumps implementation simplicity

7 Nov. 8, 2006IDR WG Meeting7 Info-SAFI and Encapsulations Softwire WG concerned with situations in which e.g., v4 packets need to be tunneled through a v4-free core. Easily done with MPLS, but a more complicated solution is desired, in which: –IP encapsulations are used to tunnel packets through core –Choice of encaps technology is a matter of policy Policies may be dependent on characteristics of tunnel endpoints e.g., if both endpoints belong to a particular class of routers, use encaps X, else use encaps Y Need way to advertise membership in a class. –Some IP encapsulations (GRE, L2TPv4) lack appropriate native signaling protocols: Need way to pass info needed to create the encaps header.

8 Nov. 8, 2006IDR WG Meeting8 Proposal Create new SAFI, info-SAFI, to carry info about a particular BGP speaker. –Address of BGP speaker embedded in NLRI. –Characteristics of BGP speaker advertised as (extended) communities attached to info-SAFI. –For particular encaps techniques, e.g., L2TPv3, define new attribute to carry signaling info. –Allows multiple info-SAFIs per speaker: some can carry slowly changing attributes and others more rapidly changing attributes but no semantics attached to how the attributes are distributed over the info-SAFIs.

9 Nov. 8, 2006IDR WG Meeting9 Obvious Alternative Just use /32 prefix identifying BGP speaker, and attach attributes to that Why not? –Route distribution constraints might be differrent –Don’t want to run into trouble with summarization policies

10 Nov. 8, 2006IDR WG Meeting10 What This Isn’t Not Tunnel-SAFI –not “tunnel infrastructure”, not trying to replace NH with tunnel Not “all purpose use BGP to send any random information about anything” scheme


Download ppt "Nov. 8, 2006IDR WG Meeting1 IPv6 Next Hop for IPv4 Prefix In BGP Updates, NH not necessarily of same address family as NLRI Currently deployed examples:"

Similar presentations


Ads by Google