APNIC 22
IPv6 Technical SIG
Thursday 7 September 2006
16:00 - 17:30


KAZU YAMAMOTO: Good afternoon, everybody. This is IPv6 Technical SIG. It's now four o'clock, so let's get started.

I am Kazu Yamamoto, IIJ. I'm one of IPv6 Technical SIG chairs and he is Mr Fujisaki, co-chair of this SIG.

Well, we have one slot. This is 90 minutes. And we have six presentations. Well, the presentation on this SIG should be all informational, no proposals at all, OK? And I believe there is no housekeeping information from APNIC. So let's get started.

Let me call first speaker.

Sorry - this is today's agenda and, again, we have six informational presentations.

So let me call first speaker. First speaker is George Kuo, APNIC. And his presentation title is APNIC IPv6 status report. George?

GEORGE KUO: Can everyone hear me?

OK. Good afternoon. I'm George Kuo from APNIC. I'm just giving a quick update on IPv6 and also this time I am going to present the survey result on IPv6 deployment that we conducted a few weeks ago.

OK. So this is just an overview, as I've mentioned in my presentation.

As of 15th of August, there have been 1,057 allocation made by all the RIRs and out of these, 259 allocations are made by APNIC.

Now this is the distribution of number of allocations made by APNIC from 1999. As you can see, up to August this year, APNIC has made 28 allocations?

Now, in the last two or three years, because of the policy change, APNIC have made a few large allocations than the minimum allocation, /32, and this is the distribution of the prefix and there are 17 in total larger than /32 allocation.

OK, this is the allocation by economy. You can see how many allocations have been made to each of those economies listed here.

A slightly different view from the previous graph - this one shows the economies which first received the IPv6 by year. So you can see in 1999, Japan, Australia, Singapore and Korea were the four economies which received IPv6 allocations in that year. So so far there are 18 economies with IPv6 allocations, and the most recent one is Bangladesh this year.

IX assignments. Nothing much has changed since the last update except an additional one to China.

OK. This is the prefix register in Whois database. With the policy change in the near future, you might see a different prefix registered in the database.

The next one is the prefix that's visible in the routing table. So we have 405 /32s announced.

OK, next I'm going to just report on the survey result of IPv6 deployment that we did. Basically, the survey was sent out to the members or networks with IPv6 allocation longer than two years so they were a total of 121 surveys sent out. 43% responded. We asked them if they have deployed a v6 network. 35% are using IPv6 whereas 45% said it would be at least 12 months before they would deploy their IPv6 network.

We did a similar survey in 2002. We asked them the type of the network and this is the comparison.

We also asked them to list equipment they're using. And the ones that are underlined were mentioned in the 2002 survey.

Followed by that, we asked them the difficulties they faced. This is what they mentioned in the 2002 survey. This survey - I've actually listed this according to the number of responses received. You can see on top a lot of people mention lack of demand, lack of software and so on.

Alright. These are the services that were mentioned in the survey that they are providing and the number next to it is just the number of respondents that claimed they are providing these services.

And finally, interesting question - we asked them to estimate, based on their existing requirement, or usage of IP address space and to project how soon would they be coming back for more or how soon would they be reaching the 0.8 ratio. 57% say they don't know, they have no idea, they don't know whether this is going to happen. 1% mentioned it would be at least two years or longer.

And that's it for my presentation. If you'd like more information, you can check out the URL s listed there. And I would also like to thank the NIRs for their help in distributing the survey and collecting the results. Thank you.

Any questions?

No?

TOMOHIRO FUJISAKI: Excuse me. Can I ask one question? I'm Tomohiro Fujisaki from NTT. Thank you very much for your interesting report. The survey for the APNIC members?

GEORGE KUO: Yes. We selected the network that already receive the allocation for longer than two years and we also asked NIRs to send out a survey to their members who have the address for longer than two years. So it's including the members and NIRs' members.

TOMOHIRO FUJISAKI: Thank you.

GEORGE KUO: Thanks.

KAZU YAMAMOTO: Any other questions?

OK. Thank you, George.

Next speak is Geoff Huston, APNIC. His presentation title is the phasing out of the 6Bone.

GEOFF HUSTON: Thank you. I'm Geoff Huston. I'm with APNIC.

This is a very quick presentation. It's based on some observations of the IPv6 BGP network and in particular looking at the period around the 6th of June this year, where the 6Bone, which some of you might recall is the prefix 3FFE, which was one of the early deployments and experimental deployment of IPv6, the 6th of June this year was the time at which those routes were meant to have disappeared from the IPv6 network.

