September 2003 - address-policy-wg

Proposed Open Letter to ICANN and Related Documents
by Axel Pawlik 13 Oct '03

13 Oct '03

Dear Colleagues, The Regional Internet Registries (RIR) have published three (3) documents: a. Proposed Open Letter to ICANN from the Regional Internet Registries b. Proposed Agreement between the RIRs to create the Number Resource Organization c. Proposed Agreement between the RIRs (acting through the NRO) and ICANN concerning the Address Supporting Organization These documents are available on a single web page at: http://www.ripe.net/ripencc/about/regional/draft-public-comment.html In order to ensure that RIR members and address communities in every region have the opportunity to comment, the Board of the RIRs have requested that RIRs post the documents for a period of 30 days. The comment period closes at midnight (UTC) on the 22nd October 2003. Each of the RIR Boards will consider the comments as they are received, and each RIR Board intends to make a decision whether to adopt these documents following this comment period. If these documents are adopted by all the RIR Boards, it is the present intention to formally pass the following open letter to ICANN on the 24th of October. On the same date the Boards of the RIRs currently intend to direct their CEOs to sign the MoU concerning the establishment of the Number Resource Organization. All comments should be addressed to: nro-comments(a)apnic.net. The comments will be passed to all the Boards of the RIRs, and will also be published on the web site http://www.apnic.net/nro-comments. Any dialogue that arises from such comments will also be published on this site. Subscription information for the nro-comments mailing list is available at: http://mailman.apnic.net/mailman/listinfo/nro-comments All postings to this mail address (nro-comments(a)apnic.net) are public, and will be published at the following URL: http://www.apnic.net/nro-comments kind regards, Axel Pawlik Managing Director RIPE NCC

2 1

Revised Draft Document for review: "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region"
by Dominic Spratley 06 Oct '03

06 Oct '03

Dear Colleagues, The RIPE NCC is pleased to announce an updated draft of the revised RIPE IPv4 policy document, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" (currently ripe-234). The major change from the draft published on 21st July is that the existing "status:" attribute values are kept for inetnum objects with the addition of a new value for sub-allocations. The updated draft can be downloaded from the "Drafts" section in the RIPE Document Store, found at: <http://www.ripe.net/ripe/draft-documents/> The major updates to the current policy text in this draft IPv4 policy document are: - Recent policy changes have been incorporated, including the policy allowing assignments for Internet experiments and the sub-allocation policy. - Wording has been improved to make it easier to read. - The explanation of how to use the database has been removed as a separate "RIPE Database User Manual: Getting Started" was published in September last year. - The document now incorporates the text from "Provider Independent vs Provider Aggregatable Address Space" (ripe-127). If the community accepts this document it will replace the existing IPv4 Policy document (ripe-234) and the "Provider Independent vs Provider Aggregatable Address Space" document (ripe-127). Feedback on this document should be sent to the address-policy-wg@localhost mailing list for a period of two weeks. This review period will end on TWO WEEKS FROM ANNOUNCEMENT. Dominic Spratley Registration Services Manager RIPE NCC

2 1

RE: [address-policy-wg] Re: [ncc-services-wg] Request Forms: upda ted and available on LIR Portal
by Bornhorst, Ludger 25 Sep '03

25 Sep '03

Hi Christian, > The question is how complex an evaluation must be? The facts needed to > evaluate a normal IP requests are simply the number of nodes needing a > public IP address. In case one or more nodes needs more than 1 IP address > then documentation is needed to explain why to exceed the normal rules, also > in case the expected growth pr. year exceeds 100%. Yes, but I don't have any problem to ask endusers about their (planned) hardware and to document their needs in the way we've done it since several years now, like "We have 20 PC's, 5 routers, 200 dial-in-ports and so on..." This general information will (in most cases) be sufficient to evaluate IP requests. > It would of course be easier to falsify the number of nodes than to falsify > the documentation, but in case an end user intends to falsify information in > order to get more IP addresses than justifyable, then I don't see any easy > way to prevent this. Right, but there are still enduser who don't know about classless addressing. That means they are asking for "Class-C" nets just because they think its hip. So I think it's responsibility of the LIR's to tell this endusers about CIDR and its outcomes. And, yes I agree: If an enduser wants to cheat at you, I can't see a way to prevent this. > I would find it reasonable if larger requests still required some form of > documentation, for example /24 and above. But it would of course still be > very important for all LIRs to stress that the information received from the > enduser must be correct. ACK! This way it would be possible to serve the main part of the customers at a simple level and only ask reasonable questions (hardware documentation) if the request exceeds a certain level. I would like to stress that the /24 border should be the maximum limit of "freedom" given here. Maybe it's better to decrease this "HW-documentation-border" down to /25 or /26 ? What do you think? mit freundlichen Gruessen/with best regards Ludger Bornhorst ______________________________________________________________________ Deutsche Telekom AG T-Com Headquarters Network Information Center Ammerlander Heerstr. 138, D-26129 Oldenburg Hotline +49 441 234 4581 (phone) +49 800 3301180 +49 441 234 4589 (fax) +49 800 3301179 ludger.bornhorst(a)telekom.de (mail) dk.call-center(a)telekom.de

