ARIN XV
Public Policy Meeting Minutes, Day 2
April 19, 2005

Call to Order and Announcements

Speaker: Ray Plzak, ARIN President and CEO

Ray Plzak opened the second day of the ARIN Public Policy Meeting at 9:00 AM EDT. He thanked those who had contributed sponsorship to the meeting: Native6, Smart City, and NTT Communications.

Ray offered information on the Terminal Room, the ARIN Help Desk, and the ARIN XV meeting survey. He reminded attendees of the Exhibitors Hall featuring vendors of IPv6 technologies. He concluded with a summary of the agenda for the day.

At the beginning of the meeting there were approximately 100 people in attendance.

John Curran, as Chairman of the Board, moderated discussions throughout the day.

[ARIN offered the opportunity for remote participation throughout the meeting. Comments from remote participants were read aloud at the meeting and are integrated into these meeting minutes.]

Continued: Policy Proposal 2005-2: Directory Services Overhaul

Speaker: Leo Bicknell, Proposal Author

Presentation: PDF PPT

Continued Discussion:

Discussion of this proposal was continued from the end of the previous day.

Ray Plzak opened discussion of this proposal with a notice that additional discussion of the proposal took place the previous night on the Public Policy Mailing List (PPML). John Curran then invited Leo Bicknell, the proposal author, back to the stage to provide a short summary of the proposal.

General Comments:

• My experience in talking with investigators and prosecutors around the country is that generally they are not encountering a bad data problem with the look-ups that you're doing on the IP allocations of today. I agree, having good data in the distributed database is a wonderful goal, and I am encouraged to hear that you share that as a goal, but I don't see this as a trade-off. I don't think it's a zero sum. I think you can have better data without necessarily hiding it from availability. And the second point about companies providing what's called the turnkey services, I mean, that may be true in some cases; in other cases, it won't be true. My concern is that the proposal as currently constituted basically takes away choice. It means there's only one entity that I can go to, either ARIN or the ISP. As opposed to today where, in the vast majority of cases, I can go to AT&T or I can go to XYZ corporation.
• A representative from the U.S. Federal Trade Commission offered the following comments. I manage the resources the FTC uses for investigating Internet matters. Before I get started, I'll refer to my lawyer background. As we're required to say, these are my opinions, they're staff opinions. They're not those of the FTC.
  Time is critical in any law enforcement pattern, and that's particularly true in the case of Internet issues. Data disappears, targets disappear, frequently in the time it would take us to get a CID. A CID is "Civil Investigative Demand." We do use data that's from assignees or delegations. It's been important in addressing an issue. I wanted to address a couple of things that maybe are unusual for the FTC. We're a consumer protection agency. We have civil law enforcement powers, not criminal, the way Justice does. We are a leading law enforcement agency when it comes to privacy and security matters for consumers. As suggested earlier, I'm really not aware of any U.S. laws that would be addressed by this provision. The U.S. laws on privacy are generally aimed at individuals, and as far as I can tell, individuals are pretty much already protected by existing provisions.
  Finally, as a big part of our consumer protection mission we're engaged in consumer education, and we're very active in consumer self-help. And believe it or not, consumers use WHOIS databases, whether they are domain lookups or IP lookups, to try to track down someone who has ripped them off and get redress without talking to law enforcement. We get some amazingly sophisticated reports from consumers. These folks don't have alternative methods to find folks who manage the website, advertise in a news group, whatever other method they got ripped off through. So at another level, it's not only important to law enforcement, it's important to the people out there who are on the net and using it for commercial or other purposes where they could be victims.
• I think I am happiest when someone asks me directly about my customer instead of asking a third party about my customers. My experience with RWhois has been generally favorable. It has it's warts and needs to be fixed. And so I'm actually happiest when I see ARIN keeping track of its direct customers, and the information that it is holding in trust for the community. Having ARIN act as a centralized depository I think is kind of a mistake.
• One of the things this proposal adds is a method to punish -- and there's really no better word for it -- people who don't comply. Today, the only punishment occurs if you ever want more IP address space from ARIN. If you get a block from ARIN and decide that that's enough for you forever, you don't have to publish anything. People might get mad at you, but you can leave the entire database blank, and there is absolutely no recourse for ARIN. And this policy proposal changes that, so you have to have your information up-to-date, maybe not all of it in there, but it has to be up-to-date.
• I would like first to mention that I support work to make ARIN policies in regards to directory services clear and do think that larger changes are needed and it might be easier if we do it at once rather than with several different policy changes.
  In regards to the current policy proposal, yesterday Leo mentioned that there would be less data in the database. I would like to point out that is not quite true. The policy does not change data that ISPs need to provide to ARIN, what it does is makes much of that data go into the private ARIN database, so it's just moving data from one database to another that ARIN still needs to maintain. However ARIN does it, the private data may well be more expensive for ARIN to maintain in regards to maintaining security of this data (like billing data).
  Also, in regards to privacy concerns regarding names of the people found in the database, this primarily refers to the contact information and it's exactly the contact data that has always been the biggest problem in regards to accuracy. It seems that it would be more appropriate to focus policy on making sure the ISPs understand that when they submit SWIP information, they need to make sure they got the permission of that person to be listed as such contact and that ISPs always do have an option to keep its own contacts (using simple reassignment for example).
  It would be more appropriate for policy to be changed and to keep the requirement for ISPs to submit reassignment information for business entities (primarily name, size of block and date when block was assigned) in the public database and make sure that all contacts for the blocks are available and reachable (be it contacts listed for the company itself or ISP contacts).
• Speaking on behalf of the consumers of this data in the private sector, particularly people combating phishing, fraud, and intellectual property owners, we too have a need to get access to data that's subdelegated. Setting aside the privacy concerns, we're talking about organizations, not individuals.
• I want to talk about this as somebody that works in other registries and puts things like this together. First of all, I want to thank Leo for putting the proposal together, but I'm questioning whether this is the most efficient way to come to this problem. Directory services is one of the major interfaces of any registry, and it's a very large problem. And the policy as it was written really attacks on some points, and I would like having a task force go off and decide what ARIN's going to do to answer all the questions we're hearing here today. The second comment I have is that there are other registries out there that have similar problems with reporting and keeping information, and I've put them on a mailing list, I guess last night or so. It might be worth looking at other models for how information is stored and managed and the technology behind that. I have been trying to push IRIS as a protocol for underlying all this stuff. Not that you wouldn't see the things that were discussed here, but this is the part where the engineering has been advanced that might help answer the problems we're seeing with reporting access information.
• As I understood the proposal, the parent delegation will be reporting to ARIN information that will go to two separate databases: the APID or public information database, and the ACID, which will be the confidential information database without all of the attribution and application information in possession of the current delegation. As a practical matter, I will tell you that I'm not entirely happy about this, but I do know from side conversations with folks at ARIN, there actually are folks in law enforcement -- I think maybe more true to the state and local level -- who are going to ARIN now for stuff that is in the public databases. And unfortunately, this is purely a function of ignorance -- and I'd obviously like to counter them and take up the organization's time when they get to public queries -- but if the information is no longer publicly available, then people will not go to ARIN any less. And if ARIN does have the information, the information is now purporting to be more accurate, I think the likelihood is that people will go to ARIN.