So I had a quick look over the data that we have of IPv6 and there are a number of events here on the routing table size of which the v6 6Bone removal is but one.

This graph shows the number of entries in the routing table from when we first started measuring it, which is in early 2003. At that point, there were 400 entries in the routing table. It grew to a peak of just under 900 entries at the start of this year and currently, a few weeks ago, it was just a little over 700.

There are three major anomalies, actually. And one of them is the 6Bone removal. But prior to that, there was leakage of more specifics coming out of IXP allocations, /48s, most of which, I think, came from this region, actually, and that was in late 2004. Early this year, there was a routing anomaly where a number of routes were not being correctly removed, ghost routes. And around 150 routes disappeared from the table in early 2006 when the ghost routing condition was reset. And, as you see there, the last anomaly, a fall of around 70 routes, we can attribute to the 6Bone removal.

Looking again at the same period, 2003 until now, this is actually the number of routes of 6Bone addresses. 6Bone peaked, actually, in 2003, early 2003, with 160 players and the number of entries in 3FFE gradually declined over the years until just before the 6th of June, where the remaining 0 turned themselves off with a few exceptions.

So here's a zoom in to the week or the weeks around the 6/6/06. We had 72 entries just before the 6th. We had 21 entries just after the 6th and those remaining 20, around 12 of them, disappeared over the days thereafter. So 6Bone largely went away.

The non-6Bone network was a bit weird because, in theory, it shouldn't have made any difference, unless the 6Bone networks were being used tour transit, which they weren't. But just after the large 6Bone removal, we saw an oscillation of around six networks over around a weekend or more, around four days of relatively severe route oscillation. As you can see it there circled - something in the network in v6 was misbehaving badly. I'll tell awe bit more later but that was about the only anomaly we noticed with the removal.

I was a bit worried that that anomaly was localised so I went to the routeviews IPv6 routing table snapshots and saw precisely the same situation - that around that period, looking at the total IPv6 network, there was a period of about four days that saw a relatively large period of route oscillation.

This is a combined view of 6Bone, non-6Bone and everything else. The red line at the top is the number of routes in IPv6. The green the green line is the number of non-6Bone routes. The blue line at the bottom is the 6Bone. Overall the 6Bone disappeared relatively cleanly.

I also looked at the number of updates appearing per second over that period. Unfortunately, my collection engines decided to die on the 10th of June and I only noticed it on the 14th of June, so there is some missing data. But of the period from the 6th of June to the 9th of June, the number of updates per second in v6 was between 10 and 100 updates per second each day. There was no great anomaly. The thing just disappeared relatively cleanly.

But not quite everyone has turned it off. Across July there were 10 networks being announced that disappeared slowly to 8 to 7 to 6 and then to 4. And there are still four folk advertising prefixes in the 6Bone. Who are these naughty people?

These naughty people are Mr Manning, Mr Manning, Mr Brinksma and - I assume it's a Mr - Zhang. If you see your name there, that's your prefix. Get rid of it please. I actually have no idea why these bogons continue to be announced. I guess many of them don't put in the extra filters. So what we see is an unfiltered view of the network and these 6Bone remnants are still there. These are now people who are indistinguishable from people routing bogons. They should not be doing it.

So my observations - there were no visible effects on the network. The 6Bone went out cleanly. The connectivity for the 6Bone appeared to be phased out for normal addresses well in advance of 6/6/06.

In the week, we saw a routing competition between AS 20071 which is TBone and AS 109 which is the Cisco transit I believe and there was some oscillation of around eight prefixes that were non-6Bone that most of us saw there for about four days. Not a big issue. So no operational instabilities on the phase-out. It happened cleanly. IANA has done the updates. Thank you, IANA. 6Bones are now no longer in the IANA v6 global Unicast Address Assignment registry and sadly there are four people who still don't recognise that the current date is well beyond the 6th of June 2006.

Thank you.

Any questions?

KAZU YAMAMOTO: So can we conclude that the 6Bone clean-up succeeded?

GEOFF HUSTON: The 6Bone clean-ups happened well and all that remains is just four instances of advertisements.

I should note for those of you who were looking at this very carefully - I'm sure you all were - that earlier this year we actually had a ghost route condition. Between two ASes which were transit, one speaker withdrew 150 IPv6 routes over time. But the other side of the BGP session didn't process the withdrawals. So we actually saw circling around the network around 150 ghost IPv6 routes. When that session was reset and it was reset in late February of 2006, those ghost routes instantly disappeared. And that's a good thing. It's not entirely clear that these folk are truly advertising it. It could conceivably be ghost routes. But my investigations appear to say that the trace routes work. I think they're real advertisements. So it happened cleanly apart from these four.