2 1

Re: [address-policy-wg] Re: [ncc-services-wg] IPv6 applications (was: Request Forms: updated and available on LIR Portal)
by Gert Doering 02 Sep '03

02 Sep '03

Hi, On Tue, Aug 26, 2003 at 12:57:13PM +0200, Dominic Spratley wrote: > You both made several points and I hope I can explain our thinking on them > for you. We think these new forms represent a change in the way we provide > services to LIRs so we've addressed this answer to the NCC Services WG list. > We don't think they represent a change to the RIPE community's policy. Actually, I tend to disagree, at least for some parts. Which is why I've put the APWG list back into the CC: (sorry for duplicates). Some of the criticism voiced is that the NCC is asking questions and enforcing rules that are more strict than what the policy demands - and this is certainly relating to policy. [..] > You asked about the requirement for a network diagram to be supplied when > requesting an IPv6 allocation. There are two reasons for this. Firstly, the > RIPE NCC has not yet made yet 250 IPv6 allocations. Our experience with IPv6 > networks is limited and we need network operators to show us how they intend > to use IPv6 address space in their networks. I agree with the assessment that "more experience for the NCC is a good thing". On the other hand, many startup IPv6 deployments are extremely trivial ("one access server with 1000 DSL circuits, serving /48s to DSL end users" would certainly qualify for the policy requirements). So I don't think it's appropriate to enforce this "you send us an interesting picture, otherwise you won't get an IPv6 allocation" approach. Make it optional. > Secondly, the current IPv6 > policy does not allow stockpiling of IPv6 address space. One way of > distinguishing a genuine request from one that is intended for stockpiling > reasons is to request a diagram showing how the address space will be used. > It doesn't have to be a a fancy diagram. It's also fine to fax a hand-drawn > diagram instead of sending one by e-mail. When we have more experience with > IPv6 I expect we will make the diagram optional. This is "conservationism striking again", and this is BAD. The idea behind the current policy is "make IPv6 address blocks available to anybody who is asking for them" (and can reasonably claim 200 future IPv6 customers). For that, you don't *need* a fancy network, so why do you have to demonstrate it at all? What are you worrying about? Address wastage is really not a problem right now. Obstacles on the way to IPv6 deployments are a problem, and we don't want the NCC to be an obstacle. Now come and flame me :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55575 (56535) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

2 1

Re: [ncc-services-wg] Request Forms: updated and available on LIR Portal
by Sascha Lenz 02 Sep '03

02 Sep '03

