IPv6 Workshop - New Delhi

Workshop - IPv6 Update
Wednesday, 13 February 2008
ICANN meeting
New Delhi, India


BARBARA ROSEMAN Okay. We're going to start in just a moment.
Is that okay? You guys okay there in the back? You ready to go?
Okay.
All right. Thank you for coming to the IPv6 workshop today.
I'm sorry we didn't have a posted agenda. We've been arranging things up until just this morning. So....
Paul Wilson from APNIC is going to give a presentation. Suzanne Woolf, from ISC and also one of our board chairs, will be giving a presentation. And I'm going to open briefly with a short history of the IPv6 registry at IANA.
We'll have time for discussion afterwards. And it's also possible that Dr. Crocker will be joining us to give a brief presentation as well.
So let me go ahead and get started.
So I'm going to cover IANA's IPv6 registries, a little bit about IPv6 in the DNS, and then our IPv6 services, "our" mean ICANN's.
These are some highlights in IPv6 registry history.
The IETF delegated IPv6 to IANA in 1995, and we began making allocations to the RIRs in 1999.
There have been several events where space has been set aside for specific purposes. If it was experimental space, it's been returned to IANA for redistribution.
'96 is when the 6Bone started. '99 is when the RIRs agreed to a bootstrap policy which allowed people to get IPv6 before they actually had customers online, obviously.
In 2002, there was a common policy adopted across the RIRs that has since moved away from being exactly coordinated, but they all have very similar policies.
The global IPv6 allocation policy refers to how IANA allocates IPv6 addresses to the RIRs, not how they distribute addresses to their members. But it did allow us to move forward with a sort of standardized process for evaluating requests for V6 from IANA and being able to give allocations that were consistent in size.
This is the way that the V6 registry looks at the moment. There's space assigned for Unicast, space assigned for multicast, a special reserved space, lots of empty, as the slide has here, and the current IPv6 registry.
As -- Leo created this slide for me, Leo Vegoda. And as he says, this is not to scale. The "lots of empty" outweighs everything else, even though it looks smaller here.
IPv6 glue for the TLD name servers was first added to the root zone in 2004, and then just last week, we added glue records for the root name servers.
ICANN has enabled V6 services in a number of places. They're not, I would say, all active today. They -- we've been going through some infrastructure changes, and so some of them are active and some of them are not. I wouldn't be able to give you a definitive list. However, we have at different times offered V6 name server, a V6 mail server, IPv6 on public.icann.org and Delhi.icann.org. Those two, I believe, are active. And we have more infrastructure changes to follow. We intend to have all of our services available over V6, as well as much of our backend infrastructure.
And if you want to take a look at the specific announcements in the V6 registry, rather, these are the URLs. And the announcement about the addition of the root servers is the lower URL there. It details the -- excuse me -- the allocations -- the microallocations that the assignments were made out of and has some information on routing that could be of use to you.
And I think that may be my last slide here. Yes. Thank you. So, Paul.

SUZANNE WOOLF While we're moving hardware around, we should introduce Dr. Steve Crocker as our last panelist.

PAUL WILSON Now, who says a Macintosh never crashes? That's not the first time that this thing has completely collapsed when plugging in a cable. Sorry, everyone. So --

BARBARA ROSEMAN Suzanne, why don't you take my place.

SUZANNE WOOLF This is not a good hardware day.
It's supposed to be....
It should be.
Well, we are not having good hardware luck today. So I'll --

BARBARA ROSEMAN Oh, it's not connecting for you, either?

SUZANNE WOOLF No. It hates me.
An unfamiliar problem. My apologies. I do have a slide set, which we can make sure is posted.

BARBARA ROSEMAN Sure. Or, actually, if you want to just take a minute to put it on a stick, since mine's working, we can just do it off of mine.

STEVE CROCKER What's the issue here?

BARBARA ROSEMAN Do you want to try?

STEVE CROCKER Sure.
[ Laughter ]

STEVE CROCKER Try for a perfect score here.

PAUL WILSON This session is powered by....

BARBARA ROSEMAN Sorry about that.

PAUL WILSON This session is powered by IPv6, by the way.

SUZANNE WOOLF Wait a minute. We didn't have this kind of trouble with IPv6 in the root name servers.
Let me get out of your way.

BARBARA ROSEMAN Why don't we just --

STEVE CROCKER Is this an issue with --

PAUL WILSON Must be.

BARBARA ROSEMAN No. We're thinking maybe an issue with....

BARBARA ROSEMAN Yeah, the problem is, then we can't show the transcription.

