Juniper Networks (UK) Limited 7 th July 2009 BEST PRACTICE IMPLEMENTING IPV6 IN THE CORE 2PM BST, 3PM CEST WITH JULIAN LUCEK, DISTINGUISHED SYSTEMS ENGINEER Duration: 00:52:25 Presenters Julian Lucek Jean Marc Uzé Operator: Thank you for standing by and welcome to the Jtech Live event Best Practice implementing IPV6 in the core. At this time all participants are in a listen-only mode. There will be a presentation followed by a question and answer session at which time if you wish to ask a question you will need to press *1 on your telephone. I must advise you this conference is being recorded today, Tuesday 7 th July 2009. I would now like to hand over to your speaker today, Mr Julian Lucek; please go ahead sir. Julian Lucek: This talk is on the subject of transporting IPv6 across the core. My name is Julian Lucek and I am co-presenting this presentation with my colleague Jean-Marc Uzé; the idea is that one of us will show slides and everyone will look out for questions which will be popping up in the Q&A window. You can type in questions during the presentation to that window. Also at the end, if you are on the phone bridge you can also ask questions verbally at the end. The background behind this talk is that we've been hearing a lot of interest in IPv6 from a lot of the customer base. This is largely driven by the fact 1
that the IPv4 address is predicted to run out relatively soon. Now for many people IPv6, rather than being a futuristic thing is now regarded as something that is relatively imminent. The good news from the Junos point of view is that from Day 1 we've had a lot of IPv6 capability, so when our very first product the M40 was introduced in 1998 the A6 already had the IPv6 capability in there. That made it easier to introduce the IPv6 protocol features and so on. When it comes to the IPv6 versions of the various protocols and also the forwarding features, we introduced those quite a long time ago, in the main, and so for example even some of the advanced things, such as 6PE and IPv6 layer 3VPNs which I am going to talk about, we've had in the code for several years. Let s have a look at an outline of what I am going to talk about today: as I mentioned I ll be focussing on different ways of carrying IPv6 across the core of the network. It might be the case that you have customers who are asking for an IPv6 internet feed, or maybe they want private connectivity using VPN between their sites, in order to carry IPv6 traffic. What I am going to talk about are different ways of carrying those types of traffic across the core of your network. If you look at the various schemes that are available, on the one hand there are some MPLS based schemes; one of those is 6PE, which allows you to carry IPv6 over the core even if the core is only IPv4 and MPLS enabled. Also I ll talk about IPv6 layer 3 VPN; sometimes this is known as 6VPE. Sometimes people do mix up 6PE and 6VPE; when we come to that section I ll be explaining the difference between those two schemes. On the other hand we have some IP based schemes; if you don t have MPLS based in your network you can either carry the IPv6 traffic using configured tunnels, transporting it over IPv4 tunnels to take it across the core of the network. Or else you can carry it natively; you can do native IPv6 forwarding through the core of the network. Typically because people are also carrying IPv4, of course, they ll be doing IPv4/ IPv6 dual stack. During this talk I ll be talking about all four of these different schemes that we have shown on this slide. First of all what I'd like to do is talk about the MPLS based schemes. The 6PE, to give it its full title its IPv6 islands over an MPLS IPv4 core that 2
is described in RFC4798; and the IPv6 VPN, which I mentioned is now sometimes called the 6VPE nowadays that is described in RFC4659. The interesting thing about both of those schemes is the fact that you can avoid turning on IPv6 in the core of your network; you can use existing IPv4 signalled transport LSPs, which you might already have deployed for carrying IPv4 traffic and you can use exactly those same LSPs if you wish for this IPv6 traffic. Both of these, as I mentioned, we've had in the code for quite a long time and lets have a look at the applicability of each of these. The 6PE scheme, the important thing to emphasise is that it is not a VPN technology; sometimes people think it is a VPN, but it is not. The roots for 6PE reside in the main routing instance on each PE router; and as such the 6PE is useful for transporting internet IPv6 just like you transport internet IPv4; typically in the main routing instance with 6PE you can transport internet IPv6 between your PE routers and do that over MPLS. The IPv6 VPN, on the other hand, by definition is a VPN and it is very similar to the IPv4 layer 3VPN model. With that you ve got routes residing in VRS on each PE router and so that gives you separation between different customers and it allows you to have overlapping addresses, just like with the IPv4 VPNs. Also one use case for it is that you could, if you want, use it for internet IPv6; by analogy some people use VRS to carry it might be Version4 internet routes. People who do that can also put internet IPv6 in the VRS if they want, and use IPv6 VPN as the infrastructure for transporting that traffic across the core. Let s have a look in slightly more detail at the 6PE scheme. If you look at this diagram, the grey region in the centre of the diagram is the IPv4 domain. That extends inwards from the PE routers towards the core of the network and the links, which are shown in black, are carrying normal IGP, carrying IPv4 reachability information, IPv4 addresses on the links. You have MPLS LSPs, which are shown in red between the PE routers; those are signalled using IPv4, either RSVP or LDP. Then you need to have BGP sessions between your PE routers and those can be going via route reflectors if you want; those again are running over IPv4; that infrastructure in the middle of the network in the grey is normal IPv4. 3
Then what you have is islands, as IPv6, because you might have customers who have asked for an internet IPv6 routes feed and so you can see customer A and customer B, which are in those IPv6 islands shown in blue. For that, between the PE routers and the customer routers you ve got EBGP sessions exchanging IPv6 prefixes, of course. Also you'd have IPv6 addresses on those links between the PEs and the customers. Similarly, at the ASBR you ve got ASBR placed in the pairing exchange and so you ve got pairings with various private peers or upstream providers, and again you ve got EBGP sessions with each of those exchanging IPv6 prefixes. The point of the 6PE infrastructure is that it allows those IPv6 prefixes to be communicated between the PEs and the ASBRs and it allows the traffic to be transported on those red MPLS LSPs without having to turn on any IPv6 within that grey island in the middle that's the premise behind 6PE. Let s have a look in slightly more detail about how you actually forward the traffic in the 6PE scheme. If you're doing transport of IPv4 packets over MPLS, then what you're doing is just putting the IPv4 packet directly into the transport LSP. If you did the same with IPv6 packets, you could actually cause problems. If you re using a Penultimate Hop Popping on your LSP, what would happen is that a bare IPv6 packet would be exposed on the Penultimate router, and the Penultimate router is typically a P router that does not run IPv6. The problem with that is that if it doesn t support IPv6, it wouldn t know how to set the correct ether type on the link going to the PE router the correct ether type in the layer 2 header, which would confuse it. If on the other hand you used the explicit NULL label on the last hop of the LSP, you have the issue that the explicit NULL label is different for IPv4 and IPv6. You couldn t use the same LSP for both IPv4 and IPv6 traffic, which would be inconvenient. In fact, what 6PE does, is it uses an inner label in order to shield the IPv6 packet from the P routers, so we can look at that in more detail on a diagram. In the top diagram, I m showing the normal IPv4 over MPLS label encapsulation, so this is assuming IPv4 internet packets in the main routing instance, and so the packets are travelling from left to right, and so the packets arrive from the customer on the ingress PE which is PE1, and PE1 does a route lookup in BGP; it determines that PE2 is the BGP next hop, and so it identifies the LSP that 4
goes towards PE2, and so it puts the corresponding label onto the packet. It puts the MPLS label X on to the packet; the packet goes to PE1; PE1 swaps the label for a label value of W, and then PE2, which is doing Penultimate Hop Popping, is popping that label value of W, exposing the bare IPv4 packet, which travels, final hop to PE2, and PE2 then routes it towards its final destination. In the 6 PE case in contrast, we show what s happening in the lower half of the slide. As I mentioned, we re using an inner label to shield the IPv6 packets, and so in that case, PE1 is putting on an inner label, whose value is Y, and then it s pushing the transport label on to the packets, which is having a value of X, and then as before, on PE1, PE1 swaps that label value of X to a label value of W; and then on PE2, PE2 is popping that label W, and so what you re left with is the IPv6 packet, with that inner label Y, and so because we ve got that inner label value of Y, PE2 never sees the IPv6 packet, which is good, because PE2, according to the definition of 6PE may not support IPv6, as I said. And so, that packet, with that label value of Y, arrives on PE2; PE2 takes off that label value of Y and does a route lookup on the underlying IPv6 packet, and sends it towards its destination. The question is, how does PE1 know what that inner label value is that label value of Y, and the answer is that that s communicated over the BGP session, and so we ve got a multiprotocol BGP session. It s using the special address family, which is AFI2 and SAFI4 as it happens, and that s an address family for exchanging labelled IPv6 routes, and so that s how that label value is communicated. Those are the BGP sessions for each IPv6 prefix that is advertised; that s the essence of the 6PE scheme. Now we can look at the configuration; in terms of the BGP configuration, the configuration is relatively straightforward, and so you are turning on family INET6, as you can see, shown in red, labelled Unicast because we want a labelled route to be sent, and then explicit NULL, and what that explicit NULL means is that the actual label value that we advertised in JUNOS is actually always the label value 2, which is the IPv6 explicit NULL. Some other implementations that necessarily advertise 2 as the label value, but that s fine, it should operate fine with those other implementations that s not a problem at all. 5
The other thing is that on the core facing interface on the PE, you need to configure family INET6. You don t configure an address on that; all you re doing by configuring family INET6 is you re saying to the router that you can expect to see packets arriving with that label value of 2, which is an IPv6 explicit NULL, and so the interface has to be ready to receive such packets. The other thing that needs to be configured is under protocols and PLS. You just have this line of configuration, IPv6 tunnelling, so those are the ingredients that you need to turn on 6PE. If you look at the link at the bottom of this slide, that shows you more details in our techpubs on how to configure the 6PE scheme. 6PE has been deployed in various networks: I would like to show you an example and so the next two slides are provided courtesy of Telefónica, who have deployed 6PE in their network. The 6PE in Telefónica has been deployed in the international network, so this is the Telefónica International World Wide Service Network, and this is a network that spans the whole of Europe and South America. For this 6PE scheme, the IPv6 pairings for the outside worlds are in AM6 Amsterdam, and also links in London, and as far as the BGP goes, there s a full mesh of BGP sessions between the 6PE PE routers, and for the transport, the LSPs or LDPs sit in the LSPs, and as I said, these are just signals using normal IPv4. Here s a schematic diagram of that network, so you can see the Telefónica International IS in the middle of the slide. You can see the two pairing exchanges, and so you ve got 6PE configured on those pairing routers, and then you ve got various PE routers facing towards the customers, and of course they have the 6PE configured on there as well, and as you saw from the previous slides, you ve got the full mesh of BGP sessions communicating the IPv6 prefixes. That s the real deployment of 6PE. Staying on the subject of using MPLS to transport IPv6 traffic, I d like to turn our attention to the IPv6 layer 3 VPN. As I mentioned before, this is described in RFC4659, and like the 6PE, you can use the existing IPv4 signalled LSPs to carry the traffic, and it s using very similar machinery to the IPv4 VPNs, and in fact you can have IPv4 and IPv6 co-existing in the same VRF, and so you re using multiprotocol BGP to exchange labelled 6
VPN routes between the PEs, so that s the prefix plus the inner label, VPN label. You re using route distinguishers to disambiguate routes; you re using route targets in the form of extended communities, to identify which VPN you want to put these routes into, and the label stacking is the same as for the IPv4 case, so the ingress PE is pushing the VPN label on to the packet, and then pushing the outer transport label, which might be the RSVP or LDP signalled LSP. This diagram shows the typical infrastructure for IPv4, layer 3VPN; you can see we ve got our PE routers, we ve got MPLS LSPs shown in orange, which are signals using IPv4. We ve got BGP sessions to communicate reachability information between the PEs, and typically that goes via route reflectors; and on those BGP sessions, you have the VPN- IPv4 address family configured. Then, between the PEs and CEs you have various protocols, depending on the customer requirements; you might be running an LSPF or EBGP or you might have static routing so that the PEs can exchange routes with the CE routes. That s typical IPv4 VPN infrastructure. For the IPv6, it s very similar, so again we ve got MPLS LSPs - signals using IPv4 as shown in orange; we ve got the BGP sessions, and those are running over IPv4. This time, you re using the IPv6 VPN address family VPN-IPv6 address family; and then of course this time, on the PEs facing the CEs, you ve got IPv6 address configured on the interface, and you re running a protocol that supports IPv6 in order to exchange routing information with the CE routers, and so that could be OSPFv3, or it could be BGP carrying IPv6 address family, or it could be static routes, of course; so a very similar infrastructure, as you can see, to the IPv4 layer 3 VPN. It s interesting to look at what the BGP updates look like, when the PEs are communicating reachability information; so on the left of the slide I m showing the IPv4 layer 3 VPN case, and on the right hand side of the slides, the IPv6 VPN case, and as you can see, they re very similar, so you ve got the address family, and in the IPv4 case that s SAFI 128, and in the IPv6 VPN case, it s SAFI 2, SAFI 128, as shown in that blue colour. You ve got the route target the extended community - and you ve got the next hop, and in the VPN IPv6 case, the BGP next hop is encoded as IPv4 mapped IPv6 address, and then if you look at the NLRI itself, you ve got the route distinguisher in both cases. In the actual prefix being advertised, and the prefix in the IPv6 case is shown in that blue colour, so it highlights it, and then the label the VPN label that s associated to that prefix it s 7
very similar, whether it s IPv4 or IPv6. This shows the configuration; from the BGP side, as shown in red, you need to turn on family INET6-VPN, and if you re also still carrying IPv4 prefixes in the layer 3 VPN, you still have the family INET VNP turned on as well, so that s the BGP part of the configuration. As you saw through the 6 PE case, under protocols and PLS we turn on this phrase IPv6 tunnelling, and then if you look at the actual configuration of the VRF, then on the left I m showing an example for IPv4, and on the right an example for IPv6. In the VRF there s no explicit configuration where you say this VRF is carrying IPv6. It s implicit, so basically it s determined by the fact that you ve got IPv6 address configured on at least one of the interfaces in the VRF. Also, in this case, in terms of the protocols, it s got OSPFv3 configured towards the CE routes, so in the main, you can see the configuration is very similar whether it s IPv4, or IPv6. If you want to see more details of the configuration, then that s in our techpubs, at the link shown at the bottom of this slide. IPv6, layer 3 VPN has been deployed, so I d like to show you some slides which are provided courtesy of Pacific Northwest Gigapop, who have deployed this. Pacific Northwest Gigapop are in North America and they provide connectivity services to R&E customers. The idea is that with the IPv6, they offer different packages of routes that the participants the research and education networks - can sign up to. For example, they can sign up to receive routes from research and education peers; they can sign up to receive routes from the Internet 2 network; they can sign up to receive routes from the general IPv6 internet. The idea is that each of these packages of routes is put into a different IPv6 layer 3 VPN, and so depending on what each R&E customer signs up for, they are connected into these various different VPNs, using a different logical interface to connect them into the different VRFs. This network has actually been in production since September 2007, so this is one of the first deployments of IPv6 layer 3 VPN. If you look at this network diagram, what you have is a mixture of different routers T640s and M120s for example - and so high speed participants, high speed customers, are connected at 10 gigs into the T640s the T640 has the Layer 3 VPN IPv6 configured on it. Sometimes people think of the T series as being a core router, but it makes a very good high speed PE 8
as well of course; and then the lower speed participants, the ones who are connected at 1 gig, are connected into M120s over the 1 gig interfaces, so this is a real deployment of IPv6 layer 3 VPNs as you can see. Also, other organisations have been involved in trials, lab trials, for example, and this is a slide provided courtesy of BT, which shows an IPv6 layer 3 VPN lab trial. In this trial, there was a live feed of IPv6 internet routes full feeds coming from the UK6x, and that feed was put into one of the VRFs for the purposes of this trial, and then other VRFs were used for other purposes, simulating private IPv6 connectivity; then various features were tested, during this trial - various routing protocols between PE and CE, so BGP, OSPFv3, and also static routes. The other thing that was tested, which is interesting, is routes target filtering on the BGP sessions, so route target filtering people use it for the IPv4 layer 3 VPNs, and it s also available for the IPv6 layer 3 VPNs. Route target filtering, in case you haven t come across it, is a really useful technique to avoid sending layer 3 VPN routes to a PE that the PE is not interested in. Rather than sending it routes pertaining to all of the VPNs in the network, route target filtering gives you an automated way of only sending routes pertaining to VPNs that it has configured on it. It s a very convenient scheme to use. That was tested as part of this lab trial as well. The other thing that was tested, which is also very important is forwarding plain features; things like classifying the packets as they come in from a customer policing, firewall filtering and so on, and we support all of those for IPv6 packets of course. One frequently asked question regarding the IPv6 layer 3 VPN is whether you can have IPv4 and IPv6 in the same VRF, and the answer is yes. You can certainly do that; in that case, going to the CE you d have a protocol that supports both IPv4 and IPv6, or two different protocols, so you could have OSPFv2 for the IPv4, and OSPFv3 for the IPv6, for example. Or you could be using EBGP sessions, with both the IPv6 and IPv4 address families, and that s perfectly fine. You can have those in the same VRF and be using the same route targets, whether it s IPv4 or IPv6 prefixes. Regarding adding IPv6 VPN into the existing VPN infrastructure, if you re already using layer 3 VPN; as I mentioned, you can use the same LSPs as you already have in your network in the same BGP sessions which you might already have for IPv4 VPNs, or BGP layer 2 VPN and BGP VPLS. 9
You simply add that extra address family on the BGP sessions and much the same features are supported for the IPv6 VPN, so typically people who want to do multi-field classification or BA classification when the packet comes in from the CE routes, firewall filtering and policing, destination class usage perhaps, selecting an LSP according to policy or class and finally sending the packet on the outbound queue and marking the XP bits to the required [audio] all the same sorts of things people often do with IPv4 Layer 3 VPN. The other thing is on the egress PE; again, people would want to do classification on the egress PE as the packet comes in from the core, firewall filtering and policing and then finally sending the packet out into the correct queue on to the outbound interface, so the same sorts of processes that people do today with IPv4 Layer 3 VPNs. That was a flavour of the MPLS-based schemes for transporting IPv6 across the core. Now let s turn our attention to the right hand side of this slide and the IP-based schemes. IPv6 over IPv4 configured tunnels I ll talk about first of all and then I ll talk about native IPv6 or IPv4/IPv6 dualstack, so let s look at those. Regarding the configured tunnels, these are used for if you ve got a core network, which only supports IPv4 or there s a reason why you can t turn on IPv6 and perhaps it s a network that doesn t support MPLS either in the core and so a way of doing that is to actually configure IPv4-based tunnels going between PEs, so you mesh your PEs with IPv4-based tunnels. These can be GRE tunnels or IPsec tunnels and the outer header is an IPv4 header and then hidden inside you ve got the actual IPv6 packet and that s the way that you can transport it across the IPv4 only core. With this scheme, the advantage is that you don t have to touch the core routers at all, so if you haven t got MPLS today and you haven t got IPv6 in the core, then you don t have to touch the core routes as you re just doing it through configuration on the PE routers. It s not particularly convenient in the sense that you have to manually configure these tunnels between the PE routers, so if you add a new PE to the network, you need to configure the tunnels on all the other PEs on the network. But as I say, it does have a niche in a network which doesn t support MPLS or IPv6 in the core. 10
Turning our attention to IPv4 and IPv6 dual-stack, this is where you re running IPv6 natively across the cores; you re running them as normal IPv6 packets and so on each router along the path we have a [deedger] in the core. You re doing an IPv6 lookup and routing the packets accordingly and so for that you need to turn on IPv6 throughout the network, of course, including the core router, so you need to turn on the IPv6 address family on the BGP session so that all the routers involved can have exterior routes. Also you need IPv6 in the IGP so that you can resolve next hops and when you re doing this of course you can run IPv4 in parallel and that s true whether you re using OSPF or IS-IS as the IGP. Let s have a look at that in more detail for the OSPF case. Traditionally certainly it used to be the case that looking back in history OSPFv2 has been around for many years and that s what people use for IPv4 reachability. When IPv6 came along people decided that it would be too difficult to alter OSPFv2 to carry IPv6 reachability information and so a new version of OSPF was devised, OSPFv3, for carrying IPv6 reachability information. These are two completely separate protocols. If you ve got OSPFv2 already because you re running IPv4 in the network, which is already up and running, you can turn on the OSPFv3 on the various interfaces without disrupting the existing OSPF version to adjacency, because they re two completely separate protocols; that makes it easy for the transition. More recently there is an alternative possibility, because since JUNOS 9.2 we also support IPv4 address families within OSPFv3 and so in that case you can just use OSPFv3 and you re carrying within that both IPv4 reachability information and IPv6 reachability information. That s described in the draft that I ve shown there on the slide, and also I ve got a link to the 'techpub switch describing how to configure it. For this IPv4 and IPv6 are in different realms, meaning they ve got a separate links database and separate adjacencies and so on, so potentially you can have different topologies for the IPv6 and the IPv4. Turning our attention to IS-IS: IS-IS is a bit different because compared to the traditional OSPFv2, OSPFv3 situation, with IS-IS it s carrying both IPv4 and IPv6 within the same protocol. In JUNOS and if you ve got IS-IS up and running, because you re using it to carry IPv4 reachability already, if you ve got an interface where IS-IS is configured and then you turn on family inet6, then IS-IS will automatically start advertising the IPv6 11
reachability information as well. When you do that there s no interruption to the IS-IS adjacency which makes it more straightforward to migrate to IPv6 and still have the IPv4 running. When you turn on the IPv6 when you re using IS-IS across the network you do have to be careful to avoid routing loops if IPv6 hasn t been turned on everywhere. The reason for that is that if you consider a router in the network, it s not aware if a remote link somewhere else in the network doesn t have IPv6 configured on it; so you can have a situation where you can get routing loops as a result of that. Ways of avoiding this, as listed on the slide, either you say I m going to turn on IPv6 everywhere between all the PE routers and all the core routers and throughout the core; and only once I ve turned it on am I going to introduce the IPv6 traffic to avoid these loops. Or you need to turn on the IPv6 very carefully in an expanding circle, so you start turning it on on a particular link and then you expand this sphere of influence. You turn it on on adjacent links on those routers and you do it in a careful way keeping an eye on the topology and the metrics to avoid routing loops; that can be quite complicated in a large complex network. Another way of doing it to avoid that problem is to use IS-IS multi-topology and so you ve got one topology for IPv4 and another for IPv6 and if you do that then you don t have these issues with routing loops. In our implementation in recent code - from JUNOS 9.5 onwards - in fact you can have IS-IS running single topology and you can turn on multi-topology and you can do that without tearing down the IS-IS adjacency. If you want to read more about these IPv6 using IS-IS considerations, I strongly recommend the book by Hannes Gredler and Walter Goralski, Complete IS-IS Routing Protocol. If you look at pages 370-388 of that book it describes what I ve just been saying on this slide in more detail. Regarding deployments, an example of deployments of IPv4/IPv6 dualstack is FLAG Telecom, which is now part of Reliance. FLAG Telecom gave a presentation at APNIC and also at SANOG on this topic, talking about FLAG s IPv6 implementation and I ve given some links to those presentations there and I strongly recommend having a look at that presentation in full at those URLs, because it s very interesting. For now I ll show a subset of the slides from that presentation courtesy of Reliance. 12
The situation was that FLAG wanted to turn on IPv6 in the network and the network had a series of T-Series and M-Series routers. A big product on that network is IP Transit Service especially for carriers and ISPs who are along the path of the FLAG cable systems. There was demand from a customer in Asia for having IPv6 internet feed, so that was the catalyst for turning on IPv6 in this network, so what happened was that IPv6 peerings were activated in most of the internet exchanges where FLAG connected to, so links in M6 and Hong Kong, Japan and also New York and LA. The way it was done was that the IPv6 was given as a free add-on service to the existing IP transit customers and the IPv6 part was done on a besteffort basis with no particular SLA. As far as the customers were concerned, they could choose; they could choose to have the IPv4 and IPv6 feed in one connection, or they could have a separate logical interface, one for IPv4 and the other for IPv6. The other interesting aspect is what it took to actually deploy this. As I mentioned, part of the process is to turn on IPv6 addresses on all the links in the network, turn on the IPv6 address family in BGP and so on. As you can see on the slide, that work took about three days and I was going to mention the PE switch does take a fair bit of time is physically going round all the interfaces and putting the IPv6 addresses on. However, it s interesting to look at the third bullet on the slide, which says it took longer to write the design document and planned work procedures and worrying about it than it took to physically do it, so this was a deployment that went smoothly for the dual-stack. That brings me more or less to the end. As you can see we ve talked about different schemes for carrying IPv6 across the core of the network, MPLS-based and IP-based schemes. What we re seeing is that as you d expect service providers are tending to use the IPv6 method, which is analogous to the way they tend to have been doing the IPv4 over time, so people who carry IPv4 internet traffic over MPLS LSPs between the Edge Routers, they tend to use 6PE for the IPv6 case; that's the most analogous scheme. People who put internet into a CRS, they tend to use the Layer 3 VPN schemes for IPv6. People who carry IPv4 natively as IPv4 packets right across the core of the network tend to do the same as the IPv6 and so have the dual-stack. Then you can have situations where either people have old routers in the core of the network that we don t want to touch - 13
we don t want to turn on MPLS, we don t want to turn on IPv6 - or perhaps the core of the network isn t actually owned by them, so they re using other people s facilities to transport the traffic between their own Edge Routers and in that case the IPv6 over IPv4 configured tunnels are good. Really there s no correct answer which is always correct for everybody; it s just like the IPv4 case where different people use different schemes according to the situation in their network. That s a summary of the different schemes that are available. In addition, there are other possibilities which I didn t mentioned: if you re using MPLS, of course, you could use Layer 2 VPN or VPLS to transport IPv6 traffic as of course those schemes are agnostic to what the Layer 3 packet is; that s another possibility that might be useful for some people. That brings me to the end; what we can do now is we can open the phone lines. If you re actually connected over the PSTN line, you can ask a question, so I ll hand over to Stephanie who will explain how you can ask a question if you want to. I think most people are actually just logged on to the webpage, not over the PSTN line. Operator: Ladies and gentlemen, we will now begin the question and answer session. If you wish to ask a question please press *1 on your telephone and please wait for your name to be announced. For any questions or comments please press *1 on your telephone. There are no questions at the moment. Jean-Marc Uzé: Jean-Marc speaking; Julian, I have a couple of questions for you: one [unclear] is about MTU; is there any issue related to MTU5 in using either 6P or 6VPE? Julian Lucek: I guess one does need to be aware of the MTU budget, because the IPv6 headers are longer, but I guess that s part of the IP packet. I guess 6PE, you ve got a bigger label stack compared to if you ve just got IPv4 packets in MPLS, because if it s IPv4 internet riding over an MPLS RSVP or LDP LSP, you ve got 4 bytes of MPLS overheads; if it s 6PE then you ve got an extra label, they re inner labels, you ve got an extra 4 bytes to take account of in your MTU budget. For the IPv6 Layer 3 VPN, in terms of MPLS overhead it s the same inner label and transport label for both. 14
Jean-Marc Uzé: Another question is related to the size of AS numbers; is there an issue using 4-octet, 4-byte AS numbers in any of the elements describe in this session? Julian Lucek: Jean-Marc Uzé: core. That should be okay; there shouldn t be issue with that. Another question was about LSP signalling using IPv6 in the Julian Lucek: That s an interesting question. Today we don t support that; as I mentioned I m using IPv4 and those schemes that I mentioned, the IPv6 Layer 3 VPN and the 6PE, they can run over those IPv4 signalled LSPs. We haven t had too much demand for IPv6 LSPs. It s something we ve got at the back of our minds as something we may need to do at some point in the future, but it s not something that, from what we ve been hearing from the user base, is urgent as such, but we re willing to discuss it offline if somebody does have a need for it. I guess if one wants to move in the years to come we ll transition to IPv6; I guess IPv4 will be regarded as legacy and I suppose ultimately people will want to build pure IPv6 networks including all of the internal infrastructure and signalling and so when that day comes, certainly it would be useful to have the actual LSPs themselves signalled using IPv6. Jean-Marc Uzé: I m getting the message that nobody can hear me when I m repeating the question, so you should also repeat the question before answering, but please encourage people to ask the questions directly now for the rest of the session if you have a couple of minutes. Julian Lucek: If there are any more questions please signal to Stephanie. Operator: Once again, if you wish to ask a question or make a comment please press *1 on your telephone now. There are no questions from here. Julian Lucek: We re going to close shortly. Just before we close, after the slides disappear you ll be in something called exit lobby and you re welcome to stay there. A couple of reasons: there are a couple of survey questions such as which IPv6 technology is the most interesting to you for your network; also there s a chat window, so you can ask any final questions as well. That will be there for a few minutes after the main session ends, which you ll see on your webpage. 15
The other thing that I d like to do is to just advertise some future sessions, J-Tech Live sessions. On 8 th September we ve got a session on Next Generation Multicast VPNs, which is obviously a very hot topic at the moment, as many of you know; the registration is open for that. Another one that we ve got coming in September, or in fact beginning of October, is one on Data Centre Design and that s on 6 th October. The registration for that Data Centre on actually starts next week. The other thing is if you look on the J-Tech Live page, there s a tab which says education and for the first 100 people who do so we ve got 100 Prometric vouchers which allow you to take any Juniper-related Prometric exam free of charge. Normally you have to pay quite a bit to take one of these Prometric exams, so as I say first 100 people get a voucher free of charge. With that thank you very much for attending; any questions, please drop us a mail or come to the exit lobby afterwards to ask questions in the chat window there. Operator: Ladies and gentlemen, that does conclude our J-Tech Live event. Thank you for participating, you may all disconnect. 16