PHILIP SMITH: Philip Smith, Cisco. I'm responsible for the v6 bit of 109. Well, I think I am. I'm not quite sure what the oscillation could have been. On the 6th of June, just for information, it was the end of the 6th of June probably as far west as you could go was when I basically removed or put filters in to block the 3FFE prefixes and we had e-mail early in the morning on the 6th of June Australian time saying, "Oi, what are you doing?" and I said, well, the 6th of June finishes when the 6th of June finishes as far as Western Samoa was concerned. I don't know what the oscillation was because we were not providing transit to anybody of any description. So I don't know.

GEOFF HUSTON: Eight prefixes on the 8th of June started to oscillate and you see the update rate here - started to oscillate at an average rate per day of around 80 withdrawals and advertisements per second for the day. What you're seeing on the graph here. There are o only eight prefixes that were doing 10 a second for about four days. It's a classic oscillation condition and the oscillation was between AS 109 and AS 20071. So I too don't understand what happened and I lost the updates when you - someone fixed something and I think it was actually the T Bone that did the fix. I suspect this was a TBone condition but I need to do a lot more data mining. I wasn't looking for this. I was looking for 6Bone. I just noticed this when I was looking.

PHILIP SMITH: I'm just interested because some people are saying there's a withdrawal bug or something or other that they try and blame these things on. I'm just looking for evidence around about this. It has been talked about at the RIPE meetings as well, the v6 working group, because someone spots these from time to time. I'm wondering if this is another of these kind of funnies. Would be interesting in tracking it down. I don't know if others are but I certainly would be interested.

JORDI PALET: Jordi Palet, Consulintel. I think you mentioned that nobody was using the 6Bone for transit. I believe Sprint was doing that and I believe that they are still using 6Bone addresses only for tunnels to customers. That's not usually going into the routing table but it's not probably good practice anyway. I tried to tell them several times but I think they keep doing whatever they want. That's the first point. Second one. I think - I heard in several mailing lists and within ourselves in networks and customers networks, we did use filters for avoiding getting the 6Bone prefixes. So I guess it depends on which part of the world you are having the view, obviously. But in our case, we don't see any more 6Bone prefixes.

And the last comment is not exactly related to this but somehow we organised an activity called the IPv6 day. There was a very good thing because we provided free services and on the 6th of June that was the day that was publicly announcing that, we got over 25,000 different people using the services. So it was quite interesting. Actually, our lease line got almost that because that many people were connecting.

GEOFF HUSTON: Thank you.

MA YAN: My name is Ma Yan. Regarding the four remaining routing entries, when is the data fixed? If it's still there, I can contact the last one?

JORDI PALET: Yes, please.

GEOFF HUSTON: They were still there just before I walked up here. Yes, maybe if you can help in removing one of them, that would be appreciated, yes. Ma Yan: I will.

KAZU YAMAMOTO: Any other questions?

OK. Thank you, Geoff.

So let me call the next speaker.



Next speaker is Ken-ichi Kanayama, Intec Netcore. His presentation title is 'the problems in IPv6 multi-prefix environment and the solving methods'.

KEN-ICHI KANAYAMA: Just a moment, please.

Hello. My name is Ken-ichi Kanayama from Intec Netcore in Japan. And the title is a little changed - 'IPv6 multi-prefix environment - concept, issues and solutions'.

First of all, I introduce IPv6 multi-prefix environment. Next, I explain some possible problems to be solved in that environment. And, last, I introduce our tools for solving these problems.

And first, what is IPv6 multi-prefix environment? And this figure is an example of multi-prefix environment. The end site uses two or more address prefixes. The end site has two or more service providers at the same time and each service provider delegates an address prefix respectively. The multi-prefix environment can be seen as an address-based service-oriented network.

KAZU YAMAMOTO: I don't know why the next slide does not appear.

OK. He needs some time. So I would like to skip. Sorry for that. Let me call the next speaker. The next speaker is Marla Azinger and, after that presentation, I will ask him to make a presentation again, OK?

So Marla is from ARIN. And her title is 'IPv6 PA multihoming'.

MARLA AZINGER: OK. We're back on the road. My name is Marla Azinger and I am on the ARIN Advisory Council and I work for Frontier Communications in the United States.

The reason I am here today is to talk-to-about multihoming and traffic engineering with IPv6. Currently, how IPv6 provider aggregates will implement multihoming and route engineering is not determined. This leaves us to ask the following questions:

