Transcript - IPv6 Technical Track

Randy Bush: Welcome to the IPv6 Technical Track. It looks like we have an audience that about matches IPv6 deployment. We are going to go ahead anyway because the speakers need the time.

The first speaker is going to be Alastair Johnson, who is from Alcatel Lucent and he will talk about access technologies for v6.

Alastair Johnson: Good morning. Thank you, Randy, for the introduction. I'm AJ. As Randy mentioned, I'm from Alcatel Lucent, I'm a product line manager and I look after most of the IPv6 portfolio.

Today, in order to cut things down, I don't have a huge number of introduction slides. Mostly I'm going to be talking about IPv6 deployment focus transition technologies and the big four that all operators in my view are looking at. There's a lot of differing opinions here but this is the way I see it from a vendor

perspective.

Looking at the access transition technologies, focusing on how to get IPv6 out to end consumers or residential subscribers, principally, there's a number of these. The community and vendors have done an extremely good job in identifying many possible options and this slide set does not look at all of them. It would be just impossible to cover it.

These transition technologies have been developed to solve a number of problems, to remove barriers to entry for deploying IPv6 services and to accelerate v6 deployment.

When you are considering transition technologies that you want to deploy in your network, obviously it is important to understand what each technology has in terms of pros and cons and which most closely align to your environment and what you want to achieve with your v6 deployment.

Some of the technologies have what we consider a long-term life, you deploy them once and they will probably be there for a number of years. Other technologies have a shorter term life, they are an interim deployment that you can use now to then replace in the future.

One of the biggest challenges with these transition

technologies, as has been with v6 deployment in general, is finding the CPE support and making sure that whatever technology and strategy you choose in your business aligns with the CPEs that you use or your customer uses.

One of the key points that we have learned when we have been analysing this with our operator customers has been avoiding multiple CPE swaps is an extremely important key. We really don't want to have to swap a CPE out this year, only to have to swap it out again in two or three years when or if we discover it does not have the hardware capabilities for future software loads.

Why would we use a transition technology? Many people ask that. If IPv6 is what we desire, why don't we deploy native IPv6? That's an excellent question.

One there are many answers to.

I'm a big proponent of deploying native IPv6 services, it's something I will always recommend to our customers where they can deploy it. But it's not always possible. There can be technology constraints on your network that make IPv6 deployment difficult or impossible, and in many cases that simply comes down to a monetary issue, there is legacy equipment that needs to be replaced or refreshed.

Another common issue I have encountered is wholesale environments, where last mile access is being purchased

from a third party operator, and they do not support IPv6 or do not have an intention to support IPv6. That obviously restricts the ability of a retailer to offer a commercial service to their customers if their wholesaler doesn't provide it.

There may be a desire to roll out v6 really quickly, as fast as possible touching as little network as possible. That's definitely a marketing and getting-it-out-there and getting people using it approach that many people are pursuing.

There may be a number of other issues, network architecture constraints, decisions made some years ago that live on in the network that constrain you and make it difficult to deploy v6 quickly in a native manner.

Of course, the CPE support I touched on before.

The key message there is that transition technologies, of which there are many, may allow you, as an operator, to get v6 out into your network quicker or easier than native deployment. So that's where we start looking at what the technologies can do for us.

The scope of my talk today is looking at the access domain, between the home, the CPE, through to the subscriber edge and the network. There are many other transition technologies that may be relevant in other parts of the network but that's what I'm going to talk

about now.

A very quick mention on large scale NAT or carrier grade NAT. These are not v6 transition technologies, they are v4 continuity solutions. Anyone who tries to sell you that NAT will save you is probably trying to sell something to you and not actually helping you get your network in the best possible state going forward.

I don't consider LS NAT a viable long-term solution, it gives you a solution for other problems but not for getting v6 into your network.

Looking at what I call the big four transition technologies, we have native dual stack, dual stack lite or DS-lite, NAT64 and 6rd. That's what I am going to go through in the remaining 19 minutes I have. I am not going to look at any of the other technologies listed on the other side of the slide because it would take far too long. That was not an exhaustive list; it probably wouldn't fit on the slide.

