RIPE 40

IPv6 / LIR / EIX WG Joint Session RIPE 40

IPv6 / LIR / EIX WG Joint Session Agenda
Topic: Interim policy for allocation of ipv6 addresses for Internet Exchange Points
Thursday October 4th, 2001, 11:00 - 12:30

A. Administrative stuff
- appointment of scribe
- agenda bashing
B. How to proceed for the next iteration of the policy.
C. Selection of most important issues that we want to discuss during this session:
- how to proceed from the interim policy ?!?
- default /64 or /48 allocation size
- do we want to have this space allocated from a special block, may be even block that is used by all RIRs for this purpose
- what documentation is needed to get an allocation
- is there any need to document allocations in the RIPE database, and if so, how ?!?
- general wording of the policy

Presentation of these issues by Mirjam Kuehne (RIPE NCC)
D. Discussion of the issues
Z. AOB

ad A:

scribe: Arno Meulenkamp, RIPE NCC

ad B:

David Kessens: how to proceed? Do we want a seperate document for exchange points or not?

Gert Doering: I'd like seperate document, since in IPv4 we are making a shorter document, it makes sense to do the same for v6

David Kessens: consensus for seperate document? no one against.

***
Voted on & accepted: seperate policy document for IPv6 addresses for Exchange Points
***

David Kessens: can we make a document now or have longer discussions?

proposed draft: http://www.ripe.net/ripe/mail-archives/lir-wg/current/msg00079.html

ad C&D:

Chris Fletcher: linx has /48 because of multicast, it should be trivial to get that because of multicast, so we might as well give /48

Francis Dupont: /64 is not enough

Randy Bush: for what?

Francis Dupont: several switches, seperate networks

Randy Bush: we shouldn't assume that IX's need more, they can get it when they need.

Francis Dupont: why less to an exchange point then a cable customer?

Randy Bush: this is the mesh we are talking about specifically. The infrastructure for the IX can have whatever it needs.

Bill Manning: site local or link local might be used. My concern is that we should support aggregation, so we should have one block for all exchange points.

David Kessens: summary: /48 is convenient, but might be too much? What number do we want?

Gert Doering: this policy is made so we can give an exchange point IPv6 addresses for the peering mesh, which they cannot get now. I am in favor of /64 but liberal with how easy it is to get it. /48 might be seen as also being for infrastructure, it should only be for the peering mesh.

Bill Manning: largest IX's have less then 300 participants, it seems /64 is enough. Multiple meshes, multiple /64's.

Francis Dupont: I don't see why special case, /48 is standard.

Randy Bush: being American I am used to grand measures, but let's use what is needed. It's 1 lan, so 1 /64, should be enough for any lan.

Bernard Tuy: rfc2177: access point is a site, so /48. Otherwise link local.

Randy Bush: with traceroute you cannot use link local. We don't need globally routable, but they need to be routable between peers at the exchange point, so we need routable, but not globally announced.

Dave Pratt: each new lan for an exchange point needs new addresses from RIPE NCC, too much overhead.

Chris Fletcher: size is in this case not important, probably ease of use more important.

David Kessens: you want to use more addresses?

Chris Fletcher: we have a /48 which is more then enough, let's give everyone one, since most IX's will use multicast on seperate mesh, so more networks, which should give a /48.

David Kessens: what has been allocated?

Sabrina Waschke: 4 /48's for 4 exchange points

Fearghas McKay: since it is now assigned on /48 boundaries, we could keep that as policy.

David Kessens: who's in favor of /48? quite a few
who think this is ridiculous? some...

Mirjam Kuehne: who is in favor of a /64? keeping it like it is?

few

David Kessens: would anyone have real problems with changing it to /48? no one...

how many don't knows? a few.

David Kessens: it seems we have consensus on /48

Randy Bush: how many people cannot live without a /48?

Keith Mitchell: /48 would be nice and also useful, because we want to do more with it. /64 would be enough, we'll get a /48 through regular means. It makes life easier, but I could live without it. It doesn't make much difference.

David Kessens: (on personal basis) it seems it is more convenient administratively. Even though it might be overkill.

Fearghas McKay: it seems the consensus is /48 default.

***
Consensus: Exchange points should, if they qualify, receive an assignment of a /48.
***

David Kessens: do we want it out of a special block? do we think this is important?

Gert Doering: I think it is usefull, not critical, but might help.

David Kessens: (on personal basis) it'll allow me to filter, I'd like that.

Mirjam Kuehne: it's what we are doing now

David Kessens: then we should document it. Do we think this is a good procedure.

