Transcript

Disclaimer

Due to the difficulties capturing a live speaker's words, it is possible this transcript may contain errors and mistranslations. APNIC accepts no liability for any event or action resulting from the transcripts.

Wednesday, 25 August 2010, 16:00-17:30 (UTC +10)

GAURAB RAJ UPADHAYA: I've slowed down as a habit, so I'll try to do this fairly slow. I'll talk about the signing of the root zone. My own experience, because I was part of the process when the key signing ceremony happened.

I wrote this slide for a very general audience, so I don't think that this audience needs to know what DNSSEC is. But primarily with DNSSEC, it signs the DNS data for the recipient can verify the integrity of the data. It doesn't really do anything. It just says that when you sign it, you can verify it against a data to know that the data is still correct. It has not been changed somewhere in the path. The Key Signing Key signs the Zone Signing Key, which then signs the actual zone, but there's a bunch of stuff there for the Key Signing Key that goes into the Zone Signing Key. The Zone Signing Key actually signs the real zone. And it's almost a 15-year-old protocol. Someone yesterday said that they're waiting for the deployment for RPKI, so this is what it is. In the last three years there where it was published, DNSSEC certainly got a lot of traction.

Again, the significance of the Root Signing Key. Why it is so important that we're talking about it. The DNS Rootn Servers lie at the top of the DNS hierarchy. So it is probably the most natural trust anchor where you can put the trust anchor for the DNS hierarchy security. And I wrote a disclaimer there that not all people agree about that, but that is not for me to discuss here. As a path for deployment for DNSSEC more widely, because a lot of times, there are zones signed using DNSSEC, and when it came to users, they said, like, but we don't have a hierarchy, and we can't maintain a list of everything that's signed and then keep updating it. But when the root zone is signed, that is no longer there, the hierarchy is there. So that's why the signing of the root zone got a lot of press and in the office and community, we talked quite a bit about it.

The signing operations, I won't really talk about it. There was an excellent tutorial yesterday by Richard Lamb. And other colleagues on the DNSSEC tutorial so that probably signed quite a bit. But the Key Signing Key ceremony it itself is well documented in the DNSSEC space. The root DNS page also has a whole lot of updates on what happened at each stage where the procedures followed and most of the things I talk about here.

When the root key signing was designed, they separated it out into two parts. There's a Key Signing Key and a Zone Signing Key. ICANN does the Key Signing Key. They actually don't have the DNS data. So ICANN does the KSK. VeriSign actually signs the DNS zone. And then to verify that everything is OK and ICANN is not really bluffing you off, there were 14 community, Trusted Community Representatives who are people with good DNS knowledge and are well known in the community to be there as TCRs. So June 16, 2010, the first key signing ceremony happened in Culpeper, Virginia, about 60km out of Washington DC. When I told friends in DC that I was going to Culpeper, they were like, "Good luck, there's nothing for miles and miles," and even the asphalt, it is a different colour, because it is all coal country out there. We had the HSM, that was done for the first time. There are seven cryptofficers. I happen to be one of them. They were incorporated, which means that we had to take an oath saying that we will not destroy the Internet, or whatever it was. There were also seven recovery key shareholders, also selected from the community. So in case the HSM is destroyed or the key is lost, or we need to recover the key, the smart card held by the recovery key shareholders would be required to have that. At least three of them to re-enter the key. And then we sat there. It was a seven-hour long ceremony. Generate the KSK. Once the key signing request was generated, we received the request for Zone Signing Key from VeriSign, and then that was accepted and then the Key Signing Key was used to generate the ZSK that VeriSign took with them to sign the actual DNS zone. So we considered that as a major milestone, because it was done for the first time.

The second key signing ceremony happened on the 12th of July somewhere near Los Angeles Airport. And it was a similar process as before. The only difference was that a new key was not generated, but the key generated in Culpeper was transferred over with the secure HSM to Los Angeles, because it was being done for the first time. Now, the two crypto hardware was there in the secure site. So that was done. And again, in Los Angeles, seven more TCRs, officers were incorporated. I didn't bring my key, but we've actually got physical keys to the Internet now. So after all of this happened, on July 12th, the root servers starting signing the signed DNS root zone.