STEVE CROCKER Are there any techies in the house?

BARBARA ROSEMAN There are,.

STEVE CROCKER I'm Steve Crocker, chair of the ICANN Security and Stability Advisory Committee. Oops.
Got a different problem here; right?

BARBARA ROSEMAN That's on.

STEVE CROCKER Can you hear me?
I'm Steve Crocker, chair of the ICANN Security and Stability Advisory Committee.
I've been looking a little bit at the IPv6 issues, and I want to share just a handful of thoughts. Unfortunately, I'm going to be queued up by what I can see on my screen, even if -- whoa! Oh. Okay.
Jennings is a genius. Is that what we learned from this? Thank you.
Actually, now I can go back to a less animated mode here.
Thank you. All right. Well, welcome again.
So there's been an awful a lot of attention to the demise or depletion of the IPv4 pool. And I really think that it's -- as important as that subject is and the amount of attention it's going to get, I think it is also as distracting as a very bright lightbulb when you're trying to look at the rest of a picture. And it's very important to look beyond the immediate distraction of these addresses being depleted.
And these -- the depletion of the IPv4 space is going to consume a hell of a lot of attention. There's going to be every kind of thing that you can imagine, hoarding and gray markets and legal fights and political fights and so forth. And, nonetheless, inexorably, they're going to get used up.
And the second thing that is important to say is that not only will they be used up, but they're going to remain in use. Come back to that in a second.
The other side of this is that IPv6 addresses are, in principle, plentiful. One amusing little calculation is that if you spread them uniformly across the surface of the Earth, there are about two-thirds of a million IPv6 addresses per square nanometer.
That's a very small number. I'm not being serious, of course. You can't allocate them uniformly, and the routing would be very interesting.
All right. So here's where I believe we really have to focus attention. IPv4 networks are going to continue to exist, essentially, indefinitely. They're not going to go away. If they had -- If they were going to go away, then we could talk about a full-scale transition from IPv4 to IPv6.
But the problem is actually harder than that. And that would be a pretty messy problem. We're going to have to have coexistence between IPv4 and IPv6, and interoperation. Coexistence is easy if they don't have to talk to each other. You build two separate networks. That, obviously, is not a good idea.
So we have to have both coexistence and interoperation. And there are an awful a lot of chicken-and-egg problems. Who goes first? How do you get these things to work?
Some things, perhaps many things, are not going to work very easily.
Do I have any good news for you?
A little bit, but not a whole lot.
A lot of the discussions that I have been hearing were very, very mushy, like, "Well, nobody really wants this," or "We wait for industry pressure," or "Dual stack," for example. "Dual stack" is an interesting term, because it means, technically, that a piece of hardware is capable of running both IPv4 and IPv6. Being capable of running both doesn't mean that it actually has an address of each, and it doesn't mean that it's connected to transports of each kind. And if you assume that every device is connected to both kinds of transports and has both kinds of addresses, then you have, essentially, assumed that there's enough IPv4 addresses and you don't need IPv6. So it's a kind of circular argument taken narrowly by itself.
In a larger context, dual stack makes a lot of sense. But by itself, it's not a complete answer.
So I think it's important to look more deeply into the -- sort of the market, if you will, or the set of users. And one of the ways to do that is to divide the space up into different categories. I've listed here some of the obvious kinds of categories ISPs, enterprises, divided into large ones, which could be further subdivided into old ones versus new or growing ones. Why is that important? The existing large enterprises typically are pretty well set. They've got large blocks of IPv4 space and they're prepared for a long, cold winter.
Newer enterprises or growing ones are more likely to feel the pinch sooner. Small enterprises have less market power. Content providers will play a very important, pivotal role in this chicken-and-egg problem. And then you have equipment vendors, both router vendors and firewall and middleware vendors, and other kinds of supporting hardware and systems, such as network management systems. Governments play a key role.
And another dimension which I think is very important is that the story may be very different, say, in Africa than it is in, say, North America, just to pick two very different regions.
So let me just dive down into one very narrow specific thing. Within our committee, we took a look at firewalls. We took a look at the existing available commercial firewalls, because one of the questions one could ask is, suppose a CIE in charge of an enterprise says, "We're" -- "It's time for us to invest in IPv6. We're going to switch to IPv6 or adopt it now." And his people say, "Okay. Fine, we'll do that. Here's how we run our IPv4 networks today, here's the tools we have, management systems, security controls, firewalls, all these things. I'll just get the comparable set of products and configure them in a comparable way for IPv6."
Is that feasible today?
So we did a little survey.
And the answer was not so good.
Across the bottom, the categories are all, small and home office type products, small and medium business products, and large enterprise or service provider products, so that the three categories on the right are subdivisions of the unified one on the left.
And the label on this one is I.P. transport. And we saw that of 42 products surveyed in different categories, not -- some of them had IPv6 transport and others did.
How many of them had I.P. routing? Here the numbers are lower. Static filtering, again, highly variable, comparing IPv4 versus IPv6.
So I don't want to -- We have -- oh, I see. I'm sorry. Some of the slides don't show here.
Where we show in, essentially, white these numbers, 13, 6, and 12, those are the IPv6 numbers. And they're contrasted with the IPv4 numbers, which are colored. There's a little problem in the transliteration in this slide from one format to the other. The general answer is that the maturity of the products in this particular segment of the market, not so good.
And these -- this pattern continues across these.
All right. So here I've jotted down eight questions that have come to mind that I think are useful for dissecting the problem. Who's going to feel the pinch? Will it be existing players or newer players? How will pure IPv6 networks interact with pure IPv4 networks?
And in that question is embodied a hypothesis that there will be pure IPv6 networks and that there will be pure IPv4 networks and that there will be a desire for devices to interact across those.
Not everybody goes immediately to that kind of picture, and so I acknowledge that there might be controversy about that. But from my point of view, if we can get reasonable answers to this question, then we're in pretty good shape if we don't get there if the problem isn't as bad as that.
When will there be IPv6 global connectivity? So there's a particular portion of the problem. If there is IPv6 global connectivity so that if I have an IPv6 device connected to a local IPv6 network, and I want to reach something on the other side of the world that is advertised as having an IPv6 address, is there connectivity from one side of the world to the other? That's an important milestone.
I don't know where we are on that. I think that things are getting better, but I don't have an exact measure. But I think that's an important thing to measure.
Are there impediments or incentives for the ISPs, business-type questions.
Do they have the available routers, network management systems, and so forth? And as I showed before, not all of the devices and supporting systems are in very good shape yet.
Are there impediments and incentives for enterprises? And comparably for content providers?
So as I mentioned, content providers have the possibility of playing a very important stimulant role here.
If I'm an IPv6-only customer, client, can I reach all of the services, the Google, the Yahoo!, the CNN, you know, news services and games and everything else that I want to be able to reach, can I reach them over IPv6? Well, even if I have transport, they have to provide their services over accessible VoIPv6.
So one of the things to look for is whether content providers begin providing their content both over IPv4 and over IPv6 and provide something to talk to if you have an IPv6 client.
Who are the strong players? What role will governments have and what companies are playing a major role? I think those are important questions to ask.
And then, finally, where should the thought leadership come from and who should be involved. What role is there to play, who is playing them? Are there new roles or are there players who are missing?
Notice that I have not yet mentioned ICANN. Clearly, one of the questions of concern in this environment is, is there a role for ICANN to play beyond the obvious role of allocating IPv6 addresses and working with the RIRs on allocation policies. That's, of course, a requirement.
And the other things that we'll hear about, I think, are that ICANN is putting its own house in order, considering how to transition its internal systems to IPv6 operation and be welcoming, and the most recent, most significant thing is the addition of the IPv6 addresses for those root servers that are already -- root servers are a sort of very selective kind of content provider, if you will. And so if you think of the 13 root servers as providing content over IPv4, we now have almost half of them also providing the same content over IPv6. So that's an important step forward.
So my last slide is that I think we do not yet have clarity. We do not yet have a widely accepted road map that says, here are the way things are going to unfold, and everybody can find their place in that process.
And I think this is a vital and important area. More attention is needed. And so this is a call for attention.
It is not simply an exhortation that IPv6 is important and it's time to get on and do that. I can give that speech. I have given that speech in this city a few months ago, in fact. And it's a delightful speech. But this is a somewhat different point of view.