What solutions exist or can exist in order to enable v6 multihoming traffic engineering?

And can we come to an IPv6 multihoming and traffic engineering solution on a global scale?

This discussion started on the ARIN ppml list several months back and the problem with PA specifically does not have a multihoming answer.

Various roundabout comments and concerns were made as to where we should be discussing this problem and where we should be creating the solution and one of the places we decided to go and speak with was IETF. But there were many different organisations mentioned besides IETF - NANOG, the RIRs and also maybe JANOG would want to put some solutions forward as well.

Hopefully there are many in this meeting wondering just how are the solutions for IPv6 multihoming and traffic engineering be made? I really hope you're all thinking about it.

First I'd like you to know that I did go to IETF. I had e-mailed them a request asking them what they saw as a solution for this issue. They responded with a prompt, "Please come to our next IETF meeting in Montreal and discuss it with our IPv6 working group." I accepted on behalf of the ARIN Advisory Council and went there and discussed it with them.

Now, IETF is working on a document that will detail their suggestions. Several members from the v6 working ops group are now working to create this document that will give a suggested solution that utilises current technology and not a technology that does not exist yet. Documents that will be published out of this collaboration are to be understood as recommendations of best practice and are not a mandate.

Now what we need is the following:

We need global RIR input, which is why I am here today. And what will work with the different RIR policies and current business practices that are in place today. We need incompetent put from educational and operational forums like NANOG and JANOG and I'm sure there are others but I still have to find out who they are.

The suggested solutions and basically the work that's in progress right now - one is CIDR boundary and filters so basically we would open up filters to a specific CIDR Boundary, that is if we could all agree on what that would be. That's one suggestion. Another suggestion is an aggregation plan that allows only a specific amount of slices to occur. For example, if you have an average an AS that will need eight discrete slices and it's a /48, everyone should accept up to and including /251s. If you want non-multihoming sites to never get into the Internet routing table, you will need to give them a prefix that is small her than what everyone typically allows.

Another suggestion is metro/regional assignment of IP address space. This example I have for it is a prefix is assigned to a suitable regional authority, such as a city, which in turn works with the relevant providers to provide an inter-exchange. Each of the providers advertises a region's prefix to the Internet and accepts longer prefixes from subscribers that are within the bounds and interchanges traffic to other routers appropriately. I know some of your minds are already wheeling because we don't do this right now. But it is a technology thank we could possibly do and all these have their pros and cons.

The next one is community codes. The memo describes a new well known BGP attributes Bute for tagging prefixes used for multihoming with PA space in order to facilitate filtering.

The next one is publish a list of IPv6 blocks that are approved to allow more specifics for multihoming and traffic engineering purposes. The RIRs would maintain these lists. How this would work as an example - RIRs would need to determine that first. Let's say they decide it's a /41. The PA allocation is to be utilised for multihoming. Then the ARIN public DB - this is an example - would provide a loadable list updated daily of IP blocks allowed for multihome or PI routing. In order to make this work, the RIRs would need to add assignments and allocation policies that require the users to subscribe to the DB list and update. That would really be the only way we could actually make it work. And the last one I have currently is shim6. Shipment six isn't on the list, as you see, because there are several groups of people that either aren't clear how exactly how it works yet because they haven't been educated enough, or they truly see there are some major traffic engineering issues with it as it sits right now. So I really hope we can get more clarity on possibly that being another solution that we could use and I'd love to add it to the list.

So all of these different solutions have been provided by many different people in our Internet community and I really would love to take back suggestions and input from your community here locally. So if we could open up the mic and please anybody if you have suggestions and ideas that we might be able to use in order to make multihoming work for PA.

KAZU YAMAMOTO: Any suggestions or questions? Comments?

Earlier we discussed portable addresses, could that be a potential solution?

MARLA AZINGER: I missed the word you discussed - what?

KAZU YAMAMOTO: We discussed a portable address, a PI address.

MARLA AZINGER: Oh, right. I - you could tell people to just go get PI address space and that's what some people have said but the large networks and ISPs should be able to offer their customers that do not want to get PI space the opportunity to get multihoming functioning. Could we change policy to let large networks go assign for a small PI space for that customer? That could be a policy, yes, that could be a solution that we could put in place too. So we definitely could add to that to the list if that's what people want to look at.

PHILIP SMITH: Philip Smith, Cisco. I suppose my question is what's broken with the IPv4-style multihoming that people are already widely using for IPv6?

