Welcome word by Hans Petter Holen. Short introduction and reminder that this is the 2nd time this WG comes together under the name "Address Policy WG", known before as the "Local Internet Registry WG" which was split into the "RIPE NCC Services WG" and the "Address Policy WG".

Introduction of the 2 other chairs. Work division: Gert's task is to follow and respond to the mailing list, Andrea's task is to compile the agenda and keep an eye on the actions list and Hans Peter chairs the meetings.

HPH gave a short explanation about each agenda item and asked whetherthere was anything needing discussion but not on the agenda. IljitschVan Beijnum (IvB) asked whether it was possible to discuss thediscrepancy between the micro-allocations policy and the IPv6policy. HPH replied that it could be discussed during the IPv6 agendapoint or at the end, during the A.O.B.

- RIPE 46 Minutes

Need to approve RIPE 46 and RIPE 45 minutes. The last minutes wherepublished in Oct 2003 on the mailing list and no comments were made toit. There is also the web cast from the last meeting, so it can alwaysbe double checked by anyone. HPH asked whether people had comments tomake to the last 2 minutes. No questions: both minutes approved!

Mike Hughes: [comment related to slide number 8] The figures are notcumulative.

LV: Indeed.

Randy Bush (RB): [question related to slide number 10] Can you be abit more specific about the category 'Other'?