So this is what it looked like. You really can't see that, but this was the KSK that was used to sign the ZSK, and this was the first thing generated, and I actually have a signed copy of this from all of the TCRs. And that's just for records.

Some picture there. That is the picture from when the ZSK was signed. The guy with the suit on the left-hand corner there actually has a gun with him, to make sure that we didn't do any funny business in there. And then the safe on the left-hand side there, you see a whole case with two really big safes. I donít know what the legal term is, but it is label category 8 safes that you can't really break with a bomb or something, and we have keys to the safe. But the smart cards are stored there. And a bunch of people, this was live casted to another bunch of people outside of the room, but to get in and out of the room was a bit complicated. We received the key in a tamper proof evidence bag, and I can't tell you where the keys are now. The ceremony administrator did the stuff.

And after it was all done, we had a group photo on the lobby of the facility. More info on the website, and I really just wanted to share my experience as a TCR, because I was one of the three TCRs from the AP region, and unfortunately, the others are not here. And it was a well executed ceremony. Richard Lamb was there. He was very instrumental in all of that, so if there's more to ask, he's probably the right person to ask questions. But if you have any questions, can you go now. You have one minute and 43 seconds!

JONNY MARTIN: Any questions from anyone?

GAURAB RAJ UPADHAYA: Comments, questions?

JONNY MARTIN: Yes, Brajesh?

BRAJESH JAIN: How many DNS process for the DNSSEC process?

GAURAB RAJ UPADHAYA: I think .org is signed. .se was the first one to be signed. .pr got signed, but they messed up the zone signing rollover thing, so they're no longer signed. Also, I think at least five or six already signed and .com and .net will be signed in October or November. I need to look through the emails that are coming through. But yeah, so I think it is now, people can claim that I can sign my zone and you can really update unless you go to the root zone. So I think it is a process now where most people start signing it. But as of now, the main zones are .org, .se. They would probably come to mind immediately. .cs got signed. .jp is fairly advanced in the process of signing. And .nz is in a very, very advanced stage of signing their zone as well.

BRAJESH JAIN: (Inaudible)

GAURAB RAJ UPADHAYA: I think now you don't have an excuse to not sign the zone, because it is already in the root zone.

 

JONNY MARTIN: OK, perfect, ten minutes. Bang on, if I drag this out. OK, so next up, we have George Michaelson talking about DNSSEC and packet sizes.

GEORGE MICHAELSON: I'm actually thinking about not saying anything and leaving that there for ten minutes!

So you may know that APNIC started its deployment of DNSSEC earlier in the year in the March/April window. It went remarkably straight forwardly. Nicely engineered and a lot of planning when in. We staged for deployment to actually track things, and this is to give people just a bit of information about it.

As background, 40% of the reverse address space is NX domain. That means that there is no delegation, so 40% of every question we get asked, we have to say, "I'm sorry, there is no answer." Interestingly, the DO bit, the bit that says, do you do DNSSEC? Is also somewhere around 40% to 50%. So that means that around 40% or 50% of the time when people say to us, there's this domain. And we say no. We're additionally saying, if you want DNSSEC, we can tell you no, with authority.

Well, it turns out that that has implications. If you look here, this is the reply sizes before DNSSEC. This is DSC, the graphing tool, by the way, that comes from the measurement factory, the DNS  ;measurement factory guys. It's very nice code. Our code 3 - the green one. That's the bad code. And our code 0, the red one, that's the good code. I've asked them to change the colour codes. They said they needed money.

LAUGHTER

But the basic point is that the packets are within the first approximation. Somewhere between 100 to 140 bytes without DNSSEC to say yes, or to say no. And that's kind of sweet, it means that it doesn't really cost us much more to give the answer. So, after DNSSEC, because the DO bit is set, we have to send authenticated denial. I'm probably using the wrong words here. A DNSSEC person will correct me, but we have to add in DS and RR SIG data to say, that isn't there. I'm the parent zone, here's the signing information. And that's extra pay load. And this is what the graph looks like after DNSSEC, and you'll see that we have the two spikes around 100 and 150, but we now also have a surge of traffic around 300 to 400 bytes, which is the good answer, and there's a little trickle of green there hiding underneath, which is also bad answers around that size. And we have a large surge of traffic around the 800 byte size.

