ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

>>LEO VEGODA: Hello, everyone. My name's Leo Vegoda. I'm the IANA Numbers Liaison. And I'm moderating this panel, which is a discussion on IPv6 deployment today.

We've got three panelists. They're each going to make a short presentation on a different aspect of IPv6 deployment. And then there's an opportunity for discussion from remote participants, anyone here in the room, all about IPv6 deployment. We've got until 3:00. We're running a little bit late. But let's get going.

Before kicking off with the actual discussion, this session is being Webcast, and because it's being Webcast, there's a possibility for remote participation by going to http://public.icann.org, where you can connect through IPv4 or IPv6, and you can leave questions, if you're watching from the webcast --

Okay. Now everyone's awake.

You can leave questions if you are using the http://public.icann.org web site either in the web chat or in the IPv6 tutorial page. And it should be fairly easy to navigate to from the front page.

Let me introduce the panelists now. On my right, I have Alex Le Heux, from the RIPE NCC. The RIPE NCC is an RIR, and they give out IPv6 address space.

On my left, I have Joao Damas, from Internet Systems Consortium. And ISC run the F root nameserver. And to his left, Gert Doering, from SpaceNet. And SpaceNet has been operating an IPv6 network since 1999. And Gert also chairs the RIPE Address Policy Working Group.

So we'll have three short presentations and then lots of opportunity for discussion. And we've already had a couple of questions I've seen posted on the public participation web site. So we'll kick off with those questions, and then plenty of time for everyone in the audience to discuss with the panel as well.

So this is the agenda. Alex, Joao, and Gert. And then the discussion.

So let me pass to Alex.

>>ALEX LE HEUX: Okay. All right. I'll be talking about IPv6 from an RIR perspective. I'll briefly introduce the RIPE NCC and say a little bit about what we do, and then I'll explain the current allocation principles and talk about IPv6 policy.

After that, I have some pretty pictures with some statistics as well.

Okay, the RIPE NCC is one of five Regional Internet Registries. We're a membership-based organization, and we distribute the IP resources through our members. We've been established in 1992. We currently have over 4500 members in our region. And membership is open to anyone.

We offer a lot of services. I can't list them all here. But the most important one is we distribute the Internet number resources, like IP addresses, and AS numbers. And we operate the RIPE Database, which holds all the registration information for all these resources. And we do the reverse DNS delegations for the numbers, IP numbers that have been delegated to us.

The current IPv6 allocation principles: There's aggregation. IPv6 has -- okay, aggregation is the concept that multiple networks are advertised into the routing table in one large prefix. Because IPv6 has very large address space and it's probably going to be in use for a very long time, routing table growth is something that's -- needs to be looked at and needs to be controlled, because, potentially, the routing table could become very large. So aggregation is one of the most important principles behind IPv6 policy then there's conservation. Even though the address space is very large, it still needs to be used for a very long time. So we should be a little bit careful with how much we do allocate. But it's not as much as an issue as with IPv4.

Of course, registration, IP numbers still need to be unique, so we need to keep track of who is using which allocation. And through the Ripe database, people can find out who is using a particular block, so they can contact operators for troubleshooting or things like that.

These are the three principles behind the whole RIR system, aggregation, conservation, and registration.

Current IPv6 address policy, you can get -- in the RIPE region, there are small differences between the different policies in the different regions. This is about the RIPE region.

You have to be an LIR, that is, you have to be a local registry. You have to be a member of the RIPE NCC, you have to not be an end site, which means you have to provide connectivity to others through your network. And you have to assign /48 prefixes to other organizations that are presumably your customers. You should advertise a single prefix into the routing table, which helps with the aggregation.

And you have to have a plan to make about 200 assignments in two years, in the coming two-year periods.

And there are quite a few policy proposals to adjust these policies. There's -- this is the first one, which is refinement of the allocation sizes and the way we account for the usage of an allocation.

This proposal provides for flexible -- more flexible customer assignments, so not everyone should get a /48. But smaller sizes are possible as well.

Due to the way we calculate the usage currently, large, very large ISPs tend to get very, very large allocations. This proposal also adjusts that so that those allocations don't -- the large allocations don't grow so very large.

And to provide for accounting for the usage of the allocations, it has a slightly different accounting methods.

Then there's 2006-01, which provides for provider independent assignments, which means IPv6 would also be possible to end users and not only to organizations like ISPs. That would enable them to multi-home their networks. But the disadvantage of that is that we'll have more routing table growth.

Then there's the last proposal, which is a refinement of the current allocation criteria. It doesn't demand an arbitrary number of customers anymore, like the 200 customers that current policy requires. And customers don't have to be other organizations. They can be different departments in the organization as well.

And this policy -- proposal has a slightly stronger wording about that the prefix needs to be announced as a single aggregate.

I have a few statistics. This is how we've been allocating IPv6 over the years. And there's a slight drop-off, but there's still a fairly healthy number of allocations being made.

And this is -- this shows how the number of prefixes that we allocate actually appear in the routing table. So the actual deployment lags a little bit behind on the allocations that we make. But it's still a steady growth in both.

Since last year, we have had a new policy to make IPv6 assignments for TLD operators to do Anycast. That's since September 2006, we had five -- we made five assignments. And two of them are now visible in the routing table, those are for .ch and .cz. If anyone would like more information, you can either go to our Web site or send me an e-mail. And if you want the slides for this presentation, you can find them at that fairly long URL.

>>LEO VEGODA: Thank you very much, Alex.

I'd like to ask if anyone either participating remotely or in the room has a clarification to ask Alex.

If -- if there are no clarifications to ask Alex, then I will move on to Joao.

Does anyone have any clarification points they want?

Okay. Joao.

>>JOAO DAMAS: My talk is going to be around exclusively supporting the DNS and deployment aspects of IPv6, but strictly with regard to DNS.

So here we go.

I'll touch on a couple of items, protocol, implementations, and how it's being used.

With regard to the protocol, well, everything was done and completed several years ago. And the last decision that affected this was taken in July of 2001 at the London IETF, where the two options that were available to support IPv6 in the DNS, one was chosen and one was deprecated. So it's been decided and settled for quite a while now how you do forward DNS with IPv6-related resources is with (inaudible) records, which look exactly like normal IPv4 resources, but with IPv6 addresses.

For the reverse DNS, the current PTR record got its syntax extended and that was all. So fairly simple modifications.

With regards to implementations, well, as well as the protocol, there are -- several of them have been ready and available for several years. Basically, ever since the final choice was made, there have been implementations anyone can use out there.

They run on different platforms. And this has been in use for a long enough period now that there are also documents on how you do this. There's a well-established operational practice. There's a lot of documentation how you do it. There are support in provisioning systems.

So, basically, from a deployment point of view, if you want to do this locally, it's pretty much all settled.

So given that the pieces are in place, are people using this or not?

Well, initial deployment took place first at the leaf level of the DNS, that's what end users control, Web sites, the final complete host names.

One early example of this was the Kame web site. Kame was a Japanese project that took upon itself to write early on implementations of IPv6 text that could be used by anyone. And it played a very important role in deploying IPv6 at that early stage. A lot of computers still use Kame based software these days.