BARBARA ROSEMAN And now we wait. Yea!

PAUL WILSON Well, that looks better. And thanks very much for your patience. My apologies for the hardware problems before.
Can you hear me?

Yes.

PAUL WILSON Is that okay? I'm Paul Wilson from APNIC, the Asia-Pacific regional Internet address registry.
I'm here at the ICANN meeting with representatives from two of the other RIRs, from ARIN and Ripe NCC, by the way, and we're having numerous discussions about I.P. addressing issues.
One of the purposes of being here, obviously, is to talk at this workshop. And I've got a presentation here which was developed by myself and APNIC's chief scientists, Geoff Huston, and it's about the path of evolution to IPv6 and what -- at least some of the barriers there and what we think critical barriers actually entail.
We all know that IPv4 addresses are being consumed and the lifetime of the remaining free pool of addresses -- these are the addresses that are held by IANA and the RIRs -- is limited.
The latest projections -- these are numerical projections, which are really predictions of the future. And, of course, things may turn out differently. They've proven to be fairly accurate so far, though, in terms of matching with the curves. But these projections show that June 2011, actually -- sorry, that's a mistype -- but June 2011, just over three years from now is when the remaining pool of IANA addresses and free addresses within the RIRs will run out.
So where are the addresses being used? I won't go into this in a great amount of detail. But we are often asked how many IPv6 addresses have actually been allocated and where are they. We really are in the early days of IPv6 deployment. And single allocations which are being made by the RIRs in one part of the world or other make, actually, large differences to the global allocation scheme. And you can see here just in a comparison of IPv6 allocations which are being made and have been made around the world over several years, these numbers are up and down all over the place. And there's no particular trend showing, certainly not an encouraging trend that we've got massive deployment or an exponential sort of growth, which is what people tend to like to see and expect in this environment.
There is some growth going on, but also there have been -- there's been quite a lot of early adoption which is shown particularly in Europe and in the Asia-Pacific. And that's not proving to be yet a launchpad for huge growth in future.
One thing is how many addresses are actually allocated. And we can allocate addresses, and, in theory, they become used at some point thereafter. But in fact, they may not actually appear in the routing table.
It's very interesting to look, and it's kind of sobering to look at a comparison between IPv4 and IPv6 as it appears in the routing table.
And that, actually, represents real use of the addresses, of the addresses appearing on the public Internet. The top couple of graphs here are IPv4. The bottom couple of graphs are IPv6. And they are both growing nicely, but in the case of v4 we have seen, over four years or so, a 67 percent growth and 250,000 prefixes in the routing table. Same amount of growth pretty much in terms of autonomous networks, but there is 27,000 of those, approximately, represented in the routing table.
v6 is growing nicely, 100 percent in the four years, but there are a thousand routes in the routing table and there are 850 autonomous networks in the routing table.
So we have got a very long way to go. These networks are hardly representative of -- and I think you probably would all expect this, but this demonstrates in a sort of fairly undeniable fashion that we are not seeing major growth or deployment of IPv6 at all. Even the networks that are being deployed, we hear that -- or we know that they are largely experimental and test beds and so on.
So it really hasn't happened yet.
Now, the reasons for this, we hear a lot of sales pitch and we have heard a lot of selling and, to some extent, overselling of IPv6 over quite a few years, but the fact is that the Internet continues to operate, we all use it happily, and it continues to grow very rapidly in terms of the size of the network and applications and user population.
There's something that goes on in the Internet today called network address translation. It's being blamed for many distributed costs which exist around the network, in terms of the complexity, the cost, the efficiency of the Internet. And for those who might not quite be familiar with how this network address translation works, it laws private addresses, which are basically addresses in unlimited supply, to be used at the end-user level while the translation, in the traffic between the end user and the network, is done to translate into a public address which can then be seen around the Internet. And it's actually rather like, to draw an analogy, a PABX, a private business exchange in the phone network, where it's quite possible for you, if you are a user of one of these phone exchanges, to make your outgoing call quite happily and you can call the rest of the world. The trouble is when the rest of the world comes and calls you, you are hidden behind a public address, and whatever your extension number may be, whatever your private address may be is not obvious.
What needs to happen there is some special protocol. The protocol on the phone network would involve you talking to a receptionist or an automated system and selecting the address. And the use of that protocol would be very different if, for instance, you were sending a fax through that phone line.
So this is very much what we see in terms of the complexity of the Internet or the InterNAT which is basically engineered for this type of technology.
Applications have been to be developed specially to use special address translators. There's all sorts of technical features which are required in applications which are engineered for NAT. I won't go into those, but the fact is that there's a distributed cost across many dimensions, across -- within the Internet for the fact that there is so much network address translation going on. It does seem to work. It works perfectly well, and some people say it can go on working almost forever. But there actually is considerable cost.
The trouble that we face -- and I'm sort of starting to look at the business issues here. The trouble we face is of that who is bearing the cost. Because at the moment the cost for network address translation, you might not realize it, but you as the Internet user have borne the cost by buying a network address translator and installing it yourself. The applications developers have borne a lot of costs. Skype, for instance, has got extremely complex routines and methods in it to allow you to connect through network address translation.
The ISP doesn't have too many costs at all. They are happily delivering you your single public address that you are having to translate. So the ISPs costs are externalized.
That's a good thing, too. I will get back to this, but there is not a hell of a lot of money in being an ISP these days, so that is also an issue in terms of who is really willing to do something to improve the Internet.
So that cost, the cost in total, in aggregate, is huge. It's distributed across hundreds of millions of users and applications and computers and so forth. But it's not terribly much a cost that rests on ISPs.
Because as I say, the ISPs -- the ISP industry has changed a lot in the last, say, six or eight years. There's been this intense consolidation, this intense competitive -- or competition in the industry.
The Internet is a mass market, very low margin service these days.
There's a sort of condition of stasis at the moment where really low margins and poor capital returns, they create an industry that, at the ISP level, is really quite sluggish, quite resistive to resolve the business model.
Business cases are everything, and you have got to have a pretty good and pretty short-term business case to spend any money in this industry.
IPv6, well, what's the problem? It is stable. One of the things that we do know and which is being explored in a lot of detail now is the transitional issues, and a lot more time is being spent, a lot more brain power is being spent on how the transition is going to work at the sort of standards level than it is in terms of the protocols themselves, which are pretty well finalized.
But the trouble is, again, NAT has worked too well. Investment is hard to get. The idea of short term versus long term investments and payoffs is not particularly clear.
I would also say that IPv6 promotion and overselling happened largely in a sort of too much, too early kind of environment. In the words of the magazine, IPv6 has become sort of tired and not wired. People have just been hearing about it, the promises, threats or warnings, for a long time. And so far, still, the Internet works.
So, yeah, again, the result is the short-term pressures are really deferring decisions about IPv6.
The business case, the linkage between cost and benefits isn't clear.
We have had this assumption in the technical and operational community that somehow an evolution would happen; that we would have a growth of the v6 activity on the Internet, gradually overtaking, sort of outcompeting, the v4 Internet. But so far that evolution is not obvious.
It's shown in all the metrics.
So is it possible in the foreseeable future? Some people would say yes, some people would say no.
Finally, the question is how could it happen. There is one scenario, at least, which is not a technical scenario and doesn't look at and talk about the actual technical challenges of transition sort of issues that Steve mentioned earlier, but it's got to do with motivations. Motivations within the industry.
And I think it's nice to sort of think about motivations and think about the potential and the benefits.
And it's a comparison here between what happened in IPv4, during the 1990s when we had, in fact, this incredible boom of switching technologies, of bandwidth, of PCs, where, again, the operational costs of the network were externalized because the users themselves funded their own gear.
We had a boom in this dumb and cheap network. We had all of the innovations of the Internet being pushed out to the edges of the network.
But these days, the Internet has changed, as I have mentioned.
As you probably know, the Internet Society has got this Internet for everyone motto, but the motto under IPv6 should be Internet for everything, because we really are looking at a vision of everything around you, everything you can possibly think of, your sand shoes or your shoelaces, being IPv6 connected. And that really is a possibility. These things are technically feasible.
The trouble is there's not a hell of a lot of extra money in the user community either. So what we need to be able to do is to provide these services while still charging 20 bucks or 30 or $40 a month. And that really means a major shift in the cost and service models at ISPs where we really want devices and traffic to be two or three or more orders of magnitude bigger than today. And, therefore, because we don't have unlimited extra money, we want service costs to be cheaper by that same magnitude as well.
So if you are talk about connecting your iPod and your camera, Geoff Huston found a reference here to an Internet-connected coffee pot, which is apparently available in Japan. He wondered why he might want that, but then he thought, well, if he can monitor his mother's coffee pot, he knows she has got up successfully in the morning and she has made a cup of tea and that might be quite useful. Again, not to say anything about Geoff's mother, but it's a question of how much people will pay for this. It's not these facilities that people will pay through the nose for, but they are facilities which will used if they are available at the right cost. And there could be billions, possibly trillions of these sorts of applications around the Internet.
So in the silicon industry there was this shift from value to volume back in the last decade. And the argument here is that v6 represents a shift in the Internet industry from value to volume as well. Really reducing transmission costs by orders of magnitude, embracing trillions of devices, having a truly universal utility model of service provision that really leaves the Internet today for dead.
That's the vision. Getting there is still the challenge. And as I have think we see here, there are many, many brains starting to look at exactly this. But we have got to get quite real about where the resistance is, what it will take. And that's what we are all here for.
Thanks.

