This proposal suggests using the HD ratio to measure IPv4 usage. Theproposed value of the HD ratio for IPv4 is 0.96. The full details areat: http://www.ripe.net/ripe/policies/proposals/2005-1.html

This proposal has already been under discussion for some time. ETNOposted a position paper to the working group mailing list in supportof the proposal. However, there seems to have been some disagreementover who signed the paper. ETNO has not participated on the workinggroup mailing list, so representatives were invited to put their viewto the group.

It was noted that Kristian Rastas (Sonera) sent an email to theworking group mailing list in August stating that his companysupported the proposal.

There was no further response from any ETNO representatives. Thechair advised that the group needs to make their decision based ontechnical arguments, and urged them to put their view points across onthe mailing list.

There were no further comments from the floor, so the proposal will bereturned to the discussion phase for another four weeks.

D: Policy Proposal #2005-02: TLD Anycast Allocation Policy

This proposal is to enable ccTLD and gTLD nameserver operators toprovide their DNS service using shared unicast technology. The RIPENCC is able to assign one IPv4 and IPv6 prefix per operator that isnot likely to be filtered by common practise for anycast-operation oftheir DNS services. The full details are at:http://www.ripe.net/ripe/policies/proposals/2005-2.html

Andreas Baess (DENIC eG) will rewrite the proposal text and change itfrom a /32 IPv6 prefix per operator to a /48. This is because ofobjections on the working group mailing list about the large prefixsize. As for all other policies, the RIPE NCC can not guaranteeroutability of the address space.

There was concern that if the RIPE NCC does not guarantee routabilitythen the address space will be worthless. This was counteracted withthe opinion that routability can only be guaranteed by paying money toa service provider.

The chair advised that a new deadline will be set for discussion afterthe updated proposal text has been submitted.

E: Policy Proposal #2005-03: IPv6 initial allocation criteria

This proposal is to change the IPv6 Initial Allocation criteriaoutlined in the "IPv6 Address Allocation and Assignment Policy". Theproposed change is to remove "have a plan for making at least 200 /48assignments to other organisations within two years" and to remove thereference to "/48s" as the assignment size. The full details are at:http://www.ripe.net/ripe/policies/proposals/2005-3.html

On the working group mailing list there was not much objection toremoving the reference to /48 assignments. However, there were moreobjections to removing the requirement for 200 assignments. For thisreason, Andy Furnell (LINX) will split this proposal into twoparts. He invited the group to suggest ideas for making the proposalmore acceptable.

There were objections raised to the proposal to remove the requirementfor 200 end-site assignments because it will mean that everyone whopays to become an LIR will be eligible for an IPv6 allocation even ifthey only need to make one assignment. Some felt that this is a wasteof space, and makes the allocation like a PI assignment.

Iljitsch van Beijnum (BGPexpert.com) stated that he fundamentallydisagreed with this proposal and added that it should not be adoptedunder any circumstances.

Gert Doering (SpaceNet AG) pointed out that that the current policydoes not work, because at the moment an LIR only has to say that they"plan" to make 200 assignments. The RIPE NCC does not ask forproof. This means that some registries get allocations when theydon't deserve it, and some don't qualify when they should.

It was suggested that a list of who should qualify for an allocationcould be produced.

Wilfried Woeber (ACONET) disagreed with the idea of a list, because itwould be difficult to adhere to. He added that whatever “magicnumber” is picked, it should not stop someone who needs anallocation from getting one. He went on to state that he supports theproposal to remove the requirement for 200 assignments.

The chair pointed out to the group that if the community is seriousabout there being a limit for the number of assignments that arerequired, then there should be consequences if this is notfulfilled. He also stated that there are 4 topics that need to bediscussed further:

- If the allocation size is too high, and the criteria are too low, then conservation and the size of the routing table will become a problem;

- The number of end-site assignments that need to be made should be decided;

- The group should consider how the RIPE NCC should verify the planned assignments;

- The group should discuss what consequences there will be if the criteria are not fulfilled. Should the RIPE NCC take back the address space if the end-site assignments have not been made after the specified time?

The proposal will be returned to the discussion phase and the proposalwill be revised.

F: Policy Proposal #2005-04: Definition of an ‘end site'

This proposal is to establish a clear definition of “end-site”in the IPv6 allocation policy. The full details are at:http://www.ripe.net/ripe/policies/proposals/2005-4.html

Eric Schmidt (Deutsche Telekom) explained that this proposal had beencreated because this organisation found that there were currently manydifferent definitions of end-site in the IPv6 allocation policy andRFC3177.

Some suggestions were given for definitions:"A collection of machines that have a common link to an ISP""A routed element with its own transmission"It was agreed that the group needs to find a wording so that everyoneunderstands it even if they are aware of the context.

It was also suggested that the term "ISP" could be defined moreclearly.

The group discussed several scenarios for the definition of"end-site". The chair pointed out that the consequence of thisdefinition is "who will get a /48".

An issue with the term "business relationship" in point 2.9a of theproposed text was also raised. Clarification of this term wasrequested, because it was unclear how it would affect an academic ormilitary institution.

Daniel Karrenberg (RIPE NCC) pointed out that RIPE should not makereference to organisational structures, business models, and legalrelationships in its policies. Terms should be defined as far aspossible in technical terms. (i.e. in terms of network architecture).He felt that this was out of the realm of the working group.

Gert Doering (SpaceNet AG) agreed that the group should think aboutthis point of view. He added that he was in favour of the proposedchange, because he felt it was a technical change which would helpISPs to decide exactly what an end-site is.

