- lir-wg - mailman.ripe.net

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

Fwd: IN-ADDR.ARPA Progress Report
by Joao Luis Silva Damas 02 Jul '01

02 Jul '01

Dear all, here I forward an announcement from ARIN regarding current progress in the maintainance of the in-addr.arpa zone. Best regards, Joao Damas RIPE NCC >From: ARIN IN-ADDR Role <inaddr(a)arin.net> >Subject: IN-ADDR.ARPA Progress Report >Message-ID: <Pine.SOL.4.05.10106291525050.10191-100000(a)ops.arin.net> > >Goal: > >Reduce the size of the IN-ADDR.ARPA zone file. This file will be reduced >in size by only containing name servers for /8 networks. > > >Completed Steps: > >Apr 2001 - Established relationships with 2 companies to provide >independent server networks for all ARIN IN-ADDR zone files. > >Jun 2001 - Released a new IN-ADDR.ARPA zone file generator to correct >existing erroneous data. > > >Next Step: > >July 9, 2001 - ARIN will begin revising the IN-ADDR.ARPA zone for those >direct /8 delegations to ARIN. These /8 zone files will be serviced by >the two ARIN nameserver networks. These changes will not affect the >performance of reverse lookup in any of the IPv4 Address space. > >Please direct any questions to inaddr(a)arin.net. > > >Ginny Listman >Director of Engineering >American Registry for Internet Numbers --

1 0

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

IPv6 for IXPs
by Mirjam Kuehne 27 Jun '01

27 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)

5 4

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

IPv6 addresses for Exchange Points
by Robert Kiessling 25 Jun '01

25 Jun '01

The discussion on the issue of IPv6 allocations for exchange points seems to stagnate, and to me it looks like an agreement might be close. Could we expect a new suggestion from RIPE incorporating the previous discussion, together with remaining open questions? Exchanges have been waiting for many months, so a solution is overdue. Robert

2 1

Unprocessed update mails to RIPE Whois Database
by RIPE Database Administration 25 Jun '01

25 Jun '01

Dear Colleagues, [apologies for duplicate messages] Between Thu Jun 14 16:19:15 2001 CEST and Fri Jun 15 10:34:29 2001 CEST, due to a failure in our systems which processes updates to RIPE Whois Database, the update message have not been processed, instead they were only stored. Most of the users who sent those messages noticed that they didn't get any acknowledgement from our system, and re-sent their updates. Realizing the failure on Friday Jun 22, we tried to find out those messages which were _not_ re-sent by the user, and we processed them. Thus, please don't be confused if you've got a late acknowledgement message. If you have any questions about the incident, please contact <ripe-dbm(a)ripe.net>. We are sorry about the inconvenience this caused. Best Regards, Engin Gunduz RIPE NCC Database Group

1 0

Re: Modifying references to contact info in the RIPE DB
by Wilfried Woeber, UniVie/ACOnet 24 Jun '01

24 Jun '01

Hi Joao! >If the reference is by name then when I query the DB I will get the list of >persons with that name, right? Right. >Whether the object belongs to the person or not is not going to save this >person from being contacted. From the point of view of the database and the >user querying it, the object belongs to that person. Right >The link is via a name. > >Now we substitute the reference by name with a reference by nic handle >pointing to the same person. >What is the difference? > >ALMOST NONE except that: True, for the case where there is a strict one-to-one mapping, e.g the recursion using the name returns *one* object. What do you suggets to do with the case where the recursion, based on the names, returns a *set* of objects? I can see 2 approaches (at least): - do not perform the handle substitution for that referring object and put it on the list of those requiring human intervention - expand the xxxx-c: list (which? the tech-c:?) to refer to *all* objects, but by ref'ing their handles While human beings are quite clever in selecting the "proper" instance of a person: object (by looking at country, address, email,...) a script might be quite clueless with that respect :-) Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------

3 3

AW: Initial PA Allocation Criteria
by Koepp, Karsten 22 Jun '01

22 Jun '01

Hans Petter and all, I am not quite determined about the alternative. Yes, I think the initial requirement needs to be less then the /22, admitting that the situation will then not change dramatically, because a /24 is easy to prove. Concerning Dave's proposal: >Perhaps a clause to permit allocations to organisations that provide or can >prove intent to provide commercial services to third parties should be added. Who else is applying for a LIR? Couldn't everybody claim that? What about the already raised proposal to set-up a usage criteria and to (maybe bi-annually) revise allocations? Could that be handled from the NCC? And are we gonna have a further increase of LIR applications over the years to come? Is it worth it? More questions then answers. Regards Karsten > Von: Hans Petter Holen [SMTP:hph@online.no] > Gesendet am: Donnerstag, 21. Juni 2001 13:52 > An: Koepp, Karsten; lir-wg(a)ripe.net > Betreff: Re: Initial PA Allocation Criteria > > | after having read several opinions in this thread, > | I still don't agree to some points. I do think, > | the policy as proposed would represent a drawback > | for start-ups entering the market. > > But how do you propose to deal with that ? > Lower the initial requirement to some lower percentage ? > > -hph >

2 1

ARIN to Allocate from 67.0.0.0/8 and 68.0.0.0/8 (fwd)
by Sabrina Waschke 21 Jun '01

21 Jun '01

Dear all, [Apologies for duplicate messages] Please see below ARIN's announcement of their new allocations. Kind regards, Sabrina Waschke Registration Services Operations Manager RIPE NCC ------- Forwarded Message Date: Thu, 21 Jun 2001 08:35:57 -0400 From: "Richard Jimmerson" <richardj(a)arin.net> To: <arin-announce(a)arin.net>, <nanog(a)nanog.org>, <apops(a)apnic.net>, <eof-list(a)ripe.net>, <afrinic-discuss(a)afrinic.org> Subject: ARIN to Allocate from 67.0.0.0/8 and 68.0.0.0/8 In the near future, ARIN will begin making allocations from 67.0.0.0/8 and 68.0.0.0/8. This will include allocations of /20 and shorter prefixes, according to ARIN's minimum allocation policy. For informational purposes, a list of ARIN's currently administered blocks can be found at http://www.arin.net/regserv/IPStats.html Regards, Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) ------- End of Forwarded Message

1 0