BARBARA ROSEMAN Thank you, Paul. That was an excellent overview.

SUZANNE WOOLF Okay. Terrific.
Good afternoon. This wasn't actually the order of presentations that we discussed earlier, but I think I like how it's working out, because I now get to wrap up with what I'm thinking of as an important step forward, and kind of a success story, as far as the deployment of IPv6 and the production Internet.
I'm at the ICANN meeting principally to represent the Root Server System Advisory Committee, but my employer, Internet Systems Consortium, operates one of the root name servers so I was asked to talk about IPv6 in the root.
So first, just a real brief overview of what's required to support -- what people mean when they are talking about supporting IPv6 in the DNS.
There's two principle parts. There is resource records for sharing DNS data that resolves to IPv6 addresses rather than IPv4 addresses. That's just another data type in the DNS, and it has to appear in a zone, but it's not special and it can be handed out over any connection, whether it's v4 or v6.
IPv6 transport is the other piece and has to do with the host being able to speak IPv6 to something that is listening to v6. There are still some assessments on areas, as my colleagues have said, on wide scale deployment for gating and translation and some of the other operational issues around operating with v6 and v4 together. But the way it works in the DNS is the name server will answer on the same interface the query came from, which means if you ask over IPv6, you will get an answer over IPv6.
The data you get back may include IPv4 addresses or IPv6 addresses or both.
So whatever is the right way to do it for the situation at hand is what you will get.
So with that said, I would like to go to the case study on our root name server. Just go over quickly why it matters, what we're doing and what the open issues have been.
The current status for IPv6 in F-root looks like this. IANA added quad A records, which are IPv6 address records, for the root name servers to the root zone, just, I believe, over a week ago. Barbara, I'm sure, has the date graven on her heart.