LV: The individual percentages of the other countries grouped in'Other' are very small and it is difficult to represent them in ameaningful way. There is however the possibility to view each IPv6allocation made on our website.[http://www.ripe.net/ipv6/ipv6allocs.html]

Arien Vijn (AMS -IX): I noticed that Germany is missing. Could Germanybe included in 'Other'?

Gert Doering (GD): I just checked and there were 25 allocations for DEin 2003.

LV: The Central Registry represented here relates to who issued theaddress space, rather than in which database the address space isregistered in. After the ERX is completed, maybe there will be a lookat opening up the old Class C space and allocate or free some of theaddresses that we can currently consider as 'frozen open addressspace'. For the time being we consider it as used and not availablefor us to allocate from. But we still have more than 90 'virgin' /8's.

Ray Plzak (RP)(ARIN): 'Central Registry's' 92 /8's representsallocations made by John Postel prior to the RIRs, by the DDNNIC andInterNIC. A good chunk of that space are the old Class A's residingwith a bunch of companies who, likely, will never give them up.

RB: [comment to slide number 4 & 6] It is interesting that APNIC handout more address space but the least amount of AS Numbers. Is itreasonable to hypothesise that this shows that there is not so much agrowth in number of ISPs but in the size of address space _per_ ISPthan in the other regions?

LV: You are probably in a better position to answer that question,being an operator in the APNIC region.

RB: No, I do not know. I'm just looking at these numbers and find itvery interesting.

RP: Randy, we would have to go back and look at registration records,the stats are on-line as well, and you'd have to have a look at thenumber of organisations that receive addresses per year. The figureson this slide are not organisations but the resource itself. You couldlook at how many organisations received AS Numbers or IP addresses peryear. This would represent a different matrix, which could answer yourquestion.

RB: Is it fewer AS Numbers per organisation in the APNIC region?Another possible clue is that this is the number of allocations notthe size of space allocated. The IPv4 allocations may be of differentsizes?

LV: Yes, they are not all the same size.

RP: Randy, those columns represent /24's. But you are correct, oneorganisation could have gotten a /16 and another a /13 and soforth. For example, ARIN have recently been making very fewallocations but they are very large. We have been handing out /13's.

RB: So back to the original hypothesis, what you are saying is towatch out for the difference between number of ASes and number oforganisations?

RP: Yes, the other thing is to look at number of membership per RIRsand the growth of new members. That will show you the number oforganisations that are getting resources from the regionalregistries. But you have to be careful about that when you look at ASNumbers because in the ARIN region, if someone has received addressesfrom an upstream provider but they want to multi-home, they come toARIN to get an AS Number for that, but they do not become a member ofARIN.

RB: Thank you.

IvB: Randy, your hypothesis could also explain why the RIPE region hasby far the most IPv6 allocations even though it is generally assumedthat the APNIC region uses more IPv6.

RB: I think it would be worthwhile conducting experiments to look atthe traffic in volume in IPv6 in the different regions with the helpof Exchange Points. If someone has a good enough magnifying glass..

GD: We have the numbers of Local Internet Registries per region. Mytheory is that in the RIPE region we have so many IPv6 allocationsbecause we have many more LIRs than in other regions, but this couldbe completely off base.

LV: It is certainly a factor. We have over 3500 LIRs and I do notthink that APNIC have that many LIRs.

Joao Silva Damas (ISC): [question related to slide number 8] Thisactually represents the number of allocations made, whereas in theIPv4 slide it represented the total number of IPs.

LV: Yes, the IPv4 slide was in number of /8's.

IvB: [comment related to slide number 11] I think the explanation why,in AFRICA, most addresses come from ARIN whereas most AS Numbers comefrom RIPE NCC is because ARIN charges per AS Number, when RIPE NCCdoesn't.

LV: That could be the answer.

Leslie Nobile (ARIN): The IPv4 that is showing on the slide includesthe InterNic numbers, the legacy space, in addition to the ARINallocated space, so it goes way back.

LV: That explains a lot.

C. ICANN ASO AC Update (Marc McFadden [MMcF], ICANN ASO AC)

"Report on the ASO AC"http://ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ap-aso.pdf

Questions & Comments:

Azucena Hernandez (Telefonica): What is the role that the NumberResource Organisation (NRO) is going to play in relation with theAddress Support Organisation (ASO) and ICANN?

MMcF: That's a great question. The NRO is an independent group. It isan organisation that represents the common interest of the RIRs andthe ASO is separate from that. One of the valuable things that the NROgives is that it allows the RIRs to speak with one voice when speakingto other organisations like IANA or ICANN. The ASO sits under ICANNand is really there to provide input and expertise in numbering issuesto ICANN.

HPH: Thank you Marc. I would like to add that we have 2representatives here from our region in the ASO: Wilfried Woeber andmyself. Sabine Jaume, the 3rd representative, is presently at home,busy increasing the RIPE population. My term on the Address Council isexpiring this year, so probably at the next meeting we will holdelections preceded by a nomination period.

[Issues raised: - Calling for consensus at meetings or on the mailinglist - Set deadlines for proposals or allow them at any time - Keeptradition of flexibility but install some structure]

Questions & Comments:

RB: I was one of the drafters of the recent APNIC policy developmentchange and based a lot of it on ARIN's philosophy. The goal of thechanges was specifically to put some more 'time' in, so that therewould be more participation from the community. APNIC is alsogeographically and culturally more diverse than the European part ofRIPE. They are cultures that are maybe more reticent to use some ofthe media we are used to for these discussions. Another goal was the recognition that these policies affect not justthe people that are managing the address space, the ISPs, but also thepeople that are doing routing, the people developing technologies,like the IETF, or even vendors etc, etc. So the actual stakeholdersare wider than maybe just the people attending the meetings, althoughthe attendees of RIPE Meetings are a bit more diverse. Installing formal mechanisms with formal notifications, not for thepurpose of bureaucracy (which RIPE is good at) but for the purpose ofensuring participation and allow time for feedback from otherorganisations, such as the IETF. So yes, it is worth looking at it forthis region too.

HPH: Thank you Randy. It is an interesting point because there is theargument that we should be able to make changes quickly but maybestability is more of a key argument. Another is indeed to give theopportunity to as many people as possible, to participate.

RB: RIPE's policy development process is notable for its flexibilityand speed, and often lack of participation, not intentionally butbecause we have a global community and some people are maybe not gluedto their e-mail nor on every mailing list in the world.

RP: ARIN documented the process in 2001. The primary reason for doingit then was to contribute more towards the transparency of theprocess, so that everyone would know what it is, and there would be noneed for second-guessing. Be a little more deliberate so that peoplecould not push something through just by getting a large enough numberof people at the meeting, for instance. We followed that process and through using it we learned somelessons. One of the concerns then was that ARIN's Advisory Council,which provides policy advice to ARIN's Board of Trustees, couldperceivably 'inject' itself into the policy process and capture thepolicy. To prevent this we built-in some safeguards, which basicallyallows people to go around the Advisory Council and have theirproposal considered. This is one of the reasons why we made somechanges to our process this past year.

HPH: [question related to slide number 12] Should we enforce a 60-day deadline before a RIPE Meeting to post a proposal?

IvB: No. There are 3 RIPE Meetings per year so that would mean thatfor half of the year you would not be able to propose anything.

RB: In the APNIC policy, there is a window before the meeting and ifthat window is not met, it may still be discussed at that meeting, butno decisions on that proposal are allowed. The purpose is not tostifle the discussions, but to make sure that the proposal gets widediscussion before it is finalised.

GD: I would rather see 30-days as the 'proposal period' before a RIPEMeeting. People generally remember that a RIPE Meeting is coming upjust before it actually happens and not 4 months before that.

HPH: While I agree with you, there is a practical problem and that isthat the chair needs to send out the agenda for the meeting 1 monthbefore the meeting, which is fair to the participants, so they candecide in advance if they want to come to the meeting. Therefore weneed the policy proposal before that deadline.

RB: But the chair only published the minutes of the last meeting only3 days before this meeting, so maybe a shorter period is need. Eitherthat or publish the minutes of the former meeting earlier.

HPH: Well, the minutes were published in October but with otherminutes, you do have a point.

RP: In the ARIN region, what Randy was saying about the time period isthat there is a cut-off point where a policy proposal cannot beconsidered as a policy proposal to be acted upon. That is done toensure that there is sufficient amount of time before the meeting forthe discussion to appear on the mailing list. But if someone has anidea prior to the meeting and is outside that window, then the itemcan go onto the agenda but as an informational policy type item, whichwould then be taken up at the following meeting to be actedupon. Another thing that our policy proposal process does is that itmakes the requirement for the minutes to be published within 5 workingdays after the conclusion of the meeting; it is part of theprocess. Also, the Advisory Council has to meet at the meeting, afterthe conclusion of the 2nd day of the policy discussion, to provide itsadvice to the Board of Trustees (BoT). After the minutes are published, those items, on which the AdvisoryCouncil think consensus was reached on and should got to the BoT, thenreceive a 'last-call'. So everybody gets to have a 2nd look at it andit has happened that proposals have gone back into discussion becauseat the 'last-call' there were some significant comments made. It isonly after the 'last-call' period is completed that the BoT would acton rectifications to the proposal.

HPH: I heard applause when Ray spoke about publishing the minutes in atimely fashion after the meeting, 5 days or so. It is a goodproposal. Maybe we should do it in the same way ICANN's AddressCouncil does: the secretariat produces the minutes and if there are nocomments from the Address Council's members before a certain deadline,the minutes will be published. So if the minute taker has the minutesready and if the chair does not comment within a certain number ofdays, the minutes will be published as the official minutes. We couldintroduce this possibly. [comment to slide number 13] Of course,policy needs to be published and we are much better at itlately. Drafts are published and there is time for people to commenton it. [comment to slide number 14] The hardest thing is the decisionmaking process. It is easy in the ARIN region with the AdvisoryCouncil and the BoT making the final rectifications. It is a group ofpeople with a specific task to do. In our region it is a burden on thechair of the WG. It is the chair of the WG that decides that there isconsensus on the proposal. Normally there would be a final call forconsensus on the mailing list, something I gradually introduced, andmaybe this should be a formal requirement. But I personally thinkthere should be a time limit to this, maybe 1 week or 2 months orsomething in between. And there should also be a requirement for thechair not to declare consensus at own will, but there should be adiscussion on the mailing prior to the decision.

Rob Blokzijl (RIPE Meeting Chair): Yes, whether a decision is calledat a meeting or on the mailing list, is something that needs to beclear to all. I agree with Randy Bush that the decision making pointshould not be at a meeting, because that excludes a lot ofpeople. Meetings are mostly very constructive towards making ordiscussing a new policy but should not be the decision makingpoint. And I agree that there should be a clear time frame for a'last-call' period on the mailing list. Also a clear notification ofthe proposal, with a clarification of its lifetime, should be sent tothe list. Whether, for instance, it is the last opportunity to speakup, is something that needs to be very clear as well. Also, it shouldbe made clear that if nobody speaks up, it will be accepted. Havingsaid this, the principle of this process should be that it is as easyas possible to join the discussion and reach the widest audience aspossible.

HPH: Yes, we think in the same line. Question is if this should be agenerally accepted process, or do we need to formalise it?

Rob Blokzijl: Yes, we should publish a process clear to all. Also, itshould be made clear that this is not done in order to installbureaucracy but clarity. Changes can be initiated at a meeting but thedecisions cannot be made at the same meeting.

RB: Hans Peter, you have asked the question 5 times. Do you have areason why the process should not be formalised?

HPH: Well, I considered presenting here the process as in the ARIN orAPNIC region. But I doubted whether to do that and instead try toadapt the text on the slides into a process without installing hardrequirements. The reason for this because it might be the flexibilitythat the community wants maybe more than the rest, I'm not sure. Butnow I am getting the feeling that putting in some basic rules willmake the process easier to follow for everyone. So, to answer thequestion, no, I see no reason why the process should not beformalised.

IvB: Maybe it is worth considering whether to install requirements tohave technical input besides this group of people interested inpolicies for this region. This because policies that are developed inthis region also have an impact on operations in other parts of theworld. And many operators in other regions are not interested indiscussing policy in this region but they do want to be informed.

Azucena Hernandez (Telefonica): What is always a difficult decisionfor my company is to know when is the right moment to bring somethingup or when are policies being discussed. We also discover a lot ofemotional e-mails, which are difficult to filter and discern theirreal information. So the 1st thing we would like to see whendeveloping such a methodology on a new policy proposal is thedeadline, a time limit. So maybe, when there is a need for a newpolicy, or an adaptation to an existing one, we could have a maximumtime period for it, for instance 9 months, a period in which there wasat least one meeting and enough time for discussion on the mailinglist. In this way my company could start planning ahead when it isalmost clear that consensus is going to be reached. This instead ofhaving to follow 150 mails etc. My impression of the mailing list isthat it is always the same 12 people that seem to be able toreact. And then there are maybe a thousand people whom do not have thetime or resources to react to those mails. So an organised methodshould help, a clear time schedule would help us allocate resourcesand a clear time frame for proposals, because the brain stormingsessions on the mailing list are great for those who have time but itis not as easy for others who would like to focus on theproposal. Another thing is to see written down somewhere what isconsidered consensus in this body. There are bodies I'm familiar withthat define consensus as 'lack of maintained or sustained opposition'and it should be clearly written somewhere that consensus is thatnobody has a strong reason to oppose. Thank you.

Andre Koopal (MCI): The problem that Iljitsch brought up could besolved by something that was brought up yesterday at the "RIPE NCCServices WG" which is that a proposal and its decision should be sentout through the 'announcements' mailing list. Which is low traffic andso maybe more people will subscribe.

Rob Blokzijl: I think it is important to keep a list of proposals madeon the website somewhere. Also where they are in their lifecycle. Butnow we should start writing a process down.

HPH: [comment to slide number 15] I would also like to discuss whodeclares consensus? Should it be 2 out of the 3 (co-)chairs or alarger group that would have such a task as it is done in otherregions? Currently, as it is the chair that decides whether consensuswas reached, if there is a strong disagreement, then a new chair iselected. This is not very constructive.

RB: In ARIN there is an Advisory Council which is elected by themembership. In APNIC there is an Executive Committee, which isselected in a back room. I'm not sure how it is done in LACNIC.

Hartmut Glaser (LACNIC): It goes to the Board.

RB: So in LACNIC it goes directly to the board, who is to say? I agreewith Rob that it is time to start writing something down.

RP: The Advisory Council at ARIN is the one that makes the initialconsensus judgement. The BoT is there to make sure that the correctprocess was followed. They will not rectify the policy if they believethe correct process was followed. Another safeguard to ensure thatthere is enough time for people to discussion to take place.

HPH: I will accept Rob's proposal as it is likely we are all dying forcoffee. Can I call for volunteers to work on a committee to revise theprocess, please come to me or let me know later.

RP: [comment to slide number 5] The BoT will pass the proposal as soon as the charging price for allocations is clear.

HPH: The proposal was discussed on the mailing list and my feeling isthat we should move forward to speed up the transition period and I donot see why we, the RIPE community, should not accept this proposal,it will only make the transition harder.

GD: After talking to Leo, it seems that the problem is that ARIN's andAPNIC's rules to get an initial allocation still require 50% usage. Wedo not ask for this requirement anymore. We should try to alignpolicies and different regions that service the African ISPs. So whileI am not overly happy about the /22 initial allocation proposal,because it is just too small to be useful in the long run, in thelight of the reasons behind I think it is good proposal.

Azucena Hernandez: I also support it like Gert. It makes sense that wemake things easier when they start and that we should accept thisexception.

IvB: There seems to be pressure to lower the block size. RIPE wants a/21 minimum and now there is this /22 minimum for Africa, where isthis going to end? Would it make sense to disregard a few thousand IPsand give them a /21? Even if they just show usage of a /23?

GD: The problem here is not the RIPE region, it is the need to alignthe 3 different policies of the 3 RIRs servicing the Africanregion. The other regions have a minimum utilisation criteria. Thiswill not affect every ISP in the RIPE region, but only those in theAfrican part of our region. And yes, I would also oppose a proposal tolower the initial allocation to a /22 for _all_ the RIPE region.

IvB: Yes, but those /22's will still have to go through my routersetc. and maybe if we set the right example, the other regions willstart thinking about it.

Daniel Karrenberg: This affects the global routing table and not justthe African one and the Africans might be doing themselves a bigdisfavour. We once more need a general discussion between aggregationand conservation, because the world has changed.

RB: There has been a long historical problem in the Africanregion. Techno-colonialists giving an entire ISP with 100 customers amere /27, is far from rare. It is a big problem in Africa. Today,there are African LIRs who, even though they were able to get anallocation, cannot get the European-techno-colonialist to route it. Onthe other hand, what Gert said is correct; the 3 RIRs that serviceAfrica have different policies that make it difficult for them tonavigate. I supported the equivalent of this proposal in the APNIC andARIN region. Here because the actual need is served by other means,I'm not sure I actually support it. But if this group and especiallythe RIPE NCC would really like to show respect to the African LIRs,what they could do is not have 'EU' on their badges.

HPH: To summarise, what I understood is that it's not a _need_ forsmaller allocations, the need for this '/22 initial' is in order toalign the policies of the 3 RIRs. We could give the advice to the RIPENCC to allocate /22's to African LIRs but make sure these blocks cangrow into bigger aggregated ones. As we previously discussed, we willdo a final call for consensus on the mailing list. Not sure yet whatit will be: the African proposal as it stands or including theamendment that aggregation is more important than conservation in thiscase. So there will be an opportunity to comment and advise me onthis.

F. Charging by LIRs (Hans Peter Holen)

HPH: At the last WG, we formed a Task Force to work on revising an olddocument called ripe-152 "Charging by Local IRs". There was some workdone by the TF but there was a lack of conclusion in bringing it backto the community, which we need to keep in mind for the future. We cando the following: 1] conclude that there is no need to revise andleave the document as it is or 2] we mark it as historical, with noreal value anymore or 3] we acknowledge the need to rewrite it. Donothing is not a good solutions because there is a clause in thatdocument that says that LIRs should not charge for name space. It isout-side the scope of this group to make that statement. We don't dealwith name space. And most ISPs here do charge for Domain Names. Thequestion is: do we need this document or not?