After that, progressively, upper levels of DNS took up deployment of this.

As it went up the DNS tree, it finally reached the root in 2004, with the introduction of IPv6 information with regards to name servers that were serving TLDs.

The first two were Japan and Korea. I've pasted there an extract from the ICANN notice at the time this was announced. It was an ICANN meeting in Malaysia in 2004.

From then on, several more have added. I've just looked at the root zone a few minutes too long see what the actual state is, and there are in the root zone today 87 names, separate name servers, that have IPv6 addresses. And they serve 92 different TLDs. That's about one-third of the total number of TLDs.

So we arrived, then, at the last missing bit. The root servers themselves serving the root zone do not to this date have IPv6 information contained in the root zone.

Without this missing step, though everything else is in place, name resolution using IPv6 records doesn't take place automatically. There are things you can do if you really want to do it, but it's not used by the vast majority of people.

Several root servers, root server operators, have been trying to get these into the zone. They have been preparing themselves. So there are IPv6 blocks allocated to several root servers that could be used and are being used, in fact.

Some of these servers also have IPv6 connectivity, which is, of course, necessary to provide the service. And as I said, the only missing piece is the lack of entries for them in the root and the root-servers.net zone.

ICANN has two committees, the Root Server System Advisory Committee and the Security and Stability Advisory Committee, which get called upon frequently when there are -- there's the need to perform changes to the root zone or the root servers and looking for advice from them. These two committees have been working together for some time on a proposal to ICANN to finally introduce these IPv6 addresses for the root servers.

I'm quite happy to say that at least finally Wednesday last week, the report has been finalized. There were just a few minor typos that needed correcting. And that this report has a set of recommendations that call for the introduction of these IPv6 addresses into the root servers into the root zone and the root-servers.net zone. We hope that report will be able to be presented to the ICANN board during this week, that the ICANN board will be able to look at it and evaluate it. And I keep my fingers crossed that on Friday we could see an announcement with regards to this. Therefore, that would establish a short timeline to see the deployment.

And that's all for me.

>>LEO VEGODA: Does anyone, either participating remotely or in the room, have a question they want to clarify a point with Joao?

I can't see anything remotely.

So I'm going to pass on, then, to Gert, who will present on IPv6 for ISPs.

>>GERT DOERING: Okay, thank you. Welcome, everybody. And thanks for the introduction.

I will try to give an overview of what's happening with IPv6 deployment seen from an Internet service provider perspective.

Not my notebook, but I will manage.

This is about what the talk is about. First, a short introduction on whose space it is and what our exposure to IPv6 has been. Then a few slides about the network that an ISP runs and what to do about IPv6 there and whether it works or not.

Then a very few, brief words about IPv6 address distribution in an ISP network. And then some more words about technical services that are more than just a bare network in an ISP network.

This is the history of IPv6 at SpaceNet. SpaceNet is a medium-sized regional ISP in Germany. We have been working with IPv6, on IPv6, since 1997, mainly because people in the technical department have been interested in and been, at that time, getting bored with IPv4.

So in 1997, I started talking to the 6bone and getting very early beta Cisco IOS images and trying to make things work. And when the first packet flowed, I was quite happy.

Since then, quite a lot has happened. In 1999, we did get official IPv6 addresses from the RIPE NCC. In 2000, the first Internet exchange point in Munich was established with IPv6 connectivity. In 2002, we decided to make our in-house office network IPv6-enabled. That is, all the office PCs can go to the Internet Web servers over IPv6 or IPv4 and see what problems this will bring and then fix the problems.

Since 2003, the set has moved from an experimental IPv6 to more production-quality. That is, the upstream provider started offering IPv6 services. The router vendors properly integrated the stuff. Well, since 2005, I would say that inside our network, we have same quality before IPv6. And the biggest problem today is that we are still not seeing a big customer in-rush.

Okay. It's still not doing what I want.

The basic thing that people think when they question themselves, what's an Internet Service Provider, that's the network that connects me to the Internet, and, basically, that's true. That's the most important part of an ISP network. In the early years of IPv6, there was no upstream providers, no Internet exchanges to go to to transport IPv6 to other networks, so this was all done via tunnels over IPv4, which worked sort of but had lots of problems. So today, IPv6 is done the same way as IPv4, that is, you just have a native line and put IPv4 and IPv6 on it.

In Europe, the biggest upstream providers, like Cable and Wireless, or Global Crossing, do provide native IPv6 service in nearly production quality. And most exchange points provide IPv6 as well. So this is pretty much straightforward. There's a small example, how to set up the interface to Munich Internet exchange point. It's really like IPv4, just another line for IPv6.

The internal network needs to handle IPv6 as well, of course. There are a couple of caveats there, depending on what sort of hardware you use. Juniper has very early provided production-quality IPv6 software, with the main focus on full performance. So the hardware is ex- -- did the IPv6 stuff as well.

With Cisco, it very much depends on what sort of hardware you have. Some of the platforms do IPv6 and IPv4 the same way in hardware and software. So there's no performance impact. Some of the routers where some of the older line cards can only handle IPv6 and software, while they do IPv4 in hardware. So that means that if a customer really uses IPv6, then the router will be overloaded. This is a big problem, for example, for the German research network, because there, IPv4 infrastructure cannot handle the same amount of traffic in v6. So they have separated v6 infrastructure, which is not as powerful and not as well connected yet, because they are afraid that the universities will just overload their routers. And maybe that's a reasonable assumption.

If you use other routers, it very much depends on vendors. Some of them have very good IPv6, some have no IPv6 at all, so you need to check to see.

To connect your customers to your network, whether IPv6 is easy or not depends a lot on the access technology used as of today.

Customers with Ethernet connectivity, like (inaudible) data center or with metro Ethernet are very easy because you just configure it like an internal link and that's it.

For traditional access lines, T1, E1, T3, it's also quite straightforward. There's an example there of how to do it with Cisco. For cable modem, it took a while to standardize how to do IPv6 over cable. But the standard is there, it's DOCSIS 3.0. And from what I hear, some networks are already using IPv6 on their cable to monitor and configure the cable modems so it's being used.

DSL is a problem because most of the low-end DSL CPE routers, that's it, at the customer's premises cannot do IPv6.

Some of the low-end models supposedly can do it today, but, well, you can get 20 or 30 different brands for 50 Euros each and maybe two of them can do IPv6.

And the Cisco series is a lot more expensive, like 200 Euros a compared to 50 Euros. That's not a big difference for an enterprise but for the home user, that means they will not get Cisco.

Another problem is depending on the DSL technology you use, the carrier might require that you use a specific CPE that they have validated, and as of today, all of these, at least in Germany, don't do IPv6.

And then there's the nice and nasty surprises when you use an intermediate carrier that's brought out software that's broken and kills IPv6. What happens in the Deutche Telecom network recently, they changed to Cisco 10,000, and they had a problem with IPv6 being transported through them. It should be pretty much transparent, but actually it broke IPv6.

This is just a very short repetition of what Alex said.