Statements For and Against:

• A representative from the Computer Crime Section of the Department of Justice offered the following comments. I'm here to express some serious concerns about the elements of the proposal that would give the parent delegation sole discretion to not make public information regarding subdelegations. In the first instance, there will be cases where that's going to have an impact on public safety information that is readily accessible now through either SWIP or RWhois. If the parent delegation chose not to post information, we'd have to go through the legal process, and there's a delay in time in some cases like bomb threats or hostage situations. Obviously, that's not the typical criminal case, but that's an important consideration.
  Also, the delay in getting to the ISP to obtain the records could lead to the failure ever to obtain those records. Those may be ephemeral records that will be lost. So if we don't get there quickly, as we are generally able to today, then the records just won't be there. As a practical consideration, one suggestion is for the adoption of a policy that allows more data hiding than is the case of the current NRPM. If there's going to be more compulsory process directed both at ARIN and the ISP information, which law enforcement and other government agencies simply look up publicly, they're going to have to start sending out grand jury subpoenas for administrative search warrants. This is not just Feds; there would be subpoenas from local law enforcement as well. That's obviously a time-consuming process on both ends. So it's not a cost-free decision for any responsible organization simply to chose not to make this stuff available. There are practical consequences, in terms of expenditure of time and other resources.
  One point I did want to speak to is the one-paragraph rationale that was put forward on this proposal. It makes reference to privacy laws, allowing you to actually grasp the notion that ARIN is not just about the United States law. I do want to say that I'm not aware of any U.S. law that would give rise to a need to change the current regime with respect to publication of assignment data.
  And lastly, I would note that I don't really understand the concern about end-user privacy to the extent that that's a factor in this proposal. As I understand the current policy manual, you have two separate provisions that seem, to me, to provide plenty of privacy to any users. You have [section] 4.2.3.7.6., which speaks to residential customers and allows for privatization of that data. And also [section] 4.2.3.7.2, which is the criteria that only the /29s need to be reported.
• I'm a strong supporter of individual privacy. I fail to see any justification whatsoever for hiding an organization's name from the public. I simply don't see it. Unless it's the CIA, and that's something else. But I fail to see any justification for this kind of suggestion.
  • Leo Bicknell responded that when he drafted that section of this proposal, privacy was not a real concern, in that he has no real interest in making more individuals or businesses private. It happened to be the case that certain businesses or individuals can act one way today and they are private, and if they can act another way, they aren't. I looked at it more from a straight record management point of view. If you're already missing half or two-thirds of the businesses of individuals out there, it seems to me there is limited value to ARIN maintaining the other records. If we went the other direction and attempted to maintain records on everybody, the end position of that, privacy aside, is potentially ARIN could have a record for every individual in the United States, and I just think that's a lot of work that ARIN doesn't need to do, to be a steward for handing out IP addresses. It's not that I want to hide somebody; it's that I don't want ARIN doing that much work.
• A representative of the U.S. Federal Bureau of Investigations offered the following comments on behalf of the U.S. Department of Homeland Security. I do want to touch on a comment made about ARIN possibly having to be a repository of information for every single user in the United States. I think one of the biggest concerns is ARIN having to maintain all this information. And some of the information may not be accurate. In fact, the database is certainly far from perfect now. But it's better than nothing. We need to have something. And as my colleague from the Department of Justice has said, there is a difference between making the information more accurate and getting rid of the information, or removing it from the public view.
  Now, something we talked about earlier was ARIN might be able to provide information that might be more accurate than what would be available to the public. That might be the case. But we're going to have to send our subpoenas and search warrants somewhere. Right now, presuming the model works all right and we have the ISP available that is the one that is closest to the IP address we're looking at -- and the IP address may be used by a suspect or may be used by a victim. We don't really know. It could be either -- right now if we have the end ISP, we can send our subpoena directly to the ISP, and they can provide the information directly, if the ISP is listed correctly, and that may not always be the case. So we're certainly for accuracy.
  The problem is if we remove all this information that we're talking about, we'll have to send the subpoena, in addition to that end-user ISP, if we ever find out who it is, we have to send it to ARIN first. So they're going to get every single -- if we don't know who the end-user ISP is, they're going to have to get every single subpoena or search warrant that's issued by all U.S., Canadian, and other relevant countries' law enforcement agencies. I mean, think about that. It could be hundreds of thousands.
  Right now, if we know who the end-user ISP is, not the individual user but the end ISP or the end corporation, we can distribute subpoenas evenly among everyone. Right now, if we don't know who these sub-ISPs are, the sub-corporations, we would have nowhere to turn but send a subpoena to ARIN, or at best the top level ISP. And what that will do is it will generate delay. Which, in some circumstances, is unacceptable. And we all know how quickly evidence can be lost or flushed.
  Even if we had to send a subpoena to ARIN or a top level ISP and the sub-ISP, we're doubling the time it takes. We could be going from one week to two weeks. Or if we're talking about international subpoenas, let's say we're talking about Canada, we would be talking about one month to two months. And if we're looking at logs, it's possible that the logs could be flushed and we could lose any evidence.
  So we could be in a situation where a change in management here in a WHOIS database, which granted was never intended to serve as a tool for law enforcement, could have a detrimental impact on law enforcement and regulatory investigations.
  It's very serious, and that's one reason why we're all here today -- it's a little unusual -- but just to explain how deeply we feel about this problem.
  And the other thing I want to add is that I think our colleagues in the Canadian Department of Justice and the RCMP [Royal Canadian Mounted Police] may be submitting an e-mail comment to you touching on a similar issue and possibly addressing some of the privacy concerns, because Canada is one of the countries that people think about.
  • Ray Plzak thanke all the governmental representatives for attending, and stated that he hoped in the future it would not be unusual for them to be here. He added that they were very welcome in this forum, and invited them to come back.
