May 2002 - lir-wg - mailman.ripe.net

neutrality and nat
by Randy Bush 22 May '02

22 May '02

i just watched a ripe presentation which claimed to be technology neutral, yet advised isps to use nats without telling how they break applications, blah blah blah. this is not neutral, and is, imiho, really bad advice to give to innocent people. is this ripe or lir policy? randy

14 37

IPv4 Address Allocation policies for organisations not connecting to the Internet
by Peter Emptage 22 May '02

22 May '02

There are a limited number or organisations that for legitimate reasons require globally unique address space apart from rfc1918 private address space, but may not connect to or announce these prefixes on the Internet. Rfc 2050 referenced such situations as seen in the extract below. On a case by case basis, it may be appropriate for these few organisations to become LIRs. Perhaps the IPv4 Address Allocation policy should reference such circumstances as rfc 2050 did? Peter Emptage Senior Consulting Engineer Cisco Systems rfc 2050 extract section 3a Assignment Framework An assignment is the delegation of authority over a block of IP addresses to an end enterprise. The end enterprise will use addresses from an assignment internally only; it will not sub- delegate those addresses. This section discusses some of the issues involved in assignments and the framework behind the assignment of addresses. In order for the Internet to scale using existing technologies, use of regional registry services should be limited to the assignment of IP addresses for organizations meeting one or more of the following conditions: a) the organization has no intention of connecting to the Internet-either now or in the future-but it still requires a globally unique IP address. The organization should consider using reserved addresses from RFC1918. If it is determined this is not possible, they can be issued unique (if not Internet routable) IP addresses.

2 1

RE: IPv4 Address Allocation policies for organisations not connec ting to the Internet
by adrian.pauling＠bt.com 15 May '02

15 May '02

Amending RFC 2050 to reflect Enterprise LIRs is a good idea, particularly as Telcos amongst others have valid reasons for operating Enterprise LIRs. However, as previous manager of an Enterprise LIR and my experience of dealing with large corporates as well as ISPs, I see 2 problem areas; 1) converting some organisations too become Enterprise LIRs is appropriate, but they won't be interested in paying the LIR fees. They already have the assignment, so why should they? :-) 2) RIPE (and ARIN & APNIC) database integrity. How accurate are the records of the RIR databases? ISP LIRs are likely to be better than Enterprise LIRs at maintaining their objects and contact information. Perhaps in the 2050 re-write some recommendations as to regular maintenance of objects to ensure accurate, correct and current operational contacts, with yearly or 2 yearly checks by the RIR, and recovery of address assignments from the Last Resort after a period of time, such as 5 years, should be made. There is also the problem that although Enterprise LIRs are mentioned in RIPE-185, definition of them, their scope, and why they are different, isn't so well documented :-) My views do not necessarily reflect my employers :-) Regards, Adrian F Pauling BT Ignite -----Original Message----- From: Peter Emptage [mailto:pemptage@cisco.com] Sent: 14 May 2002 14:32 To: lir-wg Subject: IPv4 Address Allocation policies for organisations not connecting to the Internet There are a limited number or organisations that for legitimate reasons require globally unique address space apart from rfc1918 private address space, but may not connect to or announce these prefixes on the Internet. Rfc 2050 referenced such situations as seen in the extract below. On a case by case basis, it may be appropriate for these few organisations to become LIRs. Perhaps the IPv4 Address Allocation policy should reference such circumstances as rfc 2050 did? Peter Emptage Senior Consulting Engineer Cisco Systems rfc 2050 extract section 3a Assignment Framework An assignment is the delegation of authority over a block of IP addresses to an end enterprise. The end enterprise will use addresses from an assignment internally only; it will not sub- delegate those addresses. This section discusses some of the issues involved in assignments and the framework behind the assignment of addresses. In order for the Internet to scale using existing technologies, use of regional registry services should be limited to the assignment of IP addresses for organizations meeting one or more of the following conditions: a) the organization has no intention of connecting to the Internet-either now or in the future-but it still requires a globally unique IP address. The organization should consider using reserved addresses from RFC1918. If it is determined this is not possible, they can be issued unique (if not Internet routable) IP addresses.

