September 2001 - lir-wg - mailman.ripe.net

Index of lir-wg on Altavista
by Bernard Steiner 07 Sep '01

07 Sep '01

Folks, considering the fact that I have started receiving UCEs to my e-mail address at work, would anybody out there point out to me the advantages of having altavista index the lir-wg archive (amongst other things) ? Fed up with UCEs for today, Bernard

1 0

Re: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points
by Wilfried Woeber, UniVie/ACOnet 06 Sep '01

06 Sep '01

IPv6 Address Assignment Policy for Internet Exchange Points =========================================================== 1. Abstract ----------- This document describes a policy for Internet Exchange Points (IXPs) under which unique IPv6 address space to be used for the infrastructure of the Internet Exchange Point can be obtained from a Regional Internet Registry (RIR). 2. Background ------------- It has been recognised that there are scenarios in which it is not desirable for IXPs to obtain address space from one of the Internet editorial: the term "desirable" is much too weak. This can set a precedent for other (presumably) special cases/groups/applications to request similar treatment. IŽd propose something like feasable or acceptable. Service Providers (ISPs) connecting at the IXP. In these cases it is viable to have unique IPv6 address space assigned directly from an RIR. This address space is needed to adress the Exchange fabric. This issue has been brought forward to the RIPE community in May 2000 and has subsequently been discussed at RIPE Meetings and on public RIPE mailing lists. The conclusions of these discussions are described in this document. It is expected that the same policy will be accepted in the ARIN and the APNIC region at which point it will be incorporated in the Global IPv6 Policy document. editorial: as suggested by others, the additional paragraph explaining the "regular" paths (RFC/6Bone or regular ISP application) might go in here. 3. Definition ------------- An Internet Exchange Point is defined as a physical network infrastructure (layer 2) operated by a single entity with the purpose to facilitate the exchange of Internet traffic between Internet service providers. The number of Internet Service providers connected should at least be three and there must be a clear and open policy for others to join. Addresses needed for other purposes (e.g. additional services provided to the members) should be aquired through other appropriate means ( e.g. an upstream ISP). This is both too restrictive (from a technology point of view), as well as too blurry: - there might be cases for an IPv6 exchange point which starts on or operates on an existing (layer2 or 3) fabric. Tunnels in v4 or a multicast-enabled v4 net used as a layer 2 tech for v6 spring to my mind. - the use of "Should" seemms to be odd in a policy definition - I would not be able to judge what an "open policy for others to join" would look like as a minimum 4. Policy --------- I think 3. and 4. should be swapped. An IXP that seeks to obtain an IPv6 address assignment by the RIR in its region, needs to submit a request to that RIR. IXPs operating in the RIPE NCC service region should use the 'IPv6 Request Form for Internet Exchange Points' (http://www.ripe.net/ripe/docs/ipv6request-exchangepoint.html). After approval of the request, the RIR will make the assignment. Since the address space does not need to be routable globally and an IXP is expected to only have one subnet, a /64 (64 bits of address space) will be assigned in most cases. In the case the IXP is using multiple fabrics (e.g. unicast separated for multicast), multiple /64s can be assigned to the IXP. IP Address requests can only be handled if the requestor is a Local Internet Registry (LIR) or if the request made through an existing LIR. 5. Other Considerations ----------------------- It should be noted that ISPs usually do not announce address space used on the IXP mesh itself to their peers. That means the address space assigned under this policy is likely not to be routable globally.

1 0

Re: Interim Policy proposal for IPv6 Address Assignment Policy forInternet Exchange Points
by Wilfried Woeber, UniVie/ACOnet 06 Sep '01

06 Sep '01

>The chairs put forth this interim policy proposal to these lists hoping to >garner consensus or judge that consensus does not exist. > >The ensuing discussion, while not unuseful, does not appear (to me) to be >helping the chairs and the wg membership from gauging the extent to which >there is consensus for this interim policy proposal. > >So I ask: I think it was your intent to separate discussion/improvement from "tallying" pro.s and com.s - so IŽll summarize my comments in a separate message... >In lieu of any other policy changes, are you, as a RIPE member and >participant in the LIR, EIX, and IPv6 WGs, in favor of the interim policy >proposal for IPv6 address assignment policy for internet exchange points? YES. >/david Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

101 IPv6 allocations made globally
by Nurani Nimpuno 06 Sep '01

06 Sep '01

Dear all, This is to inform you that in the last days, the RIRs last week reached a total of 101 /35 (SubTLA) allocations globally. According to the global "Provisional IPv6 Assignment and Allocation Policy Document" [1], the bootstrap phase with interim criteria apply until 100 allocations have been made globally or 60 allocations in one RIR region (4.2.2.1. Duration of Bootstrap Phase). However, at last RIPE meeting (RIPE 39, May, Bologna), it was agreed to further extend the bootstrap phase. The end of the extended bootstrap phase will be discussed and defined at the upcoming RIPE 40 meeting in October. Per region, the following amount of allocations have been made: APNIC: 38 ARIN: 20 RIPE NCC: 43 A list of all IPv6 allocations made globally can be found at: http://www.ripe.net/cgi-bin/ipv6allocs Kind regards, Nurani Nimpuno *--------------------------------------------------------* | Nurani Nimpuno <nurani(a)ripe.net> | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *--------------------------------------------------------* [1] http://www.ripe.net/ripe/docs/ipv6policy.html

1 0

Re: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points
by Henk Steenman 06 Sep '01

06 Sep '01

At 07:19 PM 9/3/2001, Randy Bush wrote: > >> What I believe is needed is an allocation for IXP service networks as well > >> as for the IX mesh, which is globally routable. I'd like to propose this > >> alongside the existing proposal we have on the table. > > I agree with you Mike, I think this is the only way an IXP can show its > > independence from any one of its members (connected ISPs, carriers or > > whatever) > >s/ixp/small isp/ > >i.e. the small isps want to appear independed from their upstream(s). >the discussion over this has been going on nigh a decade. so what makes >an ixp's business so special they warrant special treatment? I believe there is a difference, An IXP is a facilitating infrastructure delivering services to all ISPs connected or to be connected. Linkage in any way to one or more of its members might harm the neutrality of the exchange towards its other members. For AMS-IX: > AMS-IX is a non-profit, neutral and independent association, meaning > that it has no bias as to who connects For LINX > A neutral, not-for-profit partnership between Internet Service Providers > globally, LINX provides a physical interconnection for its members to > exchange Internet traffic through co-operative peering agreements I believe that in both cases "neutral" and "no bias to.." will be harmed if IXP address space (in any way, for the exchange infrastructure as well as for the services infrastructure like web server, e-mail etc) is related to a limited set of its customers. - Henk

14 29

Interim summary of current discussions
by David Kessens 05 Sep '01

05 Sep '01

Hi, The proposed interim policy was proposed to go into effect on the 7th september 2001. Since this date is getting closer, we would like to summarize the discussion so far. - comments from exchange point operators: In order to be neutral, they need independant address space for the services that they offer besides the addresses used for setting up peering relationships. - many comments that they can apply for regular address space, just like anybody else - many comments that it is too hard to get regular address space - we didn't see too many comments about the policy itself, until David Huberman asked the community: In lieu of any other policy changes, are you, as a RIPE member and participant in the LIR, EIX, and IPv6 WGs, in favor of the interim policy proposal for IPv6 address assignment policy for internet exchange points? - quite some people reacted and responded with a 'yes' - few comments were send earlier to the list that a policy might not be needed at all - several different proposals were sent to make it easier to get sTLA address space (which can be used by exchange points too) - most want to relax the current rules in some way or the other - people are worried about easier rules for special interest groups (eg. IXPs, small or big providers) - one completely different proposal was submitted that proposed to allocate a sTLA to exchange point operators which can be used to assign address space to customers - worry was expressed that the interim policy will not be as interim as suggested At this point, it looks like that the community is supportive of the interim policy but that there are still issues regarding address space needs other than for the exchange points customer peering sessions. These issues are not really part of the discussion regarding the interim policy but seems part of a grander discussion regarding the revision of allocation guidelines for ipv6 address space. We should be able to get progress on this topic on the next RIPE meeting (and on the mailing list before that). We appreciate all the input that we have had so far and we continue to encourage you to let your opinion known. Thanks, Fearghas McKay David Kessens EIX-WG Chair IPv6 wg Chair ---

3 2

Re: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points
by Chris Fletcher 05 Sep '01

05 Sep '01

One of the points that has been raised a couple of times is... There is a lot of IPv6 address space - why not just give IXP's a sub TLA. The argument against this seems to be - if IXP's are treated as a special case then there is a precedent for every other 'special case' to justify their case. ... but there is still *lots* [1] of address space so why not give everyone who wants one a sub TLA? AIUI the reason for restricting who gets sub TLAs is... In the current IPv4 world (multiprovider) multihomed customers have their own address space and AS number this fills the default-free routing table and won't scale. In IPv6, addressing is hierarchical and multihomed customers have multiple addresses, this keeps the default-free routing table small and scalable. If everyone (multihomed customers) gets a sub TLA then the default-free routing table fills up with multihomed customer sub TLAs and IPv6 routing tables are as cluttered and unscalable as IPv4. Is this the issue? If not, why not give out sub TLAs to all who want them? Chris - LINX [1] There are 2^32 (~ 4,000,000,000) /35s available... +--+-----+-----+---+-----+------+------------------+ |-3|--13-|--13-|-6-|--13-|--16--|------64 bits-----| +--+-----+-----+---+-----+------+------------------+ |FP|-TLA-|-sub-|Res|-NLA-|--SLA-|---Interface ID---| |--|-ID--|-TLA-|---|--ID-|--ID--|------------------| +--+-----+-----+---+-----+------+------------------+

5 5

OPS-NM interim meeting before RIPE-40
by Randy Bush 04 Sep '01

04 Sep '01

Howdy, At the last two IETF OPS Area Open meetings, we had some good discussion between the OPS NM folk and some operators. We also have had a so called OPS-NM Interim in the USA that was co-located with NANOG in May of this year. We also called it something like: Net Management Protocol Folk & Net Operators - Reality Check #2 We will have another IETF Interim Meeting for the OPS-AREA Network Management people, this time in Europe, co-located with the next RIPE-NCC meeting. The idea is to meet with another set of operators to try and understand their needs and to explain to them how we think that our NM related work in the IETF can help them to manage their networks. In other words: Net Management Protocol Folk & Net Operators - Reality Check #3 We probably will have similar sessions in the future to meet with people who operate enterprise networks, because their requirements may be different. We are still working on the agenda, however below you will find a prelimenary agenda proposal. Any suggestions should be sent to Randy (randy(a)psg.com) and Bert (bwijnen(a)lucent.com) We have limited space for this meeting. Those who plan to attend, pls send a short email to Bert Wijnen <bwijnen(a)lucent.com> to let us know. Pls add a few lines as to why you want to participate. Discussion has been occurring since May on the mailing list ops-nm(a)ops.ietf.org, which is normal internet-style. And a web-based archive is at <http://ops.ietf.org/lists/ops-nm/>. Bert and Ern^H^H^HRandy -------------- OPS-NM Interim Meeting details ------------------ The plan is to have this meeting co-located with the next RIPE NCC meeting, namely RIPE 40. That means: Oct 1st OPS-NM Interim from 2-5pm Oct 2nd OPS-NM Interim from 9am-noon Oct 2-5 RIPE 40. Starts at 2pm on oct 2nd. RIPE 40 and OPS-NM Interim will be in the Prague Congress Centre in Prague, Czech Republic. For RIPE 40 and hotel registration, pls visit: http://www.ripe.net/ripe/meetings/current/ripe-40/ There is a whole range of hotels to choose from, but it is very hard to book, so do it now. Those only participating in the OPS-NM meeting are not required to pay the RIPE meeting fee. Of course, if you want to take the opportunity to participate in the RIPE-NCC meeting, then you should register for that meeting via the web page listed above. Those who plan to attend the OPS-NM Interim should send an email to Bert Wijnen <bwijnen(a)lucent.com> because we only have limited room, and if too many people want to show up we may have to tell some that there is no more space. Prelimenary Agenda ------------------ - Agenda bashing and intro - Summary of the current set of OPS requirements draft-ops-operator-req-mgmt-00.txt Please read this document to prepare for the meeting. If this one no longer exists, then pls check for a possible revision 01.txt. It is important to try and figure out if this also represents needs of European operators, or do they have different/new/additional requirements? - Discussion of the above. - Discussion of SNMP, MIBs, COPS, POLICY and such - how do the developers of these protocols/specs think that they can address operator NM requirments. - what do operators think about that - what kind of positive or negative expoerience do operators have - Operator requirements - what are the real hot issues to be solved this year - what are the constraints within which the tools have to work - Next steps - Wrapup/Summary -30-

1 0

RE: Interim Policy proposal for IPv6 Address Assignment Policy fo r Internet Exchange Points
by paul.mylotte＠bt.com 03 Sep '01

03 Sep '01

I totally agree with Mike in his comments below, and those from Dave Pratt in a previous email. Some time ago I sent the following proposal to the list, and I would like to point out, again, that address space is already allocated for this and is clearly specified in RFCs. The proposal was: At the RIPE 39 joint meeting it was clarified that we should cater for the support of both types of IPv6 exchanges, viz: (i) allocate addresses for IPv6 exchange infrastructure only (no onwards allocation in the manner of a backbone ISP). (ii) allocate a sub TLA to the IPv6 exchange which will then act in the manner of an ISP and allocate downstream. In order to progress this, I would like to propose: 1 IPv6 exchanges that need addresses for the purpose of internal addressing can apply for the addresses already set aside for this purpose and held by IANA, as per RFC2928 (Initial IPv6 Sub-TLA ID Assignments) and RFC2450 (Proposed TLA and NLA Assignment Rules). In this case a /48 allocation will be sufficient. (How IPv6 exchanges should apply for these addresses is out of scope - either direct to IANA, or IANA allocates down to RIRs first). extract from RFC2928 Section3 Initial IPv6 Sub-TLA ID Assignments ... ..The block of Sub-TLA IDs assigned to the IANA (i.e., 2001:0000::/29 - 2001:01F8::/29) is for assignment for testing and experimental usage to support activities such as the 6bone, and for new approaches like exchanges. 2 IPv6 exchanges that plan to onward allocate addresses in the manner of an ISP should apply via the existing mechanism. The existing mechanism is currently being reviewed and this review should take account of any changes necessary to include IPv6 exchanges explicitly desiring addresses for onward allocation as being acceptable candidates for address space. Could we please add this proposal to what is already on the table. Regards, Paul P. S. Mylotte IP Addressing & Naming BTexact Technologies Adastral Park 01473 606333 / + 44 1473 606333 paul.mylotte(a)bt.com BTexact Technologies is a trademark of British Telecommunications plc Registered office 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the number or address above) immediately. > -----Original Message----- > From: Mike Hughes [SMTP:mike@linx.net] > Sent: 03 September 2001 11:19 > To: lir-wg(a)ripe.net > Cc: eix-wg(a)ripe.net; ipv6-wg(a)ripe.net > Subject: Re: Interim Policy proposal for IPv6 Address Assignment > Policy for Internet Exchange Points > > On Fri, 31 Aug 2001, Dave Pratt wrote: > > > Unfortunately, I must respond against the proposal as it stands with use > of a > > /64 allocation. > > If the proposal for the /64 allocation for the IXP mesh is "it" - i.e. > this will be the only address space allocated to an IX, period - then I > find it hard to be in full agreement with this proposal. > > The LINX is currently an RIR in it's own right, with a /19 of PA space > delegated to it. This is diced up to provide addresses for the IXP meshes > at LINX (both Unicast and Multicast), for LINX's own public-facing and > member services, and some space is delegated for essential services LINX > hosts (such as nic.uk). > > LINX peers with all it's members, and announces this /19 to them - this > means that members have direct, independant connectivity to the LINX > services. We also have a handful of transit ISPs (a small subset of > members, but over independant media) to fill in the gaps, and make sure > we're still online if there is an exchange problem. > > If v6 addresses for an IXP's member services have to be delegated from an > upstream provider, this makes the exchange dependant on that provider. If > that provider has problems, or ceases trading, that could have serious > impacts on the business continuity of the exchange, for it's > member/participant community, and possibly other members of the RIPE > community. > > Please don't say IPv6 address-based multihoming to me. It's not ready > for primetime IMHO. > > What I believe is needed is an allocation for IXP service networks as well > as for the IX mesh, which is globally routable. I'd like to propose this > alongside the existing proposal we have on the table. > > Comments? > > Mike > -- > Mike Hughes Network Architect London Internet Exchange > mike(a)linx.net http://www.linx.net/ > "Only one thing in life is certain: init is Process #1" >