Native dual stack is always the technology I'm going to recommend, it's generally the best case approach for operators, however it is often the most difficult, and I have already touched on why. However, it is best if it can be offered this way, you get the native access to both address families, you get consistent behaviour between your CPE and your subscriber edge and you still

support both address families.

If you choose to bolt NAT onto that IPv4 server, that is a separate decision, not relevant to the deployment of IPv6.

The challenge is the complexity levels to deploy native dual stack services wildly all over the scale.

Some networks that are either greenfields or freshfields going into servers now, there are absolutely no restrictions at all, all the equipment you are buying is brand new, there is no legacy, no constraints to stop you deploying these IPv6 services. It might be something you get for free as part of your build-out.

Older networks or networks with legacy equipment, networks that have been around for a number of years, might find dual stack is not possible or more challenging because of the equipment constraints; 15-year-old DSLAMs in your network that simply don't know how to pass IPv6 through PPP sessions are a pretty common constraint that I have found.

CPE support is a challenge. It's increasing significantly. One of the things I've found when I have been talking to and working with a number of operators has been as access speeds are increasing, the operators or customers are replacing their CPE anyway. A CPE that was appropriate for a 10MG Internet service is not going

to be appropriate for a 100MG Internet service. It simply doesn't have the CPU to forward the traffic.

This has been giving a nice refresh cycle in the last one to two years in a number of countries to get modern hardware out there and remove one of the biggest barriers to entry for operators; that is getting the CPE to support it.

It is increasingly common now for CPE vendors, and there are a number of big name vendors that have aggressively attacked the v6 problem.

One thing to consider that is something of a negative on deploying dual stack is what's the impact of running two parallel stacks in your network. You now need to measure and monitor and support two different address families and make sure that performance and service quality is equivalent. That's twice the monitoring, twice the reporting and obviously twice the training for your staff to go through.

That's always something to consider, and a number of operators I have spoken to have said, "That's a real concern for us." When you look at a dual stack network, looking specifically at a wireline network, this is pretty much what you should be seeing. The home environment with the residential gateway or CPE, the internal network, as

it is today, typically DHCP with NAT on the home gateway, and IPv6 support with stateless address auto config and DHCP.

The access environments are PPP, DHCP or similar and the aggregation, edge and core -- generally speaking, I'm going to assume the aggregation, edge and core are areas where the problem has been solved.

We end up with our IPv4 user case, traffic is flowing through the network. We have this optional NAT at the customer end and we route the traffic out into the service provider world.

IPv6 -- all going well with native dual stack -- we bolt it on and it looks similar, the v6 traffic is routed through the network and out to the world.

There are a number of different impacts to be considered. I won't touch on all these points, so I can keep to my timeframe. There are a number of different considerations you have to look at, particularly for deploying the service: what happens in your access network, do I have PPP or am I running IPOE, what does that mean? You might have to look at network architecture, whether the equipment in those areas supports it.

I have cheekily said zero impact in PPP environments. That's not always true, it pays to check

in your lab environments whether your DSLAMs, for instance, will happily forward that traffic.

Looking at the subscriber edge, obviously the B-RAS or BNG needs to support IPv6 services, so you need to figure out whether you can do that, what the scale impact is, if anything, and making sure you have equivalent future sets between your v4 and v6 capabilities. The service should feel the same.

In the home network, which I have touched on quite a bit, the CPE needs to support it. As we are seeing with people constantly buying new Apple products and deploying Windows 7 and now Windows 8, more and more of the home network environment is supporting IPv6 out of the box.

I am not presenting that slide.

Moving on to the next technology, that I am now seeing quite a bit of demand for from a number of customers, is dual stack lite, DS-lite. It's defined in RFC 6333. This technology addresses operators that want a v6-only access network. We remove IPv4 from the access network entirely and we tunnel that across the v6 access network. That supports the view that I touched on before, that removing v4 could have some benefits in terms of monitoring and service assurance in the access network.

The way it works is the CPE will encapsulate all the IPv4 traffic originating from the home network into an IPv4overIPv6 tunnel and this forms a software and that software is terminating as an address family transition router, an AFTR, which encapsulates that traffic, it performs NAT, and we are performing the NAT effectively as a single layer of NAT, we have removed the NAT from the home CPE.