MARLA AZINGER: It's not broken.

PHILIP SMITH: So we're looking for better solutions?

MARLA AZINGER: It's not broken, but nobody has agreed if we're going to do it that way. And if we're going to do it that way, then we have to determine a CIDR. Because /24 is how we're making it work, basically, with v4 right now.

PHILIP SMITH: Yes. That's right.

MARLA AZINGER: Right. And that's why that is one of the suggestions. It definitely can be worked on. It's just we need everybody to come together and we really would like a global unification on it so we don't have pigeon hole answers around the globe.

PHILIP SMITH: The reason I'm asking is that I just see most of the ISPs I work with at the moment are just doing what they're accustomed to with v4. That seems to be the kind of pop layer solution at the moment.

MARLA AZINGER: Right. And thank you for your input because that's what we need. We need to hear what people really want.

KAZU YAMAMOTO: Kanayama-san, will you propose a kind of solution in your presentation?

MARLA AZINGER: Is he ready?

KAZU YAMAMOTO: OK. Probably he'll show one solution to the audience.

MARLA AZINGER: Great.

KAZU YAMAMOTO: And any other suggestions?

MARLA AZINGER: I'll wait to see your presentation and then I'll add it to my list. That way you don't have to get up twice.

KEN-ICHI KANAYAMA: Multihoming is out of scope of my presentation.

KAZU YAMAMOTO: Do you have a document with all of this information?

MARLA AZINGER: Today I realised I need to put together a document that details completely all the suggestions we've had so far with the pros and cons on them. But that's not developed yet. So sorry - I didn't think that far ahead, unfortunately. But I will definitely be working on it and I need to contact all the people with those suggestions so I can pool what they also see as the pros and cons. And I would love for input from everybody in there room, if you do go look at it and make enough sense what you see already, send me what you see as the pros and cons of those suggestions that we've already put forward. I didn't put my e-mail. My e-mail so you have it is marla.azinger@frontiercorp.com. Excellent.

KAZU YAMAMOTO: Again. Any comments?

MARLA AZINGER: OK. Thank you very much for your time and your input that I know you're going to send me.

KAZU YAMAMOTO: Is your documentation is available, please let us know.

MARLA AZINGER: Yes. The document - I'll start working on that right away, that you're asking for. And this is available on your website already.

KAZU YAMAMOTO: So, thank you, Marla.

APPLAUSE

OK, again, let me call Kanayama-san. Please come up to the stage.

KEN-ICHI KANAYAMA: Sorry for my problem.

Let me start from first.

I will introduce IPv6 multi-prefix environment. And next I explained some possible problems to be solved in the environment. And last I introduce sour two solutions for the problems.

First - what is IPv6 multi-prefix environment? This figure is an example of multi-prefix environment. And our end site uses two or more address prefixes. End site uses two or more service providers at the same time. And each service provider delegates an address prefix respectively. IPv6 multi-prefix environment can be regarded as address-based, service-oriented network.

Next slide please. This is about the IPv6 multi-prefix service model. Various xSPs can provide its service to an end site directly using a single access line. This picture makes this. Here an xSP is not only ISP but ASP. For example, it could be a Security Service, or a facility management, or medical service. Characteristics of xSP is the following - not only ISP but ASP. And its network may be a closed network, and xSP provides service to end site directly and xSP can have unique global address.

There are already some examples in Japan. Host media is the biggest service which uses IPv6 multicast. And the next example is IPv6 kiosk terminal in convenience store of FamilyMart. FamilyMart is a big store in Japan and this company decided to put the terminals in several large stores in this year. This application service is provided an IPv6 closed network. Next slide please.

And the next slide is about the merits of the IPv6 multi-prefix environment. The first point is about cost. xSPs can reduce the cost but they can share a single address line to each end site. And the next point is about reliability. XS P can provide its service to end site directly, not via the Internet. So its service is more reliability than any service provided via the Internet. And next point is about manageability. Each xSP uses its own unique global address so it's easy to manage its service. And last merit is encouragement of new type of ASP providing QoS-sensitive service or critical service is easy by this model.

And next is about technical problems. So I think IPv6 multi-prefix service model is very useful but there are still some possible problems in some situations. The presentation focuses on the following situation. The point of this is end site connects one ISP and one or more ASPs. In this presentation, multihome for Internet is out of scope. And ASP service is provided on a closed network.

The following slides introduce main three problems and their solving methods.

