|
|
 |
Minutes from RIPE 39
Minutes from the LIR working group at ripe-39 in Bologna, Italy
Joint session: IPv6 & LIR & EIX Wrking groups
1 May 2001, Tuesday
Agenda:
=======
G. Draft on allocation sizes (Niall Murphy)
H. Status of IETF/RIR allocation boundary discussions
(Randy Bush/Mirjam Kuehne)
& "The Bootstrap phase"
(Mirjam Kuehne)
I. IPv6 and Exchange Points
(Mirjam Kuehne)
G. Draft on allocation sizes
============================
Review of the IPv6 Policy Situation" (Niall Murphy)
http://www.enigma.ie/articles/global-ipv6-alteration.html
Additional info (Dave Pratt)
http://www.djp.net/ipv6/proposal.html
http://www.ripe.net/ripe/mail-archives/ipv6-wg/20010101-20010401/msg00017.html
Niall: "At the last meeting, RIPE38, there were quite few comments on the
IPv6 policy: Stuart Prevost from BT was pointing to the inconsistencies
between RIR documents and the RFCs; Dave Pratt (?) was pointing to the
problem of the subTLA width; and I was talking about the problem for
start-ups getting IPv6 (addresses). All of that was from looking at the
RIR documents, RFCs and also practical experiences.
Between then and now, a small task force was formed to look at the
problems, and try to create a document to explain them, and possibly
suggest the ways to fix them. Very few people sent me comments, but I am
hoping that this is the right forum to receive some additional input.
We think that "ripe-196" needs to be reviewed.
{{{{
With the following things in mind:
1) default allocation for end-node has been proposed and accepted to be /48
2) the world has changed since ripe-196 was created. World-wide
organisations, exchange points etc - these all need to work with Ipv6. At
the moment, it is quite difficult for them to do that, because it was
anticipated that v6 will be top-down driven, and at the moment it appears
to be bottom-up or edge-in driven.
3) there is, perhaps, also, some unnecessary _buerocracy_ in the process,
particularly for start-ups.
4) weird bit boundaries may cause people to make mistakes.
}}}}}}}
Our recommendations:
- accept IETF (/48) proposal
- better size of the allocation
- fix 6bone competence test
- shorten time period
- replace "6bone" with any big v6 network
- synchronise the policy document with the reality
Slides:
http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/RIPE39-IPv6-policy/index.html
Niall: Has the /48 "4all" been adopted by ARIN?
ARIN (??? Richard or Ray): Community adopted it, board is looking into it.
By the end of May.
Audience: ieab/IETF proposal says that cell phones should _not_ get /48.
Niall: Excelent! I'm very happy!
David: If the device is not a phone, but a 3G "phone"... See the draft.
Chair: discussion should be after the Randy's & Mir's presentation.
H. Status of IETF/RIR allocation boundary discussions
======================================================
(Randy Bush/Mirjam Kuehne)
Randy: people looking for the v6 peering, should meet in the corner after
the meeting.
Mir: I want to reassure you that RIRs will update documentation, thank you
for suggestions and contributions.
To answer about the 6bone requirement: participation in 6bone was not
supposed to be and should not be taken as a hard requirement, but as an
additional option.
This same presentation was given at ARIN meeting a month ago.
Slides:
http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/ipv6develop/
Referenced info:
draft-IETF-ipngwg-addr-arch-v3-05.txt
ftp://ftp.ripe.net/rfc/rfc2374.txt
Discussion items:
* Middle level: RIR to LIR: "slow start" method, based on current practice
- minimum initial allocation
- subsequent allocation based on utilisation rate
David Pratt: This is a fundamental flow : RIR allocation policy is based
on the scarcity of address space. We should be dealing with aggregation.
Randy: Major problem that we have with aggregation is multi-homing, not
allocation policy.
Bernard: What is the status of 2450 (subTLA definition)?
Randy : subTLA's are disappearing.
Chair: Status is "overtaken by events".
Bernard: We need to inform the community that this is not relevant any more.
Randy: Again?
Randy: The issue of - what the purpose and method of the allocation
policy are - should be clear after today's discussion here, and specially
in the LIR wg.
We finally separated the policy issue from technology. On the one end of
spectrum is routing aggregation problem, which is not going to be solved
by giving TLA to 8000 big ISPs, because of the multihoming. What boundary
is conservative ISP going to filter on? /48?!
The other end of spectrum: iana currently allocates big chunks of IPv4
space to Regional Registries; they allocate to LIRs; and what we're seeing
is many global ISPs. Maybe some of the "question mark" boundaries should
be zero?
Audience: Internal structure of LIR and ISP is the question.
Dave Pratt: The only hierarchical part is in the big ISP.
David: One step back - do people think that this was the useful exercise,
dividing technical and policy part?
Audience: Good step forward.
Wilfred: To start re-writing documents is progress.
Question to Randy: what is the reasoning for searching an agreement of
ISPs to the filter length?
Randy: Operators don't agree. They look into the policy and see different
things. That's what the whole multihoming discussion is about. Some
of them listen to /24 today, and they will listen to /48. Others will
listen to this (pointing to the other boundary).
There are two discussion forums, and they do not have the answer (yet).
multi6@ops.iet.org & ptomaine@shrubbery.net
Q: Reverse delegation in IPv6?
Randy: First issue is the protocol issue - what will happen if the
delegation is not on nibble boundaries?
A: Let's keep on the nibble boundaries on ip6.int, so far.
Randy: It has been agreed that it (ip6.int?) will not be constrained to
nibble boundaries. The IPv6 Directory directorate had a conference call
last week, where that was decided. That implies the decision whether to use
(...) currently used in IPv4, or do we use bit-stream labels. That discussion
is ongoing within DNS directorate.
The third issue is how the transition from ip6.int to ip6.arpa. Current
suggestion is that they will run in parallel, for couple of years. Those
servers who are running one should also run the other. We will devise some
simple tools to keep them in sync. And ip6.int will go down in 2 years.
Bill Manning announced that he will show (after this session) how they do
bit-streams and other inverse delegation things.
Conclusion: the "question marks" (unknown boundary sizes of allocations
from IANA to RIRs and from RIRs to LIRs) will be discussed on the mailing
list.
Wilfred: To avoid going back and forgetting about this issue, I am
proposing to WG chairs and RIRs to come up with the draft proposal on what
are the steps for review of the policy document, and other documents,
and how are we going to make progress. This is a question about the
procedure of re-writing the document, and the time-lines.
David: The current document is outdated, for various reasons, that were
presented here today by Niall and others. Policy documents needs to be
re-written. We need some dates, time-line of when will we get the new draft.
Mirjam: RIRs will take it over. We made a list of what needs to be done.
David: .. and the bootstrap criteria is running out!
"IPv6 Bootstrap Phase" (Mirjam Kuehne, RIPE NCC)
======================
Slides:
http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/ipv6bootstrap/index.html
Summary: There are two sets of criteria, "regular" ones, and the
"bootstrap" ones, which were to be used only during the "bootstrap phase".
That expires when number of organisations who receive IPv6 allocation
reaches 100 in the world, or 60 in one region. Shall we extend the
"bootstrap phase"?
David: Yes, at least until the next meeting.
ARIN region agrees, too.
Mir: Conclusion - we will keep the bootstrap criteria in place, even if we
hit 100, before the October meeting.
Wilfred: At the moment that you do reach 100 allocations globally, the
community should at least have the opportunity to discuss that fact in all
the 3 regions.
David: ACTION item on RIR to give us updated document by the next meeting,
at least the draft.
Jurgen: There are more RIRs being formed. Certainly I would like to see
that current RIRs are aligned and have an agreement, but I also don't want
to have problem with going ahead with RIPE NCC in this direction, even
without the agreement between all RIRs.
Mir: I hope that this will not be an issue.
Q: What will be the benefits of stopping the bootstrap phase?
Mir: It was there to stop the rush.. and that is not happening.
It might help some organisations to keep the "bootstrap phase" on.
Wilfred (with the Address Council member "hat"): it is certainly a good
idea for RIRs to keep working with each other to keep that from your end.
However, I would propose to try also to get input and help from the 3
"communities" from the 3 regions right from the beginning. Because we have
seen, and might run into the same problems again, of getting the
"rubber-stamp" supplied in the different regions. We might be quicker, for
the next round, if we are already pulling in the people from those regions
- not only the RIR staff, but also from the users, who have an interest,
one way or another, and put them into the "editorial group". The result
should be one draft, instead of having RIRs coming up with the draft or new
version, and then we have to go back all the way into the regions and
collect comments.
David: Asking the audience - what do you think?
Mir: There are operators in this room already, and I am expecting them to
express their opinion and be part of the discussion.
Randy: RIRs & operators are (already) working together - operators from
Asia/Pacific and North America are here. Forming "Task Force" groups is
fine, but you'll have to circulate the document for public opinion anyway
in RIR fora. Public meeting is the place to get exposure. Creating small
Task Force group is a way to get document drafted, not to get consensus.
Audience: I am from ETNO - European Telecomm Operators group, with 47
members. We support conclusions of Nialls group -- between /48 and /35
there is very few space for efficient management, in terms of aggregations
and routing tables. I will send our propose to ipv6-wg list, as an input
to the discussion.
David: action points:
1. bootstrap: continue bootstrap phase till the next meeting, but the
notification will be sent when 100 subTLAs border is reached;
2. revised policy document by the next RIPE meeting
3. more people from the community to get involved from the beginning, in
the discussions of the draft
Mir: Are you suggestion rewriting of the RIPE document in the larger group
or shall the smaller group be involved in drafting , and we proceed by
sending draft to the list?
David: Both... sending the draft is OK, but not the last day before the
RIPE meeting.
I. IPv6 address space for Internet Exchange Points
Mirjam Kuehne, RIPE NCC
http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/ipv6exchange/index.html
Wilfred Woeber: What the technical description of the Exchange Point
infrastructure would be? What sort IXP infrastructure requires global
accessibility?
Randy: In '97 the large providers asked shall they announce IXP mash to
each other? The answer was NO. Whether shall they be "golden networks"?
no. but you do not want to get the packet with the destination of IXP.
Gert Doering (sp?): In Germany (it="IXP mash") is visible. It is useful -
because of troubleshooting.
Someone: The issue is not reachability. The issues are uniqueness and
independence. They have to be unique, because (...).
Independence - addresses can not be granted from one of the participant,
because that participant can pull out.
I think that we need to continue exactly as we do in IPv4, which is
that Registries granted the exchange point block to the exchange point
block maintainer,
Randy: I thought that RIRs allocate directly to the Exchange Points?
Mir: There are various options - we either allocate directly to IXP, or
(directly) to the organisations that maintain [multiple?] IXPs.
A: The advantage is that there is one maintainer. And it's a convenience.
Randy: What's the advantage of this adding of the "middle person"?
Mir: Is there a technical reason to get all (the addresses for various
IXPs) from one block?
A: You can block the whole space if you prefer.
Mir: There are other ways to do that, rather then getting whole
aggregatable block.
Randy: We'll get the address and know where it is from.
A: Do you really want Registries (RIRs) to have to deal with every single
EXP that comes along?
Randy: That's why I pay them money.
A: One interesting advantage might be.. Do you remember what happened few
days ago when somebody announced LINX address space as a more specific, and
a couple of people's peerings went down (because ...)
But if I know the address block where is that coming, I could block it..
Randy: That is exactly where the discussion in 97 came from - it allows
me to NOT listen to the IXPs -at which I am present- from my peers.
Andrew from IX in Zurich: We have the need for globally unique IP
addresses because this IX network addresses get propagated to the internal
networks of members, so if they happen to peer with two or more IX, and
for some reason these two have identical site-local addresses, then they
have a problem. Therefore, we need globally unique address space.
The other thing is - having the middle man is a bit.. first, who would be
that?
Maybe it's OK to have the general block of IX prefixes, but the
allocations from that block are done by usual suspects like ARIN or APNIC.
But not having yet another organistion or person that cares about these
things.
Mike Hughes from LINX: We are on of the IX that are LIR, and out of that
block we allocate addresses . All our peering LAN(s?) are from that block,
and not from IXs block. I accept the issue that it makes it easier by
going to the central maintainer of the IX block, but we need addresses for
our other services (our transit network, our own network infrastructure,
mail servers, web servers..), and for that reason we need addresses which
are not going to be black-holed.
Randy: I don't think that anybody would advise filtering the IXP block,
because I don't think that anybody in on every IX.
But - there are IXPs where people who co-operate to make an IXP feel that
any one of them can not be trusted to operate the in-addr. And there have
been searching for the external function. The RIR should allocate
the address space, and if IXP entities wish to have some external entity
maintaining in-addr.arpa to for them - they can choose anybody: this is DNS
delegation, not address allocation .
Andrew (Zurich): To the LINX problem - maybe the solution is to
split these two functions: for the IX network, for the addresses for the
ISPs, for the PO that are given out;
and having a separate IPv6 delegate address space for the servers, that is
routed by the transit provider of the IX office of administration.
Bill Manning: I have received requests from approximately 15 IXP
who would like the v6 space for their exchanges. Some of these requests go
back 2 or 3 years. Within 6bone they do have it. There is some need for a
block of space to be "earmarked" for IXPs.
With regard to IXP addressing and for the "critical infrastructure"
addressing, I think RIR already have some things in place for IPv4, and
IPv6 should not be too much different.
Mir: Just for clarification, there is only one Registry which has a list
of "critical infrastructure". In RIPE we could not come up with the
criteria, so we don't have it.
Francis: The addresses are not useful by themselves, they are useful
because they are routed. You should use addresses from these ISPs.
David: We need the distinction between IP addresses that are used in the
exchange, and IP addresses that are used by IXP for other purposes like
mail server.. We need to separate that - is that correct?
Keith (LINX): I don't think we can make that distinction.
The existing model: RIRs set aside special block, from which
IXP get smaller allocations. The other solution is to change criteria.
Answer to "what's different for IXP" is: more ASN, small amount of
address space.
Distinct discussion issues:
1st: admin services, mechanism for allocating without going through RIR.
2nd: special addresses.
Mir: One block can set aside from RIRs .
Dave Prat: Criteria is much tighter -
the same allocation guidelines for pi space for ipv6.
globally routed = pi space (but smaller).
it doesn't really matter how many we give to IXPs.
Randy: to define : 3 or more ASes, RIR allocates /48 or /64.
Regarding "golden networks": would the RIR please put up the web site,
where everyone who thinks that their subnet is "golden" can (place
themselves?)
Tony Hain (Cisco): Something to think about: treating each of the IXP as a
site, and use site-local addresses.
WW: for the layer-2 exch.infrastr. people are looking for 1819 (private).
for the other services: IXP is just a customer, who is multihomed to lot of
ISPs; it should not be too difficult to assign more then one prefix to
them.
Bill: site-local were used, but there are some issues: measurements, etc
Andrew (Zurich): for the address space in IXP you can not use private
address space because the addresses are in fact global. If there is any
chance of conflict, we can not use them.
2nd reason - if anyone is using (other protocol)...
I don't think that site-local can be used.
Keith: on the last IETF, there was a presentation on IPv6 for IX
[include URL here]
Bernard: take away idea of usage of site-local. I would suggest to use
globally unique addresses...
Q (chair?): Anyone for using local? NOT.
WW: definition of exchange point?
Bill Woodcock: The only open issue is - who is doing the allocation?
EP: http://www.ep.net/ & http://www.euro-ix.net/
David: Why should not ep.net just ask for subTLA?
Someone: i am in favor of choice. i provide the choice.
i'd prefer that registries have done the better job.
David: if you need only few addresses, why can't you just get them
without RIRs.
David Prat: IPv6 addresses will be given. how much? /35, along current
policies. and then the document is being revised anyway..
David and Mir: let's continue on the mailing list, wrap this up, write
this down. It's action on Mir - to send it to all 3 iex, ipv6, LIR-wg.
Someone: IXP are critical in the bootstrap phase of ipv6.
i trust bill Manning, but what if he gets hit by the bus?
i would rather have RIRs...
Randy: if the IXP comes to the RIR, there is criteria -
give them /64. "we have multiple IXPs" - give them a /48.
that is the proposal i will help to write up.
if other people have different proposals, write them up...
|
|
|
|