V6 traffic is routed as natively as possible. It is important to understand there is no protocol translation between v4 and v6. We end up with a topology that looks like this. We have a private IPv4 network in the home, as we always have; we have an IPv6-only access session between the CPE, through the BNG and the backbone network to the address family translation router and we terminate all the v4 traffic there.

The service provider performs all the NAT functionality for the IPv4 services; we don't have two layers of NAT. IPv6 is routing and IPv4 is routing, but when the IPv4 traffic gets to the AFTR, that's where we perform the NAT.

So this starts to look like large-scale NAT because we have all the complexities of managing the large-scale NAT service. We need to manage logs, we need to make sure we have a large enough pool of ports available for

the customers, et cetera.

When we start looking at what the complexities are of deploying dual stack lite, we need to say, is my access network going to be able to support IPv6-only access? Do my CPEs support it? One of the challenges here is that if you want to roll it out in a geographic region, it's an all or nothing thing. All the CPEs, generally speaking, you are going to have to make sure are ready to support the technology.

You need to look at where you place the AFTR nodes in your network; whether it is something that goes in the BNG or whether it is something that you deploy a separate node for. You need to particularly consider all the impact we have discussed, in many cases around NAT, lawful intercept, and how you manage that effectively with a service provider NAT environment.

This works. We have an operator who has deployed this in Europe, they have several hundred thousand customers running on it today. The interesting thing is that they have said, well, very quickly, once we deployed native IPv6 services, we saw the amount of IPv4 traffic decrease on the network because an awful lot of our traffic comes from ACMI, Facebook, Google and so on that have native IPv6 services, so the amount of traffic we thought we would have to pass through the NAT has

gone down but it's still a very large amount of traffic, so scaling the NAT44 function is a big challenge.

Looking now at NAT64, that's another technology, it addresses operators again who want a v6-only access network with v6-only CPE, so a well controlled handset, for instance a cell phone that is well behaved and well understood and generally speaking has a fairly limited set of applications. There are an awful lot of things that will break when going through a NAT64 because we are translating between protocols and address families.

This technology does not support an IPv4-only host.

If I were to plug in my Windows XP laptop or my PlayStation in at home, it would not function in this environment.

There are alternatives that I believe are going to be spoken about next, using the 464XLAT architecture which can reuse NAT64 capabilities to allow IPv4 hosts to continue to survive.

What we get in NAT64 is the CPE or the equipment connects to IPv4-only servers, legacy servers that haven't upgraded to support v6 and we do a DNS translation. When we receive an A record the DNS64 engine will translate the v4 IP address into a synthesised v6 address.

Any client that can't use DNS64 will fail; it simply

won't be able to connect to a v4-only destination because we need the DNS64 synthesis.

Looking at the topology, we have native IPv6 router traffic at the bottom and we have this magic translation box sitting in the BNG or in the NAT64 element with the DNS64 sitting co-located to it.

We have a core flow that ends up looking like this.

Following it through, the CPE says I'm going to query, for example, dot-com with a AAAA record, we have no response for an NX domain, we query again for an A record and we get a response, in this case 203.0.113.0.

As it passes back through the DNS64 engine, we synthesise this fake IPv6 address and allocate a NAT binding as the traffic starts to flow, which basically says this synthesised address of 64.FF9B.CD.00.7B01, we know, because we can take the last 32 bits of the address, it corresponds to an IPv4 address out in the real world. The NAT64 engine translates between these two address families. Thus traffic will flow.

Where this starts to fall apart is where you have an IPv4-only host on the left-hand side, it doesn't know how to do this and cannot do this. When NAT64 starts becoming very interesting or very useful is largely in environments where there is a limited set of applications, applications that are happy to traverse

NATS, and CPUs that are relatively simple and can operate in a v6-only environment.

We typically see this in a wireless environment, cellular networks, rather than in broadband or residential focused networks.

Again, we have this impact, we have to upgrade the access network to v6-only, we need NAT64 in the subscriber edge. We need a DNS64 and we need to have all the requisites to deploy IPv6 services.