• As a person that processes requests daily and I did subpoenas weekly, sometimes one daily, it's much easier when we get the FBI or a court system calling us and asking "Hey, do you have this information?" It might be someone that already knows the process, it might be someone new that needs to learn the process. I'd rather train one person and they don't call me next time. These subpoenas will have a day turnaround sometimes. Do you know what the subpoenas say if you don't get them that information? You have to show up at court. Having this stuff available, one, makes it much faster, like they're saying, and two, it makes the job easier. If we were to start not making a lot of this visible, we would have to process a lot of subpoenas. There are a lot of different situations that require subpoenas, and when they can be sent to us at a main level and they also see in the database who that goes to, they can go out automatically and subpoena that customer.
  I know my database isn't perfect either, but it's pretty darn close. I try to keep all of our information up-to-date. Is the WHOIS perfect? No. But at least there's something there, and that's why it's very important to keep the information there as far as the subpoena issue. The other view I'd like you also to look at is there is a difference between commercial and residential. Right now, when we say yes, you don't have to show your part of that residential users. We do that with the Frontier half of my company, and it works just fine. However, a lot of the subpoenas come from them too, and it takes time, and it slows them down. If we went to the commercial part, it would just make the can of worms much, much larger.
  The other thing is, we have to look at an economic whole view. These policies can be economically impacting on our community. So if we say commercial ISP where you're selling to different commercial or retail shops, or whatever, wholesale, some of you can hide the information if you want. We have now created an environment where we're going to have customers shopping for the ISP that hides their information. Therefore, your little companies that can't afford not to show all that information are now going to be losing customer base. And I'm highly against any policy that is economically impacting like that.
  We converted to RWhois so we could keep our information up-to-date. With SWIP, it was very hard when there were changes, because ARIN's concerned about privacy and security in the aspect of the wrong person changing the information on the company. So that makes things more difficult. Yes, we had a few people call in and say, "We can't find your information." And we explained to them, end of story. But we have not had problems with RWhois. It works great.
• There is a saying that bad data is worse than no data. Having said that, my legal department of a large ISP for whom I used to work likes to say "Let's not publish the database of all of our customers." There are reasons why we might not want everybody to know our complete customer list. On the other hand, somebody pointed out to me earlier that if I'm providing multihoming service to an end-user and they come to me with a block assigned from another ISP, I would like a way to know that they actually had permission to use that block, and it is currently a permission that comes from ARIN's WHOIS database. And with all those points into the record, what I'd really like to suggest is what is the basis to talk about striking provisions allowing data not to be published. And how is the rest of the proposal? Because the rest of it looks pretty good to me.
• A representative from the Canadian Internet Registration Authority provided the following comments. I just want to add a couple of comments from our perspective. Number one, I do like the policy in general. I think it's a great idea to try and get all of this stuff in one spot, and in one section of the policy, and have it all kind of written to work together. I mean, I think it's good to do that. And hopefully, we can address our concerns and be able to get something similar to this through. As far as the privacy concerns, we have a problem in Canada that under our privacy law, ISPs have a requirement to conceal any personal information about individuals that they have assigned, or that have been given addresses. There is an out that says, in the law, if there is a good business case for it, you can publish private information. But given some of the rulings that we've had from the Privacy Commissioner, I'm not entirely sure that because ARIN says so is enough of a business case.
• Scott Bradner, speaking as an ARIN Board member, said this proposal increases costs to ARIN. If ARIN has to deal with all of these subpoenas that's going to increase our costs. I don't like that as a Board member.
  • Leo Bicknell responded with the following. I do not understand why this would increase the subpoena burden on ARIN, because this policy does not allow the block ARIN gives to an ISP to be hidden, and also requires that information be correct. So that first level is always there, and the only information ARIN could ever provide is that first-level information with reliability. So it seems like without a subpoena, you will always be able to publicly get the thing ARIN can provide. So I don't see the subpoena hitting ARIN.
• I am baffled by the tenaciousness by which you cling to this provision for not publishing data, which seems to be so nonsensical.
• A statement was submitted remotely by a representative of the Royal Canadian Mounted Police (RCMP) that read as follows. The Purpose of this letter is to share with your organization our concerns on the implication and impact that the proposed changes to your APID policy would pose for the Royal Canadian Mounted Police (RCMP) Technological Crime Branch. By way of background the RCMP Technological Crime Branch conducts forensic investigations of computers and networks in support to investigators in the RCMP, to other Canadian police services or government agencies, and, in the case of Internet investigations, to any accredited international police service or agency. The Technological Crime Branch also supports investigations of cyber threats, or criminal activity using computer networks, that may threaten one of Canada's critical infrastructures.
  While we applaud your efforts to develop a unified policy that is easier to understand and to ensure that the privacy concerns of your customers are addressed, it is our belief that the proposed policy, if implemented, will hinder our ability to investigate and deter the perpetration of crimes against Canadians or Americans using the Internet. Access to information currently available through ARIN, such as contact information, date of allocation and other identified information is an invaluable asset to combat criminal use of the Internet for foreign Law Enforcement Agencies (LEA).
  The use of such information permits the RCMP and other LEAs to effectively pursue criminal investigation of trans-border crimes. This information is essential to criminal investigations and in most instances ARIN is the only source for such information. The proposed changes to your policy will in many instances delay or hinder our access to valuable information in a timely manner and directly cripple our ability to detect and combat criminal use of the Internet.
  In the realm of the Internet, criminal activity knows no jurisdictional boundaries. An individual or organization can easily be located in one jurisdiction and transact in other jurisdictions. The ability to determine the jurisdiction of the offence and the offender and ensure the preservation of evidence becomes primordial. Access to ISP subdelegation information in a timely manner becomes indispensable in determining who has jurisdiction and the authority to investigate the offence.
  Changes to your policy would have implications for foreign law enforcement agencies conducting criminal investigations. As you are no doubt aware, foreign law enforcement agencies investigating crimes committed in their jurisdiction, by individuals or organizations also rely on information provided by your organization's online directory. Loss of access to the information contained on the online directory may also signal an end to the investigative avenues available to our agency. The ability to detect and combat crime will be greatly reduced and will be in contrast to the Council of Europe Convention on Cyber Crime designed to promote international cooperation in countering cyber crime.
  Foreign law enforcement agencies wishing to have a subpoena executed in the United States must do so through the Mutual Legal Assistance Treaty. These requests are governed by complex procedures that are labour intensive and time consuming. Every time a foreign law enforcement agency wishes to have a subpoena or other judicial authorization executed in the United States, an application must be made under the terms of the Mutual Legal Assistance Treaty. The proposed changes to your policy would require an increase in the number of MLAT applications and subpoenas that we would require to obtain information in criminal investigations. For our organization, the increased requirement under the MLAT provisions would add a level of complexity and time to most investigations and greatly reduce our ability to quickly gather evidence before it is lost or destroyed. As you are aware, given the fluidity of Internet, when dealing with cyber crimes, time is of the essence. The drafting of MLAT applications and execution of a subpoenas requires the use of a large number of resources that could be better used in other investigative capacities. There is at this time no way to predict the increased number of subpoenas that would be required should your policy be implemented as proposed.
  Finally, your policy rationale specifically makes reference to the fact that several laws have been passed that may restrict the personal information that can be published. Some discussion has taken place on your internet site about the various privacy legislation, including Canadian legislation that your organization may wish to comply with. The Canadian legislation that would be applicable, known as the Personal Information Protection and Electronic Documents Act (PIPEDA), specifically exempts corporate or business information such as the information presently contained in the APID from the definition of personal information in section 2(1).
  As well, I note that paragraph.7 (3)(c.1) of the Personal Information Protection and Electronic Documents Act allows organization to continue to provide law enforcement agencies access to the information contained in WHOIS online directory without the necessity of having to resort to the use of judicially authorized instruments. Disclosure under these provisions is at the discretion of the organization and not prohibited by the Act.
  I hope that these comments may be of assistance to you in drafting a policy that proves to be both responsive to the public need for accountability while respecting the privacy concerns of your customers.

