______________________________________________________________________ DRAFT TRANSCRIPT SIG: IPv6 technical Date: Wednesday 1 March 2006 Time: 11.00am Presentation: Technical consideration on deprecation of ip6.int Presenter: Kazu Yamamoto ______________________________________________________________________ KAZU YAMAMOTO: OK, before my presentation, we have urgent announcement, OK? An APRICOT 2006 conference bag is missing. Someone may have picked up a wrong bag from the area with chairs towards registration desk in Level 2. If you have someone else's bag by mistake, please bring it to the APRICOT registration area as soon as possible. Would you make a look in your bag, OK? Is it your own bag? Please make a double check. The owner's business card, Zita Wenzel, is inserted to the bag's name card is on the bag. If you have one, please go to registration desk as soon as possible. Thank you very much. OK, so my presentation - 'Technical consideration on deprecation of ip6.int'. I'm Kazu Yamamoto, IIJ. So background - as Sanjaya said, ip6.int will be deprecated on 1st June, 2006, OK? A rumour said that deprecation of ip6.int will make reverse mapping worse. It is true that some application servers have ill behaviour when reverse mapping is a mess. We repeatedly experience that, you know, when we login with SSH to SSH server, this login and SSHD makes a reverse look-up, then, if the DNS server hold to reply answer, login OK also holds. Then our login is hold. These kind of things actually happen if, and only if, reverse mapping is a mess. So we need a technical consideration on whether or not deprecation of ip6.int will make reverse mapping worse. What does 'worse' mean? I think there is two criteria. First one is DNS server response time will be longer. This is the SSH program. And the other one is host names will be unavailable. The interesting question is which applications use reverse mapping? Fortunately, most clients do not. And some servers do, like is SSHD, OK? And for what do servers use reverse mapping? First one is logging host names, OK? And the other is authentication. This is in two - one is the existence of reverse mapping. So server make use of existence of reverse mapping for authentication. And the other is consistency between forward mapping and reverse mapping. But this is too detailed for this presentation, so please keep in mind, one is logging host names and the other is authentication. OK. So after 1st June, 2006, what will happen? As Sanjaya explained, roughly speaking, a name error will be always returned when names under ip6.int are looked up. OK? This is too technical, so what does it mean? It seems that no new LAME delegations will be generated. Rather, the number of LAME delegations will probably decrease because bad effects from lower ill-maintained domains will disappear. So, fortunately, DNS server response time will be shorter, OK? In case where host name is resolved and even in the case where host name is not resolved. So DNS server response time will be shorter anyway, in any case. So, fortunately, an SSH server does not hold your login. So are we all happy? Unfortunately, the answer is no. Side effects would happen. Remember that host name will be unavailable in some cases. Let me explain this one in detail. Most servers use resolver libraries on local machines. And ip6.int-only resolver will not be able to resolve reverse mapping after 1 June. So if a server is using this kind of resolver called 'ip6.int only', host name is always unavailable. But please note again that response time will be shorter than before. Resolvers are categorised into four - ip6.int only, ip6.arpa only, ip6.int then ip6.arpa - this means that this kind of resolver, first tries to reverse mapping to ip6.int. If host name is resolved, the query is stopped, OK. Host name is not available, then give next try to Ip6.arpa, OK? The last one is ip6.arpa then ip6.int, OK. Only IPv6 only resolver has, you know, a bad effect, you know. Reverse look-up always will fail after 1 June, 2006. All other libraries don't have bad effect, OK. So the question is how many ip6.int only resolvers are out there. Fortunately, most recent resolvers are not, are not ip6.int only. But some old resolvers are ip6.int only. We cannot, you know, cover all resolvers but why the project pick up ip6.int only resolvers, this kind, probably the most impacted one here is Windows Server 2003 without update, OK. So, if you are using Windows Server 2003, please do Windows update to get ip6.arpa only resolver. If you usually do Windows update, you don't have to care at all. So technical expectation - if a server is using ip6.int only resolver for logging, OK, IPv6 addresses are recorded in log instead of host names, OK. This is not so bad. And host name-based authentication - so access from some legitimate clients is denied, unfortunately. But I should emphasise that these side effects are rare and not fatal. That is our expectation and to, you know, check our expectation true or not, we did a field test. This is done by v6fix Working Group of the WIDE Project since 18 January. What we did is make our server provide separate views. I mean so this server returned name error to WIDE community when the query for reverse mapping from WIDE community. Then to other Internet, host name was returned, OK. So this is a simulation for after 1st June. Fortunately, no side effect has been observed at this moment. So I cannot say this is, you know, evidence to bad things will not happen, but we can believe that side effects are rare, not fatal, somehow. OK, this is my last slide - summary. Our conclusion is a situation would be better after 1 June 2006. But side effects would happen, but they are rare and not fatal. So if you are using ip6.int only resolver, please update your resolver, OK? And for more information, please look at this page indicated by this URL (refers to slide). Thank you. Any questions? SHIN YAMASAKI: Shin Yamasaki from JPNIC. You mentioned Windows server 2003 is somewhat critical. Can you pinpoint which fix or which service should be required for ip6.arpa? KAZU YAMAMOTO: WIDE Project made a question to technical guy in Microsoft. He answered that please do fully updated, OK? I don't know which update fixes this one. I don't know. SHIN YAMASAKI: OK. Just I thought some people cannot always apply the latest pack so if they can know the base line of the fix or service that would be good but if Microsoft doesn't tell you, there's not a way, I guess. KAZU YAMAMOTO: I guess that is for, you know, user side. If you are using some specific applications on your Windows, it is not possible to fully update, but this is server side and server should be, you know, updated because of security or something, OK? So fully update is always a good thing in server side, I guess. SANJAYA. First off, thanks for a very good explanation of the potential impact. I think it's a positive message that we are receiving from you. I'm just curious - did you - because the Japanese community seems to be using IPv6 more than probably the rest of the world. I was wondering if you have done an analysis like what we've done and looking at the query rates of the ip6.int somewhere in your lab? KAZU YAMAMOTO: Yeah. You are talking about statistics, right? SANJAYA: Yeah. KAZU YAMAMOTO: We and WIDE Project checked all the detailed statistics and please - I did not explain because you explained, OK? And the situation is the same and the statistics is available in this page, so please look up this one (refers to slide) JORDI PALET: Regarding the Windows 2003 service pack, I believe in Windows 2003, there is not an isolated packet to solve this but you get it sorted out with service pack one. So obviously, you said, being a server, you should apply everything because of the security issues, but service pack one, as I can remember, solved this. KAZU YAMAMOTO: OK, so we do fully updated, right? Jordi? Yes. OK. GEORGE MICHAELSON: George Michaelson from APNIC. Thank you very much for this presentation. I think it was very interesting to see a totally independent measure of behaviour confirm what we also felt would happen. I would like to suggest that, even though you believe this is a safe activity and we believe this is a safe activity, our responsibility to the community is still to alert people and to be ready to react if there turn out to be problems that we did not foresee. I do not think this will happen but our responsibilities as custodians of the reverse address space is that we must be ready to advise people how to move on if they wind up having problems. In particular, an earlier measure that was made in the WIDE community suggested there is a functional split of DNS in the v6 community. The corporate sector keeps up to date with patches, runs more new software and so are quite likely to have code which will do the right thing and the small business cable home-user sector tends not to do this and is at a higher risk of, firstly, not understanding the problem, and secondly, running older machines. But the other side of the problem is these people are much less likely to trigger problems like the SSH problem. They would not ordinarily be doing services that demand functional reverse DNS and, as you have said, because we are terminating delegation, there will be an NXDOMAIN. Instead of it being a lame response, it will be a 'does not exist' response, which is a much faster termination. So I still believe this is safe and will have the good effect, but I do think, particularly that the Japanese community, you maybe have the shared responsibility with us to be ready to help and advise people. But this is a very good body of work and thank you for presenting. KAZU YAMAMOTO: I think we can do two things - one is write a document. So I will update my - our document, but, because we - our native tongue is Japanese, can I ask you, you know, to proofread - GEORGE MICHAELSON: Sure, yeah. KAZU YAMAMOTO: Thank you very much. The second thing, probably something else will explain but APNIC can ask to NIR - the NIR actually ask IIJ and IIJ is asking our customers. So such a hierarchy should work. Any other questions? OK, thank you very much. APPLAUSE