So, that 40 byte difference is still there, but some responses have now gone up to 300 to 400 bytes and troubled in size. And some of the NX domains have gone up to 800 bytes, gone up five times. The outcome is that it actually cost us two to three times as much bandwidth outbound for exactly the same query rate. No change. Oh, and there's no ramp-up. Remember, 40% of the clients querying have DO bit, so the minute we said we're doing DNSSEC, we had to do this. You have to think about this. You've got to think about the fact that if you're serving information and you turn on DNSSEC and a lot of your traffic is potentially going to be negative answers, and you have people who are enabling DNSSEC, it costs you more. So, really, the only message here is that you just want to get some link monitoring in place before you do one of these deployments. You want to make sure that you've got the head room. You want to look at your NX domain frequency. You want to look at server config. It turned out we had optional data we were including in the additional section, and if we remove that, we're actually able to get back about 20% of the bandwidth, I believe, and there's some links to a couple of tools that we use to do this.

Six minutes and counting!

JONNY MARTIN: I think this is the time that we ask for questions now, if anyone has them. Otherwise we have six minutes of George!

GEORGE MICHAELSON: How much are you going to pay me!

JONNY MARTIN: The presentations will all be up on the website later today or early tomorrow.

GEORGE MICHAELSON: I might add by the way, that I think this community has probably more DNSSEC clue than many I've been in. There's any number of people scattered around this room that have amazing information about getting this technology working. Rich Lamb, for instance, wealth of experience in making this beast fly. So this is a good place to be if you want to talk about it with your peers. Have you got the details?

JONNY MARTIN: All right, well we've got URLs being transcribed. Has anyone else got any questions? Let's move on.

GEORGE MICHAELSON: Thanks, guys.

APPLAUSE

JONNY MARTIN: Next, we have Ichiro Mizukoshi, who is going to talk about v6 at NTT.

ICHIRO MIZUKOSHI: Hello, I'm Ichiro Mizukoshi. I come from Japan and I'm working for NTT East. It's a Japanese local carrier, so our service area is the eastern part of Japan. And we, NTT East, have been providing access service called FLET's. It's a PPPoE access to provide the PPPoE to the customer. And these PPPoE organizations, I would get the point of going to the Internet. So this line is the demarcation point for our services. It means, we, NTT, East and West, provide only the access line, not to the Internet connections. Internet connections are done by the ISP. The reason is fairly simple; we provided access-only lines. We have the telcos who are highly regulated by the Government, so we only provide the access line to the customers and the ISP provides the Internet connection.

Here's a bit of history. In thef year 2000, we started the ISDN with 64 kbps. And in December, the ADSL and fiber to the home. Two years ago, we have studied the NGN. It's our scale from March 2010. Fibre to the home customers, 7.5 million. So it is quite huge. Only half of Japan. And as I say, in 2008, we have studied NGN services. NGN, it 's a kind of... so technically, NGN consists of three. IPv6, SIP, and the QoS. It means that it is designed for the PSDN lines.

Our brand name is now FLET NEXT. it is primarily designed for the PSDN line, so we have used IPv6, but it is our inter cross network. So in IPv6, we use Internet Protocol version 6. So we don't connect it to the Internet itself. But, as we know, we had to connect to the, we had to prepare the IPv6 connectivity to the whole of the world before exhaustion. So we had two options. One for v6 on PPPoE. The other one is Quasi Native. v6 on PPPoE. Quite similar to IPv4, just replace the v4 with the IPv6. But the NGN, as I said, our NGN, instead of using IPv6 in our internal services, so connecting to the Internet using global v6 addresses, it makes some problems at the home. So to escape it, we prepared the IPv6 NAT to the home gateway. It's one option for v6 on PPPoE. The other one is Quasi Native. It's a strange name. Someone from the PPPoE said that Native is too positive a word, so I had to say Quasi Native. So we use at the Quasi Native, we use global v6 addresses assigned to the customer, and these addresses are the same as the internal services. But if they use or provide addresses, the address is going into the gateway and that dispatches it by the source address. So people can choose the source address from the ISP. This method, this option has a weak point, because these addresses are limited to now only three blocks. It's a limitation for our system-wide program. We wanted to expand it some day. Anyway. So this is the schedule. The Government regulators asked v6 for the access line services are prepared before the v6 co-exhaustion. So in April 2011, next April, v6 on PPPoE, it will be started. And soon, the next one, Quasi Native, will be started. I hope that this service will solve the problems to deploy IPv6 in Japan. That's all.