The chair agreed that the new text was an improvement, but suggestedthat it is reviewed again keeping Daniel Karrenberg's advice inmind.

This proposal is to amend the RIPE IPv6 address allocation policiesregarding the definition of the default size of end-site assignments,the threshold value for End Site allocation efficiency, and the methodof calculation of the end-site allocation efficiency metric. The fulldetails are at:http://www.ripe.net/ripe/policies/proposals/2005-08.html

There was a lot of positive feedback about this proposal after RIPE50, and there have been no objections on the working group mailinglist. This is intended to be a common IPv6 policy, so it is dependanton other RIRs adopting it. The feedback at APNIC was that RIRs shouldnot tell ISPs how much to assign to end users. They should only usethe information to judge efficiency when making decisions about anadditional allocation.

Unlike IPv4, the total address space is not counted any more. For IPv6the efficiency inside end-sites is not deemed to be important. It isjust the number of end-sites that is counted. With this proposal, thenumber of /56 assignments would be counted instead of /48.

Geoff Huston (APNIC) explained that the proposal allows for productdifferentiation. It avoids saying /48 for everything, which means moreefficient use of space. It makes it a local ISP business decision. Theidea is to avoid the overhead involved in IPv4 and stick to theoriginal intent of IPv6 - ensuring that addresses are availableeasily, efficiently, and accurately.

Iljitsch van Beijnum (BGPexpert.com) pointed out that RFC3177 saysthat fixed length customer assignments are good. One reason is to makerenumbering easier. The idea that “one size fits all” is alsoimportant. He suggested that the proposal is withdrawn and looked atagain in another five years. He added that what we do in the nextfive years is not relevant, because we are not going to run out ofspace.

Geoff Huston (APNIC) replied that there is a draft with the IETF thattries to get rid of the parts that tell RIRs what to do. Also, can wemove on as we are now and change things later? This proposal is basedon some very careful thinking about what IPv6 really means. Changingthings on the fly in IPv4 has been painful. He added that policies forIPv6 need to be set up correctly now.

It was suggested that the proposal should be split into twoparts. Point 3 of the proposal (fixing the HD-ratio) should besubmitted separately. Geoff Huston added that the APNIC membershipagreed to do the same.

The proposal is to have a policy governing the allocation of IPv6 address space from the IANA to the Regional Internet Registries(RIRs). The full details are at:

http://www.ripe.net/ripe/policies/proposals/2005-09.html

The chair advised that this policy is to make sure that the RIPE NCCgets addresses, so it is important to discuss it. This is the sametext that has been proposed in the other regions. Leo Vegoda (RIPENCC) has some suggestions to improve the clarity of this text, but itis a bit late in the process because it has already been formallyapproved in three regions (LACNIC, APNIC, ARIN). We are now at thestage where we can run this through PDP for approximately sixweeks. After this it will go to the Address Council, who will look atit to make sure the process has been followed in all the regions. TheICANN board is probably going to ask for advice on the contents ofthis proposal, and then they can either approve it or send it back tous.

Daniel Karrenberg (RIPE NCC) said that changing the text is not a goodidea. But if clarity can be improved we can create another document toshow our understanding of the text, like an explanatory document.

The global policy development process can be viewed on the NROwebsite:http://www.nro.net/documents/nro4.html

Regions may have different wording as long as content is thesame. Variations may be adopted by each of the RIRs. Ray Plzak (ARIN)advised that variations can occur in each RIR, and the editing groupcan come up with common text.

Several speakers voiced their support of the proposal.

Olof Nordling (ICANN) advised that this policy has been announced forearly awareness to ICANN board. No comments for or against have beenmade. The board are eagerly awaiting the formal proposal. He pointedout that he was speaking on behalf of ICANN, not IANA.

There is a one-page overview of the status of this proposal in eachregion is available on the ICANN and ASO website. The deadline fordiscussion of this proposal is 1st November 2005.http://www.icann.org/announcements/ipv6-report-06sep05.htm

This agenda point was added to discuss the most appropriate addressmanagement policy measures that will support the continued wellbeingof the global Internet and its users, and when they will be needed.

Geoff Huston (APNIC) explained that there is wide spread expectationthat RIRs will make more restrictive refinements to policy as theremaining address pool dwindles, but is that really something that wewant to do? Policy changes take time, and often the outcome is notquite what was expected. And would it really make any difference?

Iljitsch van Beijnum (BGPexpert.com) added that any changes should bebased on predictability. He suggested limiting the size of allocationthat can be given. Larger registries would need to come back moreoften for space, but this would at least prove they are using it.

Daniel Karrenberg (RIPE NCC) agreed, and also said that it is probablynot a good idea to continuously adapt policies only with the aim ofincreasing the lifetime of the unallocated pool. He added that thegroup should consider the "fairness" aspect as well. As well ashanding out numbers we co-ordinate routing and operational issues onthe Internet. We don't want to turn into another government orregulator. We should stick to our original chartered purpose, and beclear with what we will do with the remaining IPv4 space.

The general opinion was that policy responses to shrinkingavailability of IPv4 will be seen, and that this should be added tothe agenda for a future RIPE meeting. The future role of RIRs shouldalso be discussed, because the exhaustion of IPv4 could drive a changein this. There should be discussion about how we can assist with theintegrity of address trading.

The chair agreed that a session to discuss the mechanisms needed for aworking Internet after the exhaustion of IPv4 will be scheduled at oneof the future RIPE Meetings

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.