Questions/Responses/Clarifications:

• John Curran asked Leo Bicknell if, when authoring the proposal, it was intentional to include the section regarding directory information being made public and putting everything in the choice of a parent delegation. Also, did he give a little thought as to why he made that trade-off in writing it?
  • Leo answered that it was intentional, and that it's very interesting to hear perspective of organizations like the representative from the Department of Justice, because normally we don't get those in the policy process.
    I originally approached this from ARIN's own rule of stewardship. But as I started to investigate some of the law enforcement aspects of it, several questions came to my mind that I haven't gotten a good answer on.
    For instance, many end-users today are not in ARIN's database at all. So if you're tracking those sorts of people today, ARIN is not much help. It seems to me that the likely number of people that we're talking about is fairly small.
    More importantly, when I look at it from a legal point of view, the timeliness is what really comes to me about that. It is correct that some of the records are not kept for a particularly long period of time, so you have to get there quickly, and it seems to me one of the things that ARIN can do that's directly in its purview to help is make sure that the first contact is the correct contact. This policy guarantees verified data at the top level.
    Another interesting point is that many don't want to slow down their subpoena process and we don't want to tie up our lawyers with it. I guarantee that for the foreseeable future, we will continue to publish all of our data. I believe others have said that is also their current intention. My company would get very upset if we didn't publish all of it and I started running up hundreds of hours of billable lawyer time dealing with the more onerous requirements of subpoenas and being involved in the legal process.
    So in terms of getting to somebody that can help you, I think the actual end result of this policy is that you will go more often in the first step to somebody who is actually interested in helping you than you do with the current database.
• A question was posed to the representative from the U.S. FBI. I know that it will probably be a surprise to some of the other people here exactly what the breakdown was that we were talking about earlier, as far as what percentage of what you investigated ended up being top-level ISPs with direct ARIN assignments versus stuff that's lower down in the chain. I think most of us here would assume that the vast majority of addresses that you're trying to track down were, in fact, assigned to the big guys who got direct assignments anyway. And if you could speak a little bit to that, I think that would add something.
  • The FBI representative replied that's a very good question. I actually don't have statistics in front of me. I'm not the front-line investigator that does these investigations anymore and this is talking from my personal perspective now.
    Before I joined the Bureau and when I was a state prosecutor in California, we did a lot of consumer protection investigations. And in most of the cases, back when the information was actually a little bit more accurate perhaps, the investigation would resolve to a sub-ISP. But as far as the numbers or statistics or how many investigations result in end-users that did not get their IP address from the parent IP directly versus sub-ISP, couldn't give you that statistic .However, if the proposal is implemented, we'll have to send it to the top-level ISP anyway, and could only guess or gamble that we get the information right away. But the top-level ISP or ARIN are still going to have to get all the subpoenas and all the search warrants, because we have no choice. We certainly don't want to double our work, or triple our work and triple the work of the attorneys of the ISP, and send subpoenas to the ISP that may not even know who the end-users are, but can only point us in the direction.
• I'm wondering if attaching a maximum application size or something like that to this provision would be enough to satisfy law enforcement's concerns. Essentially saying that very small applications, which are likely to be a home user, are not in the database.

End of Discussion:

A straw poll of the consensus of those in attendance was not immediately taken. However, later in the day, the question was posed, to provide feedback to the Advisory Council, on whether those in attendance supported changing publication requirements to make subsequent delegation data publication optional or keeping the current schema? The consensus in the room was that they did not support changing the publication requirements for reporting subsequent delegation data.

Policy Proposal 2004-8: Allocation of IPv6 Address Space by the IANA to RIRs

Presenter: John Sweeting

Presentation: PDF PPT

Ray Plzak presented an introduction to the proposal. Highlights included:

• Revised text posted to PPML – April 15, 2005
• Presented – ARIN XIV
• Staff Impact Analysis – April 2005
  • ARIN departments - no significant implementation impact
  • Implementation - within 90 days following ratification by the ARIN Board of Trustees
• Legal Review – October 2004
  • "…saw nothing that created concerns for liability related to ARIN or issues of compliance with law or regulation."
• Public Policy Mailing List (PPML) Discussion Summary
  • There were 16 posts by 10 people. Notable responses included:
    • “…suggest adding a sentence stating that IANA will also announce the allocation to other interested parties.’"
    • Who makes list announcements to whom and in what format(s)… RPSL, XML?

John Sweeting continued with the presentation of the proposal. He stated that this policy, which is global in nature, was presented at the last APNIC meeting by Ray, on behalf of the Number Resource Organization (NRO). It will be presented at the AfriNIC meeting next week in Mozambique, and then at the RIPE and LACNIC meetings which follow. He went on to provide some background on the proposal and details on why it was needed and the resulting benefits in terms of IPv6 allocations to the RIRs from IANA. He also noted that during the previous week, the ICANN Board approved a similar process for IPv4 allocations from IANA to the RIR.

General Comments:

• Geoff Huston, of APNIC, offered the following comments. I'd specifically like to respond to the issue of /16 allocations against the /12. The assumption here is that we're going to manage IPv6 using sparse allocation practices by shifting the amount of the windows every time you make an allocation. The idea behind this is to actually allow the maximum extent possible for individual allocation windows to expand without creating fracturing of the space so an individual applicant is seeing multiple allocations they can't aggregate in the routing system.
  What I have done over the last few months is to actually simulate an IPv6 registry using data originally from our v4 history and mapping it into v6. What you find is that the initial allocation you work from has a relatively large effect on the amount of fragmentation that happens. Coming out of the /16 as distinct from a /12, you actually collapsed your windows quite significantly, and you get longer and more frequent fragmentation. Indeed, what happens is you stimulate the registry operation itself over a three-month period. With the v4 data, all but two, LACNIC and AfriNIC, will actually see the /16 within a three-year window. So a /16 is not as large as you think.
  Now, there was a fair deal involved with sparse allocations. But what I would say is that if one of our primary objectives here is to manage the space responsibly so that routing scales, this issue of the /12 from a /16 is a critical issue. And if one of our objectives is to ensure, as much as we know, that we're trying to protect the integrity of the routing space for a very long time, and a /12 offers you the assurance that you can do sparse allocation over that and minimize the fragmentation.