Most critical in the home network, if this is deployed in a home network environment, those home network components, PCs, PlayStations, Nintendo, Wiis, fridges, toasters, etc, must all need to support v6 as well.

The last technology I am going to touch on is 6rd, RFC5969, IPv6 rapid deployment on IPv4 infrastructures.

This is a technology which popped up three or four years ago. A very large operator in France just deployed their v6 services using this and a number of other operators are also using it. It allows IPv6 to be deployed rapidly over IPv4 infrastructures without any forklift upgrades, without replacing any of the IPv4 services. So it allows us to simply stack v6 on top.

It fits really well for wireline environments where a CPE upgrade or swap is easy but the access networks is

complex or expensive to modify or owned by someone else.

6rd has some drawbacks as well, particularly everyone is saying, it is a great technology for the now, to get v6 out there but we need to look at how we remove it in the future.

6rd topology would look a lot like that. The IPv4 use case is pretty much the same as it always was, and with the 6rd capable CPE, when it is configured by DHCP or manual config or operator push automatic config, it can set up a 6in4 tunnel, very similar to the way 6to4 operates, it is a stateless tunnel, it gets its prefix and it is a relatively stable IPv6 prefix that can be used, transported over the v4 network.

Where this starts to get tricky, long term you might want to deploy native dual stack or you might want to deploy DS-lite, which means we have to do a second migration on the v6 network. We have to deploy the border relay function, which is the 6rd terminating router, we need to consider how we load balance that traffic in the network, how we traffic engineer the traffic on the network, whether there are any impacts for lawful intercept, because we have the double encapsulated traffic effectively, and what that means.

Again, we need a CPE that supports 6rd. Luckily, there is an awful lot of CPE out there today that is now

shipping with 6rd support.

One of the other problems we have seen recently has been considering the MTU issues. We need to be able to fragment traffic in 6rd tunnels and we need to support a 1,500 byte IPv6 MTU transported over a 1,500 byte or smaller IPv4 network, so that often pushes some interesting requirements into the 6rd relay routers; how we handle fragmentation.

A quick summary. These are the big four that I've mentioned, these are the ones we spend most of our time talking to operators about. A quick look at dual stack: we have a v4 home device going through a v4 access network to the v4 Internet; v6, v6 and v6.

With DS lite we have different parts of the network at different address families, and we end up with a NAT64, a v6 home device with a v6 access network; in the service provider network we translate and allow them access to the legacy IPv4 Internet.

Looking at this as a comparison of the technologies, you can see there are pretty common trends. We almost always have a CPE change a or software upgrade or some kind of refresh. The end user impact, for at least three of the technologies it's OK, not much changes from the end user's impact.

NAT64 is the one which you need to single out.

IPv4-only devices or devices that are only partially IPv6 capable, for instance Windows XP, are impacted. If you can't use a DNS64 engine, for instance if you are trying to connect with a literal IPv4 address, Telnet 203.0.110.1, you will fail, you will not get a translation build.

There are some pros and cons for all of these different technologies. I have tried to boil it down in the purple boxes at the bottom. Native dual stack is most suitable for deployment everywhere, this is always what I will focus on and always what I will encourage people to pursue until it becomes clear they cannot use it because of some constraint, and then we look at the alternatives.

DS-lite is quite interesting in new build environment, stuff that is being built today, in 2012, particularly in areas where we hope most of the end consumers have IPv6 capable devices and the majority of traffic will be IPv6.

NAT64, we see this as new build, where v6-only access with no legacy IPv4 host support is acceptable.

Typically, this is a wireless cellular environment technology at this point; that may change in the future.

6rd, legacy environments that cannot support native v6 access or we need to skip the upgrade process because

it will take years and millions of dollars, et cetera.

Again, pretty practical for wireline environments.

In conclusion, v6 and the transition technologies are a multidimensional problem. That is a nice picture there looking at all the things you have to consider when you are thinking about v6 and how to get it working in your network. This should not be a surprise to anyone. There are lots of transition technologies available, varying levels of support from different vendors, different CPEs, different end devices.

Operators should pretty carefully evaluate which technology is most appropriate. The big four I've singled out might not be appropriate for you but this is what I see as a vendor, this is what our customers are principally asking us for. If you are talking to any large network equipment vendor, they are probably going to talk first and foremost about these four.