Hay, On Thu, Aug 21, 2003 at 04:02:16PM +0200, Dominic Spratley wrote: > Hi Daniel, > > I hope I can clarify some of your points below: actually i didn't really want to get into this discussion, but it looks like _noone_ else has anything to say about the issues Daniel raised? Than can't be since he is right in most points. > At 03:37 AM 8/21/2003 +0200, Daniel Roesen wrote: [...] most points have been more-or-less clearified by Dominic's answer, but: > >- [EQUIPMENT DESCRIPTION] > > > > This requirement _can't_ be meant serious. We're not on April 1st, > > are we? The silliness of such information requirement was already > > recognized within the IPv6 allocation realm, so why introducing it > > now again for IPv4? > > This is a difficult one as it does require the LIR to do more preparation on > their side. The less time a Hostmaster spends sending E-mails asking > for additional information, the sooner the LIR gets their requested resource. > Asking for the type of equipment used really helps the Hostmaster > understand what and why IP addresses are being requested. ... i still have a problem here if that should be a "must provide this information". I have no much problems with questions like "why-pi" or "routing-reasons" because they can obviously be answered with standard phrases (which renders them useless again, but if RIPE NCC sees that many "bad" requests from many LIRs (aren't they trained?), it's OK for me, no much work, no stupid questions). BUT... information like the equipment being used or a network plan or so _must_ be optional information, not _required_ information. It can't be that a company is _required_ to make statements about their network and equipment if they want to have IP-Adresses! (and no, RIPE doesn't always qualify for receiving such information). Besides that it's way too much work to fill that in seriously for big requests, and doesn't really make sense for small requests. This should be _optional_ information in cases where it's needed to explain an unusual request, whatever, "we have only one machine but it has 500 IP Adresses due to this and that special purpose which can't be handled otherwise due to these and those hardware and software limitations". Is it really only me who is of that opinion, or noone recognized this problem or doesn't think it's a problem? Or isn't it meant as _required_ information anyways and a "N/A" is enough in most cases as answer to this part of the request? ...curious. The reason i noticed that this might get a problem was due to the unholy [...] #[REQUIRED INFORMATION]# [...] % % 2. Please provide a network diagram in PostScript or JPEG % format showing your IPv6 network. Submission instructions % can be found in the RIPE document "Supporting Notes for the % Initial IPv6 Allocation Request Form in the RIPE NCC Service % Region" found at: % % http://www.ripe.net/ripe/docs/ipv6-support-initial.html % % The diagram should indicate expected completion dates of % construction as well as how much IPv6 address space is % expected to be used in each subnet. % % [...] in the (old and new) IPv6 Initial Allocation request form. Since it says "required information" there, i already assumed that it might get a problem to get the IPv6 Allocation for us without providing this one. But i didn't see the point in doing so if i can make our network plans clear in text form, and explain the reasons why a network diagram for an IPv6 network is _completely_useless_ in general at the moment and especially in our case. Though, even on my 2nd mail on that request i just got the reply from some RIPE Hostmistress that "the inability to provide this network topology map calls into question the need for the IPv6 addresses being requested.". At the moment i'm really mad about this. We are currently prevented from deploying IPv6 addresses immediately because i don't have any Windows PC with Viso or something at hand, let alone the time to paint a very useless topology of our IPv6 overlay network, though i explained it in detail in text. (Not to mention that the statement that an active LIR which assigns IPv4 addresses for years is questioned that it will assign IPv6 addresses just because it doesn't like to waste time on painting network maps of some routers and tunnels is VERY doubiously to me.) Why the hell is such information _required_? Information about what equipment being used and a network topology map on a picture might be additional information at best. I fear that IP(v4) request will be denied or at least delayed in future if the RIPE Hostmasters are gonna complain about missing or unsatisfying information about the equipment in the future, too. That's not acceptable i think. But i might be wrong, we're realatively small and don't have that many requests in general, i just wonder why noone of the "big LIRs" sees this problem? You all have AWs that big that you don't care about filling in RIPE forms anyways and have payed managers to paint network diagrams all day? *hint* :) > >Further, the term "peer" is used in a very unclear way in the ASN > >request form and the supporting notes. > > > >Formerly, one uplink and one peer (commercial term) were enough to > >justify an ASN, as this constitutes a "unique routing policy". The > >ASN request form allows this interpretation of "peering partners" > >with "peering" in the technical sense. BUT the supporting notes > >specifically mention the requirement for two peers to "ensure that the > >organisation is multihomed". For me, multihoming means to have at least > >two _upstreams_. This would be a more stricter policy than before. > >What was the real intention behind these phrases? These documents > >should be very specific in the usage of "peer". It might be interpreted > >technically or commercially, each implying different constraints. > >I suggest changing the wording from "peer" to "upstream" in order to > >avoid ambiguities. > > Again this is a good point. However I don't think that either term is > appropriate for all situations. When writing these documents we used > the word peer as we wanted to emphasise it was the routing policy which > was important. So, the policy didn't change to "you have to have two _upstreams_ to get an ASN" but it's only a language-confusion here? P.S.: I think this discussion belongs to the address-policy-wg, not ncc-services-wg? Sorry for crossposting, remove the latter in any replies if i'm right. -- ========================================================================== = Sascha 'master' Lenz SLZ-RIPE slz(a)baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ==========================================================================

4 7