Mohsen Souissi (AFNIC): In some African countries LIRs charge a veryhigh price and argue to their customers that this is because they arecharged a lot by the RIPE NCC. It should be made clear somehow that itis not allowed to charge per IP and IPs are very rare in Africa.

Dave Wilson (HEAnet): We are still in the process of trying toencourage people to move to IPv6. /64's and /48's should be freelyavailable to customers as much as possible. So there is a need forsuch a document.

Azucena Hernandez (Telefonica): I do agree that some parts/words ofthe document are outside of the scope of the RIPE NCC. The only thingwe need is a clear revision of the wording. There is no real need inmy opinion to discuss whether the LIRs are charging right orwrong. The document is a bit obsolete but I don't see a real need anda lot of effort undertaken to change it. LIRs are applying logic andthey charge for services and not IPs. The business is runningreasonably, so there is no need to touch it. Don't fix what is notbroken basically.

HPH: In Scandinavia it has been discussed, for broadband technologyservices. Several ISPs, including my own, do charge different feeswhether the IPs are dynamically or statically assigned. According tothis document, this should not be allowed. Should the community beinvolved in this at all?

Speaker 1: Can your 'fixed-IP' customer ask another provider toannounce that space? Because, from the moment I am paying for an IPaddress, I would view it as my own. Don't charge for an IP address,like the lady from Telefonica said, charge per service.

