RIPE 52

• content to the Chair of the working group.
• format to [email protected].

Address Policy Working Group Minutes from RIPE 52
Version 1.1

WG Chair: Hans Petter Holen
Meeting chaired by Gert Doering
Scribe: Catherine Carr
Istanbul, Wednesday 26 April 2006 14:00 - 15:30


A: Administrative Matters

- Welcome
- Catherine Carr (RIPE NCC) to scribe
- Agenda finalised.
- Minutes from RIPE 51 approved:


B. Ongoing policy work in other regions

Filiz Yilmaz (RIPE NCC Policy Development Officer) gave a presentation
about a worldwide view of current policy topics.

Filiz mentioned that there is a new format for drafting RIPE documents
to make the review phase easier.

An information only mailing list [email protected] has been
created for people who want to be kept informed about the progress of
policy development in the RIPE region.

The IANA Global Policy for Allocation of IPv6 Blocks to RIRs (2005-09)
has been accepted in the RIPE, ARIN, APNIC, and LACNIC regions. Alan
Barrett from the AfriNIC board announced that it has passed all
discussion phases in the AfriNIC region, and is now just awaiting
board approval.


C. Policy proposal overview (of address policy WG proposals)

Filiz Yilmaz (RIPE NCC Policy Development Officer) gave a presentation
about the ongoing policy proposals in the RIPE region.

Current ongoing policies:
2005-01 HD-Ratio proposal (Concluding)
2005-02 IP assignments for anycast DNS (Open)
2005-03 IPv6 initial allocation criteria (Discussion)
2005-08 Amend IPv6 assignment and utilization requirements (Open)
2005-09 IPv6 IANA->RIR distribution policy (Consensus)
2005-12 4-byte AS number policy (Open)


D. Necessary steps to conclude 2005-09 (IPv6 IANA->RIR distribution policy)

Gert Doering commented that this policy does not affect only the RIPE
community it is a global policy that affects the way that ICANN
allocate address blocks to the regional registries. The proposal now
only needs to be ratified by AfriNIC board. Then it will go to the
address council and they will verify that the correct procedures have
been followed before passing the new policy to ICANN for
implementation.


E. Discussion on existing proposals that are not yet closed

2005-09 IPv6 IANA->RIR distribution policy

Tony Hain (Cisco) commented that if we change from /48 to /56
assignments, then /12 allocations to RIRs may not be justified.

Geoff Huston (APNIC) replied that when this proposal was drafted we
were working with a HD ratio of 0.8 and /48 end site assignments. This
is still the case today. Within the framework of the policy today, /12
is an appropriate size for RIR allocations. It may be reasonable to
review this again at a later stage if we change the assignment size in
the future, but for now we have to work with where we are today.

Tony Hain asked why are we pushing the assignment boundary to /56?
Conservation is not an issue with IPv6.

Geoff Huston advised that over the years the install base will get
very large, which will make it more difficult to change allocation
policies in the future. The proposal does not say that we have to
change from /48 assignments to /56. In fact, it is variable and
depends on the business needs of the LIR. How the RIPE NCC calculates
that an allocation is filled to an agreed level must be
considered. This policy says that we count the number of /56's and
apply the HD ratio. It

Gert Doering asked how many /56s will be counted if an LIR makes /48
assignments to its end sites. Will larger assignments count as correct
utilisation, or will it have to be justified?

Geoff Huston answered that within this policy a /48 is 256 /56
assignments. If an LIR is making larger assignments, they will use
their allocation more quickly and have to return to the RIPE NCC more
often. It may also mean that they pay a larger fee to the RIPE
NCC. Realistically, the assignment size is the choice of the LIR.

Tony Hain added that in this context we should be looking at subnet
structure, not the number of devices.

2005-1 HD-Ratio proposal

German Valdez (LACNIC) commented that they had been following the
discussion on the mailing list, and asked that the RIPE community
considers this proposal carefully because it impacts other regions.