JONNY MARTIN: All right. Thank you very much. Any questions at all? OK, thank you very much.

APPLAUSE

So next up, we have BGP route origin validation from Mark Dranse.

MARK DRANSE: Hello. OK, BGP origin route validation. I spoke earlier about RIPE labs, so I've taken this from there, which I think will be interesting. The routing infrastructure is vulnerable to attacks. More specific ones like we saw with Pakistan Telecom and YouTube, and there's just a little image there showing the routing switch when YouTube tried to fix the problem that was created. There are other vulnerabilities. You can announce someone else's prefix on the shortest AS path wins in BGP. So in this example. Two people announcing the same prefix. AS 1 at the end is going to see the announcement from AS 7 rather than from AS 5. Depending on the global topology and you're peering policies and who you're closest to and not, will depend how effective this sort of attack will be. Some of them will work and some of them won't.

So, at the NCC, we run this thing called the Routing Information Service. We collect BGP data. We've done it for ten years and we have it all in a database somewhere. There's 15 remote route collectors around the planet and 600 peers and ten years of data. You can access that at the URL at the bottom there.

So to analyse this specific routing potential attack, we looked at the data from here and looked at it.

So methodology, take the RIS data for all full table peers and look and see how effective it is to hijack somebody else's routes. So, to estimate how often bogus routes are preferred, we assume that we ignore ROAs. We take every single AS that we see, which is 35,000, and we assume each of them to be both attacker and targets. So that's 35,000 squared combinations. And in this situation, when somebody announces a prefix which belongs to somebody else, that would be seen by the wrong... sorry, from the wrong origin in the 34.2% of cases. That's plotted on the graph here. You can see it in the blue. If you look along the bottom, here, approximately 30% of ASes would be able to hijack 40% of routes, for example. As you get towards the top left-hand corner, there's obviously a small number of ASes which would be almost 100% successful, which depends on how well connected they are to other parts of the Internet.

So to mitigate against this, you can use RPKI. To certify Internet number resources and you can inject this into your routing policy creation. RPKI supports Origin Validation. It checks if an AS is allowed to announce a specific prefix. But this can be attacked by spoofing, by prepending, by spoofed origin prepending. So basically, you pretend that you're originating on behalf of the legitimate AS. So we looked again at this data to see how successful this would be. And the credit here is to David Murray, who is an intern in my group back at Information Services in Amsterdam.

So, the attack itself. You take the valid AS and you prepend the valid origin to a fraudulent route. For example here, AS 1 is attempting to hijack a prefix from AS 2. He announces that prefix with AS 2 as a spoofed origin and transits it through the AS 1 network into the Internet. So what we wanted to look at is how many of our RIS peers would see that invalid route and believe it.

So again, we crunched all the numbers and came up with a different number. So when, we take all of the RIS data and assume the same situation as before and the number now goes down from 34% to 13.6%. The variation in success there is actually between 7% and 22% depend on the actual originating AS. We stick that on a graph like this, and you see the mean hijack success per peer. In blue, without the prepending, and in red, with the prepending. You can see that it actually has quite a dramatic effect now that the AS paths are actually one longer. We still have to the top left of the graph, though, a small number of ASes, something in the region of 2% to 3% who are hyper ASes. Who are very capable of successfully hijacking other people's prefixes.

Susceptibility per peer. What's on this graph here is actually each column is one of the peers that we get a full table from. And you can see how successful each of these people would be. So how susceptible they would be to the attack. On the very far left, I'm not actually going to name who these people are, for fairly obvious reasons. On the far left, there's a couple of peers which are low. These are people who operate large global anycast networks and the people on the right are high susceptibility and these are people that only have one transit, maybe. They're not very well connected. So the susceptibility to this depends on how well or not connected you are.

Just some observations on this, then. All of this assumes that there would be 100% route origin validation in the future, but of course, in a real deployment situation, that would probably be less. It assumes that within BGP, the shortest path always wins, but that's not necessarily the case. There's other factors at play and people configure things how they want and we donít know. The data here is drawn from a limited data set. There's just 82 tables. If Randy was in the room, he would probably be screaming and shouting at me about now. So it is representative, but not a comprehensive view of the planet. As I mentioned, there's a significant drop in success with the longer path, but apparently, this can be solved with path validation, which is something that's defined somewhere, but not very well used. If you want to see the full article on this there's a link there to labs.ripe.net. Thank you.