1 0

Rép. : Re: first allocation
by Jerome Tissieres 14 May '02

14 May '02

Hi group, just one comment on the document ; 5.2.3 Renumbering (...) A period of 3 months is generally accepted, within the RIPE community, to be enough to migrate a network from the old to the new address space. For exceptional cases where the End User requests to keep both assignments for more than three months, an agreement should be obtained from the RIPE NCC for the proposed time frame. 3 months could be enough for a end user but not for an ISP or a hosting services, specially when you need to migrate DNS servers or customers with fixed public IP addresses. I think the "default" time for a LIR should be 6 month. I took part to two renumbering precesses with two differents LIR and, both time, we needed to negotiate more time with RIPE NCC. I think it's wasted time for both parties. Best Regards, Jerome Tissieres Network Engineer ----------------------------------------- Cablecom GmbH IP- NOC Av. de Lausanne 57 CH-1110 Morges http://www.cablecom.net >>> leo vegoda <leo(a)ripe.net> 14.05.2002 17:15:16 >>> Hi Tanja, ripe-185 was published in October 1998. At RIPE 36 the RIPE Community changed the policy so that, like the other RIRs, the minimum allocation size is a /20. See section nine of the minutes at: <http://www.ripe.net/ripe/wg/lir/r36-minutes.html> The IPv4 Address Allocation and Assignment policy document has been re-drafted to incorporate this and other policy changes made since ripe-185 was published. The draft document can be obtained from our web site at: <http://www.ripe.net/ripencc/mem-services/registration/policies/draft-docume…> The review period for this document ends this Friday. If you have any comments on the docuemnts up for review please send them to <lir-wg(a)ripe.net>. -- leo vegoda RIPE NCC, Registration Services Assistant Manager

1 0

first allocation
by Tanja Heimes 14 May '02

14 May '02

Hi All, a simple question: What is the size of a first allocation for a new LIR - a /20 or /19. I found some inconsistency in the documents. Would someone please inform me about the correct size. Thanks, Tanja FAQ ---- When do I receive my /20 allocation? Upon approval of your first request we will first provide you with an allocation* of a /20. RIPE-185 -------- 4.2.First Allocation When a new Local IR starts up, it has no address space allocated to it. The first allocation will be made automatically by the RIPE NCC, generally upon receipt of the first assignment request from the Local IR. Because there is no information about the rate at which a new IR will make address assignments, the size of the first allocation is always a /19 (8192 addresses). -- Tanja Heimes / IP Engineer E-Mail Tanja.Heimes(a)de.cw.com Cable & Wireless Deutschland GmbH TEL. + 49 89 92699-0 Landsberger Strasse 155 Fax. + 49 89 92699-810 D-80687 Munich, Germany web: http://www.cw.com/de

5 5

AW: first allocation
by Hoffmann, Jens 14 May '02

14 May '02

Hi, we are LIR since May 2000. At this time we received a /19 allocation. It seems to be a question of general availability situation in the moment of registration. Kind regards, Jens ===================================================================== DDkom Die Dresdner Telekommunikationsgesellschaft mbH Bereich - IP-Dienste - / Department IP Services AS13270 route 212.80.224.0/19 ===================================================================== > -----Ursprüngliche Nachricht----- > Von: Patrick Evans [mailto:pre@pre.org] > Gesendet: Dienstag, 14. Mai 2002 16:36 > An: Tanja Heimes > Cc: lir-wg(a)ripe.net > Betreff: Re: first allocation > > > On Tue, 14 May 2002, Tanja Heimes wrote: > > > Hi All, > > > > a simple question: > > > > What is the size of a first allocation for a new LIR - a /20 or /19. > > > It's a /20 > > I set up an LIR about a year ago and asked the same question at the > time and was told the documents were being revised to clear up the > inconsistencies. Whether that's happened I couldn't say. > > -- > Patrick Evans > Email: pre(a)pre.org > CV: www.pre.org/pre/cv > Bike: Kawasaki ZXR400L9 (for sale) > >

