RIPE 51

RIPE Meeting: 51
Working Group: Address Policy
Status: Final
Revision Number: 1

Address Policy Working Group Minutes from RIPE 51
Amsterdam, Wednesday 12 October 2005
14:00 - 15:30
Scribe: Catherine Carr

A: Administrative Matters
- Welcome
- Catherine Carr (RIPE NCC) to scribe
- Participants list was missing, so it was not circulated
- Agenda finalised. New agenda point (I) was added to discuss issues
raised by Geoff Huston's presentation from the morning plenary
session.
- Minutes from RIPE 50 approved:
http://www.ripe.net/ripe/wg/address-policy/r50-minutes.html

B: Policy Overview

A detailed overview of the current policy proposals was presented
during the morning plenary session:
http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51-policy-worldwide.pdf

The new PDP website shows all ongoing policy proposals and their
current status and deadline:
http://www.ripe.net/ripe/policies/proposals/

C: Policy Proposal 2005-01: IPv4 HD Ratio

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

This proposal has already been under discussion for some time. ETNO
posted a position paper to the working group mailing list in support
of the proposal. However, there seems to have been some disagreement
over who signed the paper. ETNO has not participated on the working
group mailing list, so representatives were invited to put their view
to the group.

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

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

There were no further comments from the floor, so the proposal will be
returned 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 to
provide their DNS service using shared unicast technology. The RIPE
NCC is able to assign one IPv4 and IPv6 prefix per operator that is
not likely to be filtered by common practise for anycast-operation of
their 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 it
from a /32 IPv6 prefix per operator to a /48. This is because of
objections on the working group mailing list about the large prefix
size. As for all other policies, the RIPE NCC can not guarantee
routability of the address space.

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

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

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

This proposal is to change the IPv6 Initial Allocation criteria
outlined in the "IPv6 Address Allocation and Assignment Policy". The
proposed change is to remove "have a plan for making at least 200 /48
assignments to other organisations within two years" and to remove the
reference 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 to
removing the reference to /48 assignments. However, there were more
objections to removing the requirement for 200 assignments. For this
reason, Andy Furnell (LINX) will split this proposal into two
parts. He invited the group to suggest ideas for making the proposal
more acceptable.

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

Iljitsch van Beijnum (BGPexpert.com) stated that he fundamentally
disagreed with this proposal and added that it should not be adopted
under any circumstances.

Gert Doering (SpaceNet AG) pointed out that that the current policy
does 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 for
proof. This means that some registries get allocations when they
don’t deserve it, and some don’t qualify when they should.

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

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

The chair pointed out to the group that if the community is serious
about there being a limit for the number of assignments that are
required, then there should be consequences if this is not
fulfilled. He also stated that there are 4 topics that need to be
discussed 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 proposal
will 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 been
created because this organisation found that there were currently many
different definitions of end-site in the IPv6 allocation policy and
RFC3177.

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 everyone
understands it even if they are aware of the context.

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

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

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

Daniel Karrenberg (RIPE NCC) pointed out that RIPE should not make
reference to organisational structures, business models, and legal
relationships in its policies. Terms should be defined as far as
possible 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 about
this point of view. He added that he was in favour of the proposed
change, because he felt it was a technical change which would help
ISPs to decide exactly what an end-site is.

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

G: Policy Proposal #2005-08: RIPE IPv6 change of end-site allocations
from /48 to /56

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

There was a lot of positive feedback about this proposal after RIPE
50, and there have been no objections on the working group mailing
list. This is intended to be a common IPv6 policy, so it is dependant
on other RIRs adopting it. The feedback at APNIC was that RIRs should
not tell ISPs how much to assign to end users. They should only use
the information to judge efficiency when making decisions about an
additional allocation.

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

Geoff Huston (APNIC) explained that the proposal allows for product
differentiation. It avoids saying /48 for everything, which means more
efficient use of space. It makes it a local ISP business decision. The
idea is to avoid the overhead involved in IPv4 and stick to the
original intent of IPv6 - ensuring that addresses are available
easily, efficiently, and accurately.

Iljitsch van Beijnum (BGPexpert.com) pointed out that RFC3177 says
that fixed length customer assignments are good. One reason is to make
renumbering easier. The idea that “one size fits all” is also
important. He suggested that the proposal is withdrawn and looked at
again in another five years. He added that what we do in the next
five years is not relevant, because we are not going to run out of
space.

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

It was suggested that the proposal should be split into two
parts. Point 3 of the proposal (fixing the HD-ratio) should be
submitted separately. Geoff Huston added that the APNIC membership
agreed to do the same.

The chair agreed with splitting the proposal to move it forward.

H: Policy Proposal #2005-09: Global IPv6 Distribution: ICANN/IANA -->
RIRs

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 NCC
gets addresses, so it is important to discuss it. This is the same
text that has been proposed in the other regions. Leo Vegoda (RIPE
NCC) has some suggestions to improve the clarity of this text, but it
is a bit late in the process because it has already been formally
approved in three regions (LACNIC, APNIC, ARIN). We are now at the
stage where we can run this through PDP for approximately six
weeks. After this it will go to the Address Council, who will look at
it to make sure the process has been followed in all the regions. The
ICANN board is probably going to ask for advice on the contents of
this proposal, and then they can either approve it or send it back to
us.

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

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

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

Several speakers voiced their support of the proposal.

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

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

I: Issues raised by Geoff Huston

Geoff Huston (APNIC) presented some information about the exhaustion
of IPv4 address space at the Wednesday morning plenary session.
http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51-ipv4-lifetime-rev.pdf

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

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

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

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

The general opinion was that policy responses to shrinking
availability of IPv4 will be seen, and that this should be added to
the agenda for a future RIPE meeting. The future role of RIRs should
also be discussed, because the exhaustion of IPv4 could drive a change
in this. There should be discussion about how we can assist with the
integrity of address trading.

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

Z: Any other business

None