JONNY MARTIN: Questions, anyone? Could you speak into the microphone, if possible?

SPEAKER FROM THE FLOOR: (Inaudible)

MARK DRANSE: No, we don't know that. We don't measure that. This is just to clarify, this is entirely theoretical. We don't look for attacks and try to measure them, because it is actually very hard to detect what an attack is when someone starts announcing someone else's space. It could be quite legitimate and we just don't know that. So I can't answer that question. We don't know.

SPEAKER FROM THE FLOOR: You may have already answered my question. I wanted to ask whether the trend is going down or we're seeing the same number of attacks?

MARK DRANSE: Sorry, could you repeat the question?

SPEAKER FROM THE FLOOR: The attacks, are they going down with time? Is it going up?

MARK DRANSE: Again, I couldn't say. This is a snapshot from one point in time. I suppose we could go back in time, if you're interested in seeing that, then go along to labs.ripe.net and ask the question. And if people with interested, we can do that and look back a year ago or two years ago or three years ago. How much time have we got? I imagine from some of the presentations that Geoff has done in the past about how BGP and routing is developing, I would expect that it would be changing and that this is probably decreasing over time. But I'm not going to put any money on that.

SPEAKER FROM THE FLOOR: And is this for IPv4?

MARK DRANSE: This is for everything. Every single prefix that we get in the full table, v4 and v6. Thank you.

TERRY MANDERSON: Quick question. Have you considered looking at the first. So let's assume that the origin, let's assume that the origin and the adjacent AS are the same. What does that bring the percentage down to?

MARK DRANSE: No, we've not looked at that. But again, if we're to do this again, if you're interested in that, we can look at that too.

JONNY MARTIN: OK, and last question.

SPEAKER FROM THE FLOOR: (Inaudible)

MARK DRANSE: It's all combined.

SPEAKER FROM THE FLOOR: OK, because I was just thinking that the v6 connectivity is vastly greater than v4. So there is probably a different profile, probably see some big differences if you do them independently?

MARK DRANSE: That's a good point there. The numbers here are completely average across the entire AS, so you're right, there would be some effect there on the v4 and the v6 pulling it one or another.

JONNY MARTIN: OK, thank you, Mark.

OK, next up we have Brajesh talking about content delivery from the Indian perspective.

BRAJESH JAIN: Good afternoon, everybody. I will be taking it from a different angle, from content delivery from the edge from the perspective of India.

Just to give a brief introduction, India is a vast country with various cultures, languages and regions. And Internet is expected to grow from present 10 million approximate broadband connections to 100 million in the next two to three years. Broadband in India still continues to be 256 kilobits and there is already debate going on about whether this should go up, especially with the video. Whilst the connections grow, a total download is expected to grow many fold because the definition now is that the subscribers will grow ten-fold. Now, such growth puts enormous need for domestic and international carriage. Content not being available nearby would reduce transport needs and there will be a focus on local needs.

Just to tell you the present situation in India. We are defining traffic within the region. There are four regions, presently. There is approximately 70% of content is coming from outside of India. 20% from other regions of India, for example, north to south, and vice versa. And 10% within the region. Latency is to be taken as measure of service within the region and for the expected growth of Internet capacity, a large capacity is required to carry traffic from region to region, as well as for the international capacity. And we have challenges on both sides.

Now, the tariff is dependant upon the number of bytes or usage time, and of course, on the aggregation, all of that depends.

India has a need for local content, and along with the text, we do delivery, and we hope that if selected, it will be possible. And scalability is important in the content system. Once accepted, then we need to scale. And also, as the video comes in, there's a focus on quality of service and quality of experience. Quality of experience, where we say that all of the acceptability of service as perceived by the user and not as decided by the service provider.

Now in the content once again, perception is very important, so we expect low latency and bandwidth and better reliability in all of these factors. If the content is served from the edge, it becomes very important. Now, service to the user, what we are trying to see is whether we can define some of the classes. If we just define two classes, class A. End-to-end latency of 100 msec, and class almost at 400 msec. So this 100 msec will tell us how much traffic is coming from the edge and how much is coming from there. So in the present context of today, there is a focus, if we focus on 100 msec, we can say that the content is coming from the edge.

