1 / 10

IPv6 Next Hop for IPv4 Prefix

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

auryon
Download Presentation

IPv6 Next Hop for IPv4 Prefix

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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. IDR WG Meeting

  2. 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) IDR WG Meeting

  3. 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 IDR WG Meeting

  4. 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. IDR WG Meeting

  5. 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 IDR WG Meeting

  6. 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 IDR WG Meeting

  7. 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. IDR WG Meeting

  8. 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. IDR WG Meeting

  9. 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 IDR WG Meeting

  10. 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 IDR WG Meeting

More Related