HPH: The question is more that I can have a customer and I give him 4IPs addresses via DHCP but if he wants me to statically route them tohim I will charge a bit more.

Speaker 1: I would view that as charging for a service, not the IPsthemselves.

HPH: That is a very subtle distinction. And it is likely that we arethe only ones that understand that distinction, my sales people andmarketing ones certainly don't, neither do the customers.

Speaker 2: This would encourage people to return addresses when theyno longer need them.

Janos Zsako (RIPE NCC Board): It is important to also make thedistinction that LIRs must charge independently from the amount of IPsassigned. This is the key issue. The RIPE-152 policy does recognisethat the resources needed to manage the address space will determinethe price of the service.

RB: I find it very hard to believe that this group is trying toregulate ISPs business practices. If I, as an ISP, decide that I amgoing to put air into a bottle and sell it, it is my business, notyours.

GD: I agree with you for Europe maybe, but there were some weird casesin Africa, in Tunisia, where all ISPs insist that IPs are so scarcethat they cost lots of money. This is an educational issue; they donot understand RIPE rules and think that IPs are difficult to comeby. We need to clarify the document, put AS Numbers and IPv6 into it,and domain names out of it. Also make it a recommendation for bestcommon practice. So, if an ISP wants to charge, it is hard to makethem stop it because RIPE does not have a big stick to stop themanyway. So, adapting the document to say that charging is fine butthat it should also say that the fee should not be linear with theamount of IP addresses. It should also not be recurrent. The argumentmade that it might encourage returning addresses is a contractualissue. PA space must be returned anyway.