Our first problem is about source address selection. And this problem happens in some conditions like this one here. This host uses both of addresses from ISP and ASP at the same time. And there are possibilities that wrong source address is selected for destination address. If wrong address is selected, the return packet will be lost. This problem can be solved by proper configuration from the policy table of hosts. Prefix policy table is specified in RFC 3484. At present, automatic configure function is proposed in IETF.

Second problem is about next-hop selection. This problem happens in some conditions like this preview. Site connects to each xSP with respective gateway. Each gateway sends out a message to hosts. In this condition, a host selects only one gateway for xSP as the preferred default gateway. This means that the reachability to the other xSPs are lost. This problem can be solved with proper configuration of routing table from each host. RFC 4191 is published by IETF. Some problem - third problem is about name resolution with DNS.

This problem happens in some conditions like this figure. Host has to look to both DNS servers if ASP allows only its users to look at DNS records of the service. So each DNS query from hosts must be forwarded to suitable DNS server, but hosts usually do not have this function. At present, as a reference, there are some methods of gateway products but it has not become a standard method.

And last, I introduce our solving tool for the current practice. This tool solves these situations automatically according to the received RA messages. Configuration of the routing table solves the problem of next-hop selection. And it solves the problem of source address selection. This tool works on Windows XP is SP2. We have a plan to support Windows VISTA in the near future.

If you have any interest in this tool, please contact us.

Thank you.

KAZU YAMAMOTO: Any questions?

TOMOHIRO FUJISAKI: Can I ask one question? I think it's possible to use this technique to the multihome environment. Why you exclude the multihome?

KEN-ICHI KANAYAMA: It may be possible. But I didn't think about it at present.

KAZU YAMAMOTO: In the last slide, you said that the problem one and the problem two will be fixed. But how about the DNS problem? Can you fix that problem?

KEN-ICHI KANAYAMA: This tool does not fix the DNS problem. This tool solves the next-hop selection problem and the source address selection problem.

KAZU YAMAMOTO: My question is how can you solve the problem three, the DNS problem?

KEN-ICHI KANAYAMA: Problem three. Now, we are researching about the problem.

KAZU YAMAMOTO: Those of you who are not familiar to Japanese situation probably feel like, feel strange a bit, but this is real problem in Japan, you know. LTT provide a closed network, IPv6 closed network and we already have an IPv6 Internet so this is a serious problem in Japan, as he is going to fix that problem.

Any questions?

SHIN YAMASAKI: Just a question. The tool is from switching from one environment to another or by using that tool can I use both networks in the same time? Just, I don't know much about the technology. So I'd like to know that.

KEN-ICHI KANAYAMA: Yes. Tool can support different environments and dynamically, it can change the configuration according to the network environment.

SHIN YAMASAKI: Thank you.

KATSUYASU TOYAMA: You said this is a special case in Japan, but I don't think so. I asked about this solution to the problem one and two can be applied to the multihome problem. And I think that to solve the multihoming in the PA environment, these two problems should be solved and these techniques should be standardised from the technical point of view. So I strongly recommend these things are technically solved in the IETF.

KEN-ICHI KANAYAMA: Thank you.

KAZU YAMAMOTO: What I want to say is this is not - this is not Japanese-specific problem, but this is a real problem. Last question please.

MOTOYUKI OHMORI: This is not a question, but I have a comment. So I would like to suggest you that the host has a route to the Internet and closed network. I mean, so the - how can I say? - could you go to the previous slide? In that case. Host - if host has a route to ASP and the Internet, I think the problem two and the problem three could be solved without something like that. Is that correct? No?

KAZU YAMAMOTO: No. You know, if host choose ASPs address as the source address, then -

MOTOYUKI OHMORI: But problem two and problem three - next-hop selection and DNS search. No?

KEN-ICHI KANAYAMA: In that situation, the gateway environment, problem two and three - problem two or three will be fixed automatically, you mean?

MOTOYUKI OHMORI: Yes. I'm sorry. So if host speaks with ASP and ISP, problem two and problem three could be solved easier, I thought.

KAZU YAMAMOTO: IPv6 host is not designed to support OSPF.

MOTOYUKI OHMORI: So it's not host, you mean?

KAZU YAMAMOTO: Host is - the definition of host is not joined for routing.

MOTOYUKI OHMORI: So you're talking about the definition of IPv6 host. So just speaking, IGP is not permitted.

KAZU YAMAMOTO: It's too heavy, too complex.

MOTOYUKI OHMORI: OK. Thanks.

KAZU YAMAMOTO: Thank you, Kanayama-san.

KEN-ICHI KANAYAMA: Thank you very much.

