- eix-wg - mailman.ripe.net

Re: IPv6 request form for Internet Exchange Points
by Nurani Nimpuno 23 Aug '01

23 Aug '01

All, When concluding the discussion on IPv6 addresses for IXPs, the RIPE NCC were under the impression that participants in the discussion felt that they had had ample time to discuss the final proposed policy. Mirjam sent out a summary on the lists 28 June 2001 after the intense discussion both at the last RIPE meeting and on the mailing lists. (http://www.ripe.net/ripe/mail-archives/lir-wg/20010401-20010701/msg00 228.html) There were a few comments on actual wording that Mirjam took into account, but no further discussion. No objections were raised to the proposed definition. The RIPE NCC has several pending requests for IPv6 address space from IXPs that have been waiting since April. After such lengthy discussion and no further input from the community, we therefore felt that it would be appropriate to move forward and implement the concluded policy in order to meet the need of these LIRs. We do of course recognise the great importance of ensuring that the policy that the RIPE NCC implements is the one agreed upon by the community. This is essential. We also recognise the need for improving the co-ordination between the working group chairs and the RIPE NCC. We hope to discuss this further with the chairs. Some comments have been made on the list suggesting the RIPE NCC to not further postpone the evaluation of the currently pending IXP requests. If this reflects the general feeling in the community, then the RIPE NCC is ready to move forward and do so. If however, there is a need for further discussion, then we wish to encourage everyone to actively contribute with their comments. I hope that there is no need to postpone this discussion until the RIPE 40 meeting in October. I trust the working group chairs to propose a way forward that will ensure a fair and correct conclusion of this discussion. Kind regards, Nurani *--------------------------------------------------------* | Nurani Nimpuno <nurani(a)ripe.net> | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *--------------------------------------------------------* "Hans Petter Holen" <hph(a)online.no> writes: * | Agreed!!! I understand the need to ensure complete consensus regarding * | allocation, but *please* can we aim for a temporary work around to allow * | us to get an allocation using the existing document. * | * | We could review the interim allocations once the consensus is finally * | reached, and supply any new information then _if_ needed. But as Robert * | says, this has gone on far too long already! * * Would this be a way to proceede; * introduce the procedure proposed by Nurani as an interim procedure * in order to get this thing rolling ? * * Nothing is worse than technology and customers waiting for politicians * to make up their mind... * * * -hph *

1 0

RGMP submission to the IETF.
by Steve Walker 21 Aug '01

21 Aug '01

All, Thought you might find this info I received from Steve Simlo at Cisco to be of interest to you: RGMP is now published as an IETF draft and can be found at: http://search.ietf.org/internet-drafts/draft-wu-rgmp-01.txt As you know RGMP is a released IOS feature and is documented here: ftp://ftpeng.cisco.com/ipmulticast.html#RGMP Cisco intends to pursue this as the standard mechanism of interconnecting Layer 2/3 devices at MIXs since it offers great scalability and will not be impacted by future modifications to the PIM protocol spec. Regards, Steve.

1 0

New Document available: RIPE-224
by RIPE NCC Document Announcement Service 16 Aug '01

16 Aug '01

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Short content description ------------------------- This document contains the set of templates to be used when submitting an "IPv6 Request Form for Internet Exchange Points". Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-224.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-224.txt plain text version You can also access the RIPE documents in HTML format via WWW. RIPE-224 is available from the WWW at the following URL: http://www.ripe.net/docs/ipv6request-exchangepoint.html

1 0

Incomplete Arpa
by Saher 15 Aug '01

15 Aug '01

Dear sir : I have a question for you when exactly do i get an incomplete arpa on the cisco router for pc's noting that they r closed not open and how to prevent it. Thank you Saher

1 0

Fwd: Re: 90 IPv6 sub-TLA allocations made
by Fearghas McKay 09 Aug '01

09 Aug '01

This will also include a section for IXP IPv6 allocation. This will hopefully be seperate from the main EIX-WG meeting as the schedule for it is fairly full currently. If anyone want to present please contact David directly. f --- begin forwarded text Delivered-To: lists-lir-wg-out(a)lists.ripe.net X-mProtect: Thu, 9 Aug 2001 06:06:48 -0700 Nokia Silicon Valley Messaging Protection Date: Thu, 9 Aug 2001 06:02:44 -0700 From: David Kessens <david(a)IPRG.nokia.com> To: Gert Doering <gert(a)space.net> Cc: Stephen Burley <stephenb(a)uk.uu.net>, lir-wg(a)ripe.net, ipv6-wg(a)ripe.net Subject: Re: 90 IPv6 sub-TLA allocations made Sender: owner-lir-wg(a)ripe.net On Thu, Aug 09, 2001 at 11:18:15AM +0200, Gert Doering wrote: > > As far as I remember the IPv6 policy discussions on the last RIPE meetings, > one thing that was voiced repeatedly was > > "if we have to hand out /48's to customers, a /35 for the LIR itself > is not enough" For your information: We are currently planning a joint session for ipv6 allocation policy issues for the next RIPE meeting. It would be really nice if we can get volunteers from the community who can give a brief presentation on possible solutions. The problem description is pretty clear by now, however, I have not seen any (public) proposals yet on how to solve it. Obviously, there are multiple ways to deal with the issue and it would be nice to discuss advantages and disadvantages of different solutions. David K. --- --- end forwarded text

1 0

Draft Agenda for RIPE 40 in Prague
by Fearghas McKay 29 Jul '01

29 Jul '01

As ever additional items and suggestions always welcome. EIX-WG RIPE 40 Prague, Czech Republic Draft Agenda Agenda Bashing Attendee List IXP presentations - Provisional list: late presentations are always welcome! LINX AMSIX SFINX DECIX CIXP VIX LoNAP Espanix NetnodIX Xchange Point TIX NIX.CZ BNIX ** New Presenter - new IXP presentations are encouraged. RIPN - Russian Institute for Public Networks who coordinate the Moscow Internet Exchange. Multicast in IXPs - Christian Panigl Euro-IX Report and Update - TBA Switching List Update - Mike Hughes Best Current Practice - Nic Lewis Joint Session with IPv6 and LIR to discuss IPv6 allocations for IXPs AOCB -- See you in Prague! Regards Fearghas

1 0

IPv6 for IXPs
by Mirjam Kuehne 02 Jul '01

02 Jul '01

Dear all, how about this (thanks to Henk): Definition: 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 assigned by upstream ISPs. Assignment size: - a /48 in most cases - a /64 if it is known that there will only be one subnet (basically following the IAB recommendation) Additional warning: The RIRs should warn the IXP that it is strongly discouraged to announce the addresses and that they will likely not to be globally routable. If this is agreeable the RIPE NCC will implement this policy and co-ordinate it with the other Regional Internet Registries. Mirjam Kuehne RIPE NCC

6 7

IPv6 for IXPs
by Mirjam Kuehne 29 Jun '01

29 Jun '01

Dear all, After the active discussion regarding IPv6 address for Internet Exchange Points (IXPs), we now need to come to a conclusion. I have reviewed the discussion again and will try to summarise it (quite a challenge :-). Many issues were raised, but so far no clear consensus was reached. Please bare with me if I have not included all opinions and comments or if some submissions are not summarised accurately. However, I hope that this summary will spark some further discussions and hopefully a conslusion at the end. I cc the eix-wg mailing list here and would like to explicitely encourage IXP operators to actively participate in this discussion. Kind Regards, Mirjam Kuehne RIPE NCC ---------- The following questions were raised during the discussion: 1. Is a special policy needed for IXPS (and following from this possibly also for other 'special purposes'? 2. What is the intended use of the addresses at the IXPs? 3. How is an IXP defined? 4. What size should be assigned? 1. special policy needed? ------------------------- Many participants believed that a policy for IXPs is needed, because they usually do not have an upstream provider and also do not want to use addresses from one of their members (for political rather than technical reasons). Some participants however felt that no special policy is needed for IXPs. They should either be treated as an end-user network or should be able to get a 'normal' (currently a /35) IPv6 allocation from the RIRs. 2. intended use of the addresses? ---------------------------------- Special policy would only be needed for addresses needed for the Exchange Point medium itself (usually a layer-2 network). Addresses needed for other purposes (e.g. additional services provided to the members) should be assigned by upstream ISPs. It was also discussed if the addresses should actually be announced. It was felt that this is not really necessary, but that some IXPs do it anyway. There was no conclusion if this should be part of the policy (e.g. the micro-allocation policy implemented in the ARIN region does require that the prefix is not announced). One option would be to warn the IXP that these addresses are likely not to be globally routable. 3. definition of an IXP ----------------------- It was generally felt that it is difficult to define an IXP, but that the following refined definition could be used as a starting point: Three or more ASes and thee or more separate entities attached to a LAN (a common layer 2 infrastructure) for the purpose of peering and more are welcome to join. 4. assignment size? ------------------- Some participants felt that a /64 would be appropriate if the IXP would consist of only one subnet. In all other cases a /48 should be assigned (this would be consistent with the IESG/IAB recommendation). Others felt that the address size should not be pre-defined, but should be based on need and discussed on a case-by-case basis between the requestor and the RIR. 5. Other issues raised ---------------------- Requests should only be sent by established LIRs or via an existing LIR. Reverse delegation would have to be done by the RIR (requested also via an existing LIR)

10 18

IPv6 addresses for IXPs
by paul.mylotte＠bt.com 29 Jun '01

29 Jun '01

In the RIPE Policy Statement under development I think we should state explicitely the support for both types of IPv6 exchanges, viz: 1 allocate addresses for IPv6 exchange infrastructure only (no > onwards allocation in the manner of a backbone ISP). > 2 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). > 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. > > > > Regards, > > Paul > > P. S. Mylotte > 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 priveleged 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. >

1 0

RE: IPv6 for IXPs
by Wilfried Woeber, UniVie/ACOnet 26 Jun '01

26 Jun '01

>To: lir-wg(a)ripe.net >CC: eix-wg(a)ripe.net >Subject: IPv6 for IXPs >Date: Tue, 26 Jun 2001 12:22:51 +0200 >From: Mirjam Kuehne <mir(a)ripe.net> > >Dear all, > >After the active discussion regarding IPv6 address for Internet >Exchange Points (IXPs), we now need to come to a conclusion. I have >reviewed the discussion again and will try to summarise it (quite a >challenge :-). Many issues were raised, but so far no clear consensus >was reached. > >Please bare with me if I have not included all opinions and comments >or if some submissions are not summarised accurately. > >However, I hope that this summary will spark some further discussions >and hopefully a conslusion at the end. > >I cc the eix-wg mailing list here and would like to explicitely >encourage IXP operators to actively participate in this discussion. > >Kind Regards, > >Mirjam Kuehne >RIPE NCC >---------- > >The following questions were raised during the discussion: > >1. Is a special policy needed for IXPS (and following from this > possibly also for other 'special purposes'? >2. What is the intended use of the addresses at the IXPs? >3. How is an IXP defined? >4. What size should be assigned? > > >1. special policy needed? >------------------------- > >Many participants believed that a policy for IXPs is needed, because >they usually do not have an upstream provider and also do not want to >use addresses from one of their members (for political rather than >technical reasons). I strongly feel that leaving the term "political reasons" in here (and maybe even allow that to creep into some archive procedural description is setting off a time bomb! The "weakest" term I would accept (instead of requiring _technical_ reasons from the beginning) is "for reasons of stable operations"). >Some participants however felt that no special policy is needed for >IXPs. They should either be treated as an end-user network or should >be able to get a 'normal' (currently a /35) IPv6 allocation from the >RIRs. > > >2. intended use of the addresses? >---------------------------------- > >Special policy would only be needed for addresses needed for the >Exchange Point medium itself (usually a layer-2 network). Addresses >needed for other purposes (e.g. additional services provided to the >members) should be assigned by upstream ISPs. I fully agree with that, but at the same time this requiremet weakens the overall reasoning. Just as an observation. >It was also discussed if the addresses should actually be >announced. It was felt that this is not really necessary, but that >some IXPs do it anyway. There was no conclusion if this should be part >of the policy (e.g. the micro-allocation policy implemented in the >ARIN region does require that the prefix is not announced). > >One option would be to warn the IXP that these addresses are likely >not to be globally routable. I really like the proposal by Robert.Kiessling: "strongly discouraged to announce the addresses and likely not to be globally routable"? >3. definition of an IXP >----------------------- > >It was generally felt that it is difficult to define an IXP, but that >the following refined definition could be used as a starting point: What do you intend by saying "as a starting point"? >Three or more ASes and thee or more separate entities attached to a >LAN (a common layer 2 infrastructure) for the purpose of peering and >more are welcome to join. For the moment this seems to take care of the situations mentioned during the meeting. However, it might be too fuzzy in general - and too specific as regards the transport mechanism for the packets being exchanged according to the peering agreement. E.g. I might agree with 2 of my students to build an exchange point for IPv6 packets, but we would prefer to use the existing IPv4-based internet as a transport mechanism. Would that be compatible with "(a common layer 2 infrastructure)"? I don't have a better proposal for the moment, unfortunately, but I would like to see (hear :-) people think about those aspects. >4. assignment size? >------------------- > >Some participants felt that a /64 would be appropriate if the IXP >would consist of only one subnet. In all other cases a /48 should be >assigned (this would be consistent with the IESG/IAB recommendation). > >Others felt that the address size should not be pre-defined, but >should be based on need and discussed on a case-by-case basis between >the requestor and the RIR. Go for the provisions as outlined in the IAB/IESG Recommendation, and if in doubt, assign the bigger block. >5. Other issues raised >---------------------- > >Requests should only be sent by established LIRs or via an existing >LIR. Please s/should/must/ !! >Reverse delegation would have to be done by the RIR (requested also >via an existing LIR) Agreed. 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1