RB: People's business models should not be regulated.

Daniel Karrenberg: As one of the writers of ripe-152, I would like topoint out that obsolete documents are not worthless, they are actuallypriceless. The truth is that the first contribution on this subjectwas from an African resident and the situation in Africa is that liesare being told. So I think that we do not need this document anymore,as long as the RIPE NCC make it very clear that they charge forservices and not by the addresses, it does not need to be a policy,just a statement. At the time we wrote it, it was necessary but alsoalready dubious. It certainly is dubious now.

Tom Petch: We are equating registries and ISPs and to me they arecompletely different animals. I have a registered a .com address andhad to pay a fee for it but the fee was very small. But my ISP chargeda lot for me to use it. I do not see a conflict in the document andwould like to see more competition between ISPs.

RB: We are IP registrars, not domain names.

Bill Woodcock: I agree with Daniel, it is inappropriate to dictate toISPs in Europe and doubly inappropriate to dictate business rules toISPs in Africa. What is needed is education so that there are moreISPs in that market.

RB: I agree that the believed notion of scarcity should be lookedinto. Transparency and educational are both needed.

HPH: To summarise, the proposal is that we move the document tohistorical and we encourage the RIPE NCC in making a clear statementthat it does not charge per IP. Is that correct?

GD: I have said this many times in the past and will happily repeat itfor the minutes: The IPv6 allocation should be forever. The RIRsshould get a /6 each, maybe this is too radical so a /8 should be moreacceptable. As far as allocations towards the LIRs, it should be a bigchunk, chopped via binary allocation algorithm, just because you donot know how large the LIR will be. On the other hand, if we do get a/8 finally from IANA, then we can allocate /32's from it for a longperiod.

IvB: Let's do some quick maths: we have a /3 for Global Unicast, youare giving out /32's that can grow into /29's, we have 64 millions of/29's, who has a router that can handle that amount of routes?Something has got to give or else in a few years we will run intotrouble.

Arno Meulenkamp (AP) (RIPE NCC): The size of the allocation depends onthe request from the LIR. We have given out one /31 and one /27 as theRIPE NCC. So if people ask for more address space and they can justifyit based on what they have right now and add the 3bit buffer.

