RIPE 37

Please mail comments/suggestions on:

• content to the Chair of the working group.
• format to webmaster@ripe.net.

IPv6 joint policy meeting
RIPE ipv6-wg & lir-wg

Wednesday, 13 September 2000
RIPE 37

Chair: David Kessens

Agenda
i Statement of current policy draft
ii IAB/IESG recommendations
iii Panel discussion
iv AOB

=i= Statement of current policy draft -- Joao Damas, RIPE NCC

One year ago 3 Regional Internet Registries produced document that
outlines allocation of IPv6 address space.
* size of end user assignments
* multihoming considerations
* what is the meaning of 80% usage in ipv6?

We need the clear picture of these issues to move forward.

[chair: Bob Hinden tries to present the opinion of the IAB/IESG as closely as
possible, but he is not the official spokesman of those bodies]

= ii = IAB/IESG Recommendations on IPv6 Address Allocation - Bob Hinden

URL: http://www/ripe/meetings/archive/ripe-37/presentations/ripe-ipv6-hinden/

We do not have real issue on service provider allocations size.
Our recommendation is: /48 fixed boundary for all subscribers.
This is consistent with responsible stewardship of the IPv6 Address space.

Reasoning:
- allocation policies influence the deployment; policies should make
deployment easy, not slow
- renumbering is (still) not painless or automatic

Exceptions:
- very large subscribers should get multiple /48:s, or /47
- transient nodes (roaming, dial-up) (/64)
- explicitly no interest in subnetting

Justifications for fixed boundary:
- easy to change ISP:s (does not require restructuring of subnets)
- straightforward renumbering
- compatible with current multihoming proposals
- allows easy growth of subscribers
- reduces burden of ISP:s and RIR:s to judge customers' needs
- no need for details of customers' networks
- no need to judge rates of consumption
- no scarcity of subscriber's space: no need for NAT
- allows single reverse DNS zone (for all prefixes)

Conservation:
- does this waste IPv6 address space? No.
- this distribution had better H ratio (RFC1715) then many others today
- still, only one of the Format Prefixes (001) is going to be used; it
leaves 85% of total IPv6 space for future usage and possible stricter policy

Multihoming: IETF is still looking for input on this issue.

= iii= Panel discussion:

1. Stephen Burley (UUNET)
2. Steve Deering (ipng)
3. Joao Damas (RIPE NCC)
4. Bob Hinden (ipng)
5. Randy Bush (ngtrans)
6. Juergen Rauschenbach (ipv6 forum)


Q: What is criteria for ISP allocation? How much IPv6 address space does
an ISP get?
A: (Randy) This proposal is not changing other parts of policy. All will
still get a /35. Normal slow start.

Q: (Dave Pratt) Could you clarify what is meant by the 80% rule?
A: (Bob) 80% of number of customers (ISP needs to allocate 80%, not the
subscribers)

Q: (Dave) I guess what I really mean is to do with ISP/LIR addressing
hierarchy. It's difficult to build in hierarchy if aiming for 80%
utilisation before more addresses will become available.
Steve: H-ratio may be more appropriate rather than a percentage.

A: I would suggest 20%. For example with 20% you can reserve addresses
for 8 regions, and not worry if 6 of the 8 sites have small take up rates.

A: (Steve) "you can start without hierarchy, and then add it later when
the need arises".

A: We could add hierarchy later, but maybe not really (same
problems later as at start). We should be designing our networks
correctly from the beginning.

A: Discussion of possibility of H ratio's also being applied also to
the LIR/ISP address range.

Randy points out that with allocating /48s in a /35, the H ratio might
be different, but the principle still holds, and there is a believe
that there are enough addresses in IPv6 (also mentions in passing that
the same believe existed in the early days of IPv4)

Q: (Wilfried Woeber) Thank you for the clear document and clarification.
Remaining issue: number of bits available for infrastructure. There should
be a recommendation to start with the least significant bits.

A: (Steve) We need an analysis regarding building an efficient hierarchy
in the top 8 bits. If the community agrees on the /48 boundary, we
may have to review the size of the initial allocation (/35 subTLA size).

Joao explains why the /35 has been chosen. One gets 8192 NLA ranges,
which can each by itself be structured and managed. This means it is
actually more than if one gets a /19 in IPv4.

Randy wonders why WW thinks one has a different problem in v6 than
today in v4. The ISP he works for aggregates per pop, very strict and
successful about it, but announce a /19 or shorter per pop. /35 feels
as comfortable. Tries to understand if people don't feel comfortable
with that and why.

A: 13 bits (/35) is fine, it allows for aggregation per pop, the problem
is the 80% usage rate.
Randy: isn't the problem the percent, not matter how much it is?

A: Problem is if the pops grow at different speed.

A: Gert Doering, space net, Germany: We started with /19. By now, we
have /16 and few /19:s, and they are not aggregated. We have
resellers, and they have theirs. It fragments awfully. I am in favour
of /56; or, I do not mind /48 if we can get bigger prefix (more bits)
in the front. I do not need more space, but more possibility to build
the hierarchy and aggregate.

Joao: You have /29 contiguous block reserved to grow into.

Gert: I don't see the need for slow start. There are so many /29s that
the routing tables would explode before the /29s were exhausted.

Bob suggests that might be solvable by rethinking the 80% usage rate (so
that ISPs are not penalised for taking a long-term view from the start).

Randy: He is in Frankfurt and Bon, and peers with Jurgen at both places,
and announces same /35 at both places and Jurgen does not know to which
one to send traffic.

Chair: Want to refocus back on the recommendations of the draft. People
seem to be OK with the /48. Let's move on. Need to come up with something
to put in the multihoming section.

For now, IPv4 method of multihoming should be used, as a short term
recommendation. There is also the option to use multiple prefixes.
The philosophy should be that addresses are cheap, so if
someone wants to experiment with the multi address multihoming, let
them and give them the addresses.

Q: (Dave Pratt) Present PI space is authorised by RIPE and does NOT come
from provider assigned space. I think this is a good rule (until
better multihoming techniques are developed) that should be continued
for IPv6.

Alain Durand: Wants to emphasise that it's early in deployment and we
need lots of feedback regarding whether multihoming techniques etc work.
Be generous with /48s.

Randy: From the proposal "if they need more address space, they get
multiple /48:s". I would suggest /47.

Steve: Looking to create a team to investigate how to measure usage.
Maybe find a H ratio measure to apply instead of the 80% rule.

Joao: the conservation is not the only issue here.

WW: We want to keep the routing table small. (...)

Randy: Small number of providers having TLA does not look good from the
market point of view and it would create the small club who owns the
Internet.

A: The requirement is not only to aggregate well (shrinks the table),
but also to find neutral mechanism of allocation; how to get into that
club.

Chair: Do you have enough info on /48 proposal?
(yes)

Chair: OK recommendation of this group is that /48 assignments should
go ahead. This will be taken to ARIN and APNIC.