BARBARA ROSEMAN February 4.

SUZANNE WOOLF And five root server operators are initially providing service over IPv6. And so now the records are in the DNS and when you ask them to ask the root name server a question, you will get an answer.
For the first time, it's possible for a normally configured DNS client to ask for quad A records, to ask for IPv6 address records over IPv6 transport and get answers.
What this means is it's now possible for a complete DNS referral chain to be formed and used over IPv6 only.
Hardly anyone will do this at first. We expect that v4 and v6 will be used together for a very long time, as my colleagues have already talked about. But we will now be able to see where the gaps are in service deployment, looking towards v6. And eventually, native IPv6 will prevail.
So before we could do this, because it is the root and because great care must be taken as far as changing anything with root name service, a number of questions were considered and reviewed at significant length to make sure that getting a quad A record for a client that wasn't necessarily expecting it would do no harm.
When you are including v6 and v4 compatible records together in the same DNS answer, that changes some characteristics of the answer, principally how large it is.
There is technical detail documented on this in SSAC 18, which is a report produced jointly by the SSAC and the RSSAC documenting that we had studied these issues and felt it was appropriate to go ahead with adding quad A's for the root. For the operator, there is a number of concerns. And again, as a content provider of any kind, these are the issues that come up. Making sure your host can handle everything they are going to need to do. Connectivity for production service. The special-purpose connectivity needs you have for troubleshooting and management.
And, of course, making sure that security is not compromised by changing the service.
The bottom line is there is no negative impact on IPv4 service is acceptable.
We could not do this until we could make sure that IPv4 could not suffer in any way.
So the critical questions, once we are ready to move forward, for each operator who wanted to provide v6 service -- again, as a content provider. These are fairly standard -- are there routes to us over IPv6 transport? Do we have transit providers? Do we have ISPs who can deliver v6 packets to us? Are there routes back from us? Is basic routing connectivity in place? Can we get good quality transport so people can rely on getting timely answers from us? And in general, what do clients do for our application, for DNS, when perhaps an answer includes both As and quad As, v4 and v6 compatible answers, what do clients do? And this depends on the operating system and the application. The behavior can vary, and experience is still limited. So these are areas for some amount future study in detail.
In addition, many of the root name servers, including ours, use a technique we call Anycast as part of our operation T improves our ability to provide a high-quality service, but it does raise some additional concerns.
Just to go over how Anycast works really quickly, it's a way to make multi, widely distant hosts reachable at the same I.P. address. Same content. No matter which server you ask, you will get the same answer, but you will get an answer from the closest machine in an Anycast cluster.
What this adds is some very important things for us. It adds redundancy in the case of any failure anywhere in the system. It adds resistance against attack, particularly distributed denial of service attack.
But the price attached to that is some amount of additional complexity, including for troubleshooting.
So this provides a little bit of extra work we have to do to make v6 service work.
The way ISC provides Anycast, and everybody who does this does it slightly different, but what we do is we provide a tiered architecture. We have a couple of global nodes and we have many local nodes scattered around the world.
The global nodes are carrier class facilities, multiple transit providers, many peers. And the local nodes are at exchange points and major colos. They are optimized for more local service. They are operated under partnerships with ISPs and registries, industry, governments, anybody in an area that wants to be part of making their local Internet work better. And in fact, I have to mention our node in Chennai is operated in partnership with NIXI, so I wanted to acknowledge them.
The particulars of Anycast deployment for IPv6, we got a dedicated address block from ARIN, which is commonly used for infrastructure services. I believe all the Regional Internet Registries provide for address blocks for purposes like this, for infrastructure services.
We have six-transit to our global nodes, multiple providers. And these are the systems -- this is the presence that is globally available, that is visible and usable from anywhere in the Internet.
Local nodes are rolling out. The hosts we have provisioned everywhere are dual stack, free BSD operating system, which has, you know, implemented early the appropriate capabilities.
We're adding v6 peering as available. We have partners that are helping us provide service over IPv4. We are going to them and saying, "How about v6 also?" And in some places, we have discovered that inviting people to peer with us over IPv6 has been the first real incentive, the first service people were being asked to enable over v6 and is providing an incentive to them to expand their capabilities at collocation facilities and exchanges, which is one of the things which we were hoping to see.
We still have some upgrading and some improvements to do as far as administrative access and some of our management, but the production service, where we have rolled it out, we are very confident and very comfortable with it. And we are rolling out more as we can.
So here is roughly where we are today. Native v6 transit for global sites. 15 out of 38 local sites are offering v6. We are adding new ones as fast as we can.
One thing we are able to do at this point is we are logging complete query data, because traffic is starting small, as we expected. So we are keeping complete query data for research purposes. We'll be making summary data available in the future.
And we regard this as a historic opportunity to watch a major technology transition for the Internet.
So we're looking forward to seeing how things move ahead.
Thank you very much.
[ Applause ]