IvB: People cannot know how big someone will be. I think the 3 bitbuffer size is too small. Even if you do increase the buffer size,experience from the transition of moving from a /35 to a /32 showsthat people do not care about aggregation.

RB: I sympathise with Gert's position but someone needs to state theopposite stand. I'm also glad to see the NCC do this marketinganalysis for the broadband community and hope they can generate somemoney from it. Some of us were around when 32 bit seemed infinite andwhy don't we chop things up in 8 bit boundaries and call things classA's and B's, there are so many and just throw them around. The 64 bitswe get with IPv6 is really not that large and already we seeschemes, the tension of not having a decent routing paradigm forIPv6 that is 10 years already, leaves us with even greater tensionbetween aggregation and conservation and routing tables. Far worseproblem as Iljitsch pointed out. Right now if the NCC has to go toIANA 3 times per year, somehow, ICANN needs to justify theirridiculous budget, I don't think we have to rush here. It is atough space. it may be a little too early.

AM: That is true, that is why we have done this presentation. Thequestion is whether we want to have a situation where there is goingto be many different prefixes announced, do you agree with theassumptions that every broadband user will get a /48, what do youthink? Should we let the policy as is? Should we get bigger blocksfrom IANA? This is really just trying to get some feedback. Thesenumbers are somewhat marketing, possibly, but what if?

Mike Hughes (LINX): One size does not fit all. Some LIRs, like thesebroadband providers might indeed need huge blocks but others in thisroom will never grow beyond a /32 or /31. There should be enoughforward looking when people make requests. There are people in thisroom who have never grown out of their /19 as well. And it isreasonable to expect that they will want to do dual-stack, have theirIPv4 space, plus their /32 and never need anything more.

GD: It has been proven difficult to predict the future and that is thenice thing about the "sparse allocation" algorithm proposed inripe-261 that says that if the block is so huge, you can justallocated it in a way that, overtime, the people that grow, will beable to grow and those that don't outgrow their /32, will be justhappy with that.

AM: How many of you are familiar with the binary chop, the sparseallocation proposed in ripe-261? Quite a few I see. When using thisalgorithm, it is easy to see where there is a lot of growth and leavemore space available there. You can use space from areas where thereis not a lot of growth.

HPH: Is this algorithm already in use?

AM: It is not currently in use. This proposal was made by all theRIRs, to use this for the entire address space but people from thedifferent communities did not like that but there is no reason why wecouldn't implement the same algorithm on a regional basis, if thecommunity wants us to do that. Although, to some extent, that is ourinternal way of doing it. Right now, you have an allocation; there isa particular reservation for it for growth, and one after the other.

DK: I agree with Randy: this is a hard space. Historically, for peoplewho might not know, the split into class A B and C was not done for noreason, it was because the routers at the time would not work if youcouldn't predict the length of the network. We are working with movingtargets. We really need this discussion in v4 and v6, conservationversus aggregation and what are our goalposts. My feeling is that weare playing soccer but we don't know where the goalposts are. We maynot even know what the goals are.

HPH: One comment: is there any reason not to use this 'sparseallocation'? Another would be: we have 15 minutes left for thissession and we have 3 more agenda items. Shall we continue or shall wemove on ?

IvB: Just one thing: we might want to increase the buffer bits so thatif people need more than the /32, they can get it without injectingmore routes into the v6 table. Now it is 3 bits, to allow the /32 togrow into a /29, can you make it 6 bits?

AM: We could but that would leave us with very few allocations perIANA allocation.

IvB: Nobody cares about that except the people that have to ask IANAfor the allocations.

Doug Barton (ICANN): Speaking of IANA allocations, I am Doug Bartonand I am here to justify my incredible budget as a general manager ofIANA. The IANA is very interested in this feedback. We have beenfollowing the discussions on many different lists, both in thetechnical community and the RIR community. And while, on the one hand,we have been criticised for not changing the current allocationpolicy, it is very difficult in my position to know what a reasonablechange would be given that there is still widespread disagreement inthe community in what the policy should be. So I want to send themessage that we haven't changed the policy, not because we areinsensitive to the needs of the RIRs, but we want to be sure that thechanges we make will benefit the community in the best waypossible. If any body would like to discuss this with me, feel free toapproach me during this conference. We are here, we are listening andwe want to move forward as soon as we have the feeling the new policywill meet the needs of the whole community.

HPH: I suggest we continue this discussion on the mailing list andcome to a concrete proposal that we can take to IANA.

HPH: One question, to Leo possibly: Isn't it possible within theProvider Independent policy to accommodate this with a /24?

LV: The way we understand the current PI policy is that if someoneneeded to use say 3 addresses we can give them a /29. We can't givethem a /24 if they are only going to use half a dozen addresses. Ourcurrent policy does not let us do that.

HPH: In my creative mind I would set up another registry and get a newallocation.. this is not the correct way of dealing with this ofcourse. So, there seems to be a proposal and we should move forwardwith it.

GD: If you are going to be creative, maybe DENIC have some /24's fromde.zz time lying around. I am in favour of this as it can be properlydocumented from a well-known block. I would want a very specificpolicy because finding a policy that is broad enough for every futureusage of people for Anycast will never be finished. I am very much infavour of having a very specific policy; we would need a few changesin the Database, like status colon "anycast" or something.