The current IPv6 policy for ISPs is very straightforward and very easy. Every customer gets a quite big chunk of IPv6 addresses, which makes -- and every customer gets the same size of network block, which makes planning easy, which makes automatic provisioning easy.

The customers can get static addresses if they want to, and the policy takes into account that there might be some loss due to internal aggregation.

The problem with that is that some math shows that this will make us run out of IPv6 address space in 30 or 40 years instead of lasting some hundred years. So there are some proposals to be a little bit more conservative.

Also, some folks claim that the reason for the slow uptake in IPv6 is due to the nonavailability of IPv6 provider independent addresses in the RIPE region. I'm not sure whether it's true, but that's what people say.

Now to the more interesting stuff.

In the ISP networks, the service provider provides a lot more services than just moving packets around. That's DNS servers, e-mail servers, web proxies, time servers for the customers and so on, and lots of management services, of course. And all of these need to take IPv6 into account of some sort.

Just a quick run through DNS.

Two of the quite widespread packages, bind and power DNS can do IPv6 without any problems. Just turn it on.

This is the power DNS configuration fragment.

For other software, there exists patches, so ISPs can offer recursive v4 and v6 dual stacked DNS services without any problem.

To move DNS fully to IPv6 is not yet possible, as Joao said, because there are some missing bits and pieces further up in the DNS tree.

It's actually more than one bit.

I just heard the comment that it's only one bit, but it's more than one bit. There's the thing about the root nameservers have no official v6 addresses and of course it's the TLD addresses that either have no v6 name servers at all. I just checked the big TLDs like com, net, org all have v6 but for example, .museum or .aero, one of them have no v6 in the name server set. And quite a number of registries doesn't support glue records with IPv6 records.

So while their names servers could do v6, it's not sufficient to do everything over v6.

Going to -- well, sort of generalize, proxy services. One possible way that migration to IPv6 might happen is that enterprises move to a v6 only network, but in that case, they still have to communicate with the v4 Internet.

That's something where an ISP could help a lot by providing e-mail servers, web proxies, DNS, and everything with IPv4 and IPv6.

So the IPv6 only end network can send e-mail to the ISP e-mail server, and the ISP e-mail server can then send the e-mail over IPv4 to the final destination.

So the end side can completely run without IPv4.

And as of today, there's enough software available that can handle this perfectly well.

Some of the packages still don't do it, like the Qmail doesn't do proper IPv6, but there are other mail programs that can do it.

So for nearly every problem that you want to solve, there is software available that will do it with IPv4 and IPv6.

Some problem areas remain, and that's specialized appliances with closed source. The most recent problem we have come about is Spam filtering. We have a very nice appliance that does really good Spam filtering, but it's IPv4 only. So that means our in-coming office e-mail will not run over IPv6 today because it has to go to the Spam filtering box first.

And another problem area is virtual servers that will be covered in more detail.

When we host customer services, like www.customer.de in our data center, there's two different ways such a customer could be connected. One is they bring their own machine, get an Ethernet cable, and we will just provide connectivity, but have little, if anything, to do with the machine itself.

In that case, IPv6 is very easy because we just turn it on on the root server interface and that's it. It will just work.

The only thing to check is that you have routers that can handle v6 with the same performance as v4; otherwise, the customer might bring in some surprises.

For lots of small customer web presences, you don't want to have dedicated hardware per customer server so you use virtual web service. That means you have 200 or 500 virtual customer web servers on the same machine, and you need to make sure that one customer cannot do bad things with an IP address belonging to a different customer.

So there are solutions like the freeBSD jail or the Linux Vserver that capsulate individual virtual servers on a given machine to watch other virtual servers.

The problem is these solutions don't work with IPv6 right now. So, for instance, freeBSD jail could work with v6 but it doesn't capsulate v6. So one customer could just use an IP address that doesn't belong to him and that makes abuse tracking very difficult.

For the Linux V servers, there are patches available but they are not production quality, and it's hard to argue for using very early patches that might not bring as much stability as you want, when there is not real customer demand.

Some other area where ISPs could bring good service to the end user or the enterprise customers is VPN and managed firewall services.

A typical enterprise, small and medium enterprise customer has no dedicated networking staff, so they are quite happy if somebody else says, yes, we can do all the VPN and firewall management for you.

And at the same time, IPv6 could bring big benefits for these customers, because as soon as you have many VPNs with private address space from IPv4 RFC 1918, you inevitably run into address collisions because everybody else is using 192.168.0.x as well.

With IPv6, address collisions are far less likely because, well, the address space is so much bigger. And in the combination with IPv6 and IPv4, dual stacked services on the ISP side, as I mentioned before, an enterprise could run with mostly IPv6 only inside.

Products for that exist, but the customer demand is still not there.

That actually brings me to my second to the last slide. Customer demand, or the lack of customer demand.

We have been doing this since 1999 and putting on all our product sheets that, yes, of course this product is IPv6 capable, and mainly to differentiate from the competition and to see what sort of response this would get from the customers.

And we have been using it internally for the office networks, and it works, but the customer uptake was fairly slow. In eight years, we managed to bring 40 access-type customers and about four hosting type customers and nearly zero customer inquiries for the more difficult-to-implement products.

So this brings me in a difficult position towards management. So if I say I need two man months to implement all the remaining IPv6 stuff, and management says "so how many new customers will this bring us?" It's hard to argue for there are a bazillion customers standing out the door that would sign the contract as soon as we have IPv6 on this product.

That's the closing words. There are some open issues that all could be solved fairly quickly given customer demand. Like e-mail servers with IPv6 should be doable in a couple of days, or testing the Linux Vserver stuff. If management is convinced that customers would actually buy it.

So the main question that remains is what would be necessary to create end user demand? What are the enterprises waiting for? Why are they not banging our doors and asking for v6?

Maybe IPv6 is the wrong way to go and everybody will be happy with IPv4 and NAT. Or maybe the Internet is doomed anyway and we start right over and find something without Spam.

regarding Spam, if you want to ask me any questions, there's my e-mail.

>>LEO VEGODA: Thank you, Gert. I don't know if anybody has any questions for Gert straight away just to clarify any issues raised in the presentation.

David.

If when you come to the microphone you could state your name and affiliation and speak relatively slowly so the transcription is good.

>>DAVID CONRAD: David Conrad with ICANN.

>>GERT DOERING: While you struggle with the microphone I should mention that yes, of course there are more areas that need more work like the whole multi-homing debate and so on. I didn't cover them because it's just not enough time. So if you want to tell me I missed anything, yes, I know.

>>DAVID CONRAD: I'm David Conrad with ICANN. My question is actually with regard to the customers you have seen. Were they -- When did the 40 dial-up customers, or not dial-up but access customers, request v6? Was it when v6 was first announced or was it more recently?

>>GERT DOERING: Actually, this came up over the years. Some of them came pretty much immediately, connected over tunnels. That's the -- the technical enthusiasts at some of our more technical customers that just say, yes, we want to try this IPv6 thing.

Well, some came over the years like research branches from mobile operators that say we have the internal mandate to find out what this IPv6 stuff is. Please give us connectivity with IPv6.