I will just give you one example of demonstrating a benefit of low latency. This is, of course, if we look at the file size. An MP3 song of five minutes is approximately 10 mega bytes. 1.5 hour duration video is approximately 1100 megabytes. And the same in HD there could bein 5 gigabytes. In the standard definition of latency, we take 400 msec in the development, I know that there are various measures in the user and downloading which can result to multiple sessions. So for 5,000 MB file, download time would be 11 hours. And with the consistency and finding the consistency of quality in 11 hours is very, very difficult. And if the same latency comes down to 40 msec, this will reduce it to 66 minutes for the HD file and 14 or 15 for an MPEG file.

So this shows that the way that the network is at the moment. Expecting the network to be consistent for a period of 11 hours or so, it is quite a bit of a challenge.

The focus here is to draw attention to all Internet ecosystem managers that content needs to be brought closer for Internet to be more relevant in India for a large part of the society. And one more thing is that as the content is being served, from the local, it is more likely to be relevant to the local needs. And another thing that we just want to add in the context of IPv6, the content has to be reachable to newer Internet customers as well. So there is the likely challenge of IPv4 address availability. Not only likely, but there is a challenge already, hence, all content needs to be able to content to customers via IPv4 and v6. And presently, we find that a lot of content is only v4 enabled.

That's all, thank you.

JONNY MARTIN: Right, have we got any questions for Brajesh?

SPEAKER FROM THE FLOOR: I'm from Indonesia. I want to confirm is that is it true that the latency makes it slower, like the slow latency. Because in my opinion, if you have 100 megs of speed, you can have 100 megs of speed, it doesn't matter of the latency. Thank you.

BRAJESH JAIN: I will not be able to just answer. I think that experts like Philip and others. But I do believe that when me measure it, the latency has an effect on download speed. As I mentioned, I'm not at all saying that with the special measure from the PC, by creating multiple windows, that time can be compressed. But in the gross time that it does take, it does take the time.

OWEN DELONG: Hurricane Electric. Windows is a particularly pathological case. It's more susceptible than any other operating system to latency. And that's because it does a piss poor job of dynamicly adjusting its window size in TCP.

BRAJESH JAIN: No, I agree with you, but in the Indian situation, as of now, a lot of machines continue to remain Windows-based, and I do not know in the future what will be the trend there. Thank you.

JONNY MARTIN: OK, any further questions? In that case, thank you very much, Brajesh.

BRAJESH JAIN: Thank you.

JONNY MARTIN: OK, and lastly, we have Xi Ling talking about IVI. It's all very well behaved. Nobody was talking there. Are there any questions on this part of the program at all? OK. We're just about there.

XI LING : OK, good afternoon. I'm Xi Ling, actually. OK. This morning, we are talking about depletion of the IPv4 address. That's really a very serious problem, and I'm from CERNET, and we've been working on IPv6 for more than ten years.

OK, we started the CERNET project in 1994, and in 1998, actually, we realized that we needed IPv6. That's 12 years ago, because there are many students in China, and there is not enough IPv4 addresses for them, so we connected to 6Bone. And later, in 2001, actually, we ran dual stack. However, by that time, actually, only IPv6 traffic is there, the ping traffic. Then we tried to do something else. So in 2004, we started CERNET2 project, and CERNET2 is actually a IPv6-only network. It is not dual stack. And because of CERNET2, which is a pure IPv6 network, so, actually, we ran the opposite way. IPv4 over IPv6. And actually, that turned into IETF software working group, part of that.

However, we realized, whatever dual stack, alternatively v4 over v6, or v6 over v4, cannot really help the transition, so finally, we realized that translation was the way to go. However, it is very difficult. Currently we're working in the IETF Behave.

I can give you another view. Like we have CERNET IPv4 and CERNET2 IPv6. CERNET2 is a v6 network. And we have servers and clients. And our promotion strategy is for CERNET IPv4, actually it's an overloaded network, a congested network. And CERNET 2, IPv6, is a light load.