Bill Woodcock: It has been a debate for some time to know whetherthere is a best common practice or not to run multiple,non-overlapping address blocks for Anycast in order to have a reliableservice, in case the nearest instance provides poor service. So thatbrings up the question how many times this policy could be executedper TLD. You might want to include that in the policy: can one TLD usethis once, or 2 or 3 times?

IvB: We are talking about having Anycast have a larger block. Whydon't we talk about having /29's or /32's routable and don't forget,even if some people keep filtering them, it is not so bad becausethere are 4 or 5 other services that are reachable over normalUnicast.

GD: Well, that is the problem: it is difficult for this forum todictate routing policy; people filter whatever they want. There seemsto be some kind of consensus that /24's from different blocks areaccepted and more specifics are not. It's down to conservation andaggregation again of course but this way is easier.

Joao Damas: While I generally agree with the proposal, I also agreewith Iljitsch; in this particular case, it might not be such a badidea to have limited distribution of these prefixes when you arerunning Anycast. Everybody uses Anycast in a slightly differentway. For instance, the way we do it is a distribution of Anycastprefixes is limited in space, or at least we try. It is somethingworth exploring. Because when you have several globally reachableinstances of Anycast, from a network operator's point of view, itmight make debugging a bit more difficult. So there is a point to hiscomment. I wanted to make a separate comment to explain my postings tothe mailing list on this subject: it comes from a requirement we haveand that other people may not have is that, when we run Anycastinstances of our server, wherever they might be in the world, weinterpret that the public service we are providing require us to havevery specific administrative boundaries of what constitutes thesystems, the addresses and the routing policy we manage and that ofthe place were we are hosting decide. And that requires us to have a/24 of independent address space that is only populated by very fewmachines, 6 to 10 if you count routers and servers and everything. Theway we interpret our requirements towards the Internet as a publicservices that we provide, Anycast instances do need distinct addressesfor the service you are providing and for the management because youcan not just associate it to the Anycast addresses, so there is arequirement for a second set of addresses. It may not apply foranyone, but we are faced with this situation where we need a 2nd /24for each node, which is only populated by a few addresses.

IvB: In the past, different operators have not been ready to acceptlong prefixes for ccTLDs as no good reasons were given. If now asignificant number of ccTLDs start doing this, document it and it isdone in a reasonable way, the operators will start doing that. Thereis also a precedent to this: ARIN is giving out a /48's to the rootservers even though there is a policy document on all the RIRswebsites _and_ the IANA website, that says that you can only give out/32 allocations. That is a second problem that needs to be addressed.

Andreas Baess: We had thought of the creative solution of finding someold net blocks, however we also think that it is much better to make aclean documentation. We have just started having the k-root instancesand we are also starting to set-up peerings, and I think it is mucheasier to get those peerings, new ISPs, to know what this peering isabout. It is hard if you have some small allocation for which there isno documentation on what it is. Until then they start seeing us as acustomer and they say that they don't want to peer with us. This isquite strange and I think TLD name servers are critical to the networkitself and they should get very good connectivity which is provided bythis kind of solution. Micro-allocations would be a solution that isquite as good but I think that it will take much more time to get thatpolicy in place. Why not do both? Make a policy change now and work onaddress space conservation and convince people to acceptmicro-allocations from a specific block. Renumbering is something thatwe have done and we would like to do it if it makes sense. But I don'tknow if we should wait for it.

Mohsen Souissi (AFNIC): Thank you Andreas for reminding us that theproblem of peering is another argument to do some micro-allocations insome identified block. Not to be just refused to peer with any othercustomer on an exchange point. I have mentioned this last year in therouting WG and the LIR. Because as AFNIC or French TLD we had thatproblem since last year and customers refuse to peer with us. Thisbecause they read in some 6Bone policy that we should accept any /24;for v6 any /28 and nothing else. I think that today we can identify 2needs: for Anycast or for peerings or for both. For DENIC forAnycast. For AFNIC we have a problem for peering. So we need to moveforward with the policy, or change the policy for v4 and v6. We can'tsay that we will take care of IPv4 now and IPv6 later. IPv6 is hereand many TLDs are already ready, France, Japan and others. I think wehave to state clearly in this policy change whether it is forTLDs. There is a discussion whether TLDs name servers are critical ornot. I don't want to dwell on this. I think it is needed and I secondAndreas' proposal. The RIRs and the routing group have to worktogether to make this policy change and state clearly the needs.

RB: From a business aspect, I don't see why a FR name server should bea peer, anymore than Amazon.com should be a peer. I'll decide whetheryou are a peering customer based on business criteria. If there is aneducation issue there, there is no reason why all the routers shouldpay for it.

Mohsen Souissi: You can't view it as a business need; it is for thewhole community.

RB: We all think we give service to the community and we all think ourservice is more important than everybody else's.

HPH: Let's focus on address policy and not on business criteria.