In the recent years, some came from the military sector, because, well, the German military also says, yes, you must have IPv6 if you want to sell us anything.

So their research branches come and says please give us a DSL line with v6 on it so we can test it.

>>DAVID CONRAD: I guess my question is are you seeing an increased demand, even though --

>>GERT DOERING: No.

>>DAVID CONRAD: -- it's small.

>>GERT DOERING: This year we have connected one.

>>LEO VEGODA: Please, if you go to the microphone in the aisle.

Thank you.

>>

>>HAIDER FRAIHAT: Okay. My name is Haider Fraihat, I am from Jordan. My organization is the National Information Technology Center, a government organization.

I guess my question is, like, what does IPv6 mean for the final end customer?

I am worried about the business part of this. Like for me as -- not my organization. For some organization making their profit from Internet business, what does this mean for them and their customers? So that they can make value -- business value out of that?

>>GERT DOERING: This question is really hard to answer. I will give it a try.

It's easier for companies that don't make their business with Internet stuff that sort of have a product and have the need of VPN services to other enterprises. And they run into problems due to address space and NAT and everything.

For those companies, going to pique and getting rid of the NAT problems and the VPN address collisions would save on expenses.

For a company that's providing web servers, like www.mycompany.org, I'm not sure what the added benefit of going to IPv6 is right now, because since all the client networks can do and need to do IPv4 anyway, the IPv6 is, as of today, just a step in the long path.

Eventually, IPv4 will run out, and then IPv4 will become more expensive. And if you are ready for v6, then you don't have to fix it then.

So it's sort of a preparedness thing.

>>JORDI PALET: Jordi Palet, Consulintel. More than a question, it's somehow a clarification. I think it's important to say for those that don't know all the technical details that even if there is not today, let's say, infrastructure support for DNS with IPv6, that's not hard to move to IPv6 because the information about the IPv6 addresses can be transported in IPv4.

I only see a situation probably where this could be a problem which will be if you have an IPv6-only network. And that brings me to a recommendation, and we have customers using this model.

If you want to run only IPv6, I will actually not suggest doing so, but instead, using only IPv6 maybe in your access and core networks, but keep the local-area networks, servers, host, as dual stack.

In this way, you will not have actually this problem with the DNS.

That's a model that we are following. We have a couple of customers. One of them has 5,000 sites which use only IPv6 in all the infrastructure, but all the local-area networks keep dual stack.

>>GERT DOERING: That's actually what I meant about the dual stack services at an ISP. So if we as a service provider provide dual stack IPv4, IPv6 DNS, a customer could, in theory, run IPv6 only because our servers would know how to reach IPv4 only DNS infrastructure.

In your case, it's the internal IT department that's providing the ISP services. Of course, the boundary is floating.

>>MARK McFADDEN: Hi, Gert.

I have a -- sort of an observation on your first question.

>>LEO VEGODA: Could you give your name and affiliation, please.

>>MARK McFADDEN: Mark McFadden with BT.

I have sort of a problem with the way the question is set up here, what would be necessary to create the end user market demand for IPv6. And I think one of the things that is happening slowly is that there is another market, an infrastructure market, which is starting to appear, and I'm going to sort of talk about that in a second.

There are emerging very, very large devices where the end devices can't be RFC 1918, can't have private address space.

And wring what we will start to see is very, very large networks where we have millions upon millions of end-user devices that we can't use RFC 1918 for turn to IPv6.

Certainly, that's happening in the old-style telco is they move away from the old switch services towards IP-based telephony.

They can't support -- they can't support the end devices, at least in larger networks in IPv4, if they are going to try to do so in private address space. And if they are going to use public address space, it's very unlikely that they are going to get the size of allocations that they require.

So I think one of the places where pressure is coming is out of these very, very large networks that have a lot of devices that I think in the future you're going to see them. The end-user isn't going to know the difference. The end-user is never even going to know about it, but those end devices are going to be v6. And I think you already start to see that in places in Europe, in the United Kingdom, in France and Germany as well where you see large companies asking for very large allocations to support that kind of activity. That's not just happening in Europe. That's happening in other places as well.

>>LEO VEGODA: That's actually quite interesting.

Sort of, I'm going to segue to a question that was asked on the public participation site by Thomas Narten who can't be in the session this afternoon. And I'll read out the question, which was aimed at the panel. But if anyone who is not in the panel wants to answer the question, then that's great, too.

IPv6 clearly has a chicken and egg problem. There is little motivation or ROI for being an early deployer since there are few IPv6 peers to communicate with.

However, I am sensing increased interest in IPv6, especially since the start of this year, in response to the following.

One, a recognition that IPv4 address exhaustion of the free pool will happen and relatively soon. i.e., 2011, give or take.

Two, U.S. government mandates requiring U.S. government agencies to have operational IPv6 network by June 2008. And three, the general availability of Microsoft vista which is completely IPv6 enabled out of the box.

Do any of the panelists see any change in the landscape with regards to IPv6 deployment or demand?

So perhaps if we could maybe start with Joao.

>>JOAO DAMAS: Okay. Perhaps a lot of people are familiar with the fact that (inaudible) produce DNS software. We have another piece of software that's DHCP what he we have been seeing in the recent months is a lot of interest in having an IPv6 version of the DHCP, and we are working on it. And this interest is coming from big, very big ISPs which don't see this service being used right now all the way to the end users, but they are using it for the infrastructure. Just basically what Mark McFadden just said before. The fact that perceived price of IPv4 is already going up makes them look to use IPv6 in those parts of the network that the end user doesn't necessarily interact with, and therefore the fact they are using IPv6 is transparent to them. And you can see all these networks moving towards using IPv6 for control and management and monitoring.

And I think the also interesting part is now that you are seeing deployment, some of the assumptions that were built into the IPv6 protocol are being challenged or bypassed.

And one of them being, for instance, the fact that everyone thought address (inaudible) allocation was a good thing. But in fact, when you hit the road and actually get to use these things, people want to have control. So there is a little bit of infrastructure (inaudible) in place.

But that's how we're seeing IPv6.

The IPv6 services, ISC, for instance, have been providing for up to ten years now. Haven't seen a huge increase. I mean, like the demand for tunnels that will provide IPv6 has access to countries all over the world, particularly in Africa where we provide this service for free, has been the same steady state for the last few years.

>>GERT DOERING: Responding to Thomas Narten, as I said, we haven't seen a big increase in this year or in this year and the last year.

In response to Mark, I can easily believe that things like big mobile operator networks or big telco networks will need the amount of addresses that IPv6 brings, just to be able to number all the devices.

The interesting question is -- and that's something I'm a little bit pessimistic on -- will that ever be public IPv6, or will that just be some internal sort of numbering devices like ATM VC numbers. And when the packet hits the public network, it will be translated to IPv4, so we might have huge IPv6 deployments, but the public Internet will still be mainly IPv4 because they say even if we could let through the packet untranslated to the whole world, the external IPv6 is so bad that we prefer to just NAT everything to IPv4 and never show anybody that we use IPv6 internally.