• Regarding the /12 or /16 discussion, I think the adaptable sizing is reasonable.

Statements For and Against:

• Doug Barton, the General Manager of IANA, offered the following statement. I would like to thank ARIN for putting this policy forward. I think it's an excellent step in the evolution of this policy.
  I particularly would like to thank the authors for amending the paragraph about announcements, and this was a topic that I spoke on back in Reston. In the IPv4 public comment forum that we had regarding the policy that was just approved at ICANN, one of the four comments that was made about that policy was that gTLD registry constituencies were specifically asking for this type of announcement.
  So I appreciate the discussion and the amendment to the language. I think it's definitely incorporated the step that we've all recognized there is a need for this thing to happen.
  We have in the past discussed the possibility that within the framework for the IPv4 allocation process, ARIN and the RIRs work really well, that in the IPv6 world we may want the periods to be longer. And specifically the period of operating capacity that is listed currently as 18 months, in the past it's been discussed that it may be more useful to have a longer period of time in the policy so that, as far as allocation and different other allocation methods that the RIRs are considering, they can be utilized more effectively. And I'm not sure that's where we want to go with this policy at this time, but if that were to be, if an amendment to that nature were to be offered, then we would definitely be in support of that.
  On the other hand, the six-month period of recent allocations that we're using to calculate more or less what the next round of allocations should be, I think is very appropriate. And the research that was presented yesterday by Mei Wang of Cisco really illustrated why that part of the policy was very important.
  So by taking into account the operating period, in addition to what we loosely call the sort of acceleration rate at which the RIRs are performing allocations, I think that gives us the best of both worlds.
  And finally, I've about lost hope on this last point, but I still think that substantiating the /12 as the only allocation unit may put us into a position down the road where the only possible way to allocate enough space for the RIRs to work for the next 18 or 24 months may be to allocate a block that is much larger than their projected needs for any reasonable time in the future.
  And for that reason, I would like to renew my suggestion that we amend the policy to state that the subsequent unit should be a /16, which would allow us to allocate as many /16s as was needed in order to give the RIRs the space they needed to manage their allocations going forward, but not lock us into a position where the /12, as the only unit, may be too large as the subsequent allocation unit going down the road.
  With that said, I have all but lost hope that we have a chance to get that in the policy, but I feel duty-bound to offer that in the discussion. And once again, thank you very much for the hard work you've done on this.
• Lee Howard, speaking to the floor as a member of the ASO AC, said I do think it's absolutely appropriate to amend the policy to allow allocations of appropriate size based on operational experience in the ARIN region, where twice, in my memory, we have changed the allocation size that ARIN can assign. And I think it would be appropriate for IANA to have the same flexibility to make sure that ARIN can meet its needs.
• I support the proposal, but I think we need to move forward by getting larger allocations in place. I think there are a lot of questions we don't fully understand the implications of, like how large do the reservations need to be to get good allocation going forth, say, over a ten-year timeframe as opposed to a two- or three-year timeframe? And how do you account, for example, for what is utilized, and that includes how big the reservation is and so forth? And I don't think it's critical we solve that today or even necessarily in the next 6 to 12 months, but we do need to solve it before we start bumping up limits where we no longer hold with the reservation because some time limit has expired. And we need to go back to IANA, and we have to allocate some of the space, because we can't go back to IANA and get more space. And I think we have time to work that out in the next couple of years. And so I think I'm generally supportive of the proposal, but I'm a little bit worried about some of the details, and we sort of are locked into them.

Questions/Responses/Clarifications:

• Where does this policy proposal stand with regard to the other RIRs?
  • Paul Wilson, of APNIC, responded that he presented this at the recent APNIC meeting, and it was accepted by a consensus of the meeting with a provision that changes to the document that may arise for future RIR meetings will be accepted in advance providing that they not be substantial changes. In his opinion, changing the allocation size from a /12 to a /16 size, for example, was exactly the type of change that was described as a possibility.
  • Axel Pawlik, of the RIPE NCC, announced that this would be presented and discussed at the next RIPE meeting.
  • German Valdez, of LACNIC, replied that this would also be discussed at the next LACNIC meeting.

End of Discussion:

Two straw polls of the consensus of those in attendance were taken. On the first question of whether to change the allocation size mentioned in the policy proposal to a /16 or keep as a /12 (as currently written), there was consensus in the room to keep it as a /12. On the second question, there was consensus to move the policy forward.

IPv6 Activities Report

Speaker: Thomas Narten, IBM

Presentation: PDF

Thomas Narten provided a presentation on activities within the IETF relating to IPv6.

Highlights:

• Multi6 working group was chartered to study the question of “how to multihome in IPv6” and winnowed numerous proposals down to an architecture. The architecture is described as a shim between ULP (e.g., TCP) and IP that would be mostly transparent to applications, in that they would use what they think are IPv6 addresses. There are many details to work out, and the current plan for the working group is to finalize some documents and then close the working group. A new working group, called shim6, will produce an implementable specification. There is a mailing list and everyone is invited to participate. Timeline is 5 years until useable solution (realistically), and in 1 year we'll have better idea if we're on track.
• A BoF was held called v6 Tunnel Config (v6tc). There is a desire to have a way to set up an automatic v6 tunnel to ISP/POP, but is unclear if a working group will form.
• There is now a IAB-IPv6 AdHoc Committee formed to advise IAB on IPv6 addressing matters. Current topics being considered are clarifying documentation (in RFCs) about how IANA manages IPv6 space, ipv6.int deprecation, IANA to RIR allocations of /23s, questions about the HD-Ratio, and a re-examination of the /48 recommendation.
• IANA and RIRs are working on policies defining
  • How big should IANA to RIR allocations be?
  • When is an RIR allowed to ask for more?
• IPv6 working group is in maintenance mode. Still need to finish protocol specifications and revise/update existing RFCs.
• v6ops working group is considering rechartering, possibly to refocus on operational issues that come up during deployment.

There were no comments from the floor.

ULAs

Speaker: Geoff Huston, APNIC

Presentation: PDF PPT

Geoff Huston, of APNIC, made a presentation on IPv6 Unique Local Addresses, and specifically an update on IETF activities related to this topic.

Highlights:

• The core objective is to define a Private / Local Scope Use IPv6 address pool that could be used in a number of important contexts.
• This is a twist on "site local addresses" that aims to keep the ideas of simple, stable, and private, remove the explicit scope declaration, and add nonambiguous addresses.
• These would be private addresses in terms of routing scope, but global addresses in terms of uniqueness.
• Two possible address pools. One for locally defined addresses that would have no global AAAA or PTR DNS records. The other pool would be centrally assigned, and would come from uniquely assigned address prefixes. This second pool may appear in the global DNS, but not in the global IPv6 routing table. Also, this second pool's status appears to be dormant within the IETF IPv6 Working Group.

Comments:

• The IAB released a document espousing there should be a single route, a common name space, and the whole nine yards. You just told me that if we're going to do this, that the IETF is recommending that the IAB was, in fact, full of hot air because you have to set up a split DNS with us? How do you reconcile that within the IETF? Does the IAB step down from its stance on a single route and a common name space?
  • Geoff responded that was a valid point. This is a pragmatic move by the IETF to satisfy a certain set of perceived needs that aren't able to be adequately met under the current policy framework.
• Paul Wilson, of APNIC, offered the following comment. It seems to me that this provision is answering one type of private address space need, to find correspondence to 192.168 space in IPv4, that is for small, private networks. But there's no solution being offered that corresponds to 10/8 space, and there are clearly applications which are private networks that are big enough to need much more than a /48.
  This came up in the APNIC region, and it was proposed to adjust the IPv6 allocation policy, so that we could make allocations to large networks that were not being connected to the Internet. And we have done that in at least a couple of cases.
  There's a bit of artificial constraint there, because we've got a minimum allocation of a /32 in some cases. So even though those private network requirements might not require a /32, we've allocated a /32 because that's what the policy says. And there seems to be a whole spectrum of possible private network needs between /48 and /32, and larger than /32, that we could allocate pretty much in the normal way, disregarding the need for that address space to be connected to the Internet, and disclaiming, as we do, any responsibility for routing that space.
  Why do we need something special for this at all? It seems that it would actually fit -- if we dropped the requirement for a minimum allocation of /32 in cases where we could say, explicitly in cases where we can say the address space in not being routed, then it would make sense to assign a /48, a /47, or whatever was appropriate or whatever need was out there.
  There just seems to be a whole lot of artificiality and a whole lot of confusion in this proposal. It's taken a long time and there's been a hell of a lot of discussion, and I'm not sure it's getting there.
  • Geoff replied with the following: In this particular case these addresses are available almost as a private transaction between you and the spinning of the wheel. If you want more bits, instead of truncating at 40 bits, you can truncate at 32 bits, or any other value. The possibility of some sort of collision were you to connect with anyone else, of course rises dramatically.
    But your other point about why couldn't this be done with your normal space is really an issue of what's the cost to end points, and what are the policy criteria in going to an RIR of such an allocation, versus this mechanism, which certainly has none of those externalities of costs associated with the selection. The externalities are expressed in another issue where you've actually got to keep these addresses in the box and not expose them outside. So that once you mounted your network using these addresses, the extent to which those addresses can be broadcast outwards is really limited. That's a trade-off, I think, that anyone who wants to use these addresses has to recognize right up front.
• What I see in many of the presentations is we are talking about two different proposals. One proposal that is more or less not that active in IPv6 working group at this point, and that proposal has much more serious consequences for the work that we're doing here than all the proposals that are actually approved. And I think it's important when people make comments here, actually which proposal they're commenting on, because there's a huge difference in consequences on which one you're recommending.
  The proposal that's approved by the IAB is a proposal for simple, fairly small amounts of -- in the context of IPv6 -- private address space that can be used for people that have needs for, for example, some ad-hoc address space, for example, in a lab. We would not have approved something in that area if people would just pick their own space. I don't see any alternative but approving something that is not ideal and, of course, it would be for people to use real globally routed IP addresses, but there would be cases where people will want to select something else. And that is the solution if it just works for them.
  These other proposals have a little more ifs, and whens, and all the issues. And like Paul's comments, I didn't really get this from your comments whether those comments are oriented towards the proposal that's approved or the other proposal that's still on the table. And I think it's very important to make the distinction, because they're very different.
• Reverses for private space is causing problems today.
• Since I was rather vocal on this last time, I thought I should make my position clear. I absolutely support this locally assigned address concept. I also think at the same time that the simply assigned thing is the worst proposal I've ever seen and I have no support for it.
  But the comment I want to make on the local addresses thing -- and I make this as someone who sits down and types things into a router sometimes -- is this is just really complex and it doesn't need to be. There is FD00/8. Go have fun with it. It's nice that we have all these things that would make it less likely to collide and whatnot, but it seems to me the RFCs should be used much like 1918 is, saying here is this thing that you can use locally. If you want to assign 48 to your site, that's great. If you want to do what I do in my lab and assign 120s, that's great. It just doesn't matter.
  However, there should be a BCP that suggests this allocation algorithm, and, for that matter, applies the same algorithm to 1918 space. There is no reason you couldn't do the same cache function, truncating it to 8 or 16 bits and applying it to to the 10 map, which would help corporations not collide. That's simply an optimization as to how somebody local uses it, but when I configure my lab, knowing it's not going to connect to anybody else, I'm going to completely ignore this whole unique identifier thing, and it's a /8 that I get to go play with. That's just a practical consideration.
• There was a question about the probability of collision. Geoff responded that the collision occurs after approximately 1.24 million spins of the wheel in a 40 bit space, that the probability exceeds .5 at that point. So if they all enter the DNS on somewhat of a mutually-colliding space, where each choice potentially collides, the number is around 1.2 million for the space.

• We may try to enforce the randomness, but if we do not enforce the randomness, I can guarantee you that it will be 192.168.1.24 all over again.

• I just was going to comment on the issue of whether this should be the BCP or in the document itself. Sometimes BCPs might be appropriate, but from the random manufacturers who are going to actually put the code in the box that does this automatically, to the random consumer, it's better if it's in one document so they don't get confused and not do the right thing.
• This creates the potential for intellectual property. I believe that under this I can claim my own FD00: Deadbeat:: and no one can take that away from me. That will muddy the waters with regards to ownership of addresses. I'm leery of that.

Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites

Speaker: Lea Roberts, ARIN AC

Presentation: PDF PPT

Ray Plzak presented an introduction to the proposal. Highlights included:

• Introduced on PPML – February 15, 2005
• Staff Impact Analysis – April 2005
  • ARIN departments - no significant implementation impact
  • Implementation - within 90 days following ratification by the ARIN Board of Trustees
• Legal Review – April 2005
  • "…saw nothing that created concerns for liability related to ARIN or issues of compliance with law or regulation."