RB: We have a general problem with Anycast. I participated to probablythe first task of IPv4 Anycast. I probably service more ccTLDs thanmost people and certainly anybody else in this room. But we have amessy space here again where the class of people who think, whetherrightly or wrongly, that their services are special where businessneeds and prefixes etcetera. I am not saying that it is not in thiscase. I have sympathy for it. I just want to understand what theboundaries of the box are and I don't think we have a clear definitionof that and until that happens, I'm not sure I want to buy the box.

HPH: Just for clarity, can you explain what you mean by "theboundaries of the box"?

RB: What the proposed qualifications are and what should it getthrough those qualifications. BTW, you should know that in my backpocket I have a lot of /24's and I will talk to ARIN at lunch andmaybe I can transfer one to you.

GD: Two small comments; to Andrea, the idea to set-up some Task Forceto work on micro-allocationÂ… As far as the registries have told us,there is no IP shortage in IPv4. To Mohsen, I don't think it is a goodapproach to replace lack of clue in your potential peers in thepolicy. I agree with Randy on that, which is rare J, if they arelooking at outdated 6Bone documents, maybe you should point out tothem that 6Bone does not exist anymore for very much longer and thatthe reality has changed somewhat. It is their problem that they don'tpeer with you. If they don't want to peer with you because you have along prefix, point them to the document, or the chair of the IPv6 WG,the mailing listÂ…

DK: Just to repeat briefly what I said on the mailing list: this wholequestion is about 99% a routing policy and maybe 1% address policy. Idon't think it is a problem for someone like DENIC to get addressspace per se for this. Like it should be no problem for ISPs to getaddress space. This is about what gets routed and that is definitelysomething that is not decided by the routing WG, like Randy said, itis decided by each ISP on their business needs because it costs themmoney. So the only thing we can do, and I proposed this on the mailinglist, is to tell them what they might want to do, rather than relyingon outdated documents, hearsayÂ… The art here is to set thecriteria. ccTLD name servers are easy to police but we can also havea category others and I can have my web server at home and say: "thisis Daniel's web server and I think it is important" and then the ISPscan make the decision that they want. I had no response whatsoever onthis on the mailing list.

RB: If the fact that swamp is there and the RIRs do manage that swampand ISPs do let /24's through on that swamp, stuff like this, if thepolicy is defined, go there. That something you do control. It's_where_ you allocate the addresses from, not how I should routeit. But you happen to know that for historical reasons we let theswamp through. I agree that this is a routing discussion, but there isa bit of the routing discussion that you are familiar with which is: Ilet swamp through. You can choose to go with the flow of that routingpolicy by, if you make a decision of a special case, to do it in swamp/24.

DK: You were saying that you were not sure what the boundaries of thebox should beÂ…

RB: That is a separate discussion: the policy for deciding who shouldget this. I am saying that when you have that policy in place; pleaseuse something that is already meeting the filters. Don't make aDatabase with thousands of little funny shaped things I have to filterdifferently because I'll 'mess' it up.

DK: I would have hoped the Database to help you. What do you thinkabout the policy?

RB: I think you will a difficulty to define. I was an advocate of amicro-allocations policy but we have never been able to have a decentmicro-allocation through and I don't we'll be able to get one.

DK: It is going to open a can of worms, and anybody can say thatbecause I'm GOOGLE or whateverÂ…

RB: That is the micro-allocation discussion; can't we separate that?

DK: No because, as Joao was saying, the thing that worries me is: "Iwant this for my maintenance network". It is going in all directions:"I'm special, I'm special". It will not converge.

RB: That is why DENIC want to limit this proposal to ccTLD servers.

Andreas Baess: to overcome a protocol limitation.

RB: You would be glad to limit it to a certain number per ccTLD, like1 or 2?

DK: My fear is that we open a can of worms that we can't closeanymore.

RB: I don't like eating worms, so let's eat lunch.

HPH: I agree with that, I propose that we take it back to the mailinglist and while listening to Leo's interpretation of the ProviderIndependent policy, it might be one to discuss because we are givingout even smaller. Apart from Daniel's concern, I didn't hear anyonevoice strong opinions against this so I'll try so see if we can reachconsensus on the mailing list.

LV: Would this be in an exceptions document? Do you want this shovedin the regular IPv4 document or an exceptions document. It is 13 pagesalready, we can make it longer if you want or shove it somewhere else.

HPH: I would be in favour of making a separate one. We have one moreagenda item but do you want lunch or IPv4? I guess we have clearconsensus and we want lunch. Since it is not a clear proposal but morea discussion, I propose that we move it to the mailing list and thenonto the next meeting. And there was one A.O.B. raisedÂ…

IvB: I'll keep it very short; what can we do to start the process ofchanging the IPv6 policy document so that item 4.3 can be removed orchanged?

HPH: make a proposal on the mailing list. With that, thank you allvery much and see you on the mailing list or the next RIPE Meeting.

The RIPE NCC uses cookies. Some of these cookies may have been set already. More information about our cookies can be found in our privacy policy. You can accept our cookies either by clicking here or by continuing to use the site.