BARBARA ROSEMAN I would like to invite to you ask questions of the panelists. We'll be here for a couple more minutes. The session is due to end at 330.

IZUMI AIZU My name is Izumi Aizu, I am from the At-Large Advisory Committee. We have studied the working group on the IPv6, and we are writing the action plan.
And we'll make it available pretty soon.
We are thinking that instead of using transitional migration, I still quite agree with Steve that we almost decided to use coexistence.
So far I have been gathering many information from the different experts in this community as well as outside, like the Japanese government organized the panel study group since last year. Some of them are shared by the GAC meetings with simulations, very technical simulations which mostly match with what Steve said. Especially on the operation side, not the allocation side, may have a lot of challenges.
The question is as Steve said, and you said as well, but I would like to ask to you again back, is there any role for ICANN to play? Because I had a discussion two nights ago with one of the board members, and no, no, no, there is very little, almost no role to play.
In a strict sense, perhaps the mission of ICANN as defined is true to manage the policy, but not the operation. Not the service quality of the various kind.
But on the contrary, for the public perception, because we have been talking about a lot of v6, and some have been promoted, that as a users' component of ICANN, we feel we have to do a lot more coordination between the different players. The workshop we propose to host at the Paris meeting will be one such step, continue to be. (Saying name) was also a host organizing between now and others for the IGF workshop of IPv6 in Rio. So at that time we didn't have too much focus on operation, but we need to have some kind of circle of people from implementation, operation, maintenance, bug fixing and then allocation. I think for the larger public interest, it's all interrelated, so I would like to see a comment, if you could.