• Public Policy Mailing List (PPML)Discussion Summary
  • There were 49 posts by 17 people. Notable responses included:
    • “The universal benefit for 2005-1 allocations is 'deployment'.”
    • “…IMHO end-sites should not, by default, be able to get their own IPv6 PI block, yet, until we explore other options.”

Lea Roberts, on behalf of the ARIN Advisory Council and the proposal author, Owen DeLong, presented information on the proposal.

Highlights:

• Proposal provides the holder of an Autonomous System Number (ASN) the ability to request a direct IPv6 assignment
• Rationale includes multihoming, relief from renumbering, and helps addresses concerns about ULAs
• Restricted to one assignment per ASN, and if more space is needed, organization must meet normal usage criteria, with the new assignment being made to cover total justified space
• Resources are reclaimable and does not create a permanent swamp
• DFZ table impact is conservatively estimated to be < 20K RIB entries, and most would be RIB entries anyway

General Comments:

• It seems to me that the work they are doing about IPv6 multihoming is in an attempt to minimize the number of routes in the global routing table. If we start allocating provider independent small space and start introducing that into the global routing table, that is then a slippery slope that sets a precedent for allocating more specifics in the global routing table. Also, if you're going to be multihoming, what is the smallest advertisement that should be globally routed? If you're giving out /48s, you're allowing a lot more specifics than a /48, because people want to engineer their traffic, draw traffic to a particular provider, try to limit their links as easily as possible. Again, I think, sets a precedent for allowing more deaggregation in the global routing table.
• In order to think about the effect of this on the routing table, it's important to think of the effect of routing table growth due to multihoming in the context of routing table growth due to contiguous allocations. For instance, I'm not picking on anyone in particular, but I did find 42 screens full of routes coming out of UUNet. And I would anticipate the sparse allocation policies that are being proposed for IPv6 would effectively cut that down by a magnitude. I would not think that in the context of fixing that part of routing table growth, that routing table growth due to multihoming is a particularly big problem. On the other hand, I don't believe people who think that the global routing table will only have 4,000 entries in it either.

Statements For and Against:

• I would like to make a point that before such policy should be undertaken, you have to seriously look at the AS assignment policy, because this will cause a run on AS numbers like you have never seen before, and you will easily blow out your AS space.
• We're the model idea of who this would be targeted at. We currently have allocated a /20. We have our ASN. Currently we advertise it through three different upstreams, and we would like to be able to do the same thing with IPv6. If we can get provider independent space, we probably will set it later. If we can't, then it would be later, rather than sooner.
• I represent something called the IPv6 Business Counsel, which was just chartered a few months ago. It already numbers about a dozen Fortune 500 companies throughout America that have an interest in looking at deploying IPv6. Some of the members are here today at your invitation, and we appreciate being allowed to participate in the process: Wal-Mart, BellSouth, Citibank, Boeing, Bechtel, FedEx. Big companies that all have expressed an interest in this. The last two meetings we looked at this particular proposal. We debated it. We looked at it from a business perspective. We're not going to tell this group, certainly, how to implement these kind of changes on a technical level. But from a business perspective, we understand that IPv6 could be very big and very critical to our businesses in the future. We don't yet know what we're going to do with it, but we're starting to finally look at it, looking to running trials and doing things. But the majority of our membership is unwilling to even get started if we have to make a decision about who our ISP is going to be, who our provider is going to be today before we even know what we're going to do with it tomorrow. So our response is, if we can't make these kinds of changes, we can't get our own allocation space to figure out what we're going to do, we're just not going to do anything yet until it gets further down the road. I would agree that this is targeted at large businesses and large enterprises. I don't think it's the same thing to say it is of interest only to that market. I would argue that this would be of interest to anybody who is thinking about deploying IPv6, because fundamentally what everybody wants at the end of the day is IP address space that they can take with them and believe will be routable for the return. That's what people want, and if we provide mechanisms to achieve that, other people are going to see if they can also use the same technique for getting such an address, even if it's usability wasn't intended that way.
• I'm with Accenture. It's important that without this policy, for the simple business aspects of it, it is going to handcuff a lot of businesses to move to IPv6. Accenture runs large global network multiple ISPs, and as a public company we're responsible to our stockholders to maintain cost-effectiveness, and to our customers to deliver a high level of services. Without this, we're going to run into some difficulties with being able to manage our service providers. And as a result we're probably going to be delayed in moving to IPv6. There's just too much flux right now in the ISP world, that we can't continue to not be able to have the flexibility to change our service provider. So we need this policy in order to effectively start to put IPv6 in our environment.
• I do agree with the comments on the run on the ASNs. I think you have to worry about that. There needs to be some specific time limit. Right now, we view our routing tables being on the order of a number of LIRs that would be out there, maybe times two or three because of a little bit of fragmentation. But now, with this we would have to consider our routing tables being on the order of the number of AS, which is a significantly higher number than the LIRs. And I again anticipate we're going to have to change the way we allocate ASNs and that would start having an uncontrolled effect there.
• I'm a strategic applications manager for Wal-Mart. Wal-Mart does support this policy as it's written. The [IPv6] Business Council has Wal-Mart's full support in that, and hopes that individuals will leverage the experiences that are available there.
• I agree with the other large enterprises that are represented here, that I do want to support this Internet policy. The difference between having provider independent space, even if it is temporary, allows still the flexibility of changing providers without having a full renumbering. Today, with IPv4 in place, a renumbering of web services isn't too complicated. But when you're talking v6, and every node having to be re-addressed, it's quite a different issue. I would say implementation of IPv6 with the necessity of being married to an ISP for your space is very limiting, if not crippling, to the implementation of the technology.
• I am a holder of IPv6 address space for Nokia. So there are big companies who did manage to get space under the current policy. I think there is a need for this policy. I think the problem is not so much the need for it, it's the problem of how this policy is proposed. Everything that I see in this thing will not work. I see big issues. I mean, the AS number dependency is just a really, really bad idea. If people need an AS number they can ultimately hold, that's fine. But you shouldn't put an IP address number policy and make it dependant on AS numbers. Because you get really big installations by people who are going to apply for AS numbers, because they have a need for address space. People apply for address space when they have a need for address space. The dependency is a really, really bad idea, and calls for problems. The policy is not going to have a lot of impact on the operational side of ARIN. At the same time I am hearing here that people just have to give this other space back at some point if they upgrade. Well, guess what? If they're going to not volunteer, are we going to get this back? We'd have a small problem, and it is going to be an operational impact. The idea about people will just give it back, I mean, we have heard it before and it hasn't worked. I'm sorry, I just don't believe in that. Part of the problems that we hear here are the side effects of the current global policy. And my preference would be to fix the issues in the global policy first, because I think that will address part of the problem that's here. Not all, but part of the problem. I do not support this policy at all.
• I'm from HP and I just want to say that we're in favor of the policy.