KAZU YAMAMOTO: Well, OK, let me call next speaker. Next speaker is Nao Fukushima-san. His presentation is IPv6 deployment status in Japan.

NAO FUKUSHIMA: Thank you for introduction. Hello, everyone. I'm Nao Fukushima. Today I will talk about the IPv6 deployment in Japan.

This is today's agenda. I will introduce the government activities and business status of Japan. Secondly, I will introduce the IPv6 solution and the products. Thirdly, I will introduce our promotional council, finally I will conclude my presentation.

Now, I introduce governmental activities of Japan. In Japan, the government is running the system to be compatible with IPv6. IT strategic headquarters decided the policies of Japan. A new strategy reform strategy in January this year. This strategy was used to undertake hardware development in Japan and a transformation through the utilisation of IPv6 by 2010 to achieve the objective.

We will be IPv6 compatible by 2008, fiscal year 2008. All government systems will come to be compatible with IPv6. The headquarters also decided primarily policy program 2006 in July this year.

This program set a complete schedule of strategy. Ministry of Internet affairs and communications will make the strategy. Each ministry will be requested to settle on a complete plan to be compatible with IPv6 by fiscal year 2006.

Next, I will introduce IPv6 deployment field trial. This experiment was conducted by the department of MIC. In this trial in 2005, the participant helped build the application in the public service, security, education, health and facility management in the local government in Japan. This trial demonstrated potential of IPv6 applications to the public through field trials in 14 sites in Japan.

These are individual projects of the IPv6 deployment field trial in Japan.

Widely carried out, the results of experiment were publicly announced through the guidelines to promote expansion of IPv6 transition. In total, 21 trials have been conducted, 15 of those are shown here.

But there are too many trials to introduce now. So I introduce some of them later in application part.

Now I introduce the deployment status in Japan. These two transition models in Japan. First, smooth transition. It prepares for an IPv6 environment at the time of system upgrades. This will lead to a gradual transition in several years.

Second, forced deployment. IPv6 transition by force, such as made by government bodies.

Third, solution-oriented deployment. It used model IPv6 before it was effective. In Japan, the third model is seen.

There are two areas of commercial market, IPv6 direct and indirect. Currently, IPv6 intranet has largest number of subscribes. As examples, facility management, censor networks, telephone, IPTV and so on. I think the Internet has some solutions too. As an example, remote monitoring system Internet. It has already been provided for persons in Japan, but a number of users doesn't exceed 2,000.

In Japan, a lot of business applications are developed and used on the business. So Japan is strong in the business application area. We think the Japanese case is the deployment model.

I introduce IPv6 solution to Japan. There is no time.

First, I introduce FLET access line service. This slide shows IPv6 service operated by FLET Network Corporation. It is an access-line provider and they don't provide Internet activity. Therefore, the IPv6 service does not provide Internet access, but provides the office network. The users can use communication, file sharing and window-streaming service.

I introduce IPv6 multicast service. This case is used for multicast. The famous Japanese drama is using the system to deliver the image of the famous place at the same time, instead of using the usual system. However, when you use this system, expensive equipment is necessary, it is difficult to take it in the individual houses. They began to image using multicast. This service has spread.

The case is current distribution service. Sorry, no?

The case is content the business service provided by Plala which is one of the major ISPs. Multicasting broadcasting is a product, provided by July 2004. They have 30,000 subscribes in 2006.

Why use? It is possible to reduce 17 million yen, it costs 200 million yen. Second, I introduce the building facility management case.

In the communications case, they think they can reduce 15% of consumption. In another case, they produced 30% of consumption.

Live E! is an approach that aims at the achievement of the infrastructure construction that can use environmental information. This case, about 50 pieces are operating now.

This figure shows an experiment in the project.

This case is the service provided by Freebit, a Japanese company. It is a construction for company users which is a fast IP address service.

They operate in June 2004, they introduced 20,000.

Without IPv6 they can't provide it in the present costs. This is IPv6 products in Japan.

Finally, I will conclude my presentation about deployment in Japan. Commercial IPv6 services for corporate and home users are available in Japan. Services within closed networks currently enjoy more advantages. For the consumer, the IPv6 connectivity is getting closer. But, there are neither attractive contents nor an application and the one that becomes the first trigger is waited for. In the field like the building maintenance, the sensor network and the disaster prevention system, the system using IPv6 will spread rapidly. That's all. Thank you very much for your attention.

KAZU YAMAMOTO: Thank you. Any questions or comments?

You didn't mention this, but another example is IPv6 terminal in FamilyMart convenience store?