The transition technology any operator picks should align with the long-term vision of what you want to do with your network, whether native is the way you want to go or dual stack lite is the way you want to go.

I have seen a number of big operators spending a lot of time thinking about this, saying, yes, we want to retire IPv4 from now on. Other operators have said, well, we think it is easier to build v6 out on top of

the v4 and we will leave it like that for the foreseeable until one day we stop building IPv4.

It might take multiple iterations as you work through your network, your constraints. Look at these technologies and figure out which is the most appropriate. It is important to try to minimise the number of iterations you invest in in your network and try to pick the technology that fits best.

This is a list of references that cover off most of what I've talked about. The broadband forum draft and technical reports are particularly useful. There is one that I have missed, it has just been published, which is TR242, which talks about, funnily enough, IPv6 transition for broadband providers. If you search for TR242 you should be able to find that, it was published last week.

All of the other technologies are referenced there.

Included in the slide deck you can download is the number of reference slides that are tagged, reference slides that I did not present, that capture a lot of what I have spoken about, so it's easy for you to go back and review. That's all from me. Thank you very much.

APPLAUSE Any questions or maybe hold them to the end or

whatever is easiest? Or I can sit down now.

Randy Bush: Next we have Masanobu Kawashima, who will speak on 424XLAT, which is a technology for giving v4 services on v6 networks. It's being played with and in deployment and still being argued inside the IETF, so it will be interesting to get his take on this.

Masanobu Kawashima: Thank you for the introduction.

Good morning, everybody. I would like to thank all of you for being here today. I am Masanobu Kawashima from NEC AccessTechnica. I am the assistant manager of product development department. My field of expertise is IPv6, so I am in charge of IPv6 related projects.

Our company is one of the largest home gateway vendors in Japan. Many network operators in Japan are already using our IPv6 capable CPE. Also, our company participated in world IPv6 launch as a home router vendor.

The topic of this presentation is 464XLAT experiences. This presentation will give you 464XLAT outline, and our experience. I think that this presentation will be about 20 minutes.

What is 464XLAT? Please take a look at this illustration. The top part of the illustration shows direct communication from an IPv6 host to an IPv6 server. In contrast to that, a private IPv4 host shown

below can communicate to a global IPv4 server through the double translation. CLAT is stateless translator at the edge and PLAT is a stateful translator in the core.

As you can see, the feature of 464XLAT is a combination of stateful and stateless translation.

I will explain the 464XLAT in detail. It combines RFC6145 and RFC6146. It is easy to deploy and is available today, due to commercial and open source shipping product.

Furthermore, it can provide basic IPv4 service to consumers over IPv6-only access networks. Lastly, we can use very scarce IPv4 resources efficiently.

What it is not: it is not a perfect replacement for IPv4 or dual stack service.

However, I think that it is a reasonable replacement. I would say the most important point is that we should focus on IPv6 deployment rather than IPv4 life support.

I would like to speak about motivation and uniqueness. First, 464XLAT requires minimal IPv4 resources and it can also perform maximum IPv4 efficiency through statistical Multiplexing. More specifically, PLAT can perform stateful NAT64 translation and each IPv4 address can treat 64,000 flows.

In other words, ISPs can efficiently and effectively share limited IPv4 global address pool.

Second, 464XLAT doesn't require new protocols, so it can deploy quickly. It is only necessary to use standard technologies based on already published RFC.

I believe most ISPs do not have a lot of time to make a new protocol. Moreover, we have already finished inter-op test. You can use Cisco, Juniper, A10 and F5 as a PLAT. This will help you use 464XLAT immediately.

We can decrease unwanted operational costs because IPv6-only networks are simpler and there are five reasons to support this. When combined with DNS64, ISP can provide sharing IPv4 address service via 464XLAT, and also provide IPv4/IPv6 translation service by DNS64 NAT64 at the same time.

Furthermore, ISPs can do IPv6 traffic engineering and billing without deep packet inspection devices.

Besides, if the other ISPs operate PLAT as PLAT providers, ISPs can independently do IPv6 traffic engineering on common backbone routers. As you know, we can do single stack network operations. This sounds good. Lastly, we don't need to consider buying IPv4 addresses, seriously.