That's something I'm a little bit worried about.

>>MARK McFADDEN: Mark McFadden again. I think your pessimism is justified.

I think you're right. I think in the early days, in the early days -- and by that I mean the next few years -- those very large networks are going to use v6 for internal activities primarily. And part of the reason is that those networks for the end devices don't really have a good way of, despite what Thomas talked about with the widespread availability of Windows Vista, Thomas is right about that, but my 76-year-old grandmother -- or my 76-year-old mother -- wow, that changed things there. I am glad she is not listening. My 76-year-old mother is not going to change operating systems, and there's an incredibly large installed base that is not going to move.

The people who are developing new services for multimedia either in the home or in mobile settings might choose to actually bring v6 to those end devices at a later time. But wring it's going to be -- and I think your pessimism is completely justified, I think it's going to be a longer time before we start to see those addresses publicly routed.

>>LEO VEGODA: Can I actually ask Alex a question based on this last exchange, then. Because one of the things Alex mentioned in the presentation that he made.

>>LEO VEGODA: Can I actually ask Alex a question based on this last exchange, then? Because one of the things Alex mentioned in the presentation that he made was that in order to get IPv6 address space today, you need to be providing an IPv6 connectivity service to a bunch of other networks, some downstream networks.

So if a very large network that needs to number its internal network space needs IPv6, but they don't intend to have IPv6 connectivity outside of their organization, how do they go and get IPv6 address space from an RIR?

>>ALEX LE HEUX: An organization that is currently, under current policies, an organization that is an end site, so it doesn't have any downstream customers that are other organizations, they will have to go to an existing ISP and obtain either an assignment or maybe a sub-allocation from that ISP.

In the RIPE region, in their current policy, they cannot get their own address space.

>>GERT DOERING: ULA?

>>ALEX LE HEUX: Well, not public -- no public -- they can't get a public address space assignment from the RIPE NCC.

But there are, as I said in my slides, there are some proposals to change this.

>>JORDI PALET: Jordi Palet.

>>GERT DOERING: Sorry, just let me clarify something that the scribes couldn't pick up correctly, because of my not saying it properly.

There's this global, unique address thing, the ULAs, that are, well, sort of, as of today, not given out by registries, but calculated by some algorithm, so you can get yourself private address space, private IPv6 space in large numbers.

It's not guaranteed that they are really unique. There's a certain probability for collisions. But an enterprise that definitely not plans to connect to the public IPv6 Internet could use those.

>>JORDI PALET: I was -- Jordi Palet again.

I was actually going to answer the same.

There is a set of addresses which is ULA which will allow that networks to have a probabilistically unique and the possibility is very, very high that they will not collide with another network using the same numbering. And in addition to that, there is a draft in IETF which is going to be revived, because right now it's expired, which is ULA central. And that's actually something that I am going to make a proposal in every registry -- I am already working on that -- to allow the organizations, if the communities accept that, to register that space, so that it will not be probabilistically unique, but actually unique. So that's something that's going to be there.

It may happen anyway that in some regions, maybe not RIPE, but in some other regions -- I don't remember the text from all the regions right now, I mean the criteria -- but in some regions may happen that the policies allow them to get addresses from global addressing space and not necessarily to announce it, especially in those regions that already support -- providing independent, I guess.

Then going back to what was actually my reason to come to the mike, the comment from Thomas, I think what this -- what is actually happening -- and I have been already doing some measurements, and especially in this first quarter of 2007 -- there will be a big number of users which, without knowing, are already doing usage of IPv6, and with the launch of Vista, Microsoft Vista, to the market, we like it or not, the reality is that it comes with IPv6 enabled by default, and many applications built in in Vista, the new Office and so on, start using IPv6 because they can do real peer-to-peer, even if they are behind a net box with a transition protocol, which is TEREDO, and I have observed the traffic in the last three or four years, and I am actually surprised that -- I have some stats already in my laptop, if somebody wants to see them -- that even if the first quarter of 2007 is still not over, the comparison with previous quarters of -- from other years, it's already showing that there is a small pickup in the traffic. And I am not able to measure peer-to-peer traffic, which will be probably much more an increase in that sense.

So I think it's already happening somehow that because these operating systems that already come with IPv6 enabled by default and support transition mechanisms like TEREDO, 6-to-4, and others, but I think will be mostly TEREDO, but also 6-to-4, because they have public IPv4 address, the increasing traffic will be evident. Probably we will see something very, very interesting in maybe one, one year and a half, when I guess it's the time that, typically, for residential customers, they take to create their operating systems. Enterprises usually take a little bit longer. And I don't think we will see a network which will be mainly IPv4. In fact, most of the big carriers not just in Europe, I will say in many parts of the world, because, typically, these big carriers are global carriers, already support IPv6, native IPv6, in their networks. And I think that's going to increase. And, yes, it may be that the access networks, that they will take a little bit more to be upgraded. And one of the reasons was mentioned already by Gert in his presentation. Because the lack of support in CPEs, the small routers, the chip ones that the users have. And, obviously, the ISPs will not invest in upgrading them. But I think that will happen in a natural way, because we will need to upgrade these routers because we need more bandwidth, bigger ADSL pipes. And that's a natural cycle. Or even some advanced users will upgrade by their own devices. There is already software in the market that you can upgrade your device, not all of them, but many of them, that are based on Linux. So you can use that.

And, in any case, I don't think it's that much difference in the access part of the network to have native or an automatic transition mechanism if the ISPs start to deploy some kind of transition helpers in the sense that maybe they can deploy 6-to-4 relays or TEREDO relays in their network to make that, let's say, a better experience for the user, instead of using a 6-to-4 relay that (inaudible) third partner. I have also a slide set talking about that. And, actually, this could mean for some ISPs that they are going to save some cost because they will not be using upstream transit for the transition if they do the transition in their own network.

There is also a very good example of why some technology's going to use IPv6. And it was mentioned by Gert also. Is DOCSIS 3.0. The main reason to move from the actual version in cable networks, DOCSIS 2.0 to 3.0, has not been the support of IPv6 to the customers, but has been the need for the ISPs to manage so big number of customers that today they do with private networks, network 10, for example, and they can actually not do that, because it's not enough big space. And there is a very good presentation from U.S. provider, Comcast, talking about this need and talking about how they are moving to IPv6, but mainly not to support the customers or IPv6 at the customer side, but, basically, even their own infrastructure management.

>>LEO VEGODA: Okay. Jordi, can I ask you a question, coming back on this transition mechanism?

There's a number of transition mechanisms available. Are the transition mechanisms available adequate for the transition period? Or are there other transition mechanisms that need to be developed?

>>JORDI PALET: Okay. I think the problem is actually there are too many transition mechanisms. So that makes very difficult the life of the people that don't know very well to choose one or the other one.

And we have been working in IETF in the last couple of years mainly in trying to find a solution, let's say one fits all. And I think we found it. It's called subwires, and actually something that most of the ISPs already have in their networks. It's actually layered two-(inaudible) protocol.