BARBARA ROSEMAN Anyone else?

RAIMUNDO BECA Raimundo Beca. I am also a board member, and I don't share the opinion of the other board members that the role of ICANN is very shortened.
My opinion is that ICANN has been able to sell to the world in the WSIS, in the IGF, that ICANN is able to manage the critical resources of the Internet.
Well, IPv6 and IPv4 are part of those critical resources and it's a big responsibility, and we are -- but having said that, I would like to ask a question of Steve.
You mentioned, Steve, before, you said that there was a very big difference between America and -- North America, me myself being from South America, and the African situation.
Could you sprain more the difference between?

STEVE CROCKER Thank you.
Thank you, Raimundo.
So that comment about Africa versus North America was not intended to say that there is necessarily a big difference, but to suggest that there possibly was a big difference.
And the reason for bringing that up is that the growth situations are very different. The amount of network connectivity in Africa, say, is far less and far less developed than there is in the U.S., to speak very parochially.
And so the transition processes and the evolution over the next five, ten, 15 years are likely to be quite different.
That was the -- Now, it's possible that it won't be that way, but that would be a reason why there could be extremely different outcomes in different regions. And I wasn't picking on Africa in particular, or North America in particular, and I wasn't trying to leave out Latin America. I was just trying to pick two exemplary regions.
And since she is standing right over there, I am going to blame Njeri, another board member, because I put that part into this talk after talking with her. So turn around and ask her the question, why Africa, and see what she says.

