Juniper Networks (UK) Limited 7th 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 7th 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 dual-
stack, 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 dual-

stack 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 best-
effort 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: That should be okay; there shouldn’t be issue with that.

Jean-Marc Uzé: Another question was about LSP signalling using IPv6 in the
core.

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 8th 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 6th 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