2 1

Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points
by Fearghas McKay 03 Sep '01

03 Sep '01

Following discussion between the WG-Chairs and the NCC we have the following proposed draft. To enable allocations to be made as soon as possible we are soliciting comments over the next few days but unless there are any issues we would like to start making allocations by the end of next week, ie 7th September 2001. Please send any comments to the LIR-WG list <lir-wg(a)ripe.net> We propose a joint session to be held at RIPE40 where we can discuss the initial size allocations, information required in the forms and other issues raised by the community after which we will formalise the proposal. Thanks Fearghas EIX-WG Chair -- IPv6 Address Assignment Policy for Internet Exchange Points =========================================================== 1. Abstract ----------- This document describes a policy for Internet Exchange Points (IXPs) under which unique IPv6 address space to be used for the infrastructure of the Internet Exchange Point can be obtained from a Regional Internet Registry (RIR). 2. Background ------------- It has been recognised that there are scenarios in which it is not desirable for IXPs to obtain address space from one of the Internet Service Providers (ISPs) connecting at the IXP. In these cases it is viable to have unique IPv6 address space assigned directly from an RIR. This address space is needed to adress the Exchange fabric. This issue has been brought forward to the RIPE community in May 2000 and has subsequently been discussed at RIPE Meetings and on public RIPE mailing lists. The conclusions of these discussions are described in this document. It is expected that the same policy will be accepted in the ARIN and the APNIC region at which point it will be incorporated in the Global IPv6 Policy document. 3. Definition ------------- An Internet Exchange Point is defined as a physical network infrastructure (layer 2) operated by a single entity with the purpose to facilitate the exchange of Internet traffic between Internet service providers. The number of Internet Service providers connected should at least be three and there must be a clear and open policy for others to join. Addresses needed for other purposes (e.g. additional services provided to the members) should be aquired through other appropriate means ( e.g. an upstream ISP). 4. Policy --------- An IXP that seeks to obtain an IPv6 address assignment by the RIR in its region, needs to submit a request to that RIR. IXPs operating in the RIPE NCC service region should use the 'IPv6 Request Form for Internet Exchange Points' (http://www.ripe.net/ripe/docs/ipv6request-exchangepoint.html). After approval of the request, the RIR will make the assignment. Since the address space does not need to be routable globally and an IXP is expected to only have one subnet, a /64 (64 bits of address space) will be assigned in most cases. In the case the IXP is using multiple fabrics (e.g. unicast separated for multicast), multiple /64s can be assigned to the IXP. IP Address requests can only be handled if the requestor is a Local Internet Registry (LIR) or if the request made through an existing LIR. 5. Other Considerations ----------------------- It should be noted that ISPs usually do not announce address space used on the IXP mesh itself to their peers. That means the address space assigned under this policy is likely not to be routable globally.

10 15