Njeri Rionge I think it's quite obvious based on the fact that we only have a 3% penetration in Africa that we are going to be facing a need, in my opinion. This is strictly my opinion as Njeri, to look for and actually use IPv6, on the one hand, and as we continue to also finish the allocation of IPv4, which already have been allocated. And primarily this conversation, as our thinking about it, is one where we are saying we want to engage the business constituencies from Africa so the decision-makers at the end are also involved in understanding exactly what it is that it is going to entail leapfrogging from IPv4 to IPv6 in terms of infrastructure capacity building, as well as skill set building, and as well as what kind of, if you like, equipment people will have to actually be focusing on making sure that they are buying IPv6-naked infrastructure today as opposed to waiting for tomorrow.

BARBARA ROSEMAN I think Thomas wanted to say something.

THOMAS NARTEN Yeah. I just wanted to -- -- hello?
Testing, testing.
I just wanted to respond to the particular question about what is ICANN's role in IPv6. And let me suggest having been involved in a number of these discussions that having -- arguing the point about whether ICANN has a small role or a large role misses the point. It's much more productive to talk about exactly what that role might be and talk specifics. Because I think if we had a discussion on those terms, there would probably be more agreement than disagreement.
I hope.

IZUMI AIZU Okay. Sorry.
My question is what is the role you perceive, Steve, as a part of ICANN, SSAC, to cope with the challenges? The same goes through to Thomas.
I am not arguing what role, large or small. ALAC would like to play a role to organize a workshop to listen to the many different players within ICANN's purview, perhaps.
We are having difficulty, in a way, to define what exactly they're thinking and the roles are in relation to the users' interest of the stability and predictability.

STEVE CROCKER Thank you.
So here's the way I see it. And I've tried to engage in this kind of discussion before, and there's sometimes a little bit of misunderstanding. So let me try to get the nuance on this right.
I'm concerned that when one asks, "How are things going to evolve? What is the road map for IPv6 coexistence and adoption?" the answers are not very clear.
And I think that that's a very uncomfortable, perhaps unacceptable, situation and, to me, speaks to a lack of leadership throughout the community.
Now, I don't view that it's ICANN's problem alone. I don't view that ICANN has the controls or the machinery or the charter to go fix it. But as one of the global participants, one of the visible and major participants in the Internet processes, I think that it is appropriate for ICANN, and now what does that mean ICANN? Does that mean the board or does that mean various components? Let me leave that a little vague. But I think it's appropriate for ICANN to seek to bring forth, in cooperation with others, some more coherent picture about IPv6 adoption and about transition issues.
It's okay if somebody else does it and ICANN says, "Oh, great, it's done." It's okay, on the other end of the extreme, for me, if somebody at ICANN sits down and says, "Here's the grand plan," and everybody else says, "Boy, that's really a great idea," everybody subscribes to it. I don't think either one of those extremes is going to be the way it plays out.
But I think ICANN should feel uncomfortable that it does not yet exist and should seek to have conversations and to stimulate conversations until such a reasonable plan emerges, and then it will become clear what everybody's supposed to do within that.
I don't see it as a way of grabbing for power. I don't see it as a matter of control. I see it as a way of trying to be somewhat orderly on behalf of the broad constituency, the broad Internet constituency, everybody, that there is a rollout plan of some sort.
That's sufficient. To get more into details, we then say, okay, who's going to call what meetings and who's going to come and what authorities? And for me, it's not really about that.

BARBARA ROSEMAN We're at the end of our time. And --

STEVE CROCKER And you're in my time?

BARBARA ROSEMAN And I'm into Steve Crocker's, into the SSAC meeting.
That you all very much for coming. This was a really good turnout and I think we had some very good presentations. And we'll have more discussions about V6 ongoing.
Thank you.
[ Applause ]


STEVE CROCKER So this is going to transform immediately into the SSAC public session. Everybody should leap out of their chairs and run for the hills.
[ Laughter ]