Gert Doering mentioned that this was why the proposal is still in the
review phase. The way that people have commented or not commented has
made it difficult for the Working Group Chairs to decide whether
consensus has been reached. There have been practically no emails from
the RIPE region except for one mail of support from ETNO saying that
all their 200 members support the proposal, but no mails from the
actual members. Lots of comments have been received from other regions
stating that they disagree with the proposal because it will
significantly increase address usage. It is not clear whether
consensus has been reached, so another round of discussion has been
arranged.

Laurent Bernard (France Telecom) and Quinn Collier (BT) stated that
they support the proposal.

Geoff Huston reminded the room of the analysis done last year about
the potential impact of this policy proposal. The rate of consumption
would approximately double. The HD ratio makes a very big difference
for larger allocations. The analysis simulated the last three years of
RIPE NCC allocations in IPv4 if this policy had been adopted three
years ago. The impact of adopting this policy has been posted to the
mailing list. People who support this proposal were advised to reread
the analysis and think about the impact on the remaining IPv4 address
pool as a whole.


F. IPv6 PI policy - ongoing work in other regions

Nobody from ARIN was available to comment about the IPv6 PI
discussions at the ARIN meeting, so Leo Vegoda (RIPE NCC) gave a brief
update.

There were two slightly different proposals for IPv6 PI presented at
the ARIN meeting. The consensus of the room was that one or other of
them should be adopted. There was a lot of support for IPv6 PI in
general. There was slightly more support for proposal 2005-1.

The 2005-1 proposal is that a /48 is assigned within a reserved
/44. This should come from a reserved block of address space so that
filters can be applied correctly. To qualify for IPv6 PI you must also
qualify for IPv4 PI space and not be an LIR.

The ARIN Advisory Council is now working on rewriting and combining
the two proposals.

A new policy proposal (2006-01) has been made in RIPE region by Jordi
Palet (Consulintel).

Jordi Palet summarized his presentation from Monday.

This proposal is intended as a solution for IPv6 PI for multihoming,
avoiding renumbering and providing independence. The idea is to
consider the problems that PI proposals create in the medium/long term
in the routing table and come up with a solution which is temporary,
but sufficient that people can go for it. The proposal states that the
address space would be reclaimed three years after a technical
solution is found. The proposed assignment size is /32, considering
that in that time some of those people will qualify to become an
LIR. In that case they will just keep the assignment. This will save
some of them renumbering. The assignments would be made from a
superblock.

Jordi Palet added that he is against PI in general, but believes that
it is not fair to adopt it in some regions and not others when
considering the global impact and routing table cost.

Ruediger Volk (Deutsche Telekom) commented that the proposal seemed
very concerned with avoiding renumbering, but did not focus on
avoiding routing table overflow. He went on to say that people should
accept that they may have to renumber, and be prepared for it. He
suggested that assignments could be easily handed out if they were
time bounded and renumbering is forced. This would ensure that people
don't stick with their numbers purely to avoid renumbering and
create unnecessary burdens on the routing table. The frequency of
renumbering would need to be considered, but at least every three
years might be sufficient to make the point.

Gert Doering reminded the room that there has been a lot of discussion
about this topic recently on the mailing list. The list is archived,
so people can read up on the topic if they wish. Some people have very
good arguments for not renumbering, even with IPv6 (for example,
commercial service providers that need to access customer intranet
sites or firewalls). If they renumber, then everyone else who touches
their firewalls also have to renumber.

Kirt Lindqvist (Netnod) stated that he was against the PI proposal
because any policy that says we wait for three years after a technical
solution is ambiguous. Also, there is no real control over who owns
the address space in the future. The customer will have no reoccurring
contact with RIRs, and no regular fee. If someone has a legitimate
reason for address space, they should be given some kind of PA
space. They will then pay the same fees as everyone else, and get the
same services from the RIPE NCC. He added that it was unclear what the
technical solution was trying to solve.

Tony Hain had a number of comments about the proposal. He advised that
a policy of reclaiming the address space would put off a lot of larger
global companies. This was expressed at the ARIN meeting. He also had
concerns that if someone was assigned PI space from the superblock,
and they later became an LIR and didn't have to renumber, this
could cause filtering problems. He added that the problem of routing
table overflow could be contained with a structured method for handing
out space.

