| Internet2 IPv6 Connector Changes - Moving Commercial IPv6 to CPS |
| Caren Litvanyi | |
| lead network engineer | |
| peering team | |
| Internet2 NOC | |
| Joint Techs Meeting | |
| January 2008 | |
| Honolulu, HawaiÕi |
| "What is CPS?" |
| What is CPS? | |
| How is Internet2Õs IPv6 peering done today? | |
| Why are we proposing changing this? | |
| What are the implications for Connectors? | |
| What about R&E IPv6 peering? | |
| What happens if my organization decides to not participate? | |
| How will moving commercial IPv6 to CPS be implemented? | |
| What is still being worked out? | |
| How can I comment or participate? |
| CPS Background |
| CPS is Internet2Õs ÒCommercial Peering ServiceÓ. | |
| ÒThrough CP Service members can leverage their existing Internet2 Network investments to help serve their commercial Internet needs, thereby saving money on commodity Internet charges.Ó | |
| CPS is included in the base connection fee, so it is available for Internet2 Network connectors at no additional cost. | |
| http://www.internet2.edu/network/cp/ |
| CPS Background |
| Implemented as an ÒoverlayÓ on the existing Internet2 Layer3 Network. | ||
| Uses MPLS Layer3 VPN, VRF on same T640 routers. | ||
| Currently 4 commercial public peering sites: | ||
| PAIX New York 10GE | ||
| Equinix Chicago 10GE | ||
| PAIX Palo Alto 10GE | ||
| SIX (Seattle) 1GE | ||
| Also PNI (private peerings). | ||
| CPS Background |
| One of the additional goals of the CPS project was to improve commercial IPv6 connectivity for our R&E Members. | |
| This was hoped to have the additional benefit of promoting the adoption and ÒmainstreamÓ implementation of IPv6. | |
| The original intention was to connect commercial IPv6 peers with the traditional R&E network instance (with which all Connectors already peer). |
| IPv6 on the Internet2 Network |
| Internet2 has the allocation 2001:468::/32, and has delegated about 40 /40s to Connectors. | |
| Allocations are documented at: http://ipv6.internet2.edu/Abilene_Allocations.shtml | |
| The R&E backbone has supported native IPv6 for years, and maintains native IPv6 BGP peerings with many Connectors, government-sponsored research organizations, international R&Es, ISPs, etc. | |
| The IPv6 working group and IPv6 how-to workshops have been sponsored for years as well. |
| Commodity IPv6 on the Internet2 Network Today |
| Internet2 purchases a modest amount of IPv6 transit from Global Crossing. | |
| Peers with commercial IPv6-enabled ISPs at PAIX and the NGIX. These are routed out of Los Angeles and Salt Lake City respectively. | |
| MAX also kindly provides additional commodity IPv6 transit to Internet2 on the east coast. | |
| Internationals pass us some commercial prefixes. | |
| All of the above are routed in inet6.0, the default R&E routing instance. |
| Why do we want to change this? |
| CPS gives us a great opportunity to have IPv6 connectivity with more commercial ISPs in more locations! | ||
| Exchange points switches generally carry IPv4 and IPv6 in the same VLAN | ||
| In Layer3-VPN implementations, an interface (or VLAN subinterface) must be defined to exist in one, and only one, VRF. That means R&E or CPS, not both. | ||
| to separate the two, putting IPv4 in cps.inet.0 and IPv6 in inet6.0 would have taken two connections to each exchange point. | ||
| This would be expensive, in port fees and cross-connects. | ||
| Other options like leaking routes between instances seemed kludgy and messy to implement. | ||
| The Recommendation sent to NTAC |
| The best thing to do seemed to be to carry the IPv6 prefixes from CPS commercial peers in the CPS VRF - cps.inet6.0. | ||
| The CPS VRF would then carry all commercial unicast traffic, IPv4 and IPv6. | ||
| New IPv6 peers at the public exchange points. | ||
| Move the NGIX and PAIX connections, and transit. | ||
| This seems ÒcleanerÓ philosophically too - aligning commercial IPv4 and IPv6 routing. Easy to explain. | ||
| Email sent to NTAC last autumn for comment. | ||
| The Implications for Connectors |
| If Connectors want to benefit from the enhanced commercial IPv6 connectivity provided by Internet2, they will need to establish a second IPv6 connection to Internet2, which connects them to the CPS VRF. | |
| For a connector already participating in CPS, this can be done on that same VLAN, or we can do a second VLAN between the Connector and the Internet2 CPS instance. |
| The Implications for Connectors |
| Addressing. | ||
| If you have a delegation from Internet2Õs IPv6 block, it particularly makes sense to participate in the CPS IPv6. | ||
| In other words, this brings up the usual multi-homing and provider-independent addressing dilemma | ||
| We encourage Connectors to take this opportunity to obtain PI address space from ARIN as appropriate, whether participating in IPv6 via CPS or not. | ||
| Internet2 is happy to be your primary upstream for IPv6, R&E and commercial, so it is not necessary to get PI space right away if you currently use a delegation from Internet2. | ||
| What about R&E IPv6? |
| This will continue to be well-supported, monitored, and instrumented, just as it is today. | |
| The master instance (inet6.0 in Juniper terms) will continue to carry IPv6 routes for R&E. | |
| Specifically, all Connector-to-Connector traffic will continue to be in the master instance. | |
| Peerings with internationals like GEANT will continue to be in the master instance, as well as ESnet, DREN, etc. | |
| Granted, today, this is still slightly messy, as not all international R&Es have IPv6 policy aligned with their IPv4 policy. You may get some commercial routes this way. | |
| ButÉ do I have to participate? |
| No, you do not have to participate at all. You may continue with just your IPv6 peering with the Internet2 R&E instance, but you will not get commercial prefixes this way in the future. | |
| Note, you may establish an IPv6-ONLY connection to CPS - you do not have to be an IPv4 CPS participant! | |
| If you use Internet2 delegated address space and choose not to participate, you will likely soon have ONLY R&E IPv6 connectivity. |
| The Implementation |
| Enable IPv6 in the CPS VRF -- done. | ||
| Get Connectors set up next. | ||
| This means you will not see much until most Connectors have the new IPv6 peering up with CPS. | ||
| This is so we can advertise our /32 and not lose anyone who wants to continue to have commercial IPv6 connectivity via Internet2. | ||
| Move current transit and commercial IPv6 peers. | ||
| Bring up new IPv6 peers at the public exchanges. | ||
| The Implementation Details |
| Internet2 staff and GlobalNOC staff will contact Connectors about their IPv6 connectivity, open a ticket. | ||
| Point-to-point addressing if delegated from Internet2 will look similar: | ||
| If you have 2001:468:ff:144::2 today | ||
| Your additional address will be: 2001:468:ffff:144::2 | ||
| We generally plan to reuse ConnectorsÕ same access-lists, MD5, etc., but this can be as you wish. | ||
| You decide where you want the routes on your end - some may want them in their own Òcommercial VRFÓ, others, dump them into what is today their R&E IPv6. | ||
| What is still being worked out |
| Feedback from NTAC indicated a desire to maintain universal access to IPv6 performance measurement servers. | |
| The addressing issues may bite us in the end, so we may need some additional changes there. | |
| We do not yet have a specific timetable to implement this migration. |
| Comments? |
| Talk to Steve Wallace of Internet2 -- ssw@internet2.edu | |
| Talk with NTAC members (Paul Schopis, chair). | |
| Technical/Implementation details - ask the NOC noc@net.internet2.edu, or me specifically -- litvanyi@grnoc.iu.edu | |
| Find us here at JT! | |
| Thank you! |