4 3

Re: IP addresses for the RIPE NCC
by auto347221＠hushmail.com 13 May '02

13 May '02

On Wed, 8 May 2002, Hans Petter Holen wrote: > Dear working Group, > Now that we have a new interim policy in place, an important policy question > comes up: How can the RIPE NCC get IP addresses for their services ? > > Either they qualify trough the Interim policy > > or they need to go to their upstream. > what does it matter? Either way the RIPE NCC is going to be the ones making the final decision, be it a hostmaster or one of their tech staff.... -p

8 10

Draft IPv4 and AS Number policy documents (review deadline extension)
by Paul Rendek 10 May '02

10 May '02

Dear Colleagues, At the RIPE 42 LIR Working Group meeting it was decided to extend the review deadline for the set of draft IPv4 and AS Number policy documents. The draft documents will be available for comments and suggestions until Friday, 17 May 2002. The set of draft documents are available at: http://www.ripe.net/ripencc/mem-services/registration/policies/draft-docume… Any feedback should be sent to: <lir-wg(a)ripe.net>. Regards, Paul Rendek RIPE NCC

1 0

RE: IP addresses for the RIPE NCC
by Guy Davies 09 May '02

09 May '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > -----Original Message----- > From: Pim van Pelt [mailto:pim@bit.nl] > Sent: Thursday, May 09, 2002 10:39 AM > To: Gert Doering > Cc: Randy Bush; lir-wg(a)ripe.net > Subject: Re: IP addresses for the RIPE NCC > [..snip..] > > | What is "the 6bone" anyway? > I find it strange that somebody who is at ripe meetings presenting > routing table information (and brokenness) never took the time to > actually find out what 'these weird 3ffe' addresses are! Gert was teasing. He knows full well what the 6bone is, having taken an active part in it from an early stage. Guy -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.1 iQA/AwUBPNpEvY3dwu/Ss2PCEQLLPACgktR3g3IFWgc1sWJ1iDSuwRJ5xOoAnjRS fzFSfZuXfS+EGQCf0hA/MA2s =+1U3 -----END PGP SIGNATURE----- This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavors to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us.

3 2

FW: Moving Forward: Call for Volunteers (editing/drafting)
by Mark McFadden 09 May '02

09 May '02