So my guess is that as we are moving in the next month, we will have, let's say, new features in L2TP devices supporting this IPv6 transition. That could be almost a universal mechanism. So probably we will stop using many of the transition mechanisms. Of course, we will keep using manually computed tunnels, especially for a small number of tunnels. And I think we will see probably a set -- a big increase in L2TP being used as a transition mechanism, and then probably 6-to-4 on TEREDO. I think we will be using basically these four transition mechanisms, and most of them -- most of the rest will not be used anymore or in a very, very small quantity. So I will say, yes, we have right now already the right transition mechanism.

I don't think we need anything else.

>>RAY PLZAK: Ray Plzak from ARIN. Point of clarification. The impression has been generated that no one can get a provider independent space from an RIR. That's not the case.

Since September of last year, you've been able to get provider independent space, which means you do not have to go to an ISP. You can get that from ARIN.

>>LEO VEGODA: My question wasn't so much about provider independent space for end sites, but more for networks, huge networks that need to number, say, 50,000 sites or more. Is that available for ARIN?

>>RAY PLZAK: No. What I'm saying is that, earlier, that comments were made that the only way you could get space independent of an ISP was to -- you couldn't do that. And so the only discussions that have been occurring here was that since you can't get it from RIR, there was a discussion about ULA. And I was just adding a point of clarification.

So what was your question?

>>LEO VEGODA: Okay. My question was referring back to the point that Mark and others made about IPv6 being very attractive to the very, very large networks.

Is it possible to obtain IPv6 address space, provider independent IPv6 address space, just for numbering a very large network, but where no customer assignments are intended?

>>RAY PLZAK: The policy is not that specific.

>> Alan Levin: Yes. I would --

>>RAY PLZAK: In other words, since it's not that specific, try it.

[ Laughter ]

>>ALAN LEVIN: Hi, my name is Alan Levin from ISOC, South Africa. As Ray pointed out, the ARIN has a policy for provider-independent space. And my interpretation of that policy is that it would certainly work for the networks that you're talking about. But that leaves another four RIRs which are trailing behind the ARIN region. And I'd like to encourage those RIRs -- I don't see any of the CEOs present here right now. So through whatever communication channels you have available to you, I'd strongly encourage those RIRs to address this problem very aggressively. I think it's very important for critical infrastructures such as ccTLDs, gTLDs, in these other four regions to start adopting IPv6, at least for research and development purposes, so that application developers and other developers that wish to embrace IPv6 can do so and be allowed to do so by the policies that are put forward by the RIRs.

>>ALEX LE HEUX: In the RIPE region today, besides the normal allocations for ISPs, we can do IPv6 assignments to Internet exchange points and TLD operators. And there is currently a policy proposal to provide for provider-independent space as well making its way through our policy development process.

So it's being worked on.

>>JORDI PALET: Jordi Palet again.

Yeah, I want to clarify something. Actually, APNIC has also already implemented a policy for providing independent, so we have APNIC. And there is a policy proposal that I made in all of the rest of the regions, including RIPE, AfriNIC, and LACNIC. I think but RIPE and LACNIC have also an equivalent policy for critical infrastructures, I think not in RIPE. Okay. So I am missing that. But in LACNIC, it's available since the beginning. So I will say that the only region which is, let's say, in a small disadvantage in this sense actually is AfriNIC, because they don't have yet a policy for critical infrastructure. But there are -- my proposal, an additional two proposals. So I guess in the next meeting in May, probably, hopefully, that will be sorted out.

>>GERT DOERING: Actually, this is quite a touchy subject. One thing that I directly want to comment on is that RIPE CEO has no say in the address policy in the RIPE region, period. That's not perfectly true, of course. But the way policy is made in the RIPE region means that the RIPE members, everybody who's using Internet, or maybe not even using Internet, in the RIPE region can influence policy. And it's not like the RIPE NCC CEO goes to the address policy folks and says, "Hey, please change the policy," because the process is definitely bottom-up.

Regarding critical infrastructure, the RIPE region has had big discussions about that in the address policy working group. And as of today, we mostly share quite different view from the other regions. And that is -- well, ccTLDs are critical, but there's nothing critical about their network connectivity that warrants special-case addresses.

They need connectivity anyway, so they can just go to a provider and get address space from there, because they need it routed, anyway. So they need, well, a provider to give them connectivity. If their provider can give them IPv6 address space. If they change providers, they can renumber. Because renumbering a second-level TLD name server is pretty easy. We have a special-case policy for the root name servers, because renumbering root is, well, near to impossible. But everything else is not hard-wired, so it can be changed.

Yeah, of course, we have a special-case policy for Anycast. But that's less them being hard to renumber, but they are special in routing. And the policy is there basically to make sure people know that these prefixes are special and can handle them especially in their routing filters. Yeah.

>>JOAO DAMAS: Just a comment.

There is a problem perhaps in how some of the IPv6 -- technical recommendations have been worded in that it's much harder to get proper multihoming in IPv6, because you are not allowed -- the common practice does not allow you to take a chunk of address space from an upstream and (inaudible) it to another ISP. You have to take several of these. Which means that suddenly your name server has to have several addresses. That is just not how networking is done.

The mismatch between the protocol development picture hasn't been imposed on the operations is actually preventing this sort of use which is necessary for serious services to be deployed on IPv6. So....

>>GERT DOERING: Well, I happen to have a different view. And at least dot DE is coping pretty well with what they have. That's the registry I know best.

>>DAVE CONRAD: Dave Conrad with ICANN.

To clarify one of the issues having to do with provider-independent space, the reason that it is somewhat controversial is because every provider-independent prefix that's allocated by a lonely registry, or anyone, for that matter, any provider-independent prefix that's created, for it to actually get routability means that it has to show up in, essentially, all of the core routers throughout the Internet. This is the same routing technology that's used with IPv4. And there are some serious concerns about whether or not the routing system can withstand the addition of a large number of additional provider-independent prefixes.

The original theory behind IPv6 was that the address space would be highly aggregated, originally, at the very top level, there would only be I think it was 8192 provider-independent prefixes.

The way the technology was eventually developed treats it identically to the way IPv4 is treated, with the exception that some of the policies that currently exist discourage punching more specifics from provider aggregatable address allocations, as Joao mentions.

>>JOAO DAMAS: And further to that, this -- the fact you just mentioned, that the original design called for a maximum of 8,192 independent service providers, shows one of the fundamental problems with IPv6, in that the protocol was developed by some technical people with no operational experience, no -- in a vacuum, basically, trying to impose an idealized view of the world which doesn't match reality for everyone else, and that we are still paying for that.

>>ALAN LEVIN: Yeah, Alan Levin back again. Sorry.

These technical issues are compounded further by business issues in that because there are technical issues, ISPs are very focused on their commercial viability, are not adopting IPv6, not even for research purposes, and therefore are not able to provide IPv6 connectivity to their customers. And their customers want to stay with those commercial providers, because they're getting the best price for their connectivity. So even if the customers wish to adopt the IPv6, they're having a problem getting their own P.I. space through the RIRs in order to get tunnels through other potential IPv6 operators.

