DNS operations SIG, Thursday 21 Aug, 2:10-3:05 pm JOE ABLEY: Can everybody hear me OK? Yes? OK, cool. Hello and welcome to the DNS operations SIG briefing. I've got a few housekeeping notes here to read out. First of all, I should mention that we're here thanks to our sponsors, of which in particular Korea Telecom is the platinum sponsor. At the end of this session, we will have morning tea. No we won't. We'll have afternoon tea. There is a MyAPNIC demo all day at the APNIC help desk. The help desk is available at all times. A reminder to check the onsite notice board for announcements. One meeting-specific announcement. We have a USB extension cable found on the floor. If anyone recognises it, it's male one end, female on the other side, come and pick it up. It was found over here somewhere. If that rings any bells, come and recover it or I'll leave it in the Secretariat room. We have a small number of things to discuss today. The agenda there is on the web page. We have a draft charter to confirm or to discuss. We have one open action item to talk about. Then we have three presentations from George Michaelson, Randy Bush and Geoff Huston. So, if we get the first two items out of the way nice and quickly, if I can find them. So, on the screen there, we have the draft charter for this DNS Ops SIG. So I can read it out. I'm sure you can read it yourself. "The charter of the DNS operations SIG is to examine developments in policies and procedures for reverse DNS operations in the Asia Pacific region. It will include topics such as reverse delegations for IP version 6 networks, dynamic updates, secure DNS, current BIND versions and legacy transfers from other databases." So I was not actually the SIG chair at the time this charter was put together so I've inherited this one. However, this has not been formally approved by the membership. Is there any objection? Randy? RANDY BUSH: Please change the word 'BIND' to 'software'. JOE ABLEY: That seems acceptable. Are there any other comments, observations, complaints? Is there any objection to Randy's change? So, with that change that Randy proposed, are there any objections to this DNS charter as on the overhead right here. I guess there are no objections. OK, good. Well that was quick. The open SIG action item that we have, action dns-15-001, which is for the Secretariat to modify the lame delegation clean-up proposal and refer it back to the mailing list. So George is going to give us a summary of exactly what that proposal is in a few minutes. At the last meeting I think this was discussed. There was a very small amount - almost none - discussion on the mailing list. There was a very, very small quantity of comments so I'm not convinced that we had any opinions expressed there. GEORGE MICHAELSON: No, but I'll represent a discussion with some modifications. I would say that there has been some action even if there hasn't been much substantive discussion on the list. JOE ABLEY: And there are no other open action items. Next on the agenda. George, do you want to pop up and do your modified presentation? GEORGE MICHAELSON: Hello, everyone. This is the modified proposal based on last year's proposal, which has been revised in line with discussions that took place at the meeting, and subsequently, in a discussion with a variety of people, including the staff of the other RIRs and also some internal discussions, looking into improving procedures. The outcomes, to summarise, are that we have adopted a much more ARIN-like communication process. We thought very hard about the suggestion from Ray Plzak and considered their procedures. We had a staff member who was actually over at ARIN working in their help desk and seeing this activity being run live and we were able to think about that and incorporate that into the proposal. We've tried to come up with a clearer definition of the applicable problems that we would regard as causing lameness in a nameserver and we've refined the process so we're now able to disable a specific lame nameserver case by case. Just to get some definitions - DNS delegations are lame if some or all of the registered DNS nameservers are either unreachable or badly configured. We say 'registered DNS nameservers' because it's possible for a zone to have other nameservers that it explicitly inserts but the ones that we can deal with in this proposal are the ones that are officially listed and delegated down the tree. In the case of reverse DNS, the people who have the delegation point are the RIRs, because we are the people who receive the delegations down from the in-addr. To summarise, there are really four conditions we were inserting. The first one is possibly the most contentious one. This is the one that had most discussion last time. That is that we cannot reach the listed DNS server. We still consider that that should be treated as lame DNS and I will talk more about this. The second case is that it is reachable but it doesn't respond on port 53. It does not function as a nameserver. Clearly this is lame. The third case is that it is reachable and functioning on port 53 but it can't supply a correct name for the domain. You have good confidence to say this is lame. The last case is it is reachable, it responds, but the data you get from the domain is Incorrect, but it does give an answer. We are not comfortable saying this is lame. We figure it would be too aggressive to say that this is lame under this policy. The problem summary, just to revise from last time, is that we're doing this because this causes problems across the Internet as a whole. You get delays in binding on to a service. The client could see this. The example would be that the receiving party of the Internet session is trying to resolve the source address and they're hanging waiting for a response in DNS. This is an increase in delay for an end-to-end service delivery. You may be refused service due to failure of DNS processing. Some sites take a strong line. If they attempt to look up DNS and it fails, it's worse than having none at all. If you claim it and it doesn't work, they regard that as a more severe failure. There is the increase in DNS traffic. This is never good. You don't want avoidable traffic on a network. There is the critical infrastructure aspect, that this causes traffic on a small number of resources that we would like to try and improve the quality of service for. We have had a specific request to address this. Something else to bear in mind here is that this isn't just about a problem that the holder of an address has. It's a problem that can be experienced by any user in the Internet trying to do operations against that address. So it's a problem that affects unrelated third parties. I personally think these problems are very bad because they're a general problem in the network as a whole. If you do something that damages your own resources, you've kind of contained it to yourself, but when you have damaged third parties, I think your responsibility to look at it is a lot stronger. The end users can't resolve this problem directly. There's nothing they can do to fix this. The responsibility to fix a problem in DNS is vested with the delegation body. And, if a network administrator can't or won't fix their problem, then the RIRs have a responsibility to resume control until something can be done to fix this. So the proposal as it stands has four components. We are going to identify potential lameness, and I stress potential, at two points of test in the network, one in Australia and one in Japan. We're going to test the DNS reverse delegation for a 15-day period, if we believe that we are seeing problems. At the end of that period, if it has consistently been wrong, we will have a 45-day notice period where we attempt to notify the domain holder and only if it is not fixed at the end of that period, we will disable it. First stage - identifying potential lameness. We are going to modify the process based on last year's proposal. It's based on the scripts that we are using for our current measurement exercise. We're going to run independently in Japan and Australia and each node will mark the domain separately. We'll collate that data in HQ in Brisbane. If either one of these locations says "this is not lame", then that's an immediate test to say, "We can't exclude this resource." One might say, "I can't see it," but if the other can, it's a routing problem not a domain problem. This seemed to be a concern last year. People were not comfortable that we would be excluding unreachable servers. We think having a test point in Japan and Australia, that has good, wide coverage of routing and connectivity, means it's safe to withdraw the service if we can't reach this from two locations consistently. We would consider more probes. This really is a minimum of two. RANDY BUSH: Especially topographically. GEORGE MICHAELSON: We're proposing a 15-day test period, a variance from last time. You've got to be consistently lame in that period. If you come up valid in that time, we won't want to withdraw you because it suggests it's an engineering issue. We feel comfortable that we can expose this information on the website to the public because it's about a publicly visible resource anyway. We expect that, during the test phase, we'll have diagnostics on the web that let people see what we think about the state of DNS. For the 45-day contact period, we'll be contacting the administrators of the domain and, if we find they're not responsive, we're going to try and contact the administrators of the parent zone, which might come from another domain or from an inetnum. We're not being specific about exactly who we will contact because we want to consider going to other records that we hold outside of Whois, such as membership records and other information. We'll use all methods we can, by e-mail, fax and phone. This is something that we took from the ARIN proposal and from discussions since last time round. The disable proposal will only - we will be disabling only if the domain remains lame for the whole period. I notice that, even if contact is successful, so if we contact someone to say, "You're lame," they respond and say, "I know," but don't fix it, we will still disable it. We will only disable the bad nameserver. Previously, last year, we proposed to withdraw the whole delegation. We decided it's better to do this nameserver by nameserver. There is a general sense that you should have more than one nameserver in your listing. That isn't accepted as a complete binding obligation. It's something you should do but it's not a must do. We felt it was better to have one, stable working nameserver than to have one stable and one broken. If you consider the case where both nameservers are broken, then the effect of withdrawing them one by one is that you will still be withdrawn from the tree. If people are withdrawn from all available nameservers, they will be withdrawn. This means that we will return no such domain which is the fastest, "no" most efficient way to confirm that there is no delegation to this object. We'll be sending out reminders. You can re-enable at any time by maintaining your object. You remove markers and then DNS update applies within two hours. The disabled objects will be clearly identified because you'll be able to see the Whois object that has been disabled. The proposal is to implement three months after it's been accepted by the community. We suggest that we would start by extending the measurement to Japan and, from what Randy says, we should consider another site. We will implement a communications process to tell people that we have detected you're lame and then we will implement the disable function. the implementation is quite cautious. We will extend measurement and go through communication. We'll only implement disabling at the end of this period. We expect to collect statistics and report back to the Ops SIG and other bodies. How do people feel about this proposal? RANDY BUSH: I like it. I note one little glitch in the write-up which is that you're publishing a shame-and-blame list in the 15-day period but not the 45. The 45- day period is more important. 45-day period, you've sent me an e-mail, I see it, I try to fix it. It would be nice if there was somewhere I could go to see if I'm off the list. GEORGE MICHAELSON: You think it's better to in the 45-day period, not the 15? RANDY BUSH: I think it's more important it's in the 45-day period. GEORGE MICHAELSON: I'm quite comfortable to do that but I don't think it's a substantive change to the proposal. The general sense of the meeting last time was that people liked the idea behind this but they were concerned that we should try to make the process similar to ARIN's activities and, in this revised proposal, we have converged on similar behaviours. The timelines and contact processes are similar. I think we've achieved the goal we were set at the last meeting. RANDY BUSH: I have to say I'm also very negative about allowing these names. GEORGE MICHAELSON: I know and I understand that. Within our own community, we have a large number of delegations in this region which are single nameserver delegated. To declare those lame we would have a stronger issue. Health in DNS is an issue and something we should talk about in this SIG but it's really not part of this proposal. The discussions that we had leading up to the revision included some activity in the RIPE meeting in Barcelona and the RIPE community are actually very interested in improving DNS standards. There is a parallel activity going on inside the IETF to try and formalise the current belief of quality in DNS which is making a much more stronger definition of lameness and, of course, we would track that and adopt any definition outcomes in this process. I think there is good community convergence on improving DNS in general. Q. I think I agree with Randy that a single nameserver is a problematic state. Would it be reasonable to consider flagging in the database that this is a configured delegation if it was only a single nameserver? GEORGE MICHAELSON: We could think about that. I'd like discussion on the mailing list. I wouldn't feel comfortable just doing this because we have a lot in the region but I think we could talk about that. Q. I'm from JPNIC and I have a question from my colleagues. That question is, we normally use two nameservers - if only one of those are lame, then how does it affect the policy? GEORGE MICHAELSON: Well, firstly, at this stage, this activity is restricted to objects directly managed from APNIC, because I think it would be preempting the relationship with you as the NIR to disable data coming from you. So, at the moment, if would have no effect on you, because we are not going to disable resources that are managed under your processes. But the general question - if we have a resource with two nameservers and one of them is persistently lame, we will disable that one nameserver and the other will be left functional. It will be returning a record that will probably list both nameservers and, it may list many other nameservers. We can't prevent that. We can't prevent caching of that other nameserver which is lame. This is not completely good because it leaves information in glue or in cached state, which refers to a nameserver that we know is not working, but the general sense from last time, from discussions with people, is that it's not appropriate to say, if any one nameserver is not working, disable the whole domain. That was felt to be too aggressive. We will have an incremental approach. If you would like us to include JPNIC resources under this procedure, we can do that but, at the moment, it will really only apply to resources maintained at APNIC. JOE ABLEY: So, for the record, if there is anybody in the room here who would object to APNIC proceeding with a trial based on this proposal? Nobody? Next on the list is Randy Bush who has a proposal regarding delegation of zones under 2.0.0.2.ip6.arpa. RANDY BUSH: I've presented this page, I don't know why I'm doing it again. There's an Internet draft by that name which talks about delegation of this part of the IPv6. I'm going to explain what that means. And possibly some implications for the delegation from the registry. I'm not suggesting policy. I think Geoff will follow me. 6to4... it's a way to allow v6 when its connection to the Internet is v4. You don't want a tunnel set-up. So what happens is the border router translates incoming packets for the v6 address encapsulated and pulls out the v6 address inside and vice versa. OK. It's encapsulating v6 packets, and it encapsulate it in v4 and traverses the Net to the v4 destination that maps that v6 address. Gets there, decapsulates it. It's using the normal v4 routing. There's no no tunnel set-up. None of that. It's a dirty trick. It's sital, but it works. If you are a 6to4 site with a host in this space, your v6 address will be this. And it's easy for you to do this delegation because you control the foo.bar domain. This is in your domain space and your domain control and you don't have to go ask anyone else for a special delegation. Unfortunately, this is not true for the reverse. The reverse is in 2.0.0.2.ip6.arpa. Excuse the line here, I wanted it to be big print. You're going to want to put a regard that looks like this in the DNS and note that this is in the 2.0.0.2.ip6.arpa. But you don't control this part of the space. That's probably some parent of yours. So you have to negotiate having the delegation for the v6 map space. But Keith Moore says the 6 to 4 space directly maps the v4 space. Remember from the first foil your v6 address is a map of your v4 address space into 2.0.0.2.ip6.arpa. So it is a 1 to 1 mapping. So therefore the holders of IPv4 who should be able to request the delegation of the 2.0.0.2.ip6.arpa that maps that part of the tree of their v4 address. In other words, it looks exactly like your IPv4 in the arpa delegation. The idea is you should be able to get the 2002 delegation from the same place you got the in-addr delegation. But there's a problem with that. The RIRs delegate the v4 space and the in-addr.arpa zones. The 2006 arpa should be delegated by the RIRs along with the corresponding space. There is a problem, which is the LIR requesting the v4 delegation may not be interested in v6. They may not want the corresponding IPv6 arpa delegation. So I'm a customer of that ISP, wanting to use a 6 to 4 gateway. my ISP doesn't know anything about that and they don't answer my requests to serve and delegate the arpa zone. They probably would have given me v6 connectivity. OK. So I have to go up the tree to the closest branch that does serve 2.0.0.2.ip6.arpa. So maybe my ISPs, my v6 ISP and I can jump the stupid IPv4-only ISP. But unfortunately, commonly, my ISP's parent may be the RIR. This means that the RIRs are going to have to delegate small fragments to end sites on the 2.0.0.2.ip6.arpa. This is an administrative load on the RIRs. Whether to accept it or not might be a policy decision here and there are also some technology acts you might consider. I would also note that the use of 6to4 in general is probably not that common. I don't think you're going to be getting 10,000 of these requests. I don't think you're going to be getting 1,000 of these requests. You might get 100. But I think especially in this region, you probably won't because there's much more native v6. I think this is going to be much more of a problem in the States where v6 is only starting. And this should take you away to Geoff's presentation. If anybody has any questions about this before? ... About something being sort of yesterday being the same as today being the same as tomorrow. There are 127 delegations in 2002 in the old IPv6. We get a new one about every six weeks. It's pretty low and likely to remain so. RANDY BUSH: Where do they come from geographically? A. Finland. RANDY BUSH: Very small number in Finland. ANNE LORD: What's the status of the draft? RANDY BUSH: She's asking what the status of the draft is. Hang on. It's in last call. And last call's due to end on... we had last call on July 14. So it should be a four week last call. That would be a four week last call. That last call should be ending about now and so it might pass through the IESG in the next - it's not on this week's agenda so maybe two weeks hence. I could answer these sorts of questions online. GEOFF HUSTON: Thanks, Randy. What I've got here is, I must admit, much more exploratory in nature and certainly well worth comment. It's not a full-baked idea and I'd be hesitant to say it's a half-baked idea. It's certainly just very informal. There is a draft out there that goes into a little bit more detail than Randy's draft that actually describes some of the issues here about reverse delegation in this space, a draft call 64 dns.03. If you're going to do this, it's not worth a huge amount of effort. You want something that's very easy to deploy, that doesn't require savage hacks on existing operations, it does the job efficiently. It also tries to get the cost and benefit to those who do benefit so it doesn't imply a huge burden on anyone else and it doesn't adversely affect security. That's the requirements that have been taken from Keith's draft. There's nothing being invented here. The various approaches that Keith goes through basically say, well, if this really is mapping in- addr.arpa, then maybe you can get guess on the fly what it will be. Or you can ignore delegation completely. If you can't find one, go to a known location in the 6to4 address space and see if there's a query that's going to answer you or you can alter the way servers actually operate. All of these approaches are hacks in various ways. They do represent some pretty savage compromises. What Randy is saying is that, if you do do conventional delegation, the problem is that your upstream in v4 might not have a 2.0.0.2 inverse delegation. So, if you're a client of some provider and you want an entry made for your v4 address, you have to go further up the tree. But, by going further up the tree, no-one can actually definitively say it's your address space that you're truly trying to get the reverse for. Because the provider's records that indicate they delegated that space to you may be in confidence, it may not be public information. So there's a certain amount of guess work, even when a large range of v4 block has been delegated in this way, in this v6 reverse space, that an entity might have to do the same 'hop over' delegationings and do the same kind of guess work. So, if you do this approach, there's a certain amount of unreliability in it which can be a burden, particularly if you want to be accurate. On the other hand, as Randy suggests, it might be a small enough issue that it's not a problem. There are other approaches. One approach is that, if you can't find an explicit delegation of that particular v6 address, 6to4 address, you look up the equivalent in-addr.arpa space and find the matching NS delegation for that particular piece of v4 space, and then send your 6to4 reverse query to that server in the vague hope that, if that server's doing v4, it's doing v6. It requires altered resolvers. It's a hack and a bad one and, if you're a single site at home and you've got a /32 from your provider, you don't own a nameserver for that /32 reverse space. It may be part of a larger name space mapping from your upstream. So that approach seemed like a bit of a waste of time. The next one is to actually say that, if I can't find that server, I infer it. And the way it works is, if I can't find a delegated server for a particular 6to4 address, I go and look at your 6to4 address at a known 64-bit IANA file. So I always go and look at the same address globally. If you want to set up the server, you set it up on a certain set of addresses and the very, very intelligent resolver out here will send you a query, even though there's no delegation. Altered resolvers reserving local address space. Again - it's a pretty ugly hack and it's not very pleasant. The next kind of question is why are we bothering? Why does the reverse space have to actually come up with the right answer? If all of this is to actually provide any old reverse answer because some applications like to reverse map the address, why not just hand them back an answer so that, if you can't find it, fake it, so that you return back an address and say, "You wanted an answer. Here is an answer. It's not right, but it's an answer." If you want to do it right, there's a problem. Certainly, if you wanted to hack it out, that last one will hack it out and hand back something. If you want to do it right, there's some overhead. Then you go, "But hang on a second - what's the architecture of a 6to4 network?" Here I must admit I'm heading into ground and territory that I was trying to find IETF documentation for and could not. I actually went to the author of the 6to4 architecture, Keith Moore, and asked him how they number their hosts? I got back this approach here. Bill Manning just walked out which is a pity because he disagrees with this and I don't know. Let's say that I have a gateway, G1, and I have some local hosts on that local network. This is a v6 and v4 network and these things are all dual-stamped. According to Keith, the architecture is that all of these machines have their own separate v4 addresses and that's fine. But, in the v6 world, all of these machines inherit the v4 gateway address. They don't use their own. So all of these machines run off that machine's v4 address and differ only in the lower part. If you make that assumption and, if you assume that that's the way 6to4 gets its internal addressing architecture, then the rest of my slight hack makes some sense. But, if I'm wrong on this and if these things actually use their own addresses in their mapped 6to4, then there's a problem. Bill has walked in the door. I'll give him a chance to digest this and, if he wants to make a comment as to whether this addressing architecture is good or bad or irrelevant or not might be helpful to me. BILL MANNING: Incomprehensible. Keep going. GEOFF HUSTON: These machines have the following v4 addresses. These machines here have the following v6 addresses using that 6to4 mapped address. As Keith Moore explained it to me, all of these machines use that machine's v4 address. BILL MANNING: I cannot speak to which one is the correct way. All I can speak to is how people have registered stuff in 2.0.0.2 over the last six or seven years and it's not the top method. It's the bottom method I believe. GEOFF HUSTON: This is all one architecture. BILL MANNING: They're registering the prefix length. If it's, say, /32 or /8. GEOFF HUSTON: I understand that but I'm looking at it. RANDY BUSH: You two are not in disagreement. GEOFF HUSTON: We're not, no. BILL MANNING: I don't know how it happens internally. I believe what happens is that things have changed over the year. If you have a 6to4 implementation of hardware and software from 1998, it will be different to the implementation of 2004. GEOFF HUSTON: With that in mind (and I could well be very wrong), if this is the case, these individual gateways are effectively using the equivalent of /32s in v4, then it is possible to create an automated system that is pretty easy. Because what you do is you delegate at the gateway. In other words, you delegate v6 at the 48-bit position, which is the equivalent of the /32 in v4. You delegate at each individual 6to4 network. And the issue is you automate it. The way it works, as far as I can see in a purely automated system, you have a web-based system that can be accessed only by 6to4 clients. If anyone else goes there, the page will say, "Here's an FAQ. Go away." if you go there, you can only delegate your own gateway. It's actually relatively tight. If we assume that whole reverse mapping space has delegations for individual 6to4 networks so it delegates on the gateway. And here it doesn't matter if the design file is flat or if you structure it, it doesn't matter because your delegations are always exactly the same point. We perform it by a web service and you only get to the real pages if you're coming from a v6 6to4 address. Anything else gives you an FAQ. It operates using a https so there's no proxy holding. It prevents people mucking around on that. It only provides a web page to enter a delegation if you're a source address. You affect your own delegation but no-one else’s. It allows you to enter some number of servers. I don't care. It's a detail. It's greater than one. It also allows, in my mind, an e- mail contact. We do a lameness check as George as described. Why not? It says, "Now I've got this data, does it work properly?" if it does, it accepts the delegation, cues it up for entry and off you go. If not, it does a lameness diagnostic and says, "Good try but you need to change something." You can also run the same old lameness checks, time stamp the thing, go back and check it periodically, much as George was suggesting earlier. You can do the full lameness checks. I've just put some days in here. It doesn't matter. I'd say whatever George suggested as a process works fine. The interesting thing is, if there's an existing delegation, it brings you back those details and allows you to change it. You can change your own gateway delegation. You can't change anyone else's. It's fully automated. It gets over the entire 'hop over' problem. It's really just the amount of time it takes to cue it up, put it in the zone file and get it live. You can only change your own record, of course. Problems. All of those clients inside that 6to4 network can go and change the record as well and maybe, if this is a corporate entity or a university, the network administrator may be not so keen on having a student change the entire site's reverse delegation on the fly. But realistically, local problem-local response. There are firewalls. if you're worried, go and stop your clients from accessing it. Proxies won't hold. You can't change someone else's delegation that way. What about all the folks on DHCP trying to do almost dynamic 6to4? I get the address from DHCP and I start doing 6to4 mapping? I think putting reverse servers on that doesn't make a lot of sense anyway. But the pool number could do the same thing as the local network administrator, putting in fixed entries and stopping people from changing it or simply say that that's how it works. As far as the zone-owner is concerned, I don't think it's a SIG issue. What about if I hijack a v4 address, do the 6to4 and come into the reverse zone and make some changes. Once I've hijacked your v4 address, I can do so many bad things that changing the reverse on your 6to4 is irrelevant. Once you start to pervert the routing system in that sense, you're in deep water anyway. What about folk with lots and lots of gate waist who want to separately administer all of them. My answer is that this is really a short-term small hack. If you're big enough that this is really a problem, go and run v6. There may be more issues that I haven't figured out. There probably are. And I may have got this address architecture entirely wrong, although I haven't seen anyone else describe the internal 6to4 address architecture of these eyes lighted islands. So this whole, sort of, automated web server that is simply a unit that simply does it, is predicated on the assumption that this whole thing works off a fixed point in the 6to4 address space. I'm delegating a /32. If I have to delegate other bits, I actually don't know from the source address how big the thing is I should be delegating. Q. When it comes to being a 6to4? (Question inaudible) GEOFF HUSTON: You're assuming that I think the router is cracking beneath me. RANDY BUSH: You should fix your Whois. GEOFF HUSTON: We could go to Whois and make the boundary larger. GEORGE MICHAELSON: I have just an observation that one of your earlier stated goals is trying to find a low- overhead solution. Managing this activity has potential to increase overhead. It seems to me not telling us the Whois has the benefit of keeping it low-overhead. GEOFF HUSTON: That's very true but the assumption is that you're delegating at a fixed pony. I was hoping for a little bit of guidance from other folk in the room if they've been running 6to4. Is anyone running 6to4? RANDY BUSH: I have run it. I'm not running it today. GEOFF HUSTON: I'm spending a lot of time on almost a non-problem. RANDY BUSH: That's a point. I did try and say that. GEOFF HUSTON: I suppose for us the decision is the RIRs need to make some approach into how to handle this. If we go down this route, we're almost cementing in place this kind of addressing architecture, which may not be a bad thing, and then setting it and letting it go - low- overhead and no-overhead when it's set up and letting it run. RANDY BUSH: I have prophesied that in the ARIN region, the only region where the costs of automating this will be greater than the costs of doing all three entries with e-mails. GEOFF HUSTON: A very valid point. I must admit - the level of discussion this is getting in this room certainly leads me to the view that the overhead is so low in doing it manually, we might as well just do it manually with an e-mail address and staff. Bill? BILL MANNING: The first 2.0.0.2 entry actually in ip 6 int was on March 6, 2001. Virtually all of the rest of them - that was the US Department of Energy - virtually all of the rest of them are in Finland or Germany. The next larger set comes from Malaysia. I can do these with VMAX and VI. It's not going to be much of a problem presuming that native IPv6 support and capability are up there. It's much easier to do that, just native v6. I wouldn't put a lot of effort into this other than as a completeness thing. If 2.0.0.2 exists, it ought to be populated but the method for doing population I think is, you know... GEOFF HUSTON: I'm quite happy to sit on this and say VI and an e-mail contact and that's fine by me too. It's not my job. BILL MANNING: The other thing besides the e-mail contact is the date. It's very helpful. GEOFF HUSTON: Thanks, Bill. Works for me. Thank you. JOE ABLEY: So that was the last item on the agenda for this meeting. Does anybody have any other issues they'd like to raise? OK, I guess not. In which case, thank you all for coming. I have one procedural meeting-type announcement to make which is that we have a room change for the APOPs meeting at 6 pm. It was previously in the Emerald Room and it will now be in the Crystal Room, which is this room. The APOPs meeting will be in this room and not the room that's on the schedule. That's it. Thank you very much for coming. APPLAUSE