When you look at this slide, you will see the difference between 464XLAT and other technologies. The

vertical axis represents translation or tunnelling and the horizontal axis represents stateless solution or stateful solution.

What technology should we choose? It depends on your requirements or situation. The advantages of 464XLAT is that, as I mentioned before.

This slide shows 464XLAT status in the IETF. I am proposing 464XLAT in order to standardize globally. To summarise, we got many feedback from the community and also got a rough consensus regarding the working group last call at the last IETF meeting in Vancouver. The working group last call is open until September 4 for the v6 ops working group. I really appreciate all the support I receive from everyone.

I would like to speak about my experiences regarding WIDE Camp. The WIDE Camp was held from 5 March to 8 March in Japan. The WIDE members tried to use in commercial IPv6 networks with several kinds of technology, such as DNS64, NAT64, 4RD, 464XLAT and SA46T. The blue box squares represent PLAT and CLAT.

This slide shows NAT behavioural tests results by Kanami Digital Entertainment. RCF4787 have many requirements regarding NAT behaviour. The tests focused on important requirements for playing P2P game.

Requirement 1 is NAT must have an end point independent

mapping behaviour. Requirement 3 is NAT must not have a port assignment behaviour or port overloading.

Requirement 9 is NAT must support hairpinning.

Requirement 13 is that if the packet received on an internal IP address has DF bit on, the NAT must send back an ICMP message, "Fragmentation needed" and DF set to the host.

Requirement 14 is that NAT must support receiving in order or out of order fragments. So it must have receive fragments out of order behaviour.

Then path MTU is out of scope in RFC4787 but it is important for playing P2P games.

I would like to focus on 464XLAT, especially hairpinning and fragmentation failed on these tests.

When you look at the next slide, you will see the reasons.

Why hairpinning function failed? The CLAT could not generate fragmented packets, even if IPv4 sender does not set the DF bit. Since more than 50 participants were using the CLAT in that time, its capacity was overloaded. When less than 30 nodes were using the CLAT, it could generate fragmented packets.

I think that it is a reasonable capacity as a home router.

I would like to speak a little bit on other topics.

The slide presents the restriction on use of VPN protocols on 464XLAT. PPTP doesn't work well, signalling packets is OK but transport packet is no good.

Next, if you can see NAT traversal IPsec works well.

SSL and SSH port forward work well. Lastly, if you can use UDP packet, LCTP works well.

What I would like you to see here is that IPv4 address sharing technologies, such as MAP-E, MAP-T, 4RD and DS-lite have the same restrictions.

I would like to speak about IPv4/IPv6 mixed trace route. I think that is an interesting tool. When you execute this interesting trace route you can get ICMP time exceeded messages from IPv6 node and the IPv4 node.

I think that this user interface is useful to do trouble shooting, especially during IPv4/IPv6 coexistence time.

Finally, the Interop Tokyo 2012 was held from 12 June to 15 June. We finished interoperability test between CLAT and Juniper, A10, F5 and other PLAT at ShowNet and not surprisingly everything went well.

Thanks so much for your time.

Randy Bush: Questions? APPLAUSE Satoru Tsurumaki is going to present on what SoftBank has discovered while trying to deploy v6 in

Japan's rather challenging environment. I am sure all of you heard that despite the law about Japan being such a wonderful v6 world, it really isn't, and SoftBank is one of the providers who has put a lot of work into a v6 deployment in tough circumstances.

Satoru Tsurumaki: Good morning, everyone. My name is Satoru Tsurumaki from SoftBank BB. SoftBank BB is one of the major ISPs in Japan. Today, I introduce our IPv6 deployment.

Our concept for IPv6 deploying is IPv6 for everybody, providing IPv6 for any access line for any user environment is our target. BBIX is our group company which provides IPv6 roaming service.

I think for IPv6 deploying there are three key factors: fee, application scheme and user environment.

Users can't choose IPv6 Internet service if it needs an additional fee and users don't want an additional application for using IPv6. Also, users do not want to set another equipment or software installation for using IPv6. So we must deploy IPv6 while the customer not cares whether their connection is IPv4 or IPv6. This is our important target.