So because of the technical issues, this is compounding the business issues and halting any kind of research and knowledge and skills acquisition in using IPv6 and therefore developing the technical specifications so that they're more ready for further adoption.

So, I mean, it's a chicken and an egg situation. How are we going to deal with it?

>>LEO VEGODA: Alan, can I ask you, you have said that you want to see provider-independent assignments made, provider-independent assignments made more widely available so that more enterprises have access to that address space. Do you think that will also drive more widespread adoption of IPv6? Will that be a large uptake or is it maybe just a few hundred enterprises across the globe that would be interested in this address space?

>>ALAN LEVIN: I'd suggest it's those companies that are smaller companies that are looking to do research and looking to exploit new technologies and gain knowledge and gain awareness and also contribute back towards building the technology that would be driving -- you know, that would be taking advantage of the use of this P.I. space.

And my understanding is no matter how small that number is, those smaller, more agile types of companies and people that are working in those companies would be driving more and future adoption of IPv6. I have no doubt about that.

>>GERT DOERING: Okay. Two comments about that.

Some years ago, we, well, decided that IPv6 is the way to go, we as an Internet Service Provider. And since then, every time a salesperson from some -- somebody that wanted to sell us anything like upstream bandwidth, a product, whatever, we have been asking, "Can it do IPv6?" and if we haven't been interested in their product anyway, we just use the IPv6 thing to drive them away. You don't do IPv6, then we are not going to buy it. Goodbye.

Of course, those things that we needed to do, we got with or without V6.

But eventually insisting on V6 took hold. And as of today, all our upstream providers, all three, provide native IPv6 service. It took us some five years, but, eventually, it worked out.

Now, in Europe, we are lucky, because the competition in the upstream provider market is fairly tough and that actually is a distinction feature between the upstreams. And I'm aware that in the African region, it's very hard to get competition at all, even without IPv6 taken into account.

So that might not really apply to you.

The other thing, if you are planning to use a tunnel to get IPv6 connectivity to do research, it's a perfectly viable approach to use provider aggregatable space from that entity that provides the tunnel. I don't have an overview about tunnel providers in the African region, so I cannot give a really educated comment on that.

In Europe, we have one, one entity that's SIXSS, which is giving out tunnels for free, including address space. So for everybody who's just trying to get the feel for IPv6 to get research done and so, that's something that works perfectly well.

If you want to do business-grade IPv6 connectivity, I would recommend against a tunnel anyway.

So I think I have some disagreement on the real necessity for provider-independence for companies wanting to get the feel of IPv6, wanting to do research.

I see the need for provider-independent space for certain types of multihoming, and, well, there's an IPv6 PI policy being worked on in the RIPE region right now. And I think we will see it go through.

>>JORDI PALET: Jordi Palet again.

I want to clarify something. I am, in principle, against provider independence, and that's a little bit crazy, because I have been proposing provider independence in all the regions. I had initially the same view as David already mentioned, that it's important to have the balance, because the cost of providing independence is the slots in the routing table. And if we, let's say, sprint around provider independence, that will create a problem, but the problem will be there, even if we don't do so, in the sense that the routing table, it's already going to be a problem without IPv6, because it's growing already, with IPv4. So probably the deployment of IPv6 will, even if we provide -- if we have provided independent everywhere, it will not increase the problem to be such a problem, because IPv6 itself.

So my reason to propose provider-independence in the rest of the regions was basically that I was thinking -- and I still think it's the right thing to do -- not to have such a difference between one region and the rest, in the sense of having one region being able to allocate provider-independent, and not in the rest of the regions.

So that was my main reason, even if I am, in principle, against providing independent, to go for that.

And I think I disagree with Alan in the sense that it's not really a barrier not being able to get provider-independent to not have access to IPv6. I think if someone wants to actually provide the service, especially at the stage that we have today, which is deployment of IPv6, even not having provider-independence, there are always a lot of solutions. And Gert also mentioned tunnels.

We have provided tunnels to Africa. Probably we have 20 or 25 tunnels to organizations in Africa for free. And some of these tunnels are direct to us, and some others are either native or tunnels to their existing upstream providers. So there are already companies in Africa -- of course, there is this lack of competition. But I don't really think if someone wants to move to IPv6 there is today a reason for saying no, I don't have provider-independence, so I cannot do it. I think that's somehow a bad excuse, unless you have a real demand from customers and you want to provide the same SLAs today and so on. But I don't think right now yet at that state, at least from content providers, for example. I don't think it's that critical.

It may change very quickly. It may change in a few months. But, in general, I see most of the people are talking about that, it's not a very good excuse.

>>LEO VEGODA: Can I ask anyone who wants to answer, have people requested IPv6 service from providers and had real difficulties finding a set of providers that can make them a tender?

>> Hello. My name is Hans Petter Holen. I'm here today because I'm on the Address Council.

But to answer your question, I can bring you some experience from my real-time job in VISMA, a Nordic ERP provider.

We are around 3,000 employees scattered around the Nordics. I did a bid last year for a new VPN for the group, around 70, 80 offices around the area and asked all the players for a bid. And from the answers I got from the four or five companies who could actually offer the service in all the countries, there was only one of them that could actually offer V6 service, but they could not offer production quality.

So as a customer today, trying to buy V6 with production quality, with an SLA, it was not possible for me to do that. I could get upstream and connectivity, but not service to all the offices that the need.

Some of you may ask, why did I ask for V6. Bought that's perhaps not usual, at least if you look at Gert's experience. And, well, part of the reason is because I'm involved in this addressing game, so I wanted to know if somebody could offer this. But if I'm looking for business reasons, what I can see immediately is that since Visma is growing through acquisitions and mergers, it would be a real benefit if I did not have to renumber networks whenever we acquired a company.

So I can see and could probably demonstrate a sort of an economic value of going to V6 and not having to renumber whenever we acquired and merged another company.

But these are figures that are not very easy to identify today, and the costs of merging the I.T. systems are probably larger anyway.

So I think for me, the real driver to go into IPv6 would be new services and functionality to the end users.

And then I'm caught in another chicken and egg problem, because my company is actually developing applications for the users. And I still haven't figured out any reason to bring V6 to the R & D department's table. And that's something that it would be interesting to understand what Microsoft is doing in this area. I tried to do some searches on their Web site. But it wasn't easy for me to find good reasons for me to look to going to V6 from their marketing material. And, therefore, I guess it's not going to be easy for Visma as one of the providers in the norDIC to try to figure out what we could do in that area as well.

So I think the orders of magnitude in justifying moving to V6 is still going to be considerable.

>>LEO VEGODA: That's sort of interesting and perhaps a little disappointing that you are having those problems.

Well, let me -- we've got a queue at the mike. Go for it.

>>MARK McFADDEN: I should never stand in front of David.

The one thing I would ask Hans Petter, is that would the inability to get IPv4 addresses be a commercial driver?

For instance, the exhaustion of the existing IPv4 pool.

>>HANS PETTER HOLEN: Well, I could say yes, of course, but in practice, we run the corporate VPN behind firewalls, so we are using private addresses. So for internal use it, would not be prohibitive and for the services we provide to the Internet, we need a handful of addresses and we already got those. And we provide the services through a firewall on that.