CERNET, actually, it's not free. The user has to pay for that. And CERNET2 is a free network. However, if the user wants to have a high-performance free network, the user needs to port their application from v4 to v6. Frankly speaking, we achieved partial success, because currently, IPv6 traffic in CERNET2 is about 10% compared with IPv4. However, we always think - can we shut down IPv4 CERNET? No way, right. Because people still want to access the global IPv4 Internet. It's not in our hand. So finally, we realized that we need to make IPv6-only host to communicate with both IPv4 Internet as well as IPv6 Internet. And we built something called Specific Prefix translation called IVI. IV means 4 VI means 6, so IVI means translation between v4 and v6. And I will not go into details, because in the previous APNIC meetings, I gave two presentations. One in APNIC 26, and another in APNIC 28. You can download my presentation ideas. And today, I just want to update the progress.

So basically, we have two solutions. One we call 1:1 IVI. Which means that we map IPv4 into IPv6 and we use that in IPv6. Another is actually port sharing multiplexing. So one public IPv4 address can support several IPv6 hosts. So we call it 1:N. And the theme actually means double IVI. So we can either use it in IPv6, or translate back to IPv4. So 1:1 IVI is stateless in the core. And the 1:N dIVI is stateless in the core, partial state in the edge, because we needed the port mapping, and it can save IPv4 addresses. That's really what we want. And no need for application layer gateways, because we translate back. Actually, dIVI is similar to tunelling, because if we do Stateless translation twice, that is equivalent to tunnelling with header compression. And in the IETF, it is documented and we will have about four RFCs published soon.

So, our our proposal actually is for ICP, content providers. It can run a single stack IPv6 network and servers. However, through a Stateless 1:1 IVI. Both can access the content, so you will not lost your customer. And for the ISP, the ISP can have a 1:N IVI in the core Stateless. And for the CPE to maintain a state and do some multiplexing, then actually, multiple IPv6 hosts or dual stack hosts can share a single IPv4 public address. So, actually, the exciting thing is that we are doing two trials. One trial is CNGI-CERNET2. We actually got funding from the Government and we are deploying IVI for 100 campus networks. But more exciting thing is actually China SP. But actually, it's China Telecom. And they are going to try double IVI for ADSL users because they want service continuity. They want to support existing applications. And they want transit to IPv6. So this is the CNGI-CERNET2 trial. You can see that we actually borrowed a part of the public IPv4 address, map it to IPv6 and the pure IPv6 servers or clients will use that IPv6 address. However, that IPv6 address has a 1:1 relationship to IPv4. So access both in IPv4 and in v6. And for China Telecom, actually, they have a dual stack core. That's not difficult. However, because they do not have enough public IPv4 addresses, they built the IPv6-only Metropolitan network, and we put the core translator between IPv4 IPv6 dual stack core network and the IPv6-only metropolitan networks and they were assigned the special IPv6 addresses to the end user and the CPE was translated back. So there are advantages for the ISP actually is Stateless in the core. You do not need to maintain CGN network in the core. And the v6-only stack accesses the network. So China Telecom can save. And to use the public IPv4 address effectively. That's very important to them, because China Telecom told us in the next three years, they were about 100 million public IPv4 addresses, and they would not get that. However, if we do 1:1 double IVI, actually, they can re-use their IPv4 and meet their demands for increasing.

They will have about 20 million ADSL user increase every year. And for users, that's actually very interesting. So the users can get a factional IPv4 address. In their case, it is actually about one over 128. And so they can get 512 concurrent sessions. No need for DNS 64 and no need for application layer gateways. That is very important for banking or those kind of applications in China because there's always clients there. And at the same time, actually, users can get a /64 IPv6 subnet. So they can have fully functional 64 concurrent sessions, so that encourages them from v4 to v6. So maybe in the trial and maybe next year, we can report the test results. So thank you very much.

JONNY MARTIN: Do we have any questions at all? OK, we can continue the clap.

APPLAUSE

OK, so that takes us to the end of our lightning talk session. Hopefully you found that enjoyable and a little bit informative. If not, educational, and maybe it's inspired a few of you to think about a lightning talk for the future and some of the research or just measurement and analysis you're doing on the networks. So we finished a wee bit early which gives you a bit of a break before the membership BoF which starts in this room at 5:30. So thank you very much.

^ Top    < Home