______________________________________________________________________ DRAFT TRANSCRIPT SIG: IPv6 technical Date: Wednesday 1 March 2006 Time: 11.00am Presentation: Progress report for ip6.int deprecation in Japan Presenter: Shin Yamasaki ______________________________________________________________________ KAZU YAMAMOTO: So next speaker is Yamasaki-san from JPNIC. His presentation title is 'Progress report for ip6.int deprecation in Japan'. (Shin Yamasaki had problems connecting his laptop to the projector) His laptop is not friendly so... he will make a presentation using PDF. OK. SHIN YAMASAKI: OK, sorry for wasting time. For some reason, this projector doesn't like my laptop. Let me use another laptop. My name is Shin Yamasaki from JPNIC. This is the supplemental presentation of Yamamoto-san's presentation. This is just reporting the progress of the ip6.int deprecation within Japan. So the background is, as you know, not all IP address ranges are managed by JPNIC. But last year several IPv6 addresses transferred from APNIC to JPNIC. Then all of those ranges have reverse DNS in APNIC that is called a 'shared zone' system. So JPNIC basically only retains records in our resource management system. That means we don't have DNS in our site. Then when we migrated IPv6 addresses, our system - we decided not to retain ip6.int zone data in our system because APNIC already announced deprecation of the ip6.int. As Yamamoto-san said, as we are one of the Internet registries, we should let our customers know about this ip6.int deprecation issue. So when we migrated IPv6 data, we counted the number of the ip6.int zones, then notified them the zone data won't be available in June 2006, at the time of the migration. We did migration three times from APNIC to JPNIC. The first migration happened in May 14. We migrated 55 IPv6 address blocks. 19 of those had IPv6 zone. Second migration happened in July 4th. We migrated nine IPv6 address blocks and two of those had ip6.int ranges. Then third migration happened in August last year. The only one range also had ip6.int zones. It's a very longwinded way, but we notified from our host masters to a members, LIRs, about the ip6.int deprecation. So first announcement was made from May to August last year. It's the same as the last slide - basically we notified each of our LIRs about the ip6.int deprecation. After that, we publicly announced about the ip6.int deprecation in our JPNIC Open Policy Meeting. Then, third time, we also announced to our LIRs in September about the same thing. At this time, we recommended to stop using ip6.int and migrate to ip6.arpa. Then, in December last year, we had another Open Policy Meeting. Then we announced this issue as part of the APNIC 20 report. And this year, we made a degree of measurement by using dig command from our end to the LIR's nameservers. Then our latest result was we still can dig the ip6.int zones without errors. So basically that shows there is no improvement since migration. But obviously, the method we did had limitations, because just submitting the request to the LIRs' ip6.int zones does not always say exactly if the LIR uses ip6.int or not. There is another issue. Since those IPv6 allocations are quite historical, most of those still have zone data for /35. That's the original allocation size. So some ranges have both /35 and /32 zone data. So that makes things more complicated. Then the next step - our hostmaster will announce to our LIRs who still use ip6.int within this month. That's the status of the ip6.int issue within JPNIC area. That's it. Any questions and comments? KAZU YAMAMOTO: I have a question. Would you show slide who is titled 'result'. I don't know what you try to mean. This is result against query to ip6.int? SHIN YAMASAKI: ip6.int only. KAZU YAMAMOTO: And you said no progress is observed, right? SHIN YAMASAKI: From the time of the migration. KAZU YAMAMOTO: But I think this is not that situation. Because we don't care NOERROR because they just provide, you know, reverse mapping and ip6.int and, after 1st June, that database cannot look up. So no bad thing happened but JPNIC should try to use dig command to ip6.arpa instead of ip6.int because the important thing is that, you know, each side provides reverse mapping database through ip6.arpa or not. SHIN YAMASAKI: So you're saying if transition was made from ip6.int to ip6.arpa was made or not? KAZU YAMAMOTO: We don't have to care ip6.int at this moment. That will be obsolete. The important thing is, you know, whether or not each site provide information through ip6.arpa, so you should check ip6.arpa zone, right? SHIN YAMASAKI: Right, right. Thank you for recommendation. TOMOHIRO FUJISAKI: I have one question. Do you get any response from LIRs? SHIN YAMASAKI: I believe we didn't. But we will individually notify if an LIR didn't migrate from ip6.int to ip6.arpa. Am I answering your question? TOMOHIRO FUJISAKI: Yeah, I just want to know the LIRs have any questions, any comments? SHIN YAMASAKI: No. No. We didn't. Any other questions? Thank you very much. KAZU YAMAMOTO: Question - what kind of message did JPNIC send to each, you know, LIRs? My intention of the question is we should not ask people, you know, to stop using ip6.int. That is not important. We should ask people to use ip6.arpa. OK? Stopping ip6.int is not so important. But usage of ip6.arpa is very, very important. So we should ask, "Prepare ip6.arpa in your domain zone," OK? SHIN YAMASAKI: OK, I'll keep this in our mind to encourage using ip6.arpa to our members. OK, thank you very much.