To achieve our target, we choose stateless tunnel solution for IPv6 deployment. Because we need access line from a third party, NTT, and it should not be dual

stack, so the stateless tunnel is better cost performance than stateful solutions.

The next slide, on the left side, for existing customers that means their access network is IPv4 only, we start to provide 6rd at April 2010, and on the right side of the figure, for new customers who choose IPv6 access network, we just start to deploy IPv4 over IPv6 service this month. Both services uses stateless tunnel solutions.

We have started an IPv6 service for all our FTTH customers, but there are many issues and problems.

Multiprefix issue and fallback program caused due to IPv6 closed network, like a walled garden. Today I don't describe this issue because it is well known and you may have heard it many times.

First, the third party CPE issue. To deploy stateless tunnel solution we need to install border relay in our networks and let users to set our CPE to support stateless tunnel termination. But in many cases users already use another CPEs for walled garden service, for example, IP phone, IPTV, so our CPE will set downstream side of third party CPE. In this situation, some CPE may cause trouble.

Firstly, performance degradation. Some CPEs do not support hardware forwarding for IPinIP packet IP packet

for IPv4 and IPv6 co-existing technology, like DS-Lite, MAP, 4rd and so on. Actually, throughput for some CPEs is going down to 8MG bps, although upstream is 1GB.

Secondly, some CPEs set to drop the inbound packet by default. Customers can't use an application like an IP phone or P2P service because of lack of transparency.

Second are DNS selection issues. In Japanese ISPs, in the dual stack environment, customers get both IPv4 and IPv6 DNS address by IPCP, DHCP, DHCP-v6 or other methods. But ISPs set AAAA filter because of the Japanese well known issue of fallback. In this situation, client DNS selection mechanism may cause trouble.

Major client OS preserves a v6 DNS server for its queries. But the DNS is declined when v6 DNS does not respond or there is too long time for the response. So the client will adopt the v4 DNS server instead of the v6 DNS server. But the DNS perhaps responds for a query, but it is filtered AAAA records out. So the user can't get AAAA records and cannot access by v6. So we need CPE to install additional DNS selection mechanism.

The CPEs that connect to IPv4 access network, DNS proxy on the CPE, send a query to DNS by using the same transport. It means that when query of customers client use IPv6, CPE uses IPv6 too. Otherwise the CPE connects

to IPv6 access network, DNS proxy on the CPE sends a query to v6 DNS only whether the client's query is IPv4 or IPv6. So the customer can resolve AAAA records any time.

You might think, why doesn't the CPE that connects to IPv4 access network don't act the same as IPv6? Our CPE connected to IPv4 access network has 6rd function but we couldn't set it on by default because of multiprefix issue. Customers will not be able to access the walled garden service when we set 6rd on, so IPv4 customers need to access to DNS by IPv4.

Summary: the key factor of IPv6 deploying is fee, application scheme and user environment, and deploying IPv6 while users do not care whether the connection is IPv4 or IPv6.

Stateless tunnelling solution is good for those ISPs who use leased access networks or has legacy IPv4 access equipment like a DSLAM.

But you must care about the problem caused by IPv4/IPv6 co-existing environment.

One more thing: I would like to speak about IETF complications. Standardization of MAP or 4rd is just like this figure.

This figure is an IPv4 map for A+P and 464XLAT.

I do not describe all of these drafts but the softwire

working group discussed which draft is most suitable for standardization at the last IETF meeting -- MAP-E, MAP-T and 4rd-U. Finally, MAP-T was chosen by a coin toss.

Rough consensus, running code, and the occasional coin toss.

Finally, I speak about implementation of MAP.

ASAMAP, as soon as MAP possible, is already now available. ASAMAP means implemented by ASAMA-san.

ASAMAP is implementation for vyatta, and you can use this ASAMAP open source program and you can use this.

If you visit this URL you can enjoy the MAP environment.

Thank you very much.

APPLAUSE

Randy Bush: Questions? We might as well talk about v6 deployment, because the watermelon won't be out there.

That's it. Unless somebody has something wonderful to tell us about IPv6 deployment.

Thank you very much. End of session.

APPLAUSE