Address Policy SIG, Thursday Aug 21, 9:05-11:00 am KENNY HUANG: OK. Good morning. OK, thank you for coming in the early morning. My name is Kenny Huang, one of the co-chairs of the address policy special interest group. Today, we have four presentations in the address policy SIG. First of all, the order is slightly changed. Initially, we're starting with Geoff Huston from Telstra and then go to Kosuke Ito from IPv6 Promotion Council. Then going back to Geoff Huston from Telstra again. So, the presentation will be presented by Geoff Huston from Telstra talking about distribution mechanisms for unique local IPv6 unicast addresses. GEOFF HUSTON: OK, so what I want to talk about today is a response - a potential response - to the work going on in the IPv6 working group about unique local-use address architecture requirements. Because I believe that that work does pose, I think, some interesting issues for the RIRs in terms of address distribution functionality. The background to all of this - as we saw in a slide yesterday in the v6 SIG, there is a requirement inside the IPv6 address architecture for what you call local-use addresses. Now, you might think of these a little bit in the same way that we use RFC 1918 private addresses in v4. But there's one critical distinction and that is that these addresses are all unique. It's not the same network every time. What we want is a requirement for these addresses in an abstract or architectural sense. They need to be useable whether you're connected to an upstream or not. So they're not part of a normal PA address space which is provided aggregated. They’re useable in what we call a non-connected context. V6 already has link-local addresses but these are meant to be more than a single link. They're meant to be passed something that - span something that used to be called a site, a number of links in a single administrative domain. But, like RFC 1918 addresses in v4, these addresses are not meant to appear in the global routing table. This is not meant to be the creation of a new swamp space for very small addresses. They're not intended to be globally routed. They're very much intended to be unique. They're not multicast addresses. They are indeed unicast addresses. Initially, this was called site- local and we had the idea of constantly reusing the prefix on a first-site basis. In March, at a working group meeting, there was a sense of the route taken that the existing site locals as defined in the v6 architecture was to be deprecated. That decision has sort of gone through. I notice there are appeals in the IETF around that decision. I don't intend in this presentation to be a repeat of that particular debate. I'd like to actually take on some of the work that's already been prepared in the IETF draft and look at its implications. The proposal I'm working on is a draft written by Bob Hinden that proposes a local-use address pool which is actually unique. The question raised by this proposal is what do we want from local-use addresses. And, from an RIR perspective, what sort of address distribution mechanisms are actually necessary? The next issue - if you read the draft very carefully, it doesn't actually script in a role for the RIRs themselves. What it scripts in is some other notional registry that does distribution of these addresses. So the question in my mind when I read this is , is there a role for the RIRs in distributing these forms of local-use addresses? And, if there is such a role, how is it different to the current role of address distribution in the RIR world? If I take the characteristics in that draft and list them out here, this is what the draft proposes as characteristics of local-use interests. They're all coming from a single common prefix - FC 00/7. All of them have the same size. They're a /48. So you have a front-end prefix - FC00::/8 - then you have a net ID and then you have local identifiers. They propose that there's no internal structure within that global identifier. What that means is that, if you apply for two, they will not be consecutive numbers and you cannot aggregate them. They also regard this assignment information as being recorded and stored in a reliable manner but they don't explicitly say that it should be published. Indeed, in the draft, they claim that this assignment information should not be published, but should indeed be held in a reliable fashion in a form of what we call escrow, so that the data is available if necessary but not published and last of course and underneath all this is the desire that these addresses are not part of a global routing table. They’re not part of what they regard as provider aggregate space. So those are the characteristics of local-use addresses as presented in the draft. Let's go into this a little bit deeper. They propose using /48 blocks drawn from that single common prefix. And they propose two mechanisms. Half of the space or 1.1 trillion global identifiers would be drawn at random, so anyone could sit at a computer, write a random algorithm and draw one of these global identifiers and use it. The problems I see is that that is not a very good mechanism is if uniqueness is important because, even though there might be a space of 1.1 trillion such global identifiers, the underlying mathematics of random selection indicate that, after some 1.2 million random draws, the probability that two folk have drawn the same number is greater than a half. So that it's not that unique, unfortunately. The draft, however, also proposes that the other half of this space, the other 1.1 trillion identifiers are guaranteed to be unique and the way they guarantee uniqueness is that they propose a registry to manage the other half - FD 00::/8 and anyone can apply for a global identifier and they get back a unique global identifier that is guaranteed to be unique. So let's have a look at that second registry. What do they want in terms of the IETF working group? What are they proposing as being the characteristics of this identifier, this registry? You'll see that it's different from the way we currently work. The way we currently work is there's a certain amount of qualification of people who get provider aggregateable address space. It's very hard for an individual to go to a registry and meet all the criteria of the direct allocation of unicast address space today. In the local-use registry, they actually propose that this registry be accessible by anybody, individuals as well as companies. They imply that it should be very, very low cost and that implies a high degree of automation. The current work being performed by hostmasters is definitely not part of this proposal. They're proposing that it really doesn't matter who applies for these addresses, so the credentials you have to present to the recommendation when you apply might even be limited to supplying a name, an e-mail address and credit card number. The identity requirement is actually quite limited. They also imply that it should be quick, not in terms of months, weeks or days but quick in terms of seconds - you apply, you get it. It should be inexpensive. The draft actually proposes an amount - 10 euros - you can see there was some European influence there - but you get the scale of things that, in applying for an address, they certainly say that there might be some service fees, but those fees would not be high. They also say that, every time the registry allocates global ID, it should do so randomly from that entire 1.1 trillion space. So the numbers come out randomly. Whatever charges are applied, you should be able to map those charges to the cost of running the services. So the charges should be transparent. They also imply quite a SIG change to the current allocation mechanism. Currently, one could describe most of the RIR allocations at leases. There is a period when you have to agree to refresh your membership to continue to use that space. The draft proposes once and forever - once you have a global ID, that's it, forever. Does it allow for agencies? Is there a wholesale extraction? It's not obvious to me that there is. They actually say a single central registry but, as we've found already in the registry business, trying to get everyone to work from one resource is difficult and the reason why we have regional registries and even national and local registries is that there is a certain amount of wholesaling, if you will, or agency work to support the function. It's an open issue whether this is required here. Because these allocations are eternal - they're meant to be forever - some care needs to be taken in storing that information. We actually need to look very hard at how to provide enduring records. And they propose that the publication - who gets which global ID - not be publicly available. So, once you get an ID, it is very hard for you to go to some upstream provider and substantiate the fact that it's really your ID and that the provider is able to route it. That information would not normally be available from the registry. So, when we compare this to the way the RIRs currently work, there are some differences and perhaps some choices. If we, the RIRs, wish to take on this work, we have to look at some of the differences. Currently, the resources that we allocate are renewable. If you cease to maintain a registry relationship with registry-allocated number resources, it is difficult for you to maintain the unique use of those resources. But, in this proposal, you go there once, you do your transaction and the resource is yours forever. Even after you die, the resource is yours forever. It never gets reused. These are rip-offs you rip the address off, send it out and never see it ever again. That's a difference. The model is not based around membership. It is transaction-based. There are issues around mutuality and associations. There are issues around the status of the organisation and its relationship in terms of taxation, in terms of the way services are provided, because this is a transaction model rather than membership-based. The service fees have to transparently reflect the cost, not only of undertaking the transaction, but the future cost of maintaining the record forever. So, you're not just looking at the cost of some web-based engine and a credit card transaction engine, you're also looking at the future cost of maintaining in a very high- integrity manner, that allocation forever. So this requires, I think, from the registries some thought about what cost factors actually apply to this work and, in so doing, also understand how do you maintain these records in a reliable fashion without using today's Whois or various other forms of publication mechanisms? It's considered to be a high-volume, low-value transaction, which is almost the opposite of today's RIR work which is lower volume, very much high-value. So it's quite a different operation. In all of this, you're trying to make sure that the allocations you perform are truly random, so they're not aggregateable, they're stable and that, if someone continually bangs against your machine, second by second, and someone tries to hoard the market, we have to prevent such distortions. It should be available to all but have some barriers to make sure that it's not captured by any single entity or group of entities. A single registry in a regulatory sense is always a problem and a single registry that sets fees in a regulatory sense is something we normally call a monopoly. A group of registries that set fees in collusion is normally called a cartel. These are not words that give comfort to public regulators. So, somehow, in constructing such a registry, we have to be aware of conventional regulatory environments if there is to be competition in providing such services, how will competition be provided? Or, if it is indeed truly to be a monopoly, how can we satisfy regulatory requirements to make sure that the market is fair, open, equitable and actually satisfies very many forms of regulatory environments? The real issue here is how is the fee set? How can you justify a fee but, at the same time, make sure that you're not setting a monopoly rental? And how can you truly ensure that the fee, whatever it may be, is low enough that someone in Malawi can get hold of one of these addresses and use them? But, at the same time, ensure that the fee is not so low that a very large corporate in some richer part of the world couldn't then allocate to themselves millions upon millions of these things and attempt to horde it. So the fee setting on a global basis is an interesting problem. So, if we look at this, I suspect that it's actually a different service part to the existing RIR operation. It's not just doing the same things we do today. it's transactions, not membership. As I said before, it's potentially very high volume, low value, as distinct from the current operation, where there is very high value placed upon the integrity and identity of the applicant, maintaining public records and ensuring public access into the assignment information. This is quite the opposite. This is automated, without any form of hostmaster evaluation and the publication mechanism is effectively one that's private, not public. How would we set up local agencies if local agencies are required? Is this a form of wholesaling? How can one wholesale randomness? Very difficult. If I get such an allocation and, for some reason, wish to transfer it, because the information that I have is a secret, can transfers be supported? Does it make any sense to support transfers? Are there legitimate reasons why transfers are necessary around the cost of renumbering? There are a number of issues that need further development. Lastly, I suspect there are broader considerations that actually aren't covered in the draft and perhaps if you wish to have input on this, the IPv6 working group mailing list is the appropriate place to take your questions. But, if the RIRs consider themselves as being a candidate operator for this space, we'll also need to consider these questions inside our forums as well. How do we maintain the distinction between these local-use unicast addresses and provider aggregated global-use unicast addresses? They're just unicast IPv6 addresses and, in theory, both are equally routable. Who gets to decide what really is routable and what isn't? It appears to be saying that it's actually the operators, the carriers, that get to decide what they put in their routing tables. But the intent of the draft and the intent of the working group is to try and place constraints around the way these things are registered, such that routing them is actually very difficult. Because you can't prove that you own it, going to your provider and saying, "Please route it," becomes an exercise in guessing and the provider might not be comfortable in doing that. Is this an alternate way, a cheap way, of getting v6 addresses out there that circumvents the existing v6 allocation policies? We certainly now have two classes of unicast addresses out there, if this thing goes ahead. We have what I call leased addresses, host- master- qualified, RIR-qualified and provider aggregated. There's a second set of addresses that don't have those qualities. They're not leased, they're enduring, they're not qualified, they're unqualified and anyone can get them. They're /48 s, they're provider-independent. Currently on the working group, there is a discussion where you can see are these addresses really going to be isolated from the routing system? If someone comes along to an operator and says, "Here is an address, here is money, please route this," the temptation to route is overwhelming. After all, money is money. Are we repeating the construction of the v4 swamp, the class c space, the /24s? The other issue is, even if we are, is this is bad thing? If the only thing that gets v6 working is actually widespread use of global addresses that you can get quickly and easily, independent of a provider, if that's the thing that gets v6 being used, then maybe it's not such a bad thing. After all, the amount of prefixes one can put into a routing table does get larger with each generation of silicon and trying to engineer a network for the future based on the characteristics of silicon in the past is perhaps being too conservative. Nevertheless, I stress it's an open issue and if you have views on this, either raise them here and now, which would be a good thing, and/or take them into the IPv6 working group mailing list and discuss them there. That's the end of the presentation. Are there any questions on this or comments? KENNY HUANG: Any questions or comments? TAKASHI ARANO: If my understanding is correct, one single individual can get a /48. GEOFF HUSTON: One single individual can go to this machine every day and spend money and get multiple /48s for as long as they want. This contains 2.2 trillion identifiers. The draft suggests cutting it in half and having 1.1 trillion being handled by a central registry, absolutely unique guaranteed, and the other half being done by a local spin of your own wheel. You just pick an address and use it. You don't pay anybody. But the characteristics of that second type is that it's not very unique and I would contend mathematically, once a whole lot of people do this, once you get over 1,200,000 it's not very unique. That may not be a problem. RANDY BUSH: Is anybody taking this seriously? GEOFF HUSTON: As far as I understand, in terms of taking this seriously, if I interpret 'this' as being local-use unicast addresses, then yes, there are many corporations - and I've heard a couple that say, "We would like to internally number in a way that's provider-independent and unique, that we don't ever need to renumber once we've done it once internally." So, from that respect, if your answer is, "Is anyone taking this seriously?" as I understand it, yes, I have direct knowledge of some entities that are taking this seriously. If your question is, "Do many people take this seriously?" I don't know. Do 1.1 trillion entities take this seriously? I doubt it. RANDY BUSH: Since the v6 address space is so enormous, why don't you just allocate the real space? GEOFF HUSTON: As I understand the folk who are "taking this seriously", the existing mechanisms, are provider aggregated. Corporate users are not happy with trying to do long-term stable numbering internally using addresses that are in effect borrowed from a provider. RANDY BUSH: I understood that point. I was trying to say that, since the v6 space is perceived to be so enormous as to never be a problem, why don't the RIRs just give those users independent space? GEOFF HUSTON: And, if you implemented this … RANDY BUSH: Just as normal, just as normal policy. Why this strange and baroque scheme? GEOFF HUSTON: Why this strange and baroque scheme - as I understand it, the interaction between the RIRs and the IETF, the implicit basis behind the current v6 unicast allocation policies, is one that attempts to place very strong emphasis on provider-based aggregation and constrain the size of the routing table thereby. You and I might agree that that's a backward-looking perspective and that trying to protect tomorrow's routing table from yesterday's silicon doesn't make an awful lot of sense. But, in the context of today's policies, this draft has appeared in terms of saying, "This is a way of having draft space that isn't intended to coincide with the routing problem, that is intended to run on a completely different mechanism." The other argument is, "What's this routing space stuff anyway? Why don't we just allocate as required in the market?" - that's a slightly different debate but nevertheless a substantive one. What I'm trying to do here is simply say, "Given that the IETF is thinking about this, one potential RIR response is to say, if that's what you want, this is the way it could be done." It's not saying this is the way it should be done. It's saying this is the way it could be done. Does that answer your question? RANDY BUSH: Yes. Thank you. GEOFF HUSTON: Thank you. KENNY HUANG: Let's move on to the next session. First of all, KT is our principal sponsor and also the MyAPNIC demo is running at the APNIC help desk. Also, please check the onsite notice board on the APNIC website for updated information. So the next speaker is Kosuke Ito from the IPv6 Promotion Council and he will speak about future IPv6 allocations and services. KOSUKE ITO: Good morning, everyone. I'm from the IPv6 Promotion Council. I have been doing a theoretical report of the trials. I'm going to update you again for that. I will talk about the update from the last report. We have conducted the third interview last month and the beginning of this month for the members and trying to see what's going on with the members in this trial program. The current members, nothing changed. As you see, these are all for all types of service providers, [who] are participating in this program to figure out what is the future potential of this service in the IPv6 area. I've summarised the results of the interview. The first one is that task on the always-on fixed-IP service is still increasing in upstreaming, which means that, from the user's side to the Internet side especially. This was typically the increase of the P2P connection and also the large amount of data transfer like hard-disc copy to another Internet. That's becoming common among users in this trial. And also, from their observations, about 40% of the traffic is P2P. Also, about three of them have actually started IPv6 trials on IPv4 infrastructure. Typically the service provider uses 6to4 mechanisms to start the IPv6 trials. So, actually, they're starting to look into the v6 transition mechanisms and also trying to figure out what's the cost to move on to IPv6. According to them, the goodness of this trial is expressed as reported before. They still think of the large-scale trial and large-scale application as pretty much about the freedom and also resulting in a simplified design network. Like they want plenty of address space and plenty of HA space on the wireless service in order to provide quick ID- issuing services. They don't have to wait for the new allocation in a slow-start policy or something like that. And also they can accommodate a block like the multiple address, the multiple assignment to users. That's giving new services to users to operate in a flexible form for users, like the great ease of providing additional services like IP-phone and IPv6 transition. And also they can simulate IPv6-era operation. They expressed also that it seems to be more simple network design with no need to have additional mechanisms such as PPPoE or something like that. That's where this trial has really benefited for them to look into new services. However, they also struggled with the down side effects from this trial. They felt that there was a greater increase of attacks to the end-user's site and especially the lack of knowledge about security protection is a problem from the operational side of supporting work. Like port scanning is increasing or messenger advertising is increasing. The open-relay things or virus transmission is really expanding. And through this program, we are trying to make the operational ease and we are implementing a registry system for this trial program. And the good thing is that we've just simplified the registry operation of management work. And also a test bed for a future IPv6 registry system, the IPv6 address assignment information and also it's interlinked with Whois and DNS. And the reason is quite simple - to minimise the manual work for avoiding human errors. So far, everything has been done in manual for this trial program. And publication can be submitted by e-mails and correspondence as well. And address management is based on Microsoft Excel, just a listing out of the works and also manual changes that have been done so far in registration. So we're trying to minimise the manual work for putting into the system. This is an overview of the system. This is a member site and through the authentication mechanism there is the website to get application forms and also sharing the information and right here the query DB to put the query, this thing. And we can deal with the queries. And after evaluation and registration work, it will be installed in the registry management system and then we're looking at these other things. This is also pretty much like the next generation. So, through this system, our information can be seen from the public point of view. So it's more open. And we emphasise more sharing of information between members and IPv6 Promotion Council. And this is very much a typical way of doing the registry system. And we can give the rest of the registered info for the members for the list of addresses assigned and also the status of the reverse DNS registration. This is really solving issues, pretty much. And also the link to DNS and Whois. OK, then considerations. This is pretty much three things. A global address service in large-scale from the initial point gives ISPs a greater market with a smaller overhead. This is pretty much remarks for the ISP side and also for the end users' point of view. They're receiving a more flexible service and they can enjoy new applications such as P2P or IP-phone, etc. And also, through this experience of the trial, makes the participating ISPs convinced to adopt IPv6 service. That's because they get the feeling of large network space, get the feeling of the global space rather than continuing in IPv4 small space. And also the other point of view would be the security point of view. They are also thinking of the IPv6 registry function. So that's the reasons why people are starting to think of IPv6 and actually some of the ISPs are starting off IPv6 trials. Continuing this trial is very good to us and the people on the IPv6 PC side are really happy with the operations and results. So more giving the loose shape of this trial program - it's a more formal way of conducting this trial to make it operate for the community. Yes, that's all for this time. Thank you very much. If there's any questions about this? KENNY HUANG: Any questions or comments? OK, thank you. So the next speaker is Paul Wilson from APNIC. PAUL WILSON: Thank you and good morning. I hope that the presentation slides that I'm about to show have a few slight changes from the slides that are on the website - there are some additional slides that have been added for clarity. This proposal is about introducing a new, different utilisation requirement for IPv4 address space and it's a requirement based on… I hope the presentation is clear in its justification. There is a bit of mathematics. I hope you can give me your attention to help to understand this. The HD ratio has been selected for use with IPv6 policies. It's a way of measuring the utilisation of addresses in a hierarchically managed address space and it was used in RFC3194. To calculate the host density of any particular address space, you calculate the log of the number of host addresses utilised over the log of the number of host addresses available. That gives you a measure of utilisation which is supposed to be a realistic and useful for hierarchically managed address space. As I mentioned, it has been adopted for IPv6 and so that the general principle of the HD ratio has been endorsed for address space utilisation. Specifically for IPv6, the criteria as I'm sure you all know, [is that] once an ISP or LIR has reached an HD ratio of 0.8 in their address space, then they can come back to the registry and see some more. You might have seen this graph which shows what the 0.8 HD ratio looks like in terms of percentage utilisation for different sizes of address spots. Your utilisation in percentage terms needs to reach 10.9% to reach more address space. That percentage utilisation requirement goes down very quickly, as you can see in this graph, down to 1.18% for a /16 for instance. Now this presentation and proposal is intended to address a particular problem with respect to IPv4 address space management. That is that ever since the days of RFC 2050, we have relied on a used utilisation requirement for ISP address space allocated from RIRs. So once an LIR or ISP has suballocated 80% of their address space, they have to come back and request an additional block. The point is that the same requirement is made for all address blocks regardless of the size. If you've got a small LIR with a small amount of address space, then 80% is the requirement, likewise if you're a very large ISP or LIR. And the policy makes no allowance for the need for hierarchical management, particularly in large address blocks. So if we accept the premise of the HD ratio, which has already been accepted for IPv6, then what we would conclude is that this really imposes an unreasonable management overhead for the larger ISPs. So the proposal that I'm making is summarised here on the slide, which is not on the website. But I'm certain it's quite clear what's being proposed. To adopt an HD-based IPv4 utilisation requirement. That will allow lower percentage terms for larger blocks to make larger hierarchically management of those blocks. What is being proposed is a slight variation on the HD ratio. It's necessary to go into the IPv4 context. The proposed value is 0.966. That value is based on the current 80% principle. I'll show you in the slides which follow. I'll provide a justification for this proposal both for general proposals and also the justification for the specific value of 0.966. You remember the chart shown just before for IPv6 utilisation which showed the value or the curve for 0.80 for IPv6 and here is what this proposal will result in for IPv4. So it's a much less steep curve than you see for IPv6 and it shows you that for instance, if you have about a /23, then the proposal results in an 80% utilisation requirement for that size address block But as the address block gets larger, say a /16, the utilisation requirement drops to just below 70%. If you get all the way up to a /8, it's about 56%. As you can see, that 80% utilisation which we currently rely on is dropping as the address holdings of the ISP get larger. Here is a table which shows you the specific values for a selection of prefixes that the calculation that I'll show you in a minute can be done for any prefix at all and for non-CIDR blocks as well. 68.59% for a /16. By way of justifying this proposal, the allocation system that we currently are operating allows a hierarchy from the RIR down to the ISP or LIR and down to the customers and the infrastructure. The RIR makes allocations to ISPs, the ISPs make assignments to customers and infrastructure. And an ISP will make successive assignments in this manner until they reach 80%. They'll receive another allocation from the registry and continue to make assignments. So, this is a hierarchical system but within the ISPs address space, there's no allowance for hierarchy, it's expected or the management is almost forced to be in a flat manner. But if we look at what really happens and what is really reasonable to expect in the way an ISP would manage its address space, is that we would have, particularly for a large ISP, the need for some kind of internal hierarchy in managing that large address block. That internal hierarchy might look like this, where you have one intermediate level of address management, say for a regionalised structure, a provincial structure of a large ISP. You may possibly have an extra two levels in there again for regions, service, even service divisions of a major ISP company and you may, in fact, if you're trying to address, to utilise and manage your address space efficiently, you might really need the structure of your address space in a multi-level way. The point is, this might be a sensible and efficient aim in address management, but the 80% utilisation makes this rather difficult because if you try to impose this sort of hierarchy, reaching 80% across the entire hierarchy, will result in need for renumbering and reassignment of address space from one part to another within your internal area. So the point here is that hierarchy is the accepted way of managing an address space globally, it's been accepted as the way for an ISP to manage, IPv6 manage internally in its structure and with IPv4 we don't have any particular way of taking it into account. The proposal is to use a way for IPv4. In the case of IPv4, it's been called the assignment density or AD ratio. We don't count individual end post addresses as we do in IPv6. In IPv6 the end address is the unit of management, the /48 is what we can register. In IPv4 we're making assignments from ISP address space which is the unit of management and we don't count the number of post addresses /32s which are being used. So the AD ratio is calculated as the total assigned addresses over the total addresses that they have. And that is the proposed measure which would apply to IPv4. Now the next step would then be how would we actually calculate an appropriate value for this utilisation measure? In order to select an appropriate AD-ratio value, let's accept the 80% measure as a reasonable level of utilisation required for a single-level hierarchy. But let's also acknowledge that within an ISP's infrastructure, there are going to be multiple levels of hierarchy within the address management structure. If an ISP has a 2-level hierarchy, then the reasonable level of utilisation requirement would be 80% times 80%. If the ISP is large enough to require three levels of hierarchy, then the utilisation requirement would be 80% too. That is 51.2%. So we take these assumptions, apply them to the ISP's internal hierarchy, then what we need to do is assume some likely useful depths of hierarchy according to the size of address space that an ISP might have. So, it's a process of selecting values which appear to be reasonable. These values haven't come from any exhaustive study of how ISPs manage or might like to manage their address space, they come from a number of discussions with particular individuals about what might seem to be useful. So, as I mentioned before, what we might see in any particularly large ISP is a mixture of any of these sorts of internal delegation or internal address management hierarchies and we need to decide how much depth is actually reasonable. So, this table shows some assumed allowed depths of hierarchy which an ISP might require, according to the size of their address space. On the first row of the table, an address block, anything up to a /20, let's say a depth of one is a reasonable. That is one level of hierarchy or no internal hierarchy at all should be reasonable for an ISP to a /20. I don't think APNIC has received a substantial complaint from small ISPs that 80% is a difficult utilisation requirement when you've got a /20. Once you get larger over a /16, that's getting to be a substantial amount of address space which might require for an ISP of that size to structure or reasonable credential type of structure. A depth of 2 would seem to be reasonable there. Certainly by the time you have reached /8 of size, it wouldn't seem reasonable to expect management of that less than three levels of hierarchy. In the principles I mentioned before, if you have two levels of hierarchy in your address management structure, then you should be able to reach a utilisation level of 64%. It is based on the principle I mentioned before which allows 80% as a reasonable utilisation requirement. If you've got a /8 and three levels of hierarchy, your overall utilisation would be a reasonable expectation would be 51.2%. I mentioned also there are intermediate depths here, 1.5, 2.5. We're talking about average depth of hierarchy here, an ISP might manage different parts of address space in different ways. It is legitimate to look at intermediate average levels. Now, in the right-hand column, we have values of the AD ratio for each of these address size ranges. So if you utilise 80% of a /24, then you're AD ratio is 0.960. That range of ratios are there. If we look at common values which form out of that right-hand column, the most conservative value is 0.966. This is where we arrived with the chart before, which shows under this set of assumptions, we have a reasonable utilisation requirement for IPv4 which drops, once you have an address block larger than /22, the utilisation will drop in accordance with the size of the block down to just 50% for a /8 and then further on. The chart does show the larger blocks as well. So that's an attempt to justify this proposal in a systematic way. What we also need to do is look at the impact of the proposal. The proposal would make it easier for ISPs, as they get larger, progressively, slightly easier to get address space. There will be an impact of overall address space consumption. Firstly, I listed some administrative impacts. They're fairly minor. The overall impact is to make life for ISPs easier to a reasonable level. There are few admin costs. All address block assignments that are being made, either through the database or the request process, which is also the system of current policies. APNIC Secretariat need to do various updates as well. The major impact we need to look at is address space consumption. The analysis that follows shows two stages of initial impact, which comes about from suddenly relaxing the utilisation. And there's an ongoing move for ISPs as they get larger, the rate of utilisation will grow as their utilisation requirement moves on. To measure the initial impact, there's an analysis here of 788 APNIC LIRs applying this proposed system of utilisation management. These are based on the address space holdings of actual APNIC LIRs. The sample of 788, we have 4.17 /8 blocks. The utilisation expectation for that address space at 80% is 3.32. Under current policies, we have distributed 4.17 blocks and we expect they would be utilised. The 3.32 blocks would be utilised. We changed the policy to a utilisation requirement of 0.966 and then the drops. We could say that introducing this policy will waste some address space and and it would waste 0.81 /8 blocks. This is a maximum possible impact and it's impact doesn't get felt immediately, it gets felt over time, because ISPs, with address space currently held from APNIC, will be at different stages of utilisation in that address space. Some of them might not come back to APNIC for address space at all. They might be a small ISP that won't need more address space now or in the near future. But assuming that all address space is ultimately used then the impact would be to utilise or to waste an extra 0.81 blocks which is 19% of total address space allocated to these ISPs. We could say that the impact is a maximum of 19% impact. We need to look at the ongoing impact. As ISPs get larger, the utilisation requirement in percentage terms falls. So based on the same sample, 788 LIRs with 4.17 /8 blocks distributed among them, what is done in this analysis is to distribute one /8 block across a whole collection of ISPs. There's an assumption there that the larger ISPs are growing more than the small ISPs which is not precisely correct. So after distributing one extra /8 block, it is now 1.57. The utilised address space under the new proposal is that 3.11. And that means, in fact, that of that single additional /8 block, 0.58 is consumed rather than 0.80 and the current 80% policy. The extra wasted space out of that initial /8 is 0.22, and that would correspond therefore to a 22% increase in address consumption. It's quite important to know how, that is based on the assumption of large ISPs growing faster than small ISPs. It doesn't take into account small ISPs which are going to become large. The APNIC community of ISPs is very heavily weighted towards the large end. So we've got quite a small number of very large ISPs and the address distribution tails off. We can expect in this region on that basis a higher impact from this policy than in other regions where there might be a broader distribution of medium-sized ISPs. So that concludes an analysis of the impact of this policy. In terms of implementation, we've got some procedural changes. We would have some procedural changes to make to replace the 80% utilisation with 0.966 in terms of our utilisations. My system automates a lot of these calculations for the convenience of APNIC members and the implementation has changed with MyAPNIC and quite an easy exercise of not costing APNIC substantially in a registration cost. In summary, an HD-ratio based requirement, it has already been accepted for hierarchical address management. It is managed hierarchically within an ISP infrastructures, we don't currently take that into account in the current policy. The proposal is to do this, to take hierarchy into account by moving to this AP ratio requirement, with the value of 0.966. The benefit impacts on larger ISPs, some of us might think it's unfair in some sense that larger ISPs are getting more benefit than the smaller ISPs. The counter argument would be, and if you accept the HD ratio theory, the counter argument would be that large ISPs pay a penalty in terms of the difficulty they faced with address management over a long period of time. And this is, in fact, making the system fairer for all ISPs. There is a consumption impact however, up to a maximum of 19% additional space. The change of utilisation requirement for those also has an ongoing impact, maximum of 22%, basically, on the assumption of proportional distribution of future address space, which is only an assumption. And that's the end of the presentation. I hope I've been able to make the reasoning reasonably clear. If there are any questions about any aspect, I'd be happy to answer. I should mention that this will not be put in by the 4-week deadline that we adopted by this meeting so I would not be asking that there be some consensus approval for implementation of the policy. I'd be very interested in maybe having some in-principle agreement or something along those lines which might be pending examination of a similar policy if it happens in other regions for instance. RICHARD JIMMERSON: Someone from inside the ARIN region has taken this and given it to ARIN as a policy proposal and it will be posted to our mailing list in the coming days as a policy proposal and it will be on our mailing list and discussed in the policy meeting in Chicago in October. KENNY HUANG: Thank you. Any questions? Q. What's the reason you are not choosing just a lower percentage of utilisation? My other question is - I'm not quite sure how you calculate extra wasted space. I just want to know. That's all. PAUL WILSON: OK, the first question - the reason that we haven't simply proposed to lower the percentage utilisation requirement is because the proposal accepts the HD ratio theory that any level of ratio accepts a consistent level of overhead. If you have an HD ratio of 0.8 in IPv6, that represents a certain level of pain in managing address space regardless of the size of the address space. And the HD ratio documentation actually says that anything above a certain level is too painful and the overhead is too high. So I guess this proposal is based on an acceptance that, in fact, this kind of logarithmic scale represents a fairer system. For smaller ISPs, I don't recall ever hearing from the holder of a /20 or a /19 that they have some substantial difficulty with reaching 80% utilisation. I'd be very interested in hearing any feedback from this audience about that. But, in my experience, I've spoken to many large ISPs that have serious difficulty in managing a /14, /12-type address space to 80%. They have incredibly complex internal routing, assignment and reassignment of address space. Possibly, also, more leakage of prefixes from different parts of the network because of the way that they are having to fragment address space internally. So, in my experience, there is a need within the larger ISP community that this proposal tends to address. And this proposal is still quite conservative. IPv4 address managements are pretty painful anyway but the idea is to even out the management overhead and make it fairer. The second question was with reference to waste of space. I guess that might not be the right term because a certain level of non-utilisation is necessary. It's not exactly a waste. But you could say that, when we have an address block that's utilised to 80%, you're not using 20% of that address block and the 20% is wasted. It's not the best term. The wastage is the unutilised space. In the documentations on these tables, the wastage, the reference to 'extra wastage' is when we implement a policy that has a reduced utilisation requirement, then we are increasing the wastage of the addresses that are likely to be unutilised. Is that clear? (Question inaudible) PAUL WILSON: It will increase the unutilised portion. It's not exactly wastage because, in fact, that free unutilised address space is critical in efficiently managing address space. It will be used in future. That's correct. This is why the consumption figures that I've given are really absolute maximums. They assume that all address space will eventually be utilised to exactly the AD ratio or the 80% level. It's comparing the difference in utilisation. KENNY HUANG: The proposal is informal so your feedback is welcome. Unfortunately, we are running a little bit late so we can only allow one last question. Any questions. IZUMI OKUTANI: It's not a question but I just wanted to say that I don't have any fixed opinion about this at the moment so I'm interested - I would like to go back to LIRs from Japan and ask the opinions from them and would come back and make a feedback about this. KENNY HUANG: Thank you. OK. One last question. Q. I'm from Indonesia. I'm one of the larger ISPs. I just want to put the comment here that we are supporting this proposal. Considering that the last time, historically, that we got… [address space], we had a very bad experience with the existing mechanism so we are supporting it. And hopefully this will be beneficial. KENNY HUANG: Thank you for your positive feedback,. RICHARD JIMMERSON: I'm sorry but I think it's important to know that, in the ARIN region there has been a policy enacted in the last two years that has made an exception to the 80% rule and that's our … policy or the use of discrete networks, international, national, whatever the case, to be able to show a figure that's less than 80% obtain extra space. There's already an exception in the ARIN region and we have proposed this formally. GEOFF HUSTON: This next presentation is purely informational. It's coming up to morning break. My observation is this is purely optional. If you want to go out and have coffee, go out and have coffee. There's nothing much here of a policy nature. If you want to leave, leave. It doesn't worry me. Don't feel it's impolite or anything. It will take a little time to go through this. This is an exercise that I've been doing over the last month or two looking at the rate of consumption of IPv4 address space and trying to figure out at what point it will actually be fully consumed in terms of allocation. The work has been supported by APNIC but the rider is pretty important. "The Regional Internet Registries do not make forecasts or predictions as a matter of official business. This is a personal contribution simply taking these statistics and analysing them." Trying to look at how long we've got with v4 addresses is not exactly a recent activity. This work I think started more than 10 years ago when it became obvious in the old Class A, B, C division of IPv4 addresses that the class B space was too small, the Class A space was too big and that they were skimming through the class C space at a pretty phenomenal rate. Some predictions were made at the time, going back to around 1992, as to how long the actual B space would last under that kind of configuration. At the time the prediction was that we would run out of these by about 1995. From time to time, this has been revisited in various venues and various models have been put forward under various bases. This is yet another contribution to that ongoing exercise. The essential difference in this exercise to other exercises is that I'm not trying to count the number of devices that run IP. I'm not trying to count the number of devices that sit behind that firewall, NATS, DHCPs or anything else. I'm not trying to estimate the host count of the Internet. That's really not part of this exercise. What I'm trying to understand is, in looking at the amount of address space globally advertised in the BGP routing table and its rate of growth, and correlating that to the amount of allocated address space, if we assume that tomorrow is a lot like today, how long will this model run through? This is based largely on adding in the factor of the routing table. So what is the address space? 32 bits, 4.4 billion entries. The space that is global unicast is handed to the IANA who allocate that to the RIRs and they allocate that. Space is reserved throughout the system. So, at the top level, if you look at the entire v4 space in /8 or equivalent, you see that 19 /8s are reserved. There is the top 16 from 240 to 255 and there are three more - network 10, network 0 and, from memory, network 14. Multicast takes a further 16 /8s and the remaining unicast space is actually 221 /8s or their equivalent. so how long have we got to go? There's actually two steps to get things into the routing table. IANA passes blocks to the RIRs. So the first thing is to look at the rate at which blocks are handed to the RIRs and try to make some extrapolation based on IANA data. How fast are we consuming blocks from the IANA pool? We can go one level into the system and look at how fast the RIRs are assigning blocks into LIRs and users and try and figure out how fast that's going and how long that will run. Or you can look at the BGP routing table. I'm not looking at the number of routing table entries. Don't care. I'm looking at the amount of address space that is covered by the entire routing table and look at that - the growth of the number of amounts of addresses and see how far we've got to go - we can find data sets for all three questions. We can look at the IANA IPv4 address registry, if you look at that, you will find /8s prescribed and you will find for each /8, if it has been allocated, the date on which that happened. For the RIRs, you can go to their stats files and all four RIRs have a record of the allocations that they have performed, the size of the allocation, the starting address of the allocation and the date. You can wander through that data. Or, if you take periodic snapshots of the BGP table regularly over a long period of time, you can look at the amount of address space covered in each snapshot and make some forward extrapolations based on that. So the data is, if you will, hard data. So the first one, IANA. If you actually have a look at the IANA registry, life is not as good as it could be. The data is certainly ... but there are some inconsistencies in the way things are described. IANA has been allocating /8 blocks since at least 1980 but the earliest date in the IANA file is 1991 and a huge amount was supposedly allocated in 1993. That's wrong. If you actually have a look at the RIR stats data, you will see that the earliest allocations coming out of the InterNIC at the time extend back to 1983. Someone rewrote the early IANA allocations and put new dates on it. So as far as I can see, the IANA data is actually reliable from about 1995 onwards if what you're looking at is dates. But even then, there's a URL there, even then the data is not completely clear. There are some problems with that IANA data. But what does the picture look like now? Same amount of reserved space - 19 /8s - same amount of multicast. 35.2% of the address space is still held as unallocated by IANA and a little over half, 51%, has actually been allocated by IANA if you looked at those files. There's the time series data. See that sudden jump there around March 1993. So it looks like the real data starts around here and that's a reasonable time series. I'm actually completely unsure about all of that data there. It just doesn't seem to make an awful lot of sense to me. So let's take the post-1995 data and let's apply a linear regression to the logarithm of the data. What I'm assuming in all of this - and be careful to note the assumption - is that the rate of growth of allocations is proportional to the amount already allocated. Think of it as a circle that expands and look at its circumference. The circumference expands faster than the radius. It assumes an exponential growth rate. Some may think it should be linear. It should be measured against something fixed in sides rather than accelerating. And you may be right. If you look at some of that data, the exponential curve fit is a reasonable fit but, quite frankly, it's not exponential. This is assuming that the rate of growth is proportional to the current data set. It's saying that growth is exponential in this extrapolation. It assumes non- disruption. It assumes that tomorrow's rate of growth is going to be roughly the same as today's and assumes that continuously. All of a sudden, if someone wants to make a new application which has a massive requirement, it's not in this model. It assumes that the things that are going to happen in the future are roughly the same as in the past only more so. So, with all of that in mind, this thing sort of says the rate of IANA allocations goes through to around January 2013, but there's a savage amount of assumption going on behind there. So it's very sensitive to a whole bunch of assumptive factors. If the RIRs change their IPv4 assignment policies to either make them more or less restrictive, the rate of IANA consumption will change. The rate of allocations that currently are hidden behind various form of other technologies - BHCP, NAT and similar - if that changed and we needed more end-to-end IP addresses, you'd find the rate of consumption would change. That date of 2019 assumes that the 16 /8s at the top of the address space remain reserved. If you brought them into play, you'd actually have a little bit more time. I might have a quick word about the IANA registry file and looking at it. If you look at the IANA registry file, I'd have to say that, as a registration date file, it's a pretty lousy file. It's very hard in the registry to separate out two different things - one, the state of allocations as they stand today, and, two, the log of transactions that got to where we are today. I'd actually contend personally that those are two different files, two different registries if you will, and should be published separately. It appears to me that the IANA IPv4 registry file is a weird compromise and that if you actually try and interpret some of the status of some of the /8s, there are two in particular for example that are listed as being allocated somehow that were handed back to the IANA. Are they real? Are they allocated? Are they reserved? That file to me seems more of a political compromise with some amount of legal intervention than a real registry file and in trying to do this data there's a certain amount of assumptions that have to be made about what is inside that IANA registry file. The next set of data is from the Regional Internet Registries and you'll actually find quite detailed stats files. The stats files are meant to be a current snapshot of the currently active allocations and the date at which the allocation was originally performed, the starting address and its size. So, if an allocation is - what's the right word? Revoked? Whatever - became invalid, you would not find it in the current stats file. If you look back, you would find it in previous stats files, since the stats files are dated, for the time for which it was valid. What happens in the RIRs is you will find a series of snapshots which, if you analyse them carefully, will give you a log of how we got to today and the most recent stats file, which is the state of RIR assignments today. What you can find is actually the split of that 51% of the v4 address space which IANA has allocateed out to the RIRs actually splits in two ways yet again. Could find that the equivalent of 115.87 /8s or 46% of the address space, has been allocated outwards, either a historical /8 listed in the IANA file or an RIR allocation listed in an RIR stats file. You actually can't find allocation entries for the equivalent of 15 /8s. So somewhere inside the RIR and IANA system are actually 6% of the address space. A lot of that is holding pools, space that is in the process of being allocated and is actually currently being worked on. So the big split looks a lot like that. Kind of interesting data. I started looking at it /8 by /8, trying to understand that, in each /8, how much space is reserved and you'll find here the top space is reserved, the 172 RSC 1918 space is reserved, 128 is reserved, network 10 is reserved and so on. You look at how much is still held by IANA that is yet to be allocated to the RIRs. How much is unallocated, that I can't find allocation records for and how much is allocated. This is the old B space and, as you see, the B space has a fair deal of allocations. There's also some unallocated space inside those old Bs. This is where we're working as RIRs inside this space and at the top of the old C space. Now, someone's given me a note "stop within 10 minutes." Let me say again, coffee is out there, go whenever you want. This is running over the time. This is purely for interest. This is the RIR allocation from 1983 onwards. You actually find that the RIR system started to operate around here. Before this is the old InterNIC allocations. I think that's the run on the Bs that happened. There was a bit of a run on the Bs on the Internet. After about 1995, we're looking at the way the RIRs actually worked and there's the projection based on the RIR data from 1995 onwards. I put two break points - one is assuming that the top of the old v4 space is not brought into play and the other is assuming that the IPv6 space is brought into play. That is smaller than the IANA rate. That drives forwards into somewhere around 2025, 2029, using data from 1995 onward. The third data - by the way, the RIR data is not very good either. There's actually two ways of looking at RIR allocation data. One is the stats files and the other is the Whois database. Unfortunately, for those three RIRs where I can access the Whois database and the stats files, the number of errors that I find is very high. In the order of hundreds, if not low thousands, rather than ones and twos. So it's actually a reasonable amount of uncertainty going on in fine detail because it's hard to understand that, if I see something in Whois, and it's not in the stats file, was it really an allocation and is someone using it improperly or is it real? It would be good at some point to understand how we can make those two sets of published data consistent because currently they are not. The last thing is the BGP routing table. What I'm looking for is the amount of address space spanned by BGP. The first thing to understand is that no-one sees the same address space which is, I think, really weird. If you go to the large aggregated route view and route views are perhaps the best ones and actually look at the span of advertisements by each peer, not everyone sees the same addresses. This is the 1.1000000000 address point just there. You notice that there is a /8 flapping. Large amounts of address space flap all the time and, across 30 peers, everyone uses different things. It's hard to understand what reality is. Unfortunately, I've got to simplify it and the only way to do that is to take one view. This is one view. You still see a /8 flap of around three or four /8s but it is easier to smooth that data out. Let's take a snapshot. Now what does it look like? Pretty weird. The amount of address space in the routing table is only 29% of the address space. The amount of address space allocated but not announced, hidden somewhere, is actually 17% of the address space, 42 /8s. This is the amount of address space in play which is not a lot. Let's analyse that sort of break-up of the space by /8s again. The old Bs, this is the bit that I see in the address space, in the routing table. The dark blue is what I don't see. A lot of the old Bs aren't advertised. Some of the old Cs aren't advertised. Where we've been recently allocating, you'll find that most of the allocated space is advertised. A lot of the old IANA /8 allocations are not advertised. so that's sort of where this empty space is. That dark blue is kind of space that's being allocated but not advertised. Unfortunately, I don't have a huge amount of data for the BGP routing table. It only goes back to 1999. That's what it looks like if you extrapolate forward. The same underlying statistical assumption hyped the data to make that forward exponential curve. There are numerous models you could put on this. This is just one. Using this model, I get an exhaustion rate of all available space of around 2029 using this model. You could use other models and get different answers. So the projection is only working over a 3-year baseline, not a 7-year baseline. Lots of uncertainties. There's all the three sets of data. This is the RIR data. This is the IANA data. This is the BGP table data. What about the differences? This is just the last couple of years - in the routing table, this is what the RIRs have allocated, this is what IANA has pushed out into the system. So this is the amount of space that the RIRs haven't allocated yet. This is the amount of space that has been allocated but not advertised. And, over the last three years, that top stuff, unadvertised allocated space, is pretty constant. It doesn't seem to be growing. So let's have a look at the age of the unadvertised space. What address space is not being advertised? Is it RIR allocated space that, for some reason, is taking a long time to appear in the routing table? Or is it very old space that was allocated years ago that has either dropped out of the routing table or never appeared? Here is the date of allocation of the unadvertised space. And you see that the bulk of the unadvertised space is around that period - 1989-1995. Here is some space that has no date. So a little over five /8s, I can't put a date anywhere. The ones I can, that's the distribution over time. This is the amount of unadvertised allocated space over time. The RIRs have been operating in their current policy environment since around '95 and the amount of allocated, unadvertised space since '95 has grown extremely slowly. If the intent of RIR policy was to allocate public use of address space, then that intent is realised. What we're allocating is being advertised. So the policy has been implemented and you can see it in the results. What we allocate is indeed public address space and appears in the routing table as public address space. It takes only a few months for allocations to be advertised. So, over time, that small bit at the edge keeps on moving forward. Most of the wastage of space occured a long time ago. So that, when you project the model, the amount of allocated, unadvertised space will not grow very big. All you've got to assume, if you push the entire model forward, is that the RIR efficiency in holding will slowly decline. As they add more growth gaps, they'll actually hang on to more space, allowing individual LIRs to grow into them. You'll also assume that the LIR efficiency declines slowly over time, because of Paul's presentation on the H-density, the AD density. That will make the LIRs be less efficient as the pools get larger, but only slowly. Again, I assume an exponential best fit. I assume this will give me an exponential growth model on my assumption. I go, "What will be the rate of the RIR holding pool over time to meet that requirement for advertised space?" - it slowly grows. There's a certain amount of … in that model. That's the RIR holding pool. At some point, IANA runs out of addresses. No more unallocated address … feed to the RIRs. Then the RIRs drain out their pool and all remaining held space gets deployed. Then you are there. If you assume that all that unadvertised space then becomes a valuable advertiseable property, if you will, and gets deployed, and that's a huge assumption, then you run out of unadvertised space and finally, the BGP routing table gets to its full extent way out there in some time in 2028. All of that is artificial. The real sort of break point in this model occurs at a little over 2020 because at the time the IANA pool exhausts, the entire process as we understand it falls over and the rest is pure speculation. But the model is driven from the rate at which advertised space grows and nothing else. I've almost finished. There are a few questions about this that you might want to ponder on. I have some idea but I don't have a definitive answer. Is this model accurate in terms of holding pools? I don't know. It seems it would fit but other considerations exist. What's this sort of IANA- allocated space of advertised blocks? Where are those 42 /8s? Are they de-employable, are they real or being held somewhere? I don't know. What's the distribution of held space across the v4 space? Who's got what? More importantly, this model assumes continuity, it assumes NATs, it assumes DHCP, it assumes all the ugliness and complexity of v4 and it assumes it gets worse over time. That's inherent in this model. If, for example, the carriers, the providers, the industry said, "Look, this is just nonsense, we can't make things bigger and more complex at the same time, let’s go to an allocations system and indeed a deployment system that stresses and uses v4 addresses native rather than NAT- based," these models won't work any more. That's a disruptive event. If every PDA needed a different address, you'll find a different model. There are many disruptive events out there. How big they are, when they occur and what impact they will have is really the question. All my exercise has been saying is, "If you assume tomorrow is a lot like today, if you assume the complex … of the Internet in terms of NATs and address compression, then you get to these types of results," but they are massive assumptions. We are assuming a network that looks a lot like today only bigger. If you assume a different future, these models don't carry as strongly. In that world, the current systems hold out for two decades. I've used up enough of your coffee break. You can have coffee for five minutes. Drink quickly. Thank you. APPLAUSE KENNY HUANG: Any questions? RICHARD JIMMERSON: Geoff, just an observation - I don't know if there's a correlation or not but that big spike in the IANA file appears to occur about the same time that the database was transfer from SRI to NSI. GEOFF HUSTON: I think the spike is a year later. I lived through the same transition and my understanding was that the transfer of records between the two organisations was less than complete and less than orderly. KENNY HUANG: OK. I'll just repeat again, the proposal was informational and if you have any questions, you can go to give your input. OK, before coffee break, one more question. We have 10 minutes for tea break. Thank you to DB SIG for your contribution. OK, so the tea and coffee service is outside. Enjoy your tea and thank you for your participation and contribution. Sorry. PHILIP SMITH: One of you has got a blaster worm for a change. Your address is .88. You have no Internet access until you get it fixed. Please come to the APNIC help desk and get it fixed.