Wilfried Woeber (ACONET) stated that he agrees in general with the
goal of the proposal, and appreciated the attempt to get this through
PDP in all regions. However, he felt that some aspects of the proposal
were mixed. Firstly, this is one way of easily doing away with the 200
customer requirement. The customer count doesn't matter, as long as
you are providing service to other organisations. He was unhappy about
the perspective of trying to reclaim the address space, and with the
idea that any entity can get resources from the RIPE NCC without a
contract (in particular because the assignment was so similar to the
regular service received by LIRs). It would be difficult for the RIPE
NCC to track the resources in the database, and make the holders of
those resources aware that they are part of a bigger picture.

Jordi Palet advised that the contract and fee issues were not included
in the original policy proposal because he thought it would be sorted
out by the board. In his opinion there should be a contractual
relationship and recurring cost between the customer and RIR.

Ed Lewis pointed out that PA space was not appropriate for some people
because they want to be independent and not need to renumber if they
change provider. However, they do not need to multihome. This proposal
means that although independence is achieved, the person would still
need to renumber which makes it no more helpful than PA. SHIM6 may
provide a solution for some people, but not everyone who wants PI
space. The technical solution that we are trying to solve is not right
for everyone.

Leo Vegoda (RIPE NCC) reminded the group that the RIPE NCC has no
contract basis for reclaiming IPv4 address space at present. The
technical solution for this proposal must be very well defined so that
the RIPE NCC can say that it definitely solves the problem and the
addresses must be handed back. Otherwise, it could put the RIPE NCC in
a difficult position.

Jordi Palet agreed that the technical solution should be well defined,
but that it would be difficult to do. He also suggested that the group
looks in at how address space is reclaimed. This is not an issue that
is specific to this proposal, but a more generic problem. He has
talked to different RIRs and thinks there are procedures there that
work (although not for legacy resources).

Ruediger Volk said many people want PI because they don't want to
renumber. This includes some residential customers. Furthermore, some
people deliberately build difficult to maintain networks as a way to
justify PI. This could replicate the problems that have been seen in
IPv4. People want to do the right thing but can't because of
commercial pressures. It is clear that there is something missing in
the design of IPv6. If we come up with a good solution, then this will
help us in the coming years.

Mark McFadden (British Telecom) stated that if this proposal is
adopted then the assignment will be permanent anyway. Technology like
SHIM6 offers a solution for a well crafted set of requirements. They
are not all of the requirements that PI addresses. This means that no
technical solution would get consensus, so this proposal has an
expiration clause that will never get used.

Daniel Karrenberg (RIPE NCC) suggested that it would have to be a hard
written expiration clause.

Tony Hain added that some large companies have contracts saying that
they must be operationally stable. This proposal does not give them
the stability that they need. We should look globally at other ways of
aggregating besides provider based aggregates.

Daniel Karrenberg replied that companies saying that they can not
renumber because it is not operationally stable is an argument of
convenience. They are trying to make life easier for themselves at the
expense of others.

Jordi Palet asked if the 200 customer requirement applied in all
regions.

Filiz Yilmaz advised that APNIC is the same as the RIPE region (200
customers within two years). LACNIC and AfriNIC have no defined
customer requirement. In the ARIN region an LIR needs 200 customers or
to be a service provider.

Gert Doering advised that this proposal should be discussed in more
detail on the mailing list. Lots of people seem happy with the idea of
having a model where a PI holder needs to have a contract with an RIR
and pay something to the RIPE NCC or their provider. The proposal
needs to be worked on so that this is included. He suggested that the
term PI could perhaps be removed, along with the 200 customer
requirement. Then we could have one proposal that says that all LIRs
can get a prefix.

Alex le Heux (RIPE NCC) mentioned that there had been some interesting
discussions on the jabber, and suggested that attendees should read
the archives. He had not been asked to read out any questions.

Z. AOB

None