Questions/Responses/Clarifications:

• What are your thoughts about this setting a precedent for the ultimate solution of solving the IPv6 multihoming problem by simply allowing aggregates?
  • Lea responded that in putting this together, she discussed with Owen some of those issues, and his feeling is that right now there are people who will not move into providing IPv6 available services because they are unwilling to take the risk of numbering into a provider allocated block. They don't want to be tied to a particular provider for their service.
• I'm Bill Darte, and I'm on the Advisory Council. I would like to ask the members that are representing business issues here, who say that they would likely defer a decision towards implementation because of the ISP uncertainty issue, this also suggests that these aren't permanent allocations and that you might have to give them back. Would that not also provide the same kind of uncertainty, or could you assess the degree of uncertainty between those two options of getting it now and then having to give it back later versus not getting it at all?
  • A representative of one of the interests Bill referred to responded with the following. I'd rather have this policy as it is than no policy at all. And granted, the wording of it, having to give it back, does create some consternation. But right now I think there needs to be some sort of policy that helps protect the business interests of the people that are trying to move to IPv6.

End of Discussion:

John Curran took a straw poll of the consensus of those in attendance. There was no clear consensus in the room either in favor or opposed to the policy.

WSIS and WGIG Observations

Speaker: Steve Ryan, ARIN Counsel

Presentation: PDF PPT

Steve Ryan, ARIN Counsel, presented a set of observations on the World Summit on the Information Society (WSIS) and the Working Group on Internet Governance (WGIG).

Highlights:

• Currently we have an Internet where each national government, within its own territory, can control what happens to its citizens and has unique views on the rights of its citizens.
• Organizations like ARIN have grown up to provide necessary services with consumer/stakeholder-based policy development and technical and engineering decisions control.
• The World Summit on the Information Society (WSIS) and Working Group on Internet Governance (WGIG) represent a real debate about the current governance model.
• Those governments opposed to the current model have a number of reasons for doing so, including:
  • Insufficient control by governmental authority;
  • Inadequate permission of international taxation and regulation;
  • Too capitalistic, too private-sector;
  • Allege it insufficiently represents “civil society.”
• A risk from the WSIS process is that it could result in a recommendation to the U.N. to develop a U.N.-based governance body that could drastically change how the Internet is managed.

Comments:

• I'm Cathy Handley from the Department of Commerce. Commerce has recognized the importance of the WSIS proceedings, and we're extremely active with them and our colleagues from State. But more importantly, for everyone in this room, I think that you all should feel comfortable that my colleagues from the Department of Justice, FTC, and FBI recognize ARIN as the place that we can go in order to address our concerns. This community here has repeatedly made me feel welcome. But we do look to ARIN directly, and that's yet another example of what we look at as this public-private partnership for the Internet.
• One thing that I don't think ARIN has is a mechanism by which the body of people who participate in ARIN authorizes ARIN to speak on their behalf on some of these issues. And you know, we come here and we set addressing policies and that sort of thing, but these are only indirectly associated with addressing policies, it seems to me, and it would be nice if there were a mechanism to vote the consensus of the group to authorize ARIN to speak.
  • Ray Plzak responded that issue was brought up at the last meeting and we are working on it. There are some mechanics of the thing that we have to work out, as far as how we could get a reasonable measure of consensus. Consensus of members is easy to judge, but it's the stakeholders at large that is a little bit more difficult, and we're actually working on a process to do that.

Open Microphone

Moderator: John Curran, Chairman of the Board

John Curran opened an Open Microphone session for comments.

Comments:

• There's something that does come up that has been a problem for us and probably for other people in regards to new allocations. I'm looking for feedback from the group about that. We thought the problem would be first with the 70 block that was allocated by ARIN, and then, more recently with the 72 block. And the problem seemed to be with the allocations for new blocks and the issue is they are not globally-routable and we tend to get a lot of customer complaints about that. I certainly would like to find out if other people are having some problems, and I'd like to discuss possible solutions that we can address. For the 70 block, since we're a large user of address space, it so happens for that block, SBC was also allocated with us as well. So we had many millions of customers going on the Internet, and we were able to sell it out in a few weeks. I don't think there's a problem with those [bogon] lists not being updated, but rather with people putting filters on the routers and then not updating them from the new updates.
  • A representative from SBC added that that continues to be a problem and there are also so many lists out there. All I can offer is what we do internally, is we have our handful of lists that we go out and look at. If we have a particular customer complaint or a problem with the block that's getting filtered, we'll do a certain amount of due diligence, and gather some information from about a half a dozen or so of those sites that are out there. If their removal policies are just outrageous -- and a couple come to mind where it's, "pay me $2,000 and I'll think about removing your block." But depending on removal policies, we just go back and say we can assign you a new block, and hopefully it will come out of another /14. I don't know what the answer is to it. The impression that we're starting to get is, as more and more of these lists appear, and as more and more of their removal policies get even more outrageous and ridiculous, I think a lot more people are starting to to ignore or take some of the information there a lot less seriously.
  • John Curran added that the discussion might be overlapping two topics. One is the list of bogons, i.e. unassigned address space that shouldn't appear in a packet. And the other one is spam blockers.
  • The gentleman from SBC is on a separate issue, RBLs. The issue of testing the routability of who assigned the space is a minimal test, and I believe that ARIN is in the process of addressing it.
    • Leslie Nobile, ARIN Director of Registration Services, added that ARIN has talked with an outside organization to do the testing with any blocks that have been assigned to ARIN. So blocks we get will be tested well in advance of us delegating space from them. We hope to do it three to six months out, but can't offer any guarantees. We're going to be doing it from here on, going forward.

Closing Announcements

Speaker: Ray Plzak, ARIN President and CEO

Ray Plzak reminded attendees that the ARIN RSD Help Desk and the Terminal Room were open until 6:00 PM EDT. He encouraged all attendees to complete the meeting survey available on ARIN's website and to visit the Exhibitors Hall. Ray concluded by announcing that after lunch, the North American IPv6 Task Force would continue its meeting.

Meeting Adjournment

Day 2 of the ARIN Public Policy Meeting was adjourned at 12:45 PM EDT.

Relevant Navigation

ARIN XV and NAv6TF Summit

• Pre-meeting Activities
• Public Policy Meeting Minutes
• Members Meeting Minutes
• Documents
• NAv6TF Presentations
• Meeting Attendees
• All Meeting Reports

---

Search ARIN.net
Advanced Search
Search Tips

© 1997 - 2008
American Registry for Internet Numbers,
All Rights Reserved.