I posted this to the 2050-wg list that is working on redrafting RFC 2050. I'm also posting a copy here to the LIR working group so that it gets wider distribution. I hope that those in the RIPE community interested in the redrafting of RFC 2050 will volunteer to participate in the small editorial/drafting teams. Mark Mark McFadden 21st Century Texts Internet Infrastructure Consulting for a New Century Madison Wisconsin mcfadden(a)21st-century-texts.com -----Original Message----- From: 2050-wg-request(a)arin.net [mailto:2050-wg-request@arin.net] On Behalf Of Mark McFadden Sent: Thursday, May 09, 2002 9:57 AM To: 2050-wg(a)arin.net Subject: Moving Forward: Call for Volunteers (editing/drafting) All: With the conclusion of the RIPE meeting last week in Amsterdam there have been presentations at each RIR and the ASO General Assembly on the plan for redrafting RFC 2050. In each case I've made a call for comments on the proposed principles and the proposed series of documents. It's easy to summarize the comments on the document series: there was very little. Instead, many comments surrounded how to publish the documents. Some suggested that the resulting documents be presented as IETF Informational RFCs. It seems to me, based on the input I've received, that we can proceed with the drafting of some of the documents BEFORE we agree HOW they are to be published. What I'd like to do now is put out a public call for volunteers to work on small editorial teams to draft initial versions of the new documents. The goal would to be to draft initial versions, submit them to this and other appropriate lists, and present them at upcoming RIR meetings. I've listed below the entire series of documents that have been proposed. Now, I'd like to build small, volunteer groups who would be willing to work on drafting initial documents for the series. In particular, I'd like to have volunteers for: IP-ADDRdoc 1: INSTRUCTIONS TO EDITORS AND AUTHORS OF IP-ADDRdocs; IP-ADDRdoc 2: A GUIDE TO ADDRESSING POLICY, ALLOCATION, AND PRINCIPLES; IP-ADDRdoc 3: THE PRINCIPLES OF IP ADDRESS ALLOCATION FOR IPv4; and, IP-ADDRdoc 5: THE PRINCIPLES OF AS NUMBER ASSIGNMENT If you would like to volunteer for work on the drafting/editing of these documents -- and I hope you do -- please reply to this email with an indication of which of the documents you would like to work on. I hope to have small teams assembled in a week or so. Thanks, the entire document series is pasted below. Mark Mark McFadden 21st Century Texts Internet Infrastructure Consulting for a New Century Madison Wisconsin mcfadden(a)21st-century-texts.com To review, the proposed document series has the following documents: --------------------------------------------------------------- RFC 2050 REPLACEMENT DOCUMENT SERIES (ADDRESSING POLICY AND RIR FRAMEWORK) "IP-ADDRdocs" --------------------------------------------------------------- IP-ADDRdoc 1: INSTRUCTIONS TO EDITORS AND AUTHORS OF IP-ADDRdocs A document describing the purpose of the documents. How each document is to be formatted, written, approved and published. A METAdocument for the IP-ADDRdoc series. IP-ADDRdoc 2: A GUIDE TO ADDRESSING POLICY, ALLOCATION, AND PRINCIPLES A guide intended to provide an introduction to IP addressing policy, the organization of the regional registries, and the RIR hierarchy to individuals and organizations not intimately connected to the RIRs. Tutorial in nature, this document would also provide a glossary to commonly used terms at the RIRs and in addressing policy in general. Much of the content for this section replaces Section 1 of RFC 2050 and puts it into a "readable," user-friendly form. IP-ADDRdoc 3: THE PRINCIPLES OF IP ADDRESS ALLOCATION FOR IPv4 This is also part of the original RFC in section 1, but could easily stand on its own. The document would also describe (or provide pointers to information about) addressing decisions that address special cases in IPv4. This will certainly include private address space (with a pointer to the appropriate RFC) and multicast. It might include other instances where special or reserved assignments have been made (either by IANA or by the RIRs). IP-ADDRdoc 4: THE PRINCIPLES OF IP ADDRESS ALLOCATION FOR IPv6 Self-explanatory, but in the wake of a recent RIPE meeting, a potentially challenging document to write. IP-ADDRdoc 5: THE PRINCIPLES OF AS NUMBER ASSIGNMENT Self-explanatory. IP-ADDRdoc 6: CRITERIA GUIDELINES FOR IPv4 ADDRESS ALLOCATION This is a reworking of Sections 2 through 4 of RFC 2050. Special attention would be paid to the common criteria used in all registries with pointers to RIR operational documents. This document would also define critical terms, such as "engineering plans," "assignment history," "utilization rate," and so forth. IP-ADDRdoc 7: REVERSE MAPPING SERVICES FOR IPv4 Self-explanatory. This document would be a replacement for RFC 2050's section 5 and document the architecture and maintenance of IN-ADDR.ARPA. IP-ADDRdoc 8: ADDRESSING AND NUMBERING ORGANIZATIONS AND RELATIONSHIPS This document would include a description of the RIRs, IANA, ICANN, and the IETF. The document would document the relationship between the RIR's and ICANN (a pointer to the MoU and explanatory text), the mechanism by which new registries come into existence (or a pointer), the relationship between RIRs and the ASO, and the relationship between the RIRs and the IETF. This document would also replace the "Right to Appeal" section of RFC 2050's Section 6. The document would also provide pointers to previously published documents regarding the procedures under which the ICANN Address Council and Address Supporting Organizations work. These pointers may include documents that define the relationship between the AC, ASO and the RIRs.

1 0