Randy Bush: I agree with the goal.. it should be adminsitrive, it assumes the registries are trying to first do it globally, if it doesn't work, lets leave the option open to change it.

Christian: since it is now /48,. what are exchange points allowed to do with it? Must it be routable or not? Otherwise ix want another /48 that is routable...

David Kessens: this is only for the meshes, not for other services.

Christian: so everyone might end up with 2 /48's, that seems wastefull.

Keith Mitchell: if it is not gonna be usable for other purposes, I might as well have a /64. why filter the seperate meshes? If we go for a /48, we shouldn't treat is special.

David Kessens: do the registries see it as problematic? no?
Should we have all exchanges an easy hacking target by having them from a special range.

Bill Manning: if you only connect routers to the mesh, it doesn't matter that much.

Keith Mitchell: Do we want one global block that the RIR's manage individually. That will be a lot of hassle, seeing as meshes are very localized, more so then isp's.

Mirjam Kuehne: that will be very ok, no problem for us.

David Kessens: ok, so the question is: do we want to recommend a single block or not? (if so, we would like to have it documented)
who is against this recommendation? *1 person*
who is in favor of 1 block for all IX's? *about 10*

David Huberman: in ARIN it is exxplicit in the contract that the IX's shouldn't announce it.

David Kessens: it seems there arent to many people interested. Are there people who don't care? *quite a few*.

Richard Jimmerson: We do the same in the ARIN region, the RIR's are capable of doing it, if our community wants it, we can do it.

David Kessens: so we have consensus that we recommend one global block.

***
RIPE recommends one global block
***

David Kessens: do we need to document it in the ripe database?

Keith Mitchell: I'd like to repeat: I don't see a particular reason to make the allocation very different from regular allocations, so use standard way. I don't see arguments to make them special.

David Huberman: I agree, no argument to make them more or less special.

David Kessens: it seems to be no special treatment?

do we agree? *most hands*
against? *noone*

***
no special documentation necessary
***

David Kessens: what documentation is needed for allocation?

???: lets not make it different from what is usual.

Mirjam Kuehne: odd to bring up the form, that is RIR business, it is odd it would come up.

Randy Bush: if this assignment is supposed to be just as normal in any aspect, then why do we need a seperate policy? why are IX's special.

Dave Pratt: because of the number of customers..

Keith Mitchell: because existing policies did not allow ix's to get addresses. (requirements were not geared towards it) but lets not make them more special then we need. The peering point still needs independent address space, if they cannot under the normal policy, we need something that allows an IX to get address space.

Gert Doering: the new policy might make it possible, but right now the old policy is in place, we need it now, so make it now, we can abolish it later if wanted.

David Kessens: why bring up the form? I did that to check the items of info that are requested.

"current address space usage template", i think it is odd.

Is the request for current v4 and v6 address space usage relevant?

Gert Doering: for the old policy it was important (/64), with /48 it doesn't matter anymore, since one assigment should be enough. So we can skip the question.

David Kessens: without this info, is it still workable? Can we remove it?

Mirjam Kuehne: I can't answer that right now. we'll have to discuss with the other registries.

Richard Jimmerson: ARIN staff doesn't make the decision, we can ask in the ARIN meeting.

Gerard Ross: In APNIC, the procedures are seperate, even though the policy is global for the different regions.

David Kessens: ok, do we recommend then to remove that part? *15 to 20 people*
who feels it is important? *not many*
don't care? *10 to 20*
who thinks we shouldn't ask this question (it's RIR business)? *about 10*
who feels we should? *about 5*

*** no consensus any which way...

Bill Manning: i suggest a possible different approach.. if we cannot get consensus, we can discuss this on the mailing list.

David Kessens: maybe we can change the question so it becomes appropriate.

Bernard Tuy: what are we discussing, the form or part of it?

David Kessens: we are discussing whether the info is necessary.

Bernard Tuy: so we can remove it? Is there a good reason to keep it?

David Kessens : maybe we shouldn't be involved with it

Bernard Tuy: then why discuss it...

Randy Bush: this is a level of detail that we shouldn't discuss here. Too detailed. The process we use for making decisions doesn't scale well for this issue.

David Kessens: ok, can we request the rir's to review and remove irrelevant info?
good? *quite a few*
bad: *none*

David Kessens: so lets ask the registry to review the form and weed out unnecesary items.

***
ask the registry to review the form and weed out unnecesary items
***

David Kessens: we have gone through the topics we had in mind

ad Z:

David Kessens: aob?

David Kessens: then we're done..