So not for a while. Not for a while.

>>JORDI PALET: I think there is a point that we are missing when we talk about building applications which take advantage of IPv6. And I think it will be the main advantage for IPv6 at the moment when you are deploying peer-to-peer applications. Because if you deploy client-to-server, that works just fine; okay?

But the problem is when you are creating applications which are peer-to-peer, that's not so easy.

And actually, there are companies like Skype that already mention that the development cost, because the NAT, is 80%.

So from all the development cost of the application, the most costly part is actually living with NAT and keeping updated with different new NAT boxes that come to the market every day and so on.

So if you want a single reason, probably, to take advantage of IPv6 today, maybe there will be others in the future, I guess, but just not needing to bypass NAT because you have transition mechanisms that do already that, even if they still don't provide native IPv6 service, that's a good reason.

>>JOAO DAMAS: Where can I get the peer-to-peer application that have support for v6.

>>JORDI PALET: Everything built today in vista is already using IPv6 as first entry point. If for whatever reason IPv6 is not working, then it reverts back to IPv4.

But I don't remember the name, but network, when you have a network without servers and so on and you want to open folders from one PC to another, even in that case it is already using IPv6. So it's transparent. Nobody will notice it. It's already being done. Even some versions of MSN, in XP, they were already trying, when doing file transfer of using IPv6, because it is cheaper and faster, actually, even if use transition mechanisms, do a file transfer, strike from one PC to another, two peers, instead of going to MSN Network, behind the NAT and then going back to the other network.

So it's something that is there and nobody will notice it, at least not at the beginning.

>>JOAO DAMAS: That's right, what happens in the local-area network is not really that important. You can use the Ethernet address for that.

I am talking about like the traffic patterns in the Internet. 80% of it is bitTorrent, eMule and similar protocols and there are just no IPv6 applications for that yet.

>>JORDI PALET: Yes, there are already some bitTorrent versions supporting IPv6 but it's true, they still are not there. But I am guessing they will come. Especially, I am not saying in two months, but I really think that when there is a sufficient deployment of Windows Vista, which will like or not, it will take maybe 70, 80% of the market in maybe two years, I don't know if even maybe a little bit less or more, but in that time there will be a lot of traffic using IPv6 even not necessarily doing anything specific about that.

It will just happen.

>>GERT DOERING: As far as I'm aware, there's no IPv6 capable eMule or that sort of thing. Regarding bitTorrent, there are two clients. I think the most official clients, the Azarius and bitTornado can both do IPv6. The problem is you need peers that have the stuff that you want and have IPv6. I have run bitTorrent with IPv6 enabled for a while just to see whether there would be any request, and I haven't had any traffic. So it's a sort of critical mass thing again.

>>DAVID CONRAD: David Conrad with ICANN.

With regards to getting IPv6 connectivity, ICANN recently just turned up v6 connectivity for the external sites. And Mehmet might actually be able to provide some input as to how difficult was to actually obtain that service for ICANN.

Was it hard or was it easy?

>>MEHMET AKCIN: It wasn't so easy to be honest, but at the same time, it was more like being able to multi-home it, was my biggest concern. I really don't want to go ahead and find the provider and just put the service on with having no backup on it.

But having some kind of native IPv6 connectivity from Los Netos. I don't know if anybody from Los Netos is around here right now. We are using them as our main IP, IPv6 connectivity, and we are tunneling with Hurricane Electric. So I believe it's pretty straightforward.

It's easy. It just takes time and most people consider it as non-mission critical, unfortunately. But yeah, we are getting there. We are already there, and hopefully we will have all of our services on IPv6 as soon as possible.

>>CARLOS FRIACAS: Hello, Carlos Friacas from FCCN, the local (inaudible).

I was looking at this slide, the last bar. I have checked the IANA Web site to check that number, and just to be certain that number doesn't count experimental blocks from --

>>LEO VEGODA: Yes, I didn't include the class E space in that graph. I understand the class E space is not going to be very easy to use.

If you add that on, then it's another 16 /8s.

>>CARLOS FRIACAS: So there is currently no plan to use it when --

>>LEO VEGODA: I think -- David will correct me if I am wrong, but I think if the RIRs request it, then we would allocate it. But I'm not sure if the RIRs want to request it or not.

I leave it to an RIR person to answer that.

>>DAVID CONRAD: David Conrad with ICANN.

My understanding, I have been told, that a certain large software vendor by the name of Microsoft believes that the class E space is insufficiently specified to actually be usable. And thus, disallows any configuration of class E space on any Microsoft product.

So it's unlikely class E space would be usable by end users. It might be usable -- I don't know if you can configure Cisco routers for it and thereby use it as some kind of internal infrastructure. No, you apparently can't configure Cisco routers.

>>ALEX LE HEUX: As an RIR person, I can say for this reason there are currently no plans to request allocation of class E space.

>>JOAO DAMAS: Besides, it wouldn't actually make a difference.

We're going to run out, 16 /8s by at most another year perhaps, when you get to the end of it. What people need to start doing is planning for the end, not looking for ways to get just that little extra bit.

>>DAVID CONRAD: David Conrad with ICANN.

The assumptions that are made with regards to projections of when the address space run out all have a fundamental flaw in that it assumes that the address space will continue to be consumed at the same rate that it's being consumed now.

If you talk to Geoff or you talk to Tony Hain, and they acknowledge this is a fundamental flaw.

Now, the reality is that as the free pool is consumed, there will be a change in consumption patterns. What that change is is not entirely clear. It could either go faster or it could go slower. There's reasonable scenarios both directions.

So if we were able to somehow free up 16 /8s, I think that would have an impact on the longevity of the free pool of IPv4 beyond what is described within some of the projections that are made available today.

>>LEO VEGODA: Okay. I think we're drawing to a close now.

We're approaching the end of our session.

I'd like to thank the panelists, Alex from the ripe NCC, Gert Doering from SpaceNet, and Joao Damas from ISC.

I would also like to thank the people participating remotely and the people taking transcription for us, which is very important. And everyone who has turned up here and participated today.

I appreciate the fact that people have come here on a Sunday afternoon, and it's a lovely day outside.

I know that there are sessions later on in the week which may be of interest to people in this room. In particular, I know that there is an ASO session. And if someone from the ASO who is here or maybe Ray, if you know, if someone could just let us know which day it is, because I can't remember. But I think people in this room might want to attend that session.

And I'd like to draw their attention to exactly when it is.

>>RAY PLZAK: Well, not being the organizer of it -- he is sitting right there (indicating) -- I believe it's Wednesday morning is when it is. And so I would say go to the ICANN meeting page and look for it.

>>HANS PETTER HOLEN: I can confirm that it's planned on Wednesday morning, but I will -- I am not the organizer of it, and I'm unfortunately not here on Wednesday morning so you will have to manage without me.

>>LEO VEGODA: Okay.

Well, thank you. Thank you very much, everyone.

Again, thank you Alex, Gert, and Joao. And also thanks to Mehmet for making all the technology work.

Good afternoon.

[ Applause ]