NAO FUKUSHIMA: I don't know details.

KAZU YAMAMOTO: Any other comments or questions? Okay. Thank you very much.

NAO FUKUSHIMA: Thank you.

KAZU YAMAMOTO: So let me call the last speaker. That speaker is Hung Chang Lee, TWNIC. His presentation title is 'IPv6 Deployment Strategies and Status in Taiwan'.

HUNG CHANG LEE: Hello, everyone. I was told I have only 10 minutes so I must speak quickly. I'm Hung Chang Lee from TWNIC. This is my presentation to talk about IPv6 deployment strategies and status in Taiwan.

We are first talk about IPv6 deployment in Taiwan and then talk about the work we have done before and present, and then we will talk about the future plan with our work in IPv6. This curve shows that we think about IPv6 deployment paradigm. It is a dream when they first invent it, but when constructed in 1996, it became a home in IPv6 land. We think we become realists by 2010, and these three curves, the technology readiness, production readiness and deployment status, maps the paradigms.

We think that we are now in the pit paradigms and we hope to put into realistic and we think there are four driving forces. The main application is product readiness and key service.

Taiwan's strategies is simple, we deployment, the IPv6 in evolution way and we and our nation and our industry, we get ready. We still wait for the cut-in point, that is the point to cut into the realistic. So we have come out and called it the IPv6 development and deployment program.

The National Information and Communications Initiative Committee is government institute and the program will last for five years and will end next year.

This is the program working structures. TWNIC in the middle of the slide is in charge of the steering committee. It is broken into four divisions: research and development, standard and testing division, infrastructure and development division and application division. This slide shows our roadmap. Next year and the year before, we coming in 2006 year, we focus on the application.

We divided into four divisions, because each division have some parts, for example, industry, academic, users so we call this a diamond shape. This is the result, we have done before. We say we have basically, academically, we have capability and we have commercial in the trial stage. We have several government networks also constructed.

We have some working product on IPv6.

This is the outline of our products and there are some important items.

This slide shows that we have an IPv6 standard and interoperational testing in the Chunghwa Telecom. We have some products by Taiwan industries listed in the slide. This slide shows we pass the first one phase one logo. We are now 34 and we've passed phase logo two - 8. And this first one, logo the product and the vendor.

And that's the picture of the products. We have enjoyed APTEL application for testing. We have IPv6 trials at some universities. We have commercial VoD service now.

We have EcoGrid, this is testing for the animal and plant and something like that.

This is a picture from the web site.

And we have the public multimedia payphone by Chunghwa Telecom.

And this is promotional activities.

We have a summit in Taiwan. This is IPv6 demonstration sites, we have two demonstration sites in Kaohsiung. That's the MoU and killer service in IPv6, Healthcare, Carv6, Campus and the main service in IPv6.

This is the working items in this year.

Our future plan is simple: We try to build a ripple. I put the Chinese character there, because the Chinese character means the meaning of ripple is romantic and beautiful, we hope to have IPv6 ripple. This ripple means we have only used IPv6 and continue to use IPv6 and to satisfy our demand. Some examples is domain specific VoIP, physical on-line games, domain-specific security and surveillance. Japan has the same project, Live E! Project, closed VoD system.

And this is my summary. I think that IPv6 is a competitor to IPv4, not a substitution. So strategy is to play a role in coordinating and supporting the development of IPv6 standards, products and international cooperation. So we hope we have IPv6 ripples that can propagate a driving force into worldwide IPv6 waves. Thank you, that is my presentation. Nine minutes.

KAZU YAMAMOTO: Thank you, thank you for keeping your presentation short. Do we have any questions, comments? We Japanese import many, many home routers from Taiwan. Some of, some routers said that they're IPv6 ready, but the only - that means only bridge will be available, so we like to have IPv6 ready.

HUNG CHANG LEE: Is it inside in the layer? Tested? The product been tested? It has been tested by our test lab.

KAZU YAMAMOTO: I'm talking that the product made in Taiwan itself, IPv6 ready, but -

HUNG CHANG LEE: It is certified by -

KAZU YAMAMOTO: Yeah, I know. But working as a bridge mode. If my understanding correct, there is no home router which really works as an IPv6 router at this moment.

HUNG CHANG LEE: I say part of it in those slides. We don't yet have an IPv6 router system.

KAZU YAMAMOTO: So we had all six presentations. Any questions, comments to, you know, all presentations at this moment? Any suggestions to improve IPv6 technical SIG? Okay?

So I think it is time to close this session, so let's conclude this session with big hands.

Thank you very much.