From andrei at ripe.net Fri May 3 15:11:03 2002 From: andrei at ripe.net (Andrei Robachevsky) Date: Fri, 03 May 2002 15:11:03 +0200 Subject: Requests to the RIPE DB Administration are now ticketised Message-ID: <3CD28C67.10200@ripe.net> Dear colleagues, [apologies for multiple messages] As was announced at the RIPE 42 meeting starting from the next week, 6 May 2002, questions and requests directed to the RIPE Database Administration (ripe-dbm at ripe.net) will be processed using a ticketing system. This will allow us to track your requests more efficiently and further improve the quality of support we provide to you. No automatic acknowledgements will be sent to you. In replies from the ripe-dbm the subject line will be modified by prepending a ticket number: Re: NCC#2002044160 Please preserve this ticket number in your further correspondence with the ripe-dbm. No other changes should be visible to you. This will not affect submissions sent to the RIPE Database at auto-dbm at ripe.net. If you have any more questions regarding this issue please don't hesitate to contact ripe-dbm at ripe.net. Regards, Andrei Robachevsky DB Group Manager RIPE NCC From webmaster at ripe.net Tue May 7 17:05:18 2002 From: webmaster at ripe.net (RIPE NCC WebMaster) Date: Tue, 07 May 2002 17:05:18 +0200 Subject: New IPv6 Draft Document Message-ID: <200205071505.g47F5I324832@birch.ripe.net> Dear All, The following draft document is available for comments and suggestions until Monday 20 May 2002. Any comments should be sent to: lir-wg at ripe.net. The draft document "IPv6 Addresses for Internet Root Servers in the RIPE Region" is available from: http://www.ripe.net/ripencc/mem-services/registration/ipv6/draft-documents/ Regards Jeroen Bet RIPE NCC WEBMASTER ================== From webmaster at ripe.net Wed May 8 14:26:11 2002 From: webmaster at ripe.net (RIPE NCC WebMaster) Date: Wed, 08 May 2002 14:26:11 +0200 Subject: Updated New IPv6 Draft Document Message-ID: <200205081226.g48CQB316532@birch.ripe.net> Dear All, The following updated draft document is available for comments and suggestions until Monday 20 May 2002. Any comments should be sent to: lir-wg at ripe.net. The draft document has been updated to include the following paragraph: "Although it is agreed that it is undesirable to give special status to any IP (IPv4 or IPv6) address block, it was agreed that the particular need defined in this document is the only justifiable exception to that general principle." The draft document "IPv6 Addresses for Internet Root Servers in the RIPE Region" is available from: http://www.ripe.net/ripencc/mem-services/registration/ipv6/draft-documents/ Regards Jeroen Bet RIPE NCC WEBMASTER ================== From hph at online.no Wed May 8 21:31:33 2002 From: hph at online.no (Hans Petter Holen) Date: Wed, 8 May 2002 21:31:33 +0200 Subject: IP addresses for the RIPE NCC Message-ID: <009701c1f6c6$f6b48df0$7900a8c0@no.tiscali.com> 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. Trouble is that as far as I know the RIPE NCC has no upstream provider, as they are multihomed to a substantial number of subscribers. What is the workinggroup opinion on this ? Regards, -hph From pim at bit.nl Wed May 8 21:34:27 2002 From: pim at bit.nl (Pim van Pelt) Date: Wed, 8 May 2002 21:34:27 +0200 Subject: IP addresses for the RIPE NCC In-Reply-To: <009701c1f6c6$f6b48df0$7900a8c0@no.tiscali.com> References: <009701c1f6c6$f6b48df0$7900a8c0@no.tiscali.com> Message-ID: <20020508193427.GB66147@hog.ipng.nl> On Wed, May 08, 2002 at 09:31:33PM +0200, 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. | | Trouble is that as far as I know the RIPE NCC has no upstream provider, as | they are multihomed to a substantial number of subscribers. | | What is the workinggroup opinion on this ? Please also try to form an opinion on the IPv6 network allocation that the RIPE NCC will be wanting to use for their services. groet, Pim -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________ From randy at psg.com Wed May 8 21:34:28 2002 From: randy at psg.com (Randy Bush) Date: Wed, 08 May 2002 12:34:28 -0700 Subject: IP addresses for the RIPE NCC References: <009701c1f6c6$f6b48df0$7900a8c0@no.tiscali.com> Message-ID: > Trouble is that as far as I know the RIPE NCC has no upstream provider, as ^ single > they are multihomed to a substantial number of subscribers. same as lots of small multi-homed sites. this is not new. they can get space from any one of their upstreams. randy From auto347221 at hushmail.com Wed May 8 21:59:14 2002 From: auto347221 at hushmail.com (auto347221 at hushmail.com) Date: Wed, 8 May 2002 12:59:14 -0700 Subject: IP addresses for the RIPE NCC Message-ID: <200205081959.g48JxEe38746@mailserver4.hushmail.com> 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 From nigel at titley.com Wed May 8 22:12:45 2002 From: nigel at titley.com (Nigel Titley) Date: Wed, 08 May 2002 21:12:45 +0100 Subject: IP addresses for the RIPE NCC References: <009701c1f6c6$f6b48df0$7900a8c0@no.tiscali.com> Message-ID: <3CD986BD.D3E57CC@titley.com> Randy Bush wrote: > > > Trouble is that as far as I know the RIPE NCC has no upstream provider, as > ^ single > > they are multihomed to a substantial number of subscribers. > > same as lots of small multi-homed sites. this is not new. they can get > space from any one of their upstreams. I must say, reluctant as I am usually to agree with Randy :-) I think he is right in this instance. I'm sure that any one of a number of the RIPE NCCs upstreams would be happy to fill out the paperwork for a couple of /24s, which the RIPE NCC could then approve (after appropriate checking of course). Nigel From joao at ripe.net Wed May 8 22:31:30 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Wed, 8 May 2002 22:31:30 +0200 (CEST) Subject: IP addresses for the RIPE NCC In-Reply-To: <3CD986BD.D3E57CC@titley.com> Message-ID: Hi, just a bit of information. The RIPE NCC has enough IPv4 addresses to support its present and foreseen services and infrastructure. See whois.ripe.net The RIPE NCC, on the other hand, has no IPv6 addresses. I think this matter is one for the LIRs, as main users of RIPE NCC services, to decide on. I shall not try to defend any of the possible options but would definitely request a path forward in order for us to be able to start implementing services over IPv6 transport. Thanks Joao On Wed, 8 May 2002, Nigel Titley wrote: > Randy Bush wrote: > > > > > Trouble is that as far as I know the RIPE NCC has no upstream provider, as > > ^ single > > > they are multihomed to a substantial number of subscribers. > > > > same as lots of small multi-homed sites. this is not new. they can get > > space from any one of their upstreams. > > I must say, reluctant as I am usually to agree with Randy :-) I think he > is right in this instance. I'm sure that any one of a number of the RIPE > NCCs upstreams would be happy to fill out the paperwork for a couple of > /24s, which the RIPE NCC could then approve (after appropriate checking > of course). > > Nigel > From randy at psg.com Thu May 9 00:01:03 2002 From: randy at psg.com (Randy Bush) Date: Wed, 08 May 2002 15:01:03 -0700 Subject: IP addresses for the RIPE NCC References: <3CD986BD.D3E57CC@titley.com> Message-ID: oh, it's ipv6? then you should get a /48 from *each* of your upstreams and your hosts will each choose source and dest v6 addresses appropriately to use the most optimal routing for a packet. and, if you believe that, you'll believe that v6 provides easy rapid and frequent renumbering, reasonable auticonf, and flying pigs. i suggest you treat v6 just as v4. get a prefix from an upstream and announce it. the reality to smoke ratio on v6 multi-homing is embarrassing. randy From gert at space.net Thu May 9 00:51:27 2002 From: gert at space.net (Gert Doering) Date: Thu, 9 May 2002 00:51:27 +0200 Subject: IP addresses for the RIPE NCC In-Reply-To: <200205081959.g48JxEe38746@mailserver4.hushmail.com>; from auto347221@hushmail.com on Wed, May 08, 2002 at 12:59:14PM -0700 References: <200205081959.g48JxEe38746@mailserver4.hushmail.com> Message-ID: <20020509005127.F50707@Space.Net> Hi, On Wed, May 08, 2002 at 12:59:14PM -0700, auto347221 at hushmail.com 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.... Actually, they are NOT. *We*, as the community, have made the current IPv6 allocation policy. The NCC people have been helpful in organizing and documenting, but have refrained from pushing in any specific direction concerning the policy. As for the original question: I have discussed various options with Joao on the last RIPE meeting, and the outcome of this (which was also an opinion-forming process for myself) was that "take one /48 and announce that all over the place" is among current options the best one. The advantage of this approach is that: - we need no special policy for the NCC "and everybody else who is special" - we do not need to create PI legacy objects, or any other kind of "I get an allocation even if I do not assign to end users" networks - the effect on the routing table is the same for whatever kind of thing they are going to announce, but with this approach, if the /48 is filtered somewhere, the aggregate will provide "fallback", and thus better resilience. As for "which upstream to go to" - I think that with some careful planning in advance (insert proper macros in all configuration files that contain explicit IPv6 addresses, etc.) renumbering of a fairly flat IPv6 network *is* much easier than for IPv4, due to the fact that one can seamlessly add a second prefix and take away the first one some time later - with v4, this usually requires lots of rebooting and thus downtime. So based on this, I'd say "pick an upstream that isn't likely to go bankrupt any time soon, and seems to provide a reliable network, and if it turns out that they are not good enough, change to a different /48" (and be prepared to do so - by good documentation and pre-planning). [Yes, Randy, Nigel, and others - we all seem to agree, which is really unusual. Must be something wrong with this idea.] Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45077 (47584) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Thu May 9 00:54:03 2002 From: gert at space.net (Gert Doering) Date: Thu, 9 May 2002 00:54:03 +0200 Subject: IP addresses for the RIPE NCC In-Reply-To: <20020509005127.F50707@Space.Net>; from gert@space.net on Thu, May 09, 2002 at 12:51:27AM +0200 References: <200205081959.g48JxEe38746@mailserver4.hushmail.com> <20020509005127.F50707@Space.Net> Message-ID: <20020509005403.G50707@Space.Net> Hi, On Thu, May 09, 2002 at 12:51:27AM +0200, Gert Doering wrote: > I have discussed various options with Joao on the last RIPE meeting, > and the outcome of this (which was also an opinion-forming process for > myself) was that "take one /48 and announce that all over the place" > is among current options the best one. That should have read "take one /48 from one of the upstream's /32", of course. I think it was pretty clear in the argumentative text, but want to clarify it nonetheless. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45077 (47584) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From randy at psg.com Thu May 9 01:21:55 2002 From: randy at psg.com (Randy Bush) Date: Wed, 08 May 2002 16:21:55 -0700 Subject: IP addresses for the RIPE NCC References: <200205081959.g48JxEe38746@mailserver4.hushmail.com> <20020509005127.F50707@Space.Net> Message-ID: as my earlier recommendation attests, i agree with you. grab a /48 and do as in v4. except ... rfc 2772 - 6Bone Backbone Routing Guidelines 4. Routing Policies for the 6bone Leaf sites or pNLAs MUST only advertise to an upstream provider the prefixes assigned by that provider. Advertising a prefix assigned by another provider to a provider is not acceptable, and breaks the aggregation model. A site MUST NOT advertise a prefix from another provider to a provider as a way around the multi-homing problem. However, in the interest of testing new solutions, one may break this policy, so long as ALL affected parties are aware of this test, and all agree to support this testing. These policy breaks MUST NOT affect the 6bone routing table globally. ... All 6bone pTLAs MUST NOT advertise prefixes longer than a given pTLA delegation (currently /24 or /28) to other 6bone pTLAs unless special peering arrangements are implemented. When such special peering aggreements are in place between any two or more 6bone pTLAs, care MUST be taken not to leak the more specifics to other 6bone pTLAs not participating in the peering aggreement. 6bone pTLAs which have such agreements in place MUST NOT advertise other 6bone pTLA more specifics to downstream 6bone pNLAs or leaf sites, as this will break the best-path routing decision. cute, eh? will work well in scalable reality, eh? randy, struggling along in 2001:418:1::/48 From gert at space.net Thu May 9 11:11:06 2002 From: gert at space.net (Gert Doering) Date: Thu, 9 May 2002 11:11:06 +0200 Subject: IP addresses for the RIPE NCC In-Reply-To: ; from randy@psg.com on Wed, May 08, 2002 at 04:21:55PM -0700 References: <200205081959.g48JxEe38746@mailserver4.hushmail.com> <20020509005127.F50707@Space.Net> Message-ID: <20020509111106.I50707@Space.Net> Hi, On Wed, May 08, 2002 at 04:21:55PM -0700, Randy Bush wrote: > as my earlier recommendation attests, i agree with you. grab a /48 and do > as in v4. except ... > > rfc 2772 - 6Bone Backbone Routing Guidelines > > 4. Routing Policies for the 6bone Does that one apply for people using 2001:: space? What is "the 6bone" anyway? Just being curious... :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45077 (47584) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From pekkas at netcore.fi Thu May 9 11:33:01 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 9 May 2002 12:33:01 +0300 (EEST) Subject: IP addresses for the RIPE NCC In-Reply-To: <20020509111106.I50707@Space.Net> Message-ID: On Thu, 9 May 2002, Gert Doering wrote: > On Wed, May 08, 2002 at 04:21:55PM -0700, Randy Bush wrote: > > as my earlier recommendation attests, i agree with you. grab a /48 and do > > as in v4. except ... > > > > rfc 2772 - 6Bone Backbone Routing Guidelines > > > > 4. Routing Policies for the 6bone > > Does that one apply for people using 2001:: space? As a recommendation (like Best Current Practises) at most. I feel these rules should be adhered to the best we can. I see nothing seriously conflicting here and w/ RIPE NCC getting a /48 from upstream(s). Just live with the reality it cannot be announced any further than the operators you have direct connectivity with, with private agreement, which is ~ok by the guideline: However, in the interest of testing new solutions, one may break this policy, so long as ALL affected parties are aware of this test, and all agree to support this testing. These policy breaks MUST NOT affect the 6bone routing table globally. "global routing table" is the key here. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From pim at bit.nl Thu May 9 11:38:52 2002 From: pim at bit.nl (Pim van Pelt) Date: Thu, 9 May 2002 11:38:52 +0200 Subject: IP addresses for the RIPE NCC In-Reply-To: <20020509111106.I50707@Space.Net> References: <200205081959.g48JxEe38746@mailserver4.hushmail.com> <20020509005127.F50707@Space.Net> <20020509111106.I50707@Space.Net> Message-ID: <20020509093852.GB67911@hog.ipng.nl> | > 4. Routing Policies for the 6bone This document describes the use of 3ffe::/16 space: The 6BONE. | Does that one apply for people using 2001:: space? No. | 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! The 6bone is a layered network on top of the current public IPv4 networks, where people in the early 90s started testing their protocol implementation mainly using 5f and 3f (top 8 bits) prefixes. It grew, policy was made, people joined the 6bone to test on ISP rollout and such things. Due to the costs involved with LIR allocation (either pay ARIN, or pay an engineer to fight with RIPE for 4 months), lots of people stuck to 6bone space. It is sequentially allocated by Bob Fink (fink at es.net) and the DNS is maintained by Bill Manning (bmanning at isi.edu) who also maintains a global '6bone mailinglist' which discusses lots of technical issues from time to time. It's a majordomo at isi.edu list called '6bone'. The problem is: people on the 6bone are not always operators. Some are kids with cablemodems announcing to their (tunneled) peers origins as 64001 or networks that have never been allocated in the first place. Another strange situation is that because nobody had a decent shared medium to create native IPv6 peerings in the old days, people would erect tunnels to just about everywhere. For example, an Amsterdam based company would peer over a tunnel to someone in California and in New York. Because the AS path lengths are almost always NOT an indication on how the traffic flows, traffic simply bounces around everywhere and not taking the optimal routes. This should be avoided of course in the production network (which still tunnels quite a bit, of course). | Just being curious... :-) I sometimes envie you for not knowing what the 6bone is. And to come back to RFC2772, I was always a strict filter person and kick and stomp any of my peers that feed me crap, but after recent events (ripe42 is one of them) I am strongly thinking on easing my filters up a little to allow for /48 to make it into my route tables. groet, Pim -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________ From Guy.Davies at telindus.co.uk Thu May 9 11:46:04 2002 From: Guy.Davies at telindus.co.uk (Guy Davies) Date: Thu, 9 May 2002 10:46:04 +0100 Subject: IP addresses for the RIPE NCC Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > -----Original Message----- > From: Pim van Pelt [mailto:pim at bit.nl] > Sent: Thursday, May 09, 2002 10:39 AM > To: Gert Doering > Cc: Randy Bush; lir-wg at 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. From nigel at titley.com Thu May 9 12:17:24 2002 From: nigel at titley.com (Nigel Titley) Date: Thu, 09 May 2002 11:17:24 +0100 Subject: IP addresses for the RIPE NCC References: <200205081959.g48JxEe38746@mailserver4.hushmail.com> <20020509005127.F50707@Space.Net> Message-ID: <3CDA4CB4.FDF210F3@titley.com> Gert Doering wrote: > [Yes, Randy, Nigel, and others - we all seem to agree, which is really > unusual. Must be something wrong with this idea.] I think I shall go and lie down for a little. All this consensus is making me feel faint From pim at bit.nl Thu May 9 12:18:08 2002 From: pim at bit.nl (Pim van Pelt) Date: Thu, 9 May 2002 12:18:08 +0200 Subject: IP addresses for the RIPE NCC In-Reply-To: References: Message-ID: <20020509101808.GD67911@hog.ipng.nl> | > | 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. My appologies. Gert surprised me nonetheless by stating that there were false /32s in the 6bone space, whereas we (the 6bone community) had changed to a /32 allocation policy some 2 months ago. Never mind my re-stating the obvious though. I misread Gerts "the 6bone" question not getting his wording properly. -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________ From mcfadden at 21st-century-texts.com Thu May 9 17:05:27 2002 From: mcfadden at 21st-century-texts.com (Mark McFadden) Date: Thu, 9 May 2002 10:05:27 -0500 Subject: FW: Moving Forward: Call for Volunteers (editing/drafting) Message-ID: <003901c1f76a$f3dc7530$0600a8c0@21stcenturytexts.com> 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 at 21st-century-texts.com -----Original Message----- From: 2050-wg-request at arin.net [mailto:2050-wg-request at arin.net] On Behalf Of Mark McFadden Sent: Thursday, May 09, 2002 9:57 AM To: 2050-wg at 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 at 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. From gert at space.net Thu May 9 20:06:38 2002 From: gert at space.net (Gert Doering) Date: Thu, 9 May 2002 20:06:38 +0200 Subject: IP addresses for the RIPE NCC In-Reply-To: <20020509093852.GB67911@hog.ipng.nl>; from pim@bit.nl on Thu, May 09, 2002 at 11:38:52AM +0200 References: <200205081959.g48JxEe38746@mailserver4.hushmail.com> <20020509005127.F50707@Space.Net> <20020509111106.I50707@Space.Net> <20020509093852.GB67911@hog.ipng.nl> Message-ID: <20020509200638.J50707@Space.Net> Hi, On Thu, May 09, 2002 at 11:38:52AM +0200, Pim van Pelt wrote: > | 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! That was ironic - I know what "6bone space" is (look it up in my slides ;-), and we started out with 5f* and later 3ffe space (from UUnet)) - but as a matter of fact, everybody means different things when speaking about "6bone". So the term is not *that* clear. When talking about "routing policies in the 6bone", one could argue that the RFC was written with the 3FFE test addresses in mind, but one could argue as well that "it logically extends to production IPv6 networks". Which it might or might not, depending on consensus among those that do try to run production IPv6... [..] > It grew, policy was made, people joined the 6bone to test on ISP rollout > and such things. Due to the costs involved with LIR allocation (either > pay ARIN, or pay an engineer to fight with RIPE for 4 months), lots of > people stuck to 6bone space. Hmmm. My application to RIPE took me about 2-3 hours of work (and two weeks of waiting), and half of the work was due to the fact that the form still had some rough edges. So "4 months" is definitely not fair to the RIPE people. [..] > Another strange situation is that because nobody had a decent shared > medium to create native IPv6 peerings in the old days, people would > erect tunnels to just about everywhere. For example, an Amsterdam based > company would peer over a tunnel to someone in California and in New > York. Because the AS path lengths are almost always NOT an indication > on how the traffic flows, traffic simply bounces around everywhere and > not taking the optimal routes. This should be avoided of course in the > production network (which still tunnels quite a bit, of course). Which is why I'm currently working (with some others) on a BCP proposal for "how to do BGP in the face of many tunnels so that other peers can see that this prefix with the nice-and-short path isn't as good as it looks like". Will be presented "soon". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45077 (47584) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Thu May 9 20:08:52 2002 From: gert at space.net (Gert Doering) Date: Thu, 9 May 2002 20:08:52 +0200 Subject: IP addresses for the RIPE NCC In-Reply-To: <20020509101808.GD67911@hog.ipng.nl>; from pim@bit.nl on Thu, May 09, 2002 at 12:18:08PM +0200 References: <20020509101808.GD67911@hog.ipng.nl> Message-ID: <20020509200852.K50707@Space.Net> Hi, On Thu, May 09, 2002 at 12:18:08PM +0200, Pim van Pelt wrote: > | Gert was teasing. He knows full well what the 6bone is, having taken > | an active part in it from an early stage. > My appologies. Gert surprised me nonetheless by stating that there were > false /32s in the 6bone space, whereas we (the 6bone community) had > changed to a /32 allocation policy some 2 months ago. Indeed I really overlooked *that* one - and thanks again for pointing it out :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45077 (47584) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Robert.Kiessling at de.easynet.net Thu May 9 13:20:20 2002 From: Robert.Kiessling at de.easynet.net (Robert Kiessling) Date: 09 May 2002 11:20:20 +0000 Subject: IP addresses for the RIPE NCC In-Reply-To: <20020509093852.GB67911@hog.ipng.nl> References: <200205081959.g48JxEe38746@mailserver4.hushmail.com> <20020509005127.F50707@Space.Net> <20020509111106.I50707@Space.Net> <20020509093852.GB67911@hog.ipng.nl> Message-ID: Pim van Pelt writes: > | 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! You completely missed Gert's question. Of course he knows what 3ffe is, but that was not the question. The question was how to precisely define it, in nowadays reality, > | Just being curious... :-) > I sometimes envie you for not knowing what the 6bone is. You still didn't define what the 6bone comprises. Any site which received an allocation? Wait, that's not sufficient since you can have a pNLA/pSLA without allocation. Any site which announces 3FFE prefixes? Well, then not all of them are bound by the agreement. Any site with a entry in the 6bone whois? Can I sign the agreement and not announce /48 to other 6bone sites, but announce to non-6bone sites? Back to the original question: I'd rather take Pekka's more practical approach and say that even the 6bone rules make allowances for e.g. a /48 announcement from RIPE as long as it's scope is limited. Allow it to be announced by RIPE to direct peers, and from them to their customers, but don't give any guarantee that it is globally visible. For true global multihoming of important services like whois, techniques can be used that work in IPv4 already: get two assignments, two AAAA records for the services, and possible some DNS magic with short TTLs and an "intelligent" DNS server to turn off AAAA answers if that uplink is seriously broken. Robert From ncc at ripe.net Fri May 10 15:58:31 2002 From: ncc at ripe.net (Paul Rendek) Date: Fri, 10 May 2002 15:58:31 +0200 Subject: Draft IPv4 and AS Number policy documents (review deadline extension) Message-ID: <5.0.0.25.2.20020510155248.02ac3590@localhost> 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-documents/ Any feedback should be sent to: . Regards, Paul Rendek RIPE NCC From joao at ripe.net Mon May 13 12:37:19 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Mon, 13 May 2002 12:37:19 +0200 Subject: IP addresses for the RIPE NCC In-Reply-To: <3CDA4CB4.FDF210F3@titley.com> References: <200205081959.g48JxEe38746@mailserver4.hushmail.com> <20020509005127.F50707@Space.Net> <3CDA4CB4.FDF210F3@titley.com> Message-ID: Hi, to wrap up the discussion. We should get addresses from upstream provider(s). Next question: how many? I guess the RIPE NCC offices are "a site" and thus the need is for a /48 which we subnet internally. Probably another one for the RIPE Meeting, which is another site (a mobile one), with its own subnets. So far so good. Doubts come when I think about the tunnels we want to provide to our staff, as we do with IPv4. If I read the policy and the IETF statements, each of these sites, which normally have a Linux box acting as end point and subnets internally (even if each subnet usually has no more than one other box), would need a /48, as that is the minimum for a site. Or should we assign, say /56's? We estimate about 50 of these cases in a reasonable period of time. What makes a site? The length of the cable? The technology used to get the packets inside those cables? The desire to subnet? Something else? I have never been able to get a definition that suits more than a small portion of the people I talk to. I am very interested in your opinion both because we would like to roll out IPv6 services in the near future and to see what is the community's interpretation of the policy as a benchmark for our hostmasters. So consider yourselves the hostmasters for our request as I would like to avoid our own departments calling a judgement on our own address resources. Jooa From randy at psg.com Mon May 13 13:59:25 2002 From: randy at psg.com (Randy Bush) Date: Mon, 13 May 2002 11:59:25 +0000 Subject: neutrality and nat Message-ID: 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 From joao at ripe.net Mon May 13 14:17:52 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Mon, 13 May 2002 14:17:52 +0200 Subject: neutrality and nat In-Reply-To: References: Message-ID: Hi randy, the policy advice set by the LIRs has been, to the best of my knowledge, to ask requesters whether they have considered using private addressing for their network, not to force anyone to use it. Just ask, nothing else. Where have you seen that presentation? Joao At 11:59 +0000 13/5/02, Randy Bush wrote: >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 From randy at psg.com Mon May 13 14:26:19 2002 From: randy at psg.com (Randy Bush) Date: Mon, 13 May 2002 12:26:19 +0000 Subject: neutrality and nat References: Message-ID: > the policy advice set by the LIRs has been, to the best of my > knowledge, to ask requesters whether they have considered using > private addressing for their network, not to force anyone to use it. there were two slides telling why/when to use nat. there were none on why not. > Where have you seen that presentation? just now, at afnog. presented by mirjam. randy From pfs at cisco.com Mon May 13 14:11:57 2002 From: pfs at cisco.com (Philip Smith) Date: Mon, 13 May 2002 22:11:57 +1000 Subject: neutrality and nat In-Reply-To: Message-ID: <5.1.0.14.2.20020513220501.0578f1b8@lint.cisco.com> Mmmm well, I didn't hear Mirjam saying "you must use NATs" in this presentation, just saying that "people can use NATs and private addresses". She did mention that they broke applications, and had known problems... Would have been helpful on the slide though. I have a feeling this is going to start another NAT war on the list. :-( philip -- At 11:59 13/05/2002 +0000, Randy Bush wrote: >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 From phk at critter.freebsd.dk Mon May 13 14:28:05 2002 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Mon, 13 May 2002 14:28:05 +0200 Subject: neutrality and nat In-Reply-To: Your message of "Mon, 13 May 2002 12:26:19 -0000." Message-ID: <14026.1021292885@critter.freebsd.dk> In message , Randy Bush writes: >> the policy advice set by the LIRs has been, to the best of my >> knowledge, to ask requesters whether they have considered using >> private addressing for their network, not to force anyone to use it. > >there were two slides telling why/when to use nat. there were none >on why not. Uhm, Randy, is this some personal crusade or something ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From pemptage at cisco.com Tue May 14 15:32:19 2002 From: pemptage at cisco.com (Peter Emptage) Date: Tue, 14 May 2002 15:32:19 +0200 Subject: IPv4 Address Allocation policies for organisations not connecting to the Internet Message-ID: <909B25C2941F454786589E5526526357740886@xbe-lon-303.cisco.com> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From theimes at de.cw.net Tue May 14 16:20:49 2002 From: theimes at de.cw.net (Tanja Heimes) Date: Tue, 14 May 2002 16:20:49 +0200 Subject: first allocation Message-ID: <3CE11D41.10D1D41@de.cw.net> 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 at 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 From theimes at de.cw.net Tue May 14 16:34:05 2002 From: theimes at de.cw.net (Tanja Heimes) Date: Tue, 14 May 2002 16:34:05 +0200 Subject: first allocation References: <3CE11D41.10D1D41@de.cw.net> Message-ID: <3CE1205D.C85BA1B6@de.cw.net> Hello again, I found the answer already. For all that have not been aware about the correct info, as me, here is the Link: http://www.ripe.net/ripe/meetings/archive/ripe-40/presentations.html#LIR Regards, Tanja Tanja Heimes wrote: > > 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 at 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 -- Tanja Heimes / IP Engineer E-Mail Tanja.Heimes at 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 From pre at pre.org Tue May 14 16:35:48 2002 From: pre at pre.org (Patrick Evans) Date: Tue, 14 May 2002 15:35:48 +0100 (BST) Subject: first allocation In-Reply-To: <3CE11D41.10D1D41@de.cw.net> Message-ID: 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 at pre.org CV: www.pre.org/pre/cv Bike: Kawasaki ZXR400L9 (for sale) From alan at linerate.net Tue May 14 16:44:17 2002 From: alan at linerate.net (Alan Sawyer) Date: Wed, 15 May 2002 00:44:17 +1000 (EST) Subject: first allocation In-Reply-To: <3CE11D41.10D1D41@de.cw.net> Message-ID: With RIPE it's a /20, Cheers, Alan 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. > > 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). > > > > From gert at space.net Tue May 14 16:50:04 2002 From: gert at space.net (Gert Doering) Date: Tue, 14 May 2002 16:50:04 +0200 Subject: first allocation In-Reply-To: <3CE11D41.10D1D41@de.cw.net>; from theimes@de.cw.net on Tue, May 14, 2002 at 04:20:49PM +0200 References: <3CE11D41.10D1D41@de.cw.net> Message-ID: <20020514165004.G50707@Space.Net> Hi, On Tue, May 14, 2002 at 04:20:49PM +0200, Tanja Heimes wrote: > 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. As much as you can document need for, with a minimum of a /20. (You might get a /16, but that would be "unusual" :-) ) [..] > RIPE-185 > -------- RIPE-185 predates this specific policy change (which was made at RIPE39 in Bologna, one year ago, if I remember correctly). As RIPE documents with a specific number never change (!), it still has the old value in it. RIPE-185bis will supercede it "soon". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45114 (45077) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Jens.Hoffmann at DDkom.de Tue May 14 16:56:44 2002 From: Jens.Hoffmann at DDkom.de (Hoffmann, Jens) Date: Tue, 14 May 2002 16:56:44 +0200 Subject: AW: first allocation Message-ID: <8886D895EE52CD40B562EE83B40F837401AEFE@hydra.intern.ddkom.net> 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 at pre.org] > Gesendet: Dienstag, 14. Mai 2002 16:36 > An: Tanja Heimes > Cc: lir-wg at 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 at pre.org > CV: www.pre.org/pre/cv > Bike: Kawasaki ZXR400L9 (for sale) > > From leo at ripe.net Tue May 14 17:15:16 2002 From: leo at ripe.net (leo vegoda) Date: Tue, 14 May 2002 17:15:16 +0200 Subject: first allocation In-Reply-To: <3CE11D41.10D1D41@de.cw.net> References: <3CE11D41.10D1D41@de.cw.net> Message-ID: <20020514151516.GA4610@ripe.net> 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: 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: The review period for this document ends this Friday. If you have any comments on the docuemnts up for review please send them to . -- leo vegoda RIPE NCC, Registration Services Assistant Manager On Tue, May 14, 2002 at 04:20:49PM +0200, Tanja Heimes wrote: Re: first allocation > 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 at 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 > -- leo vegoda "One size never fits all" RFC1925 - The Twelve Networking Truths From gert at space.net Tue May 14 17:41:34 2002 From: gert at space.net (Gert Doering) Date: Tue, 14 May 2002 17:41:34 +0200 Subject: first allocation In-Reply-To: <8886D895EE52CD40B562EE83B40F837401AEFE@hydra.intern.ddkom.net>; from Jens.Hoffmann@DDkom.de on Tue, May 14, 2002 at 04:56:44PM +0200 References: <8886D895EE52CD40B562EE83B40F837401AEFE@hydra.intern.ddkom.net> Message-ID: <20020514174134.H50707@Space.Net> Hi, On Tue, May 14, 2002 at 04:56:44PM +0200, Hoffmann, Jens wrote: > 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. Please don't start such kind of rumors. Policies are made and decided upon by the RIPE community, and *executed* by the RIPE NCC hostmasters. There are certain rules, and they are documented (even if the docs are sometimes hiding). There is no random element, and there is no "availability" thing - this isn't communism. As long as there is IPv4 space left, the same rules apply to everybody. When you got your allocation, which was in 2000, the /19 was the minimum allocation size. This was changed in 2001. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45114 (45077) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From jerome.tissieres at cablecom.ch Tue May 14 17:55:59 2002 From: jerome.tissieres at cablecom.ch (Jerome Tissieres) Date: Tue, 14 May 2002 17:55:59 +0200 Subject: =?ISO-8859-1?Q?R=E9p.=20:=20Re:=20first=20allocation?= Message-ID: 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 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: 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: The review period for this document ends this Friday. If you have any comments on the docuemnts up for review please send them to . -- leo vegoda RIPE NCC, Registration Services Assistant Manager From stuart.prevost at btinternet.com Tue May 14 20:52:54 2002 From: stuart.prevost at btinternet.com (Stuart Prevost) Date: Tue, 14 May 2002 19:52:54 +0100 Subject: neutrality and nat References: Message-ID: <042c01c1fb78$8e9596e0$5e00a8c0@futures.bt.co.uk> Hello Joao, Shouldn't RIPE NCC modify it's questions to say have you considered IPv6 instead of asking if they have thought of using NAT. If RIPE would like to further IPv6 shouldn't it asking it's customers (IPv4) about using IPv6!!!!! :-) Stuart ----- Original Message ----- From: "Joao Luis Silva Damas" To: "Randy Bush" ; Sent: Monday, May 13, 2002 1:17 PM Subject: Re: neutrality and nat > Hi randy, > > the policy advice set by the LIRs has been, to the best of my > knowledge, to ask requesters whether they have considered using > private addressing for their network, not to force anyone to use it. > Just ask, nothing else. > > Where have you seen that presentation? > > Joao > > > At 11:59 +0000 13/5/02, Randy Bush wrote: > >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 > > From gert at space.net Tue May 14 22:04:45 2002 From: gert at space.net (Gert Doering) Date: Tue, 14 May 2002 22:04:45 +0200 Subject: neutrality and nat In-Reply-To: <042c01c1fb78$8e9596e0$5e00a8c0@futures.bt.co.uk>; from stuart.prevost@btinternet.com on Tue, May 14, 2002 at 07:52:54PM +0100 References: <042c01c1fb78$8e9596e0$5e00a8c0@futures.bt.co.uk> Message-ID: <20020514220445.R50707@Space.Net> Hi, On Tue, May 14, 2002 at 07:52:54PM +0100, Stuart Prevost wrote: > Shouldn't RIPE NCC modify it's questions to say have you considered IPv6 > instead of asking if they have thought of using NAT. If RIPE would like to > further IPv6 shouldn't it asking it's customers (IPv4) about using IPv6!!!!! > :-) Good idea! gert -- Total number of prefixes smaller than registry allocations: 45114 (45077) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From randy at psg.com Tue May 14 23:55:38 2002 From: randy at psg.com (Randy Bush) Date: Tue, 14 May 2002 14:55:38 -0700 Subject: AW: first allocation References: <8886D895EE52CD40B562EE83B40F837401AEFE@hydra.intern.ddkom.net> Message-ID: > 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. becuase they take less one less one bit on the average, more even numbered ipv4 addresses are manufactured than are odd numbered addresses. so, if you apply on an even numbered day, you get more addresses than if you apply on an odd numbered day. randy From randy at psg.com Tue May 14 21:44:17 2002 From: randy at psg.com (Randy Bush) Date: Tue, 14 May 2002 12:44:17 -0700 Subject: neutrality and nat References: <14026.1021292885@critter.freebsd.dk> Message-ID: >> there were two slides telling why/when to use nat. there were none >> on why not. > Uhm, Randy, is this some personal crusade or something ? not unless you still beat your wife. nats do cause problems. we should not be presenting only one side. in this case, to an audience which has serious problems with nats and allocation. for example, one organization with a backbone that alone needs about three /24s and has over 1,600 end hosts scattered over this routed backbone. the techno-conialist ptt gives them a /29 because, among other reasons, ripe says use nats. in these countries, good engineers are an extremely scarce resource. having them spend time dealing with the aberations and consequences of nats is socially irresponsible as well as often technically unsound. randy From theimes at de.cw.net Tue May 14 17:08:13 2002 From: theimes at de.cw.net (Tanja Heimes) Date: Tue, 14 May 2002 17:08:13 +0200 Subject: AW: first allocation References: <8886D895EE52CD40B562EE83B40F837401AEFE@hydra.intern.ddkom.net> Message-ID: <3CE1285D.57ACBD98@de.cw.net> Hello Jens, as Gerd Doering wrote there started to be a discussion to lower the size of the first allocation at RIPE-39. I think at RIPE-40 there was made the desicion to lower it to a /20. (This was in 10/2001) This presentation is from Nurani Nimpuno and she held it at the RIPE-40. http://www.ripe.net/ripe/meetings/archive/ripe-40/presentations/ipv4-as-policy-revision/sld009.html Regards, Tanja "Hoffmann, Jens" wrote: > > 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 at pre.org] > > Gesendet: Dienstag, 14. Mai 2002 16:36 > > An: Tanja Heimes > > Cc: lir-wg at 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 at pre.org > > CV: www.pre.org/pre/cv > > Bike: Kawasaki ZXR400L9 (for sale) > > > > -- Tanja Heimes / IP Engineer E-Mail Tanja.Heimes at 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 From adrian.pauling at bt.com Wed May 15 10:18:07 2002 From: adrian.pauling at bt.com (adrian.pauling at bt.com) Date: Wed, 15 May 2002 09:18:07 +0100 Subject: IPv4 Address Allocation policies for organisations not connec ting to the Internet Message-ID: <27EDC2145E42D211AD9600606DD5EC1D12CBECAB@mbrpb1nt02.mww.bt.com> 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joao at ripe.net Wed May 15 11:11:13 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Wed, 15 May 2002 11:11:13 +0200 Subject: neutrality and nat In-Reply-To: <042c01c1fb78$8e9596e0$5e00a8c0@futures.bt.co.uk> References: <042c01c1fb78$8e9596e0$5e00a8c0@futures.bt.co.uk> Message-ID: At 19:52 +0100 14/5/02, Stuart Prevost wrote: >Hello Joao, > >Shouldn't RIPE NCC modify it's questions to say have you considered IPv6 >instead of asking if they have thought of using NAT. If RIPE would like to >further IPv6 shouldn't it asking it's customers (IPv4) about using IPv6!!!!! >:-) LIRs ask us to be technology agnostic when dealing with requests :-) Joao >Stuart >----- Original Message ----- >From: "Joao Luis Silva Damas" >To: "Randy Bush" ; >Sent: Monday, May 13, 2002 1:17 PM >Subject: Re: neutrality and nat > > >> Hi randy, >> >> the policy advice set by the LIRs has been, to the best of my >> knowledge, to ask requesters whether they have considered using >> private addressing for their network, not to force anyone to use it. >> Just ask, nothing else. >> >> Where have you seen that presentation? >> >> Joao >> >> >> At 11:59 +0000 13/5/02, Randy Bush wrote: >> >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 >> >> From stuart.prevost at btinternet.com Wed May 15 18:36:38 2002 From: stuart.prevost at btinternet.com (Stuart Prevost) Date: Wed, 15 May 2002 17:36:38 +0100 Subject: neutrality and nat References: <042c01c1fb78$8e9596e0$5e00a8c0@futures.bt.co.uk> Message-ID: <002a01c1fc2e$afa7cef0$5e00a8c0@futures.bt.co.uk> Which was Randy's point, so if your technology agnostic why do you ask if the requesting LIR has thought of using NATs!!!! > At 19:52 +0100 14/5/02, Stuart Prevost wrote: > >Hello Joao, > > > >Shouldn't RIPE NCC modify it's questions to say have you considered IPv6 > >instead of asking if they have thought of using NAT. If RIPE would like to > >further IPv6 shouldn't it asking it's customers (IPv4) about using IPv6!!!!! > >:-) > > LIRs ask us to be technology agnostic when dealing with requests :-) > > Joao > > >Stuart > >----- Original Message ----- > >From: "Joao Luis Silva Damas" > >To: "Randy Bush" ; > >Sent: Monday, May 13, 2002 1:17 PM > >Subject: Re: neutrality and nat > > > > > >> Hi randy, > >> > >> the policy advice set by the LIRs has been, to the best of my > >> knowledge, to ask requesters whether they have considered using > >> private addressing for their network, not to force anyone to use it. > >> Just ask, nothing else. > >> > >> Where have you seen that presentation? > >> > >> Joao > >> > >> > >> At 11:59 +0000 13/5/02, Randy Bush wrote: > >> >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 > >> > >> > > From randy at psg.com Wed May 15 18:55:04 2002 From: randy at psg.com (Randy Bush) Date: Wed, 15 May 2002 09:55:04 -0700 Subject: neutrality and nat References: <042c01c1fb78$8e9596e0$5e00a8c0@futures.bt.co.uk> <002a01c1fc2e$afa7cef0$5e00a8c0@futures.bt.co.uk> Message-ID: > Which was Randy's point, so if your technology agnostic why do you ask if > the requesting LIR has thought of using NATs!!!! the inverse of the current message would be "Given their difficulties, have you checked that you're not using NATs?" probably something educational and neutral would actually be helpful. "While NATs can be useful in conserving address space in situations such as o a o b o c see blah blah "They also create problems such as o d o e o f see blah blah "We neither encourage or discourage their use, and strongly suggest that LIRs and ISPs do not encourage or discourage their use." randy From hph at online.no Wed May 15 19:32:38 2002 From: hph at online.no (Hans Petter Holen) Date: Wed, 15 May 2002 19:32:38 +0200 Subject: neutrality and nat References: Message-ID: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> Hmm, if this is right, I think we should change policy. If I remember right this whole thing comes from the "Have you concidered using private address space" which back when it was formulated in the addressing form was before NAT was a wide spread technology. Personaly I feel it is a pity that this has turned into a "please use NAT". Therefore, I am proposing to change this policy into: - stop asking this question - stop promoting NAT Any views on this ? Hans Petter ----- Original Message ----- From: "Randy Bush" To: Sent: Monday, May 13, 2002 1:59 PM Subject: neutrality and nat | 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 | From mpb at melitacable.com Wed May 15 19:56:40 2002 From: mpb at melitacable.com (Mark Pace Balzan) Date: Wed, 15 May 2002 19:56:40 +0200 Subject: neutrality and nat In-Reply-To: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> Message-ID: I'd agree. I dont believe it should ever be a "please use nat (because of conservation of IPv4 space)", although it looks like it may have turned into this. Maybe a "NAT exists and may work, even partially in your situation, but may also be your worst nightmare" would be good. To be fair with NAT it has done alot towards IPv4 space conservation in sitautions where it does work ! Mark > -----Original Message----- > From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net]On Behalf Of > Hans Petter Holen > Sent: 15 May 2002 19:33 > To: Randy Bush; lir-wg at ripe.net > Subject: Re: neutrality and nat > > > Hmm, if this is right, I think we should change policy. If I > remember right > this whole thing comes from the "Have you concidered using private address > space" which back when it was formulated in the addressing form was before > NAT was a wide spread technology. > > Personaly I feel it is a pity that this has turned into a "please > use NAT". > > Therefore, I am proposing to change this policy into: > > - stop asking this question > - stop promoting NAT > > Any views on this ? > > Hans Petter > > > ----- Original Message ----- > From: "Randy Bush" > To: > Sent: Monday, May 13, 2002 1:59 PM > Subject: neutrality and nat > > > | 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 > | > > From peter.galbavy at knowtion.net Wed May 15 20:26:05 2002 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Wed, 15 May 2002 19:26:05 +0100 Subject: neutrality and nat References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> Message-ID: <027801c1fc3d$fa08cd50$8b0609d4@carpenter> > Therefore, I am proposing to change this policy into: > > - stop asking this question > - stop promoting NAT > > Any views on this ? Seconded. Peter From randy at psg.com Wed May 15 20:31:42 2002 From: randy at psg.com (Randy Bush) Date: Wed, 15 May 2002 11:31:42 -0700 Subject: neutrality and nat References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> <027801c1fc3d$fa08cd50$8b0609d4@carpenter> Message-ID: an important part of the rirs' job is information/education. trying to pretend that nats don't exist is not realistic. trying to explain the trade-off would be useful. the hard part would be doing so usefully without getting into a document mire. randy From alan at linerate.net Wed May 15 20:56:51 2002 From: alan at linerate.net (Alan Sawyer) Date: Thu, 16 May 2002 04:56:51 +1000 (EST) Subject: neutrality and nat In-Reply-To: Message-ID: Why not take this tone with the first email rather then set the mob off? On Wed, 15 May 2002, Randy Bush wrote: > an important part of the rirs' job is information/education. trying > to pretend that nats don't exist is not realistic. trying to explain > the trade-off would be useful. the hard part would be doing so usefully > without getting into a document mire. > > randy > From gert at space.net Thu May 16 10:28:31 2002 From: gert at space.net (Gert Doering) Date: Thu, 16 May 2002 10:28:31 +0200 Subject: neutrality and nat In-Reply-To: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com>; from hph@online.no on Wed, May 15, 2002 at 07:32:38PM +0200 References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> Message-ID: <20020516102831.B13918@Space.Net> Hi, On Wed, May 15, 2002 at 07:32:38PM +0200, Hans Petter Holen wrote: > Personaly I feel it is a pity that this has turned into a "please use NAT". It has NOT. The RIPE185-bis document is clear on this. > Therefore, I am proposing to change this policy into: > > - stop asking this question > - stop promoting NAT > > Any views on this ? I seriously think that adding a second question "have you considered IPv6" (if only to raise awareness "IPv6 is here to stay") might be a good thing. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45114 (45077) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From pre at pre.org Thu May 16 10:35:53 2002 From: pre at pre.org (Patrick Evans) Date: Thu, 16 May 2002 09:35:53 +0100 (BST) Subject: neutrality and nat In-Reply-To: <20020516102831.B13918@Space.Net> Message-ID: On Thu, 16 May 2002, Gert Doering wrote: > On Wed, May 15, 2002 at 07:32:38PM +0200, Hans Petter Holen wrote: > > Personaly I feel it is a pity that this has turned into a "please use NAT". > > It has NOT. The RIPE185-bis document is clear on this. > > > Therefore, I am proposing to change this policy into: > > > > - stop asking this question > > - stop promoting NAT > > > > Any views on this ? > > I seriously think that adding a second question "have you > considered IPv6" (if only to raise awareness "IPv6 is here to > stay") might be a good thing. > Would it not be very very wise to avoid doing that until *anyone* has worked out a coherent and workable IPv6 allocation/assignment policy? -- Patrick Evans Email: pre at pre.org CV: www.pre.org/pre/cv Bike: Kawasaki ZXR400L9 (for sale) "her eyes were like pissholes in the snow - they could melt right through me" From joao at ripe.net Thu May 16 11:59:00 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Thu, 16 May 2002 11:59:00 +0200 Subject: neutrality and nat In-Reply-To: <20020516102831.B13918@Space.Net> References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> <20020516102831.B13918@Space.Net> Message-ID: Rather than engage in a long discussion to arrive where we already are, I would ask you to allow me to point you to http://www.ripe.net/cgi-bin/webiprequest/webiprequest.cgi section "request overview template" and settle the issue of NATs and look into making what we have even better. (as a personal opinion, raising awareness of IPv6 is probably a good thing. Seeing people working with it and fixing the rough edges in the technology before widespread deployment would be a great thing to see). Cheers, Joao At 10:28 +0200 16/5/02, Gert Doering wrote: >Hi, > >On Wed, May 15, 2002 at 07:32:38PM +0200, Hans Petter Holen wrote: >> Personaly I feel it is a pity that this has turned into a "please use NAT". > >It has NOT. The RIPE185-bis document is clear on this. > >> Therefore, I am proposing to change this policy into: >> >> - stop asking this question >> - stop promoting NAT >> >> Any views on this ? > >I seriously think that adding a second question "have you considered IPv6" >(if only to raise awareness "IPv6 is here to stay") might be a good thing. > >Gert Doering > -- NetMaster >-- >Total number of prefixes smaller than registry allocations: 45114 (45077) > >SpaceNet AG Mail: netmaster at Space.Net >Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 >80807 Muenchen Fax : +49-89-32356-299 From nigel at titley.com Thu May 16 15:01:15 2002 From: nigel at titley.com (Nigel Titley) Date: 16 May 2002 13:01:15 +0000 Subject: neutrality and nat In-Reply-To: References: Message-ID: <1021554075.1145.97.camel@magrat> On Wed, 2002-05-15 at 18:56, Alan Sawyer wrote: > Why not take this tone with the first email rather then set the mob off? 'Cos Randy likes winding people up. And we all expect it of him. And it usually stirs up a useful discussion as everyone rushes to arms..... From peter.galbavy at knowtion.net Thu May 16 14:26:05 2002 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Thu, 16 May 2002 13:26:05 +0100 Subject: neutrality and nat References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com><027801c1fc3d$fa08cd50$8b0609d4@carpenter> Message-ID: <003601c1fcd4$d9fa7260$8b0609d4@carpenter> > an important part of the rirs' job is information/education. trying > to pretend that nats don't exist is not realistic. trying to explain > the trade-off would be useful. the hard part would be doing so usefully > without getting into a document mire. I disagree. The RIRs jobs (certainly in the case of RIPE) should be the (fair) management of those resources they are responsible for - IPs and ASes etc. Information / Education should be functions iff they do not impact on the primary function and are acheived at close to zero cost - i.e. self funding. Vendors selling solutions that use NAT (ISPs, router vendors, free software projects, consultacies) should be esposing NAT if they feel they can sell it and support it. Not RIPE. NAT is *not* a general method for conserving IPv4 address space - it is a very specific and limited method as we all know - and is very very useful in many cases. Peter From peter.galbavy at knowtion.net Thu May 16 14:53:02 2002 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Thu, 16 May 2002 13:53:02 +0100 Subject: neutrality and nat References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> <20020516102831.B13918@Space.Net> Message-ID: <005901c1fcd8$9db19140$8b0609d4@carpenter> > I seriously think that adding a second question "have you considered IPv6" > (if only to raise awareness "IPv6 is here to stay") might be a good thing. My reply would be templated: "I have but I have found that I am not permitted to apply for IPv6 space." Peter From randy at psg.com Thu May 16 15:31:57 2002 From: randy at psg.com (Randy Bush) Date: Thu, 16 May 2002 06:31:57 -0700 Subject: neutrality and nat References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> <20020516102831.B13918@Space.Net> Message-ID: > I seriously think that adding a second question "have you > considered IPv6" (if only to raise awareness "IPv6 is here to > stay") might be a good thing. while i might agree on philosophical grounds, i am trying to run v6 and it is not clear to me it is even 'here' let alone to stay. and certainly, there is no non-nat transition plan. and even a natted transition plan, in which hosts are not 'restricted' as in v4 nat, needs as many v4 addresses as a non-natted v4 network. v6 needs a lot of work. and i don't think we will have social fun agreeing on the caveats we would be obliged to put into a "you may want to consider" clause. randy From randy at psg.com Thu May 16 16:03:44 2002 From: randy at psg.com (Randy Bush) Date: Thu, 16 May 2002 07:03:44 -0700 Subject: neutrality and nat References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> <027801c1fc3d$fa08cd50$8b0609d4@carpenter> <003601c1fcd4$d9fa7260$8b0609d4@carpenter> Message-ID: >> an important part of the rirs' job is information/education. trying >> to pretend that nats don't exist is not realistic. trying to explain >> the trade-off would be useful. the hard part would be doing so usefully >> without getting into a document mire. > > I disagree. The RIRs jobs (certainly in the case of RIPE) should be the > (fair) management of those resources they are responsible for - IPs and ASes > etc. > > Information / Education should be functions iff they do not impact on the > primary function and are acheived at close to zero cost - i.e. self funding. an amazingly naive view of what actually happens at a rir. if that was anything like the case, all that would be needed would be a web form or two. the fact is that each of the N thousand applicants had to be walked through it all. and then, when a new employee came in at the LIR, it had to all happen again. there is a reason hostmasters burn out, and it ain't from pushing "accept the web form" buttons. randy From randy at psg.com Thu May 16 16:40:20 2002 From: randy at psg.com (Randy Bush) Date: Thu, 16 May 2002 07:40:20 -0700 Subject: neutrality and nat References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> <20020516102831.B13918@Space.Net> Message-ID: > Rather than engage in a long discussion to arrive where we > already are conservatives might consider this much better than short or no discussion to arrive at some place new. :-)/2 > I would ask you to allow me to point you to > http://www.ripe.net/cgi-bin/webiprequest/webiprequest.cgi when someone to whom i am begging asks "have you considered X," this is taken as close to "we expect you to use X if you can." but the issue i raised is not what is on the form, but what is communicated in presentations and training. what the audience took away from the afnog presentation was "nat is a desirable approach that we think you should use if possible." > (as a personal opinion, raising awareness of IPv6 is probably a > good thing. Seeing people working with it and fixing the rough > edges in the technology before widespread deployment would be a > great thing to see). randy From gert at space.net Thu May 16 22:12:17 2002 From: gert at space.net (Gert Doering) Date: Thu, 16 May 2002 22:12:17 +0200 Subject: neutrality and nat In-Reply-To: <005901c1fcd8$9db19140$8b0609d4@carpenter>; from peter.galbavy@knowtion.net on Thu, May 16, 2002 at 01:53:02PM +0100 References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> <20020516102831.B13918@Space.Net> <005901c1fcd8$9db19140$8b0609d4@carpenter> Message-ID: <20020516221217.R13918@Space.Net> Hi, On Thu, May 16, 2002 at 01:53:02PM +0100, Peter Galbavy wrote: > > I seriously think that adding a second question "have you considered IPv6" > > (if only to raise awareness "IPv6 is here to stay") might be a good thing. > > My reply would be templated: > > "I have but I have found that I am not permitted to apply for IPv6 space." Of course you are permitted to ask your ISP for IPv6 space. If your ISP does not have some, but you want some, time to tell their marketing folks. We're not talking about LIR->RIR requests (they have no "have you considered NAT" clause). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45114 (45077) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From peter.galbavy at knowtion.net Fri May 17 10:35:09 2002 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Fri, 17 May 2002 09:35:09 +0100 Subject: neutrality and nat References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com><027801c1fc3d$fa08cd50$8b0609d4@carpenter><003601c1fcd4$d9fa7260$8b0609d4@carpenter> Message-ID: <004201c1fd7d$c1529a40$8b0609d4@carpenter> > an amazingly naive view of what actually happens at a rir. if that was > anything like the case, all that would be needed would be a web form or > two. the fact is that each of the N thousand applicants had to be walked > through it all. and then, when a new employee came in at the LIR, it had > to all happen again. there is a reason hostmasters burn out, and it ain't > from pushing "accept the web form" buttons. Huh. Right. If it was a web form or two then maybe the process would actually work in a timely fashion. I get this feeling that over the (changing) years much of the paper work has been created to keep the NCC in the 'power' to which they have become accustomed. While I am sadly aware of how complex the current processes are and of many of the original reasons for this complexity, let's not forget the whole point of the NCC - to manage resources for it's 'owners'. See a recent thread on concerns why the NCC and RIPE are not the same thing - to many views (we, the members paying for it) they should be the same. Peter From peter.galbavy at knowtion.net Fri May 17 10:38:36 2002 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Fri, 17 May 2002 09:38:36 +0100 Subject: neutrality and nat References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> <20020516102831.B13918@Space.Net> <005901c1fcd8$9db19140$8b0609d4@carpenter> <20020516221217.R13918@Space.Net> Message-ID: <006501c1fd7e$3d38e510$8b0609d4@carpenter> > > My reply would be templated: > > > > "I have but I have found that I am not permitted to apply for IPv6 space." > > Of course you are permitted to ask your ISP for IPv6 space. > > If your ISP does not have some, but you want some, time to tell their > marketing folks. > > We're not talking about LIR->RIR requests (they have no "have you > considered NAT" clause). I am my ISP. I have my AS, my IPv4 allocation and my upstream(s) - one at this exact moment. I still cannot get my IPv6 space. I am not going to restrict myself from moving / adding / removing upstreams based on the paperwork associated with IPv6 address space through each one. Peter From gert at space.net Fri May 17 10:41:10 2002 From: gert at space.net (Gert Doering) Date: Fri, 17 May 2002 10:41:10 +0200 Subject: neutrality and nat In-Reply-To: <006501c1fd7e$3d38e510$8b0609d4@carpenter>; from peter.galbavy@knowtion.net on Fri, May 17, 2002 at 09:38:36AM +0100 References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> <20020516102831.B13918@Space.Net> <005901c1fcd8$9db19140$8b0609d4@carpenter> <20020516221217.R13918@Space.Net> <006501c1fd7e$3d38e510$8b0609d4@carpenter> Message-ID: <20020517104110.D13918@Space.Net> Hi, On Fri, May 17, 2002 at 09:38:36AM +0100, Peter Galbavy wrote: > I am my ISP. I have my AS, my IPv4 allocation and my upstream(s) - one at > this exact moment. I still cannot get my IPv6 space. Why? Have you read the current policy? If you're an ISP and are serious about connecting customers, getting an IPv6 allocation should be easy. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45114 (45077) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From peter.galbavy at knowtion.net Fri May 17 10:57:58 2002 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Fri, 17 May 2002 09:57:58 +0100 Subject: neutrality and nat References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> <20020516102831.B13918@Space.Net> <005901c1fcd8$9db19140$8b0609d4@carpenter> <20020516221217.R13918@Space.Net> <006501c1fd7e$3d38e510$8b0609d4@carpenter> <20020517104110.D13918@Space.Net> Message-ID: <007801c1fd80$f1b70830$8b0609d4@carpenter> I may well have missed an announcement, but the last time I looked the rules were very counter productive. Peter ----- Original Message ----- From: "Gert Doering" To: "Peter Galbavy" Cc: "Gert Doering" ; "Hans Petter Holen" ; "Randy Bush" ; Sent: Friday, May 17, 2002 9:41 AM Subject: Re: neutrality and nat > Hi, > > On Fri, May 17, 2002 at 09:38:36AM +0100, Peter Galbavy wrote: > > I am my ISP. I have my AS, my IPv4 allocation and my upstream(s) - one at > > this exact moment. I still cannot get my IPv6 space. > > Why? Have you read the current policy? If you're an ISP and are serious > about connecting customers, getting an IPv6 allocation should be easy. > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 45114 (45077) > > SpaceNet AG Mail: netmaster at Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > > From gert at space.net Fri May 17 11:00:49 2002 From: gert at space.net (Gert Doering) Date: Fri, 17 May 2002 11:00:49 +0200 Subject: neutrality and nat In-Reply-To: <007801c1fd80$f1b70830$8b0609d4@carpenter>; from peter.galbavy@knowtion.net on Fri, May 17, 2002 at 09:57:58AM +0100 References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> <20020516102831.B13918@Space.Net> <005901c1fcd8$9db19140$8b0609d4@carpenter> <20020516221217.R13918@Space.Net> <006501c1fd7e$3d38e510$8b0609d4@carpenter> <20020517104110.D13918@Space.Net> <007801c1fd80$f1b70830$8b0609d4@carpenter> Message-ID: <20020517110049.H13918@Space.Net> Hi, On Fri, May 17, 2002 at 09:57:58AM +0100, Peter Galbavy wrote: > I may well have missed an announcement, but the last time I looked the rules > were very counter productive. The rules have changed as of the last RIPE meeting. A pointer to the new policy document ("global IPv6 interim policy") should be in the LIR-WG mailing list archives. It is not yet in force, but the action item on the NCC was "make *this* the official policy, and make it *quick*". gert > > Peter > > ----- Original Message ----- > From: "Gert Doering" > To: "Peter Galbavy" > Cc: "Gert Doering" ; "Hans Petter Holen" ; > "Randy Bush" ; > Sent: Friday, May 17, 2002 9:41 AM > Subject: Re: neutrality and nat > > > > Hi, > > > > On Fri, May 17, 2002 at 09:38:36AM +0100, Peter Galbavy wrote: > > > I am my ISP. I have my AS, my IPv4 allocation and my upstream(s) - one > at > > > this exact moment. I still cannot get my IPv6 space. > > > > Why? Have you read the current policy? If you're an ISP and are serious > > about connecting customers, getting an IPv6 allocation should be easy. > > > > Gert Doering > > -- NetMaster > > -- > > Total number of prefixes smaller than registry allocations: 45114 > (45077) > > > > SpaceNet AG Mail: netmaster at Space.Net > > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > > 80807 Muenchen Fax : +49-89-32356-299 > > > > > Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45114 (45077) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From peter.juul at uni-c.dk Fri May 17 10:46:26 2002 From: peter.juul at uni-c.dk (Peter B . Juul) Date: Fri, 17 May 2002 10:46:26 +0200 Subject: neutrality and nat In-Reply-To: <20020517104110.D13918@Space.Net>; from gert@space.net on Fri, May 17, 2002 at 10:41:10AM +0200 References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> <20020516102831.B13918@Space.Net> <005901c1fcd8$9db19140$8b0609d4@carpenter> <20020516221217.R13918@Space.Net> <006501c1fd7e$3d38e510$8b0609d4@carpenter> <20020517104110.D13918@Space.Net> Message-ID: <20020517104626.D13369@uni-c.dk> On Fri, May 17, 2002 at 10:41:10AM +0200, Gert Doering wrote: > Why? Have you read the current policy? If you're an ISP and are serious > about connecting customers, getting an IPv6 allocation should be easy. Oh yes, by the new policy. However, we have to wait for RIPE NCC and the other RIRs to actually implement this policy. That was the reply I got a few days ago, when I wrote RIPE NCC and asked. Peter B. Juul, Uni?C (PBJ255-RIPE) From gert at space.net Fri May 17 11:54:38 2002 From: gert at space.net (Gert Doering) Date: Fri, 17 May 2002 11:54:38 +0200 Subject: neutrality and nat In-Reply-To: <20020517104626.D13369@uni-c.dk>; from peter.juul@uni-c.dk on Fri, May 17, 2002 at 10:46:26AM +0200 References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> <20020516102831.B13918@Space.Net> <005901c1fcd8$9db19140$8b0609d4@carpenter> <20020516221217.R13918@Space.Net> <006501c1fd7e$3d38e510$8b0609d4@carpenter> <20020517104110.D13918@Space.Net> <20020517104626.D13369@uni-c.dk> Message-ID: <20020517115438.L13918@Space.Net> Hi, On Fri, May 17, 2002 at 10:46:26AM +0200, Peter B . Juul wrote: > On Fri, May 17, 2002 at 10:41:10AM +0200, Gert Doering wrote: > > > Why? Have you read the current policy? If you're an ISP and are serious > > about connecting customers, getting an IPv6 allocation should be easy. > Oh yes, by the new policy. Yes, of course. The old policy was not adaequate in any way, which is what (as far as I heard) everybody agreed upon. > However, we have to wait for RIPE NCC and the other RIRs to actually > implement this policy. That was the reply I got a few days ago, when > I wrote RIPE NCC and asked. Did they mention a timeframe? The LIR WG made it pretty clear that this is supposed to happen "soon". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45114 (45077) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From peter.juul at uni-c.dk Fri May 17 11:59:12 2002 From: peter.juul at uni-c.dk (Peter B . Juul) Date: Fri, 17 May 2002 11:59:12 +0200 Subject: neutrality and nat In-Reply-To: <20020517115438.L13918@Space.Net>; from gert@Space.Net on Fri, May 17, 2002 at 11:54:38AM +0200 References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> <20020516102831.B13918@Space.Net> <005901c1fcd8$9db19140$8b0609d4@carpenter> <20020516221217.R13918@Space.Net> <006501c1fd7e$3d38e510$8b0609d4@carpenter> <20020517104110.D13918@Space.Net> <20020517104626.D13369@uni-c.dk> <20020517115438.L13918@Space.Net> Message-ID: <20020517115912.H13369@uni-c.dk> On Fri, May 17, 2002 at 11:54:38AM +0200, Gert Doering wrote: > Did they mention a timeframe? The LIR WG made it pretty clear that > this is supposed to happen "soon". "Probably two weeks", meaning that it'll probably be at least a month before I actually have my prefix. But at least with the new policy I have a reasonable chance of getting those addresses, which is very much a plus-thing. Peter B. Juul, Uni?C (PBJ255-RIPE) From leo at ripe.net Fri May 17 16:39:12 2002 From: leo at ripe.net (leo vegoda) Date: Fri, 17 May 2002 16:39:12 +0200 Subject: neutrality and nat In-Reply-To: <20020517115912.H13369@uni-c.dk> References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> <20020516102831.B13918@Space.Net> <005901c1fcd8$9db19140$8b0609d4@carpenter> <20020516221217.R13918@Space.Net> <006501c1fd7e$3d38e510$8b0609d4@carpenter> <20020517104110.D13918@Space.Net> <20020517104626.D13369@uni-c.dk> <20020517115438.L13918@Space.Net> <20020517115912.H13369@uni-c.dk> Message-ID: <20020517143912.GA1636@ripe.net> Hi Peter, On Fri, May 17, 2002 at 11:59:12AM +0200, Peter B . Juul wrote: Re: Re: neutrality and nat > On Fri, May 17, 2002 at 11:54:38AM +0200, Gert Doering wrote: > > > Did they mention a timeframe? The LIR WG made it pretty clear that > > this is supposed to happen "soon". > > "Probably two weeks", meaning that it'll probably be at least a month before > I actually have my prefix. But at least with the new policy I have a > reasonable chance of getting those addresses, which is very much a plus-thing. We are co-ordinating with ARIN and APNIC on implementing the new Global IPv6 Policy. The three RIRs would like to have a single date from which the new policy is implemented. We expect to be able to publish a date of implementation for the policy next week. Kind regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager From gert at space.net Fri May 17 17:10:56 2002 From: gert at space.net (Gert Doering) Date: Fri, 17 May 2002 17:10:56 +0200 Subject: neutrality and nat In-Reply-To: <20020517143912.GA1636@ripe.net>; from leo@ripe.net on Fri, May 17, 2002 at 04:39:12PM +0200 References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> <20020516102831.B13918@Space.Net> <005901c1fcd8$9db19140$8b0609d4@carpenter> <20020516221217.R13918@Space.Net> <006501c1fd7e$3d38e510$8b0609d4@carpenter> <20020517104110.D13918@Space.Net> <20020517104626.D13369@uni-c.dk> <20020517115438.L13918@Space.Net> <20020517115912.H13369@uni-c.dk> <20020517143912.GA1636@ripe.net> Message-ID: <20020517171055.M13918@Space.Net> Hi, On Fri, May 17, 2002 at 04:39:12PM +0200, leo vegoda wrote: > We are co-ordinating with ARIN and APNIC on implementing the new > Global IPv6 Policy. The three RIRs would like to have a single > date from which the new policy is implemented. Why would that be a desireable goal? Sorry to be so direct - but all outcome I can see from this is "delay", and I do not see any grave danger of having different start dates for the new policy in different regions. There are other differences as well (like "what amount of paperwork do I have to sign beforehand", etc). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45114 (45077) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From hph at online.no Wed May 22 19:33:49 2002 From: hph at online.no (Hans Petter Holen) Date: Wed, 22 May 2002 19:33:49 +0200 Subject: neutrality and nat References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> <20020516102831.B13918@Space.Net> <005901c1fcd8$9db19140$8b0609d4@carpenter> Message-ID: <007201c201b6$d6ddc910$7900a8c0@no.tiscali.com> Why ? If you buy transit from me you can have the IP space from me. (replace me with upstream to make the reply generic :-) -hph ----- Original Message ----- From: "Peter Galbavy" To: "Gert Doering" ; "Hans Petter Holen" Cc: "Randy Bush" ; Sent: Thursday, May 16, 2002 2:53 PM Subject: Re: neutrality and nat | > I seriously think that adding a second question "have you considered IPv6" | > (if only to raise awareness "IPv6 is here to stay") might be a good thing. | | My reply would be templated: | | "I have but I have found that I am not permitted to apply for IPv6 space." | | Peter | | From hph at online.no Wed May 22 19:40:54 2002 From: hph at online.no (Hans Petter Holen) Date: Wed, 22 May 2002 19:40:54 +0200 Subject: IPv4 Address Allocation policies for organisations not connecting to the Internet References: <909B25C2941F454786589E5526526357740886@xbe-lon-303.cisco.com> Message-ID: <00bc01c201b7$d34a9ac0$7900a8c0@no.tiscali.com> MessageAs far as I understand this is covered by the Provider Independent Address space http://www.ripe.net/ripe/docs/pi-pa.html -hph ----- Original Message ----- From: Peter Emptage To: lir-wg at ripe.net Sent: Tuesday, May 14, 2002 3:32 PM 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.galbavy at knowtion.net Wed May 22 19:46:00 2002 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Wed, 22 May 2002 18:46:00 +0100 Subject: neutrality and nat References: <00f601c1fc36$863d6a90$7c0a0a0a@no.tiscali.com> <20020516102831.B13918@Space.Net> <005901c1fcd8$9db19140$8b0609d4@carpenter> <007201c201b6$d6ddc910$7900a8c0@no.tiscali.com> Message-ID: <003d01c201b8$8937a210$8a0609d4@carpenter> > Why ? > If you buy transit from me you can have the IP space from me. > > (replace me with upstream to make the reply generic :-) And if I am connected to two upstreams and do BGP ? Why do I want two address spaces. IPv6 needs to map back onto existing IPv4 architectures to make it feasible. Peter From mir at ripe.net Thu May 23 15:45:44 2002 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 23 May 2002 15:45:44 +0200 Subject: Implementation of Global IPv6 Policy Message-ID: <20020523134544.GC21422@ripe.net> Dear Colleagues, We are pleased to announce that the RIPE NCC will implement the new Global IPv6 Policy on 1 July 2002. This policy has been agreed by the communities of all the Regional Internet Registries (RIRs). Before 1 July 2002 we will publish and announce the following as RIPE Documents: - Global IPv6 Policy Document - Initial IPv6 Allocation Request Form in the RIPE NCC Service Region - IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region (for prefixes shorter than a /48) Regards, -- Mirjam Kuehne RIPE NCC From mir at ripe.net Thu May 23 15:45:44 2002 From: mir at ripe.net (mir at ripe.net) Date: Thu, 23 May 2002 15:45:44 +0200 Subject: Implementation of Global IPv6 Policy In-Reply-To: <20020523134544.GC21422@ripe.net> References: <20020523134544.GC21422@ripe.net> Message-ID: Dear Colleagues, We are pleased to announce that the RIPE NCC will implement the new Global IPv6 Policy on 1 July 2002. This policy has been agreed by the communities of all the Regional Internet Registries (RIRs). Before 1 July 2002 we will publish and announce the following as RIPE Documents: - Global IPv6 Policy Document - Initial IPv6 Allocation Request Form in the RIPE NCC Service Region - IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region (for prefixes shorter than a /48) Regards, -- Mirjam Kuehne RIPE NCC From david at IPRG.nokia.com Fri May 24 00:30:01 2002 From: david at IPRG.nokia.com (David Kessens) Date: Thu, 23 May 2002 15:30:01 -0700 Subject: Implementation of Global IPv6 Policy In-Reply-To: <20020523134544.GC21422@ripe.net>; from mir@ripe.net on Thu, May 23, 2002 at 03:45:44PM +0200 References: <20020523134544.GC21422@ripe.net> Message-ID: <20020523153001.D6142@iprg.nokia.com> Mirjam, On Thu, May 23, 2002 at 03:45:44PM +0200, Mirjam Kuehne wrote: > > We are pleased to announce that the RIPE NCC will implement the new > Global IPv6 Policy on 1 July 2002. This policy has been agreed by > the communities of all the Regional Internet Registries (RIRs). > > Before 1 July 2002 we will publish and announce the following as > RIPE Documents: > > - Global IPv6 Policy Document > - Initial IPv6 Allocation Request Form in the RIPE NCC > Service Region > - IPv6 End User Site Assignment Request Form in the RIPE > NCC Service Region (for prefixes shorter than a /48) I would like to thank you and everybody else at the RIPE NCC who worked on the introduction of the new policy for getting the policy implemented so swiftly! David K. --- From pekkas at netcore.fi Fri May 24 08:02:09 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 24 May 2002 09:02:09 +0300 (EEST) Subject: Implementation of Global IPv6 Policy In-Reply-To: <20020523153001.D6142@iprg.nokia.com> Message-ID: On Thu, 23 May 2002, David Kessens wrote: > On Thu, May 23, 2002 at 03:45:44PM +0200, Mirjam Kuehne wrote: > > > > We are pleased to announce that the RIPE NCC will implement the new > > Global IPv6 Policy on 1 July 2002. This policy has been agreed by > > the communities of all the Regional Internet Registries (RIRs). > > > > Before 1 July 2002 we will publish and announce the following as > > RIPE Documents: > > > > - Global IPv6 Policy Document > > - Initial IPv6 Allocation Request Form in the RIPE NCC > > Service Region > > - IPv6 End User Site Assignment Request Form in the RIPE > > NCC Service Region (for prefixes shorter than a /48) > > I would like to thank you and everybody else at the RIPE NCC who > worked on the introduction of the new policy for getting the policy > implemented so swiftly! I guess one could say 2 months is swift. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From randy at psg.com Fri May 24 08:06:27 2002 From: randy at psg.com (Randy Bush) Date: Thu, 23 May 2002 23:06:27 -0700 Subject: Implementation of Global IPv6 Policy References: <20020523153001.D6142@iprg.nokia.com> Message-ID: >> I would like to thank you and everybody else at the RIPE NCC who >> worked on the introduction of the new policy for getting the policy >> implemented so swiftly! > I guess one could say 2 months is swift. indeed, especially if you remember what these two wgs did in prague. the members of the other registries have been overly polite about waiting for these ripe wgs to stop smoking "everybody should get a /whatever, v6 space and your routing table are infinite." randy From gert at space.net Fri May 24 10:28:55 2002 From: gert at space.net (Gert Doering) Date: Fri, 24 May 2002 10:28:55 +0200 Subject: Implementation of Global IPv6 Policy In-Reply-To: ; from randy@psg.com on Thu, May 23, 2002 at 11:06:27PM -0700 References: <20020523153001.D6142@iprg.nokia.com> Message-ID: <20020524102855.Z13918@Space.Net> Hi, On Thu, May 23, 2002 at 11:06:27PM -0700, Randy Bush wrote: > >> I would like to thank you and everybody else at the RIPE NCC who > >> worked on the introduction of the new policy for getting the policy > >> implemented so swiftly! > > I guess one could say 2 months is swift. > > indeed, especially if you remember what these two wgs did in prague. > the members of the other registries have been overly polite about > waiting for these ripe wgs to stop smoking "everybody should get a > /whatever, v6 space and your routing table are infinite." Well... that's one way to view it, of course. One could as well say "everybody has been struggling with the stupid IETF/IAB /48 rule and the fact that the ARIN region is disinterested enough in IPv6 to be conservative to the point of stagnation..." Neither is really helpful. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45114 (45077) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From ncc at ripe.net Fri May 24 17:01:15 2002 From: ncc at ripe.net (RIPE NCC Document Announcement Service) Date: Fri, 24 May 2002 17:01:15 +0200 Subject: New Document available: RIPE-233 Message-ID: <200205241501.g4OF1F213064@birch.ripe.net> New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-233 Title: IPv6 Addresses for Internet Root Servers in the RIPE Region Author: Joao Luis Silva Damas Date: 24 May 2002 Format: PS=9362 TXT=2362 Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- The "IPv6 Addresses for Internet Root Servers in the RIPE Region" document describes the special case assignment policy for Internet DNS root servers in the RIPE region. Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The document will be available shortly on the FTP-server at: ftp://ftp.ripe.net/ripe/docs/ripe-233.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-233.txt plain text version You can already access the RIPE document in HTML format via WWW at: http://www.ripe.net/docs/ipv6-rootservers.html Kind Regards, Jeroen Bet RIPE NCC Webmaster From bernard.tuy at renater.fr Fri May 24 16:55:19 2002 From: bernard.tuy at renater.fr (Bernard Tuy) Date: Fri, 24 May 2002 16:55:19 +0200 Subject: Implementation of Global IPv6 Policy References: <20020523134544.GC21422@ripe.net> <20020523153001.D6142@iprg.nokia.com> Message-ID: <3CEE5457.11B29DD1@renater.fr> ====BT: Hi Mirjam, I'd like to join David's congrutalations for the excellent work achieved. It seems we end up in a situation where everybody will be able to deploy IPv6 services in a quite straight forward way. The important thing to bear in mind is -evenif some could complain about time delays- we use to revise periodically our policies with the experience we got, and it seems to me very important to go ahead with this good usage. Appointment in one year from now ? Thanx a lot, +bernard T. --- David Kessens wrote: > > Mirjam, > > On Thu, May 23, 2002 at 03:45:44PM +0200, Mirjam Kuehne wrote: > > > > We are pleased to announce that the RIPE NCC will implement the new > > Global IPv6 Policy on 1 July 2002. This policy has been agreed by > > the communities of all the Regional Internet Registries (RIRs). > > > > Before 1 July 2002 we will publish and announce the following as > > RIPE Documents: > > > > - Global IPv6 Policy Document > > - Initial IPv6 Allocation Request Form in the RIPE NCC > > Service Region > > - IPv6 End User Site Assignment Request Form in the RIPE > > NCC Service Region (for prefixes shorter than a /48) > > I would like to thank you and everybody else at the RIPE NCC who > worked on the introduction of the new policy for getting the policy > implemented so swiftly! > > David K. > --- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2477 bytes Desc: S/MIME Cryptographic Signature URL: From matthew.ford at bt.com Fri May 24 17:23:09 2002 From: matthew.ford at bt.com (matthew.ford at bt.com) Date: Fri, 24 May 2002 16:23:09 +0100 Subject: New Document available: RIPE-233 Message-ID: " It is not associated with the organisation(s) that operate the root server at a particular point in time and these organisations should not use the address space to provide any services not related to the root server." s/should/must/ Mat. > -----Original Message----- > From: RIPE NCC Document Announcement Service [mailto:ncc at ripe.net] > Sent: 24 May 2002 16:01 > To: ipv6-wg at ripe.net > Cc: lir-wg at ripe.net > Subject: New Document available: RIPE-233 > From crain at icann.org Fri May 24 21:15:18 2002 From: crain at icann.org (John L Crain) Date: Fri, 24 May 2002 12:15:18 -0700 Subject: New Document available: RIPE-233 In-Reply-To: <200205241501.g4OF1F213064@birch.ripe.net> Message-ID: <5.1.0.14.0.20020524120612.03f93d38@127.0.0.1> Question: Why would you make a root-server renumber if it changes areas? The document starts by talking about why the servers are special and it is difficult to change the addresses etc. It ends by saying that if they change region they will have to renumber. Is there an explanation for this. At present we are talking about 13 servers I can't think of any large issues that would be caused by having the addresses routed from elsewhere outside the RIPE region. Maybe I'm missing something crucial? JC From pekkas at netcore.fi Sat May 25 09:32:14 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 25 May 2002 10:32:14 +0300 (EEST) Subject: New Document available: RIPE-233 In-Reply-To: <20020524213925.A49252@foobar.nisse.dk> Message-ID: On Fri, 24 May 2002, Robert Martin-Leg?ne wrote: > On Fri, May 24, 2002 at 05:01:15PM +0200, RIPE NCC Document Announcement Service wrote: > > Ref: ripe-233 > > Title: IPv6 Addresses for Internet Root Servers in the RIPE Region > > I heard someone suggest that all allocations should be done from > the same superblock. Although it's not in the document, I think > it makes sense. We all hate our martian filters, so putting the > "exception to the rule" in the same superblock will make your name > go over in history. This is assigning /32's to root servers. There are no need for "exceptions to the rule", unless you're thinking of e.g. special rules for BGP flap dampening for root servers or such. Btw, I agree with Matthew Ford that 'should' was too mild a word. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From joao at ripe.net Tue May 28 10:43:52 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Tue, 28 May 2002 10:43:52 +0200 Subject: New Document available: RIPE-233 In-Reply-To: <5.1.0.14.0.20020524120612.03f93d38@127.0.0.1> References: <5.1.0.14.0.20020524120612.03f93d38@127.0.0.1> Message-ID: John the idea is to treat this block of addresses as any other issued by the RIPE NCC. If the root server changes region, I will change administration (sort of having an LIR closing down). The new operator would request addresses somewhere else, or put forward a case to the LIR-WG to ask the RIPE NCC to re-issue the allocation to the root server at the new place. Things are better without exceptions, that's all Cheers, Joao From john at chagres.net Tue May 28 10:55:28 2002 From: john at chagres.net (John M. Brown) Date: Tue, 28 May 2002 02:55:28 -0600 Subject: New Document available: RIPE-233 In-Reply-To: Message-ID: Having to "force" a root server to renumber if it goes out of RIPE's region seems like a bad idea. ARIN's micro allocation policy does not specifically require a renumber for critical (root-server) infrastructure, should that infrastructure move outside of ARIN's region. So, maybe the root-servers should goto IANA and be allocated IP space directly from IANA and thus be a "special RIR" ?? John Brown Chagres Technologies, Inc critical infrastructure != LIR winding up > -----Original Message----- > From: owner-lir-wg at ripe.net > [mailto:owner-lir-wg at ripe.net]On Behalf Of > Joao Luis Silva Damas > Sent: Tuesday, May 28, 2002 2:44 AM > To: John L Crain; webmaster at ripe.net > Cc: ipv6-wg at ripe.net; lir-wg at ripe.net > Subject: Re: New Document available: RIPE-233 > > > John > > the idea is to treat this block of addresses as any other issued by > the RIPE NCC. > If the root server changes region, I will change > administration (sort > of having an LIR closing down). The new operator would request > addresses somewhere else, or put forward a case to the > LIR-WG to ask > the RIPE NCC to re-issue the allocation to the root server > at the new > place. > > Things are better without exceptions, that's all > > Cheers, > Joao From crain at icann.org Tue May 28 16:19:31 2002 From: crain at icann.org (John L Crain) Date: Tue, 28 May 2002 07:19:31 -0700 Subject: New Document available: RIPE-233 In-Reply-To: References: <5.1.0.14.0.20020524120612.03f93d38@127.0.0.1> <5.1.0.14.0.20020524120612.03f93d38@127.0.0.1> Message-ID: <5.1.0.14.0.20020528071145.046b0e78@127.0.0.1> H Joao Isn't the whole policy in itself is a single, and to be a very clearly defined, exception? So if we have to make this one exception because of the issues stated, i.e. difficulty in renumbering etc. Why not make the exception in such a manner that the address block is allocated to the specific root-server and stays with that root server, no matter where it goes? The idea of having them possibly need to renumber, when they move, be treated just like any other network (or LIR) to my mind defeats a large part of the point of the exception. JC At 10:43 AM 5/28/2002 +0200, Joao Luis Silva Damas wrote: >John > >the idea is to treat this block of addresses as any other issued by the >RIPE NCC. >If the root server changes region, I will change administration (sort of >having an LIR closing down). The new operator would request addresses >somewhere else, or put forward a case to the LIR-WG to ask the RIPE NCC to >re-issue the allocation to the root server at the new place. > >Things are better without exceptions, that's all > >Cheers, >Joao From david at IPRG.nokia.com Tue May 28 22:29:59 2002 From: david at IPRG.nokia.com (David Kessens) Date: Tue, 28 May 2002 13:29:59 -0700 Subject: New Document available: RIPE-233 In-Reply-To: <5.1.0.14.0.20020528071145.046b0e78@127.0.0.1>; from crain@icann.org on Tue, May 28, 2002 at 07:19:31AM -0700 References: <5.1.0.14.0.20020524120612.03f93d38@127.0.0.1> <5.1.0.14.0.20020524120612.03f93d38@127.0.0.1> <5.1.0.14.0.20020528071145.046b0e78@127.0.0.1> Message-ID: <20020528132959.C17579@iprg.nokia.com> John, Joao, On Tue, May 28, 2002 at 07:19:31AM -0700, John L Crain wrote: > > Isn't the whole policy in itself is a single, and to be a very clearly > defined, exception? > > So if we have to make this one exception because of the issues stated, i.e. > difficulty in renumbering etc. Why not make the exception in such a manner > that the address block is > allocated to the specific root-server and stays with that root server, no > matter where it goes? > > The idea of having them possibly need to renumber, when they move, be > treated just like any other network (or LIR) to my mind defeats a large > part of the point of the exception. I agree. In addition, just like we asked the registries to use a single block of addresses worldwide for exchange points, it seems to make sense to do the same thing (but a different block!) for rootname servers. Would it not be possible to coordinate such a block with the other RIRs ?!? David K. --- From kurtis at kpnqwest.net Wed May 29 09:46:41 2002 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Wed, 29 May 2002 09:46:41 +0200 (MEST) Subject: IPv6 policy and Supernational-LIRs Message-ID: Now that we have the new IPv6 policy in place, and we have try and start using it, I have a small problem. We have been allocated a IPv6 block for the Supernational-LIR. However, the actual LIR consits of several ASes, each present at it's own IX and with it's own routing policy. To me, a Supernational-LIR consists of several sub-LIRs. My problem is that RIPE will only allocate on /35 block to us, saying that is the allocation for our LIR. This means that we will end up having to break that block into smaller announcements, one per each sub-LIR. Could someone elaborate on the thinking behind this policy. To me it would routingwise make more sense to allocate a block per sub-LIR. Best regards, - kurtis - From joao at ripe.net Wed May 29 10:00:24 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Wed, 29 May 2002 10:00:24 +0200 Subject: New Document available: RIPE-233 In-Reply-To: <20020528132959.C17579@iprg.nokia.com> References: <5.1.0.14.0.20020524120612.03f93d38@127.0.0.1> <5.1.0.14.0.20020524120612.03f93d38@127.0.0.1> <5.1.0.14.0.20020528071145.046b0e78@127.0.0.1> <20020528132959.C17579@iprg.nokia.com> Message-ID: At 13:29 -0700 28/5/02, David Kessens wrote: > >I agree. In addition, just like we asked the registries to use a >single block of addresses worldwide for exchange points, it seems to >make sense to do the same thing (but a different block!) for rootname >servers. Would it not be possible to coordinate such a block with the >other RIRs ?!? Actually I think it makes much more operational sense to *not* put all the root name servers in one block. Joao From fredrik at sunet.se Wed May 29 10:14:34 2002 From: fredrik at sunet.se (Fredrik Widell) Date: Wed, 29 May 2002 10:14:34 +0200 (CEST) Subject: IPv6 policy and Supernational-LIRs In-Reply-To: Message-ID: On Wed, 29 May 2002, Kurt Erik Lindqvist KPNQwest wrote: > > > > Now that we have the new IPv6 policy in place, and we have try and start > using it, I have a small problem. We have been allocated a IPv6 block for > the Supernational-LIR. However, the actual LIR consits of several ASes, > each present at it's own IX and with it's own routing policy. > > To me, a Supernational-LIR consists of several sub-LIRs. My problem is > that RIPE will only allocate on /35 block to us, saying that is the > allocation for our LIR. This means that we will end up having to break > that block into smaller announcements, one per each sub-LIR. > > Could someone elaborate on the thinking behind this policy. To me it would > routingwise make more sense to allocate a block per sub-LIR. To me, it would make sense to allocate a /3x to each and every one who has an AS#, and requests ipv6-space, then we would NOT have any problem like the above or with 'multihoming' either. It is not like the adresses would be used-up with this scenario.. > > Best regards, > > - kurtis - > -- Regards /Fredrik ------------------------------------------------------- KTHNOC, KTH, S-100 44 Stockholm, Sweden +46 8 790 65 17 ------------------------------------------------------- From gert at space.net Wed May 29 10:48:19 2002 From: gert at space.net (Gert Doering) Date: Wed, 29 May 2002 10:48:19 +0200 Subject: IPv6 policy and Supernational-LIRs In-Reply-To: ; from fredrik@sunet.se on Wed, May 29, 2002 at 10:14:34AM +0200 References: Message-ID: <20020529104819.I13918@Space.Net> Hi, On Wed, May 29, 2002 at 10:14:34AM +0200, Fredrik Widell wrote: > To me, it would make sense to allocate a /3x to each and every one who has > an AS#, and requests ipv6-space, then we would NOT have any problem like the > above or with 'multihoming' either. It is not like the adresses would be used-up > with this scenario.. Won't really solve anything - it will just move the question to "who is entitled to get an AS number?" and "do we really want to see 32 bit AS numbers?". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45201 (45114) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From pekkas at netcore.fi Wed May 29 11:20:36 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 29 May 2002 12:20:36 +0300 (EEST) Subject: New Document available: RIPE-233 In-Reply-To: Message-ID: On Wed, 29 May 2002, Joao Luis Silva Damas wrote: > At 13:29 -0700 28/5/02, David Kessens wrote: > > > >I agree. In addition, just like we asked the registries to use a > >single block of addresses worldwide for exchange points, it seems to > >make sense to do the same thing (but a different block!) for rootname > >servers. Would it not be possible to coordinate such a block with the > >other RIRs ?!? > > Actually I think it makes much more operational sense to *not* put > all the root name servers in one block. Definitely not one _/32_, that's for sure. But 10 different /32's, from one /27 (for example)? Seems just fine to me. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From john at chagres.net Wed May 29 11:05:31 2002 From: john at chagres.net (John M. Brown) Date: Wed, 29 May 2002 03:05:31 -0600 Subject: New Document available: RIPE-233 In-Reply-To: Message-ID: I would agree that having them in on single block could make for certain types of capture problems. Thus having the RIR assign a "random" block to a root server would be a good thing. As long as it doesn't mandate a renumber of the server should it re-locate. john brown > -----Original Message----- > From: owner-lir-wg at ripe.net > [mailto:owner-lir-wg at ripe.net]On Behalf Of > Joao Luis Silva Damas > Sent: Wednesday, May 29, 2002 2:00 AM > To: David Kessens > Cc: ipv6-wg at ripe.net; lir-wg at ripe.net > Subject: Re: New Document available: RIPE-233 > > > At 13:29 -0700 28/5/02, David Kessens wrote: > > > >I agree. In addition, just like we asked the registries to use a > >single block of addresses worldwide for exchange points, > it seems to > >make sense to do the same thing (but a different block!) > for rootname > >servers. Would it not be possible to coordinate such a > block with the > >other RIRs ?!? > > Actually I think it makes much more operational sense to *not* put > all the root name servers in one block. > > Joao From gert at space.net Wed May 29 11:18:40 2002 From: gert at space.net (Gert Doering) Date: Wed, 29 May 2002 11:18:40 +0200 Subject: IPv6 policy and Supernational-LIRs In-Reply-To: ; from kurtis@kpnqwest.net on Wed, May 29, 2002 at 10:54:42AM +0200 References: <20020529104819.I13918@Space.Net> Message-ID: <20020529111840.K13918@Space.Net> Hi, On Wed, May 29, 2002 at 10:54:42AM +0200, Kurt Erik Lindqvist KPNQwest wrote: > > me, it would make sense to allocate a /3x to each and every one who > > has > an AS#, and requests ipv6-space, then we would NOT have any > > problem like the > above or with 'multihoming' either. It is not like > > the adresses would be used-up > with this scenario.. > > > > Won't really solve anything - it will just move the question to "who is > > entitled to get an AS number?" and "do we really want to see 32 bit AS > > numbers?". > We could always go for 128-bits! :) The problem with that isn't so much the lenght of the number (that's just "linear memory waste"), the problem that I see is that the number of ASes actually in use reflect the complexity of the overall topology - and *that* goes into BGP convergence times much stronger than linearily. > Seriously, what about the orginal problem? Is there any logical reason as > to why not the Supernational-LIRs would not be allocated a block per > sub-LIR? I can speak only for myself here, of course. The way I see the current (new) policy, and the idea behind it, is to use *hierarchical aggregation*, which means "you get one big block and feed your sub-LIRs out of this". If you have a big block, say a /28, and each of your sub-LIRs gets a /32 out of it, and those that really need it announce the /32 to the world, the net impact on BGP is mostly the same, but for documentation purposes, it's still clear that "yes, this is all the same LIR". Not all of the /32s might even necessarily be visible globally, upstream could go through the /28. The new policy (effective next monday) will permit this - if you come up with good reasons and some thought about addressing plans and hierarchy, getting something "large enough" should not be a unsolveable problem. At least that was the intention - the address space is large enough so that haggling over "we need a /28" - "no you can only get a /31 plus a /32" should not occur (unless the "need" for a /28 really isn't justificable). Does this make sense to anybody? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45201 (45114) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From pekkas at netcore.fi Wed May 29 11:46:41 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 29 May 2002 12:46:41 +0300 (EEST) Subject: IPv6 policy and Supernational-LIRs In-Reply-To: <20020529111840.K13918@Space.Net> Message-ID: On Wed, 29 May 2002, Gert Doering wrote: > The new policy (effective next monday) will permit this - if you come up You mean, effective 1 Jul 2002. - Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From gert at space.net Wed May 29 11:54:51 2002 From: gert at space.net (Gert Doering) Date: Wed, 29 May 2002 11:54:51 +0200 Subject: IPv6 policy and Supernational-LIRs In-Reply-To: ; from pekkas@netcore.fi on Wed, May 29, 2002 at 12:46:41PM +0300 References: <20020529111840.K13918@Space.Net> Message-ID: <20020529115451.N13918@Space.Net> Hi, On Wed, May 29, 2002 at 12:46:41PM +0300, Pekka Savola wrote: > On Wed, 29 May 2002, Gert Doering wrote: > > The new policy (effective next monday) will permit this - if you come up > You mean, effective 1 Jul 2002. July? Ooops. I thought that was "June". Hrm. So we'll have to wait a bit longer :-/ Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45201 (45114) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From alan at linerate.net Wed May 29 12:29:10 2002 From: alan at linerate.net (Alan Sawyer) Date: Wed, 29 May 2002 20:29:10 +1000 (EST) Subject: IPv6 policy and Supernational-LIRs In-Reply-To: Message-ID: On Wed, 29 May 2002, Fredrik Widell wrote: > On Wed, 29 May 2002, Kurt Erik Lindqvist KPNQwest wrote: > To me, it would make sense to allocate a /3x to each and every one who has > an AS#, and requests ipv6-space, then we would NOT have any problem like the > above or with 'multihoming' either. It is not like the adresses would be used-up > with this scenario.. Providers state that aggregation/hierarchy is needed because of faster convergence time and less wasted resources (among other valid reasons). Customers appear to believe that providers are less reliable than the other business critical services they may depend on (read the SLA offered to clients and the financial penalties applied for outages, draw a conclusion) >From an engineering perspective the providers are correct in their conclusion. >From a commercial perspective the customers seem justified in theirs. It does seem as if the desire to multihome (as a (perceived|actual)) form of risk management will continue to be an issue for the M/L Enterprise which needs to be addressed by the SP community. Rightly or wrongly. A- > > > > > > > Best regards, > > > > - kurtis - > > > > From randy at psg.com Wed May 29 11:52:40 2002 From: randy at psg.com (Randy Bush) Date: Wed, 29 May 2002 02:52:40 -0700 Subject: New Document available: RIPE-233 References: <5.1.0.14.0.20020524120612.03f93d38@127.0.0.1> <5.1.0.14.0.20020528071145.046b0e78@127.0.0.1> <20020528132959.C17579@iprg.nokia.com> Message-ID: > Actually I think it makes much more operational sense to *not* put > all the root name servers in one block. agreed^2 if one believes this scenario, than each having its own normal sized (i.e. globally routable) block is the only method i can see. [ unless we want to discuss the anycast path ] randy From jhma at mcvax.org Wed May 29 11:29:33 2002 From: jhma at mcvax.org (James Aldridge) Date: Wed, 29 May 2002 09:29:33 +0000 Subject: IPv6 policy and Supernational-LIRs In-Reply-To: Message from Kurt Erik Lindqvist KPNQwest of "Wed, 29 May 2002 09:46:41 +0200." Message-ID: Kurt Erik Lindqvist KPNQwest wrote: > Now that we have the new IPv6 policy in place, and we have try and start > using it, I have a small problem. We have been allocated a IPv6 block for > the Supernational-LIR. However, the actual LIR consits of several ASes, > each present at it's own IX and with it's own routing policy. > > To me, a Supernational-LIR consists of several sub-LIRs. My problem is > that RIPE will only allocate on /35 block to us, saying that is the > allocation for our LIR. This means that we will end up having to break > that block into smaller announcements, one per each sub-LIR. There is a definite change between the IPv4 and IPv6 allocation policies for supernational LIRs as far as the RIPE NCC is concerned. For IPv4, supernational registries (contributing as, for example, as KPNQwest does for the eu.eunet registry, the equivalent of 6 large LIRs) would receive up to 1.5 times the number of allocations from the NCC that a single large registry would get. For IPv6, on the other hand, a supernational registry can only get a single allocation, irrespective of its size and contributions to the NCC. I don't recall this policy change being discussed in the RIPE policy making forum (the LIR WG) being being put in place by the NCC for the then interim IPv6 policy. I am aware that there are few supernational registries and that they are a pain for the RIPE NCC but this policyy change seems to work against the aggregation principles we need to follow if we're not going to have the routing table growth rate we've seen with IPv4. James From phk at critter.freebsd.dk Wed May 29 11:14:06 2002 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Wed, 29 May 2002 11:14:06 +0200 Subject: IPv6 policy and Supernational-LIRs In-Reply-To: Your message of "Wed, 29 May 2002 10:48:19 +0200." <20020529104819.I13918@Space.Net> Message-ID: <12069.1022663646@critter.freebsd.dk> In message <20020529104819.I13918 at Space.Net>, Gert Doering writes: >Won't really solve anything - it will just move the question to "who is >entitled to get an AS number?" and "do we really want to see 32 bit AS >numbers?". Considering that we are running out of 16 bit numbers, and considering that no other viable multihoming option has been found yet in either of IPv4 and IPv6, I think 32bit AS numbers are a foregone conclusion... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From kurtis at kpnqwest.net Wed May 29 10:54:42 2002 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Wed, 29 May 2002 10:54:42 +0200 (MEST) Subject: IPv6 policy and Supernational-LIRs In-Reply-To: <20020529104819.I13918@Space.Net> Message-ID: > me, it would make sense to allocate a /3x to each and every one who > has > an AS#, and requests ipv6-space, then we would NOT have any > problem like the > above or with 'multihoming' either. It is not like > the adresses would be used-up > with this scenario.. > > Won't really solve anything - it will just move the question to "who is > entitled to get an AS number?" and "do we really want to see 32 bit AS > numbers?". We could always go for 128-bits! :) Seriously, what about the orginal problem? Is there any logical reason as to why not the Supernational-LIRs would not be allocated a block per sub-LIR? Best regards, - kurtis - From oppermann at pipeline.ch Wed May 29 14:06:14 2002 From: oppermann at pipeline.ch (Andre Oppermann) Date: Wed, 29 May 2002 14:06:14 +0200 Subject: IPv6 policy and Supernational-LIRs References: <12069.1022663646@critter.freebsd.dk> Message-ID: <3CF4C436.ABB406E8@pipeline.ch> Poul-Henning Kamp wrote: > > In message <20020529104819.I13918 at Space.Net>, Gert Doering writes: > > >Won't really solve anything - it will just move the question to "who is > >entitled to get an AS number?" and "do we really want to see 32 bit AS > >numbers?". > > Considering that we are running out of 16 bit numbers, and considering > that no other viable multihoming option has been found yet in either of > IPv4 and IPv6, I think 32bit AS numbers are a foregone conclusion... How about BGPDNS? See http://www.bgpdns.org. It could stop quit a number of those multihomed /24s. -- Andre AO6-RIPE From gert at space.net Wed May 29 14:29:22 2002 From: gert at space.net (Gert Doering) Date: Wed, 29 May 2002 14:29:22 +0200 Subject: IPv6 policy and Supernational-LIRs In-Reply-To: ; from jhma@mcvax.org on Wed, May 29, 2002 at 09:29:33AM +0000 References: Message-ID: <20020529142922.R13918@Space.Net> Hi, On Wed, May 29, 2002 at 09:29:33AM +0000, James Aldridge wrote: > For IPv6, on the other hand, a supernational registry can only get a single > allocation, irrespective of its size and contributions to the NCC. I don't > recall this policy change being discussed in the RIPE policy making forum (the > LIR WG) being being put in place by the NCC for the then interim IPv6 policy. > > I am aware that there are few supernational registries and that they are a > pain for the RIPE NCC but this policyy change seems to work against the > aggregation principles we need to follow if we're not going to have the > routing table growth rate we've seen with IPv4. I don't understand why "not giving out multiple IPv6 blocks" is "against the aggregation principles". Could you elaborate on this? Being a bit more relaxed in judging whether a multinational LIR really needs a "/22" (to be a bit extreme) would mimic the "IPv4 approach" (give out more space than usual) fairly well. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45201 (45114) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From jhma at mcvax.org Wed May 29 16:33:04 2002 From: jhma at mcvax.org (James Aldridge) Date: Wed, 29 May 2002 14:33:04 +0000 Subject: IPv6 policy and Supernational-LIRs In-Reply-To: Message from Gert Doering of "Wed, 29 May 2002 14:29:22 +0200." <20020529142922.R13918@Space.Net> Message-ID: Gert Doering wrote: > Hi, > > On Wed, May 29, 2002 at 09:29:33AM +0000, James Aldridge wrote: > > For IPv6, on the other hand, a supernational registry can only get a single > > allocation, irrespective of its size and contributions to the NCC. I don't > > recall this policy change being discussed in the RIPE policy making forum (the > > LIR WG) being being put in place by the NCC for the then interim IPv6 policy. > > > > I am aware that there are few supernational registries and that they are a > > pain for the RIPE NCC but this policyy change seems to work against the > > aggregation principles we need to follow if we're not going to have the > > routing table growth rate we've seen with IPv4. > > I don't understand why "not giving out multiple IPv6 blocks" is > "against the aggregation principles". > > Could you elaborate on this? The old IPv6 policy gave a single /35 to a supernational registry. This meant that each "sub-LIR" would have to put up with, say, a /40 (enough for a mere 256 /48 assignments) and once this was used it would be unlikely that the next /40 available from the LIR's allocation would form an aggregatable block with the earlier "sub-allocation". With different "sub-LIRs" having different (national) routing policies, these multiple non-aggregatable blocks would have to be announced to peers. This doesn't sound like following aggregation principles to me ;-) However, that was the old IPv6 policy... > Being a bit more relaxed in judging whether a multinational LIR really > needs a "/22" (to be a bit extreme) would mimic the "IPv4 approach" > (give out more space than usual) fairly well. ... yes, I'm sure this would help. The supernational LIR adds a few extra levels of hierarchy here: - RIR - Supernational LIR - "sub-LIR" - sub-LIR's ISP customers (who are either not LIRs or LIRs who don't meet current IPv6 criteria) - end-user assignments If a hierarchy such as this could be used to justify a larger-than-/32 allocation then I don't think that big supernational registries would have any particular problems. James From gert at space.net Wed May 29 17:10:27 2002 From: gert at space.net (Gert Doering) Date: Wed, 29 May 2002 17:10:27 +0200 Subject: IPv6 policy and Supernational-LIRs In-Reply-To: ; from jhma@mcvax.org on Wed, May 29, 2002 at 02:33:04PM +0000 References: Message-ID: <20020529171027.B13918@Space.Net> Hi, On Wed, May 29, 2002 at 02:33:04PM +0000, James Aldridge wrote: > > I don't understand why "not giving out multiple IPv6 blocks" is > > "against the aggregation principles". > > > > Could you elaborate on this? > > The old IPv6 policy gave a single /35 to a supernational registry. This meant [..] > However, that was the old IPv6 policy... Now I understand your point. Yes, under the old IPv6 policy, there was no way a "decentralized entity" could do proper networking and aggregation. This is why the new policy has so much focus on "be liberal in judging address space requests", "HD ratio", and so on. I hope it will work. > > Being a bit more relaxed in judging whether a multinational LIR really > > needs a "/22" (to be a bit extreme) would mimic the "IPv4 approach" > > (give out more space than usual) fairly well. > > ... yes, I'm sure this would help. The supernational LIR adds a few extra > levels of hierarchy here: > > - RIR > - Supernational LIR > - "sub-LIR" > - sub-LIR's ISP customers (who are either not LIRs or LIRs who don't > meet current IPv6 criteria) > - end-user assignments Of course. And what makes this worse is that the "sub/national-LIR" level is visible in external BGP, which is not the case for "normal" hierachical allocations. > If a hierarchy such as this could be used to justify a larger-than-/32 > allocation then I don't think that big supernational registries would have any > particular problems. I would strongly favour this approach. Of course I do not speek for the IPv6 WG or the NCC. But I think the new policy is meant to be read that way, and "if we waste a /16 on all of the 10 (?) every supernational LIRs", so what (being provocative again). Conservation is NOT a high-prio issue. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45201 (45114) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From oppermann at pipeline.ch Wed May 29 14:06:14 2002 From: oppermann at pipeline.ch (Andre Oppermann) Date: Wed, 29 May 2002 14:06:14 +0200 Subject: IPv6 policy and Supernational-LIRs References: <12069.1022663646@critter.freebsd.dk> Message-ID: <20020529150513.8662.qmail@mail-int.eurodata.de> Poul-Henning Kamp wrote: > > In message <20020529104819.I13918 at Space.Net>, Gert Doering writes: > > >Won't really solve anything - it will just move the question to "who is > >entitled to get an AS number?" and "do we really want to see 32 bit AS > >numbers?". > > Considering that we are running out of 16 bit numbers, and considering > that no other viable multihoming option has been found yet in either of > IPv4 and IPv6, I think 32bit AS numbers are a foregone conclusion... How about BGPDNS? See http://www.bgpdns.org. It could stop quit a number of those multihomed /24s. -- Andre AO6-RIPE From he at uninett.no Wed May 29 18:03:37 2002 From: he at uninett.no (Havard Eidnes) Date: Wed, 29 May 2002 18:03:37 +0200 (CEST) Subject: IPv6 policy and Supernational-LIRs In-Reply-To: References: Message-ID: <20020529.180337.100006631.he@uninett.no> > To me, it would make sense to allocate a /3x to each and every one > who has an AS#, and requests ipv6-space, then we would NOT have any > problem like the above or with 'multihoming' either. It is not like > the adresses would be used-up with this scenario.. I agree. With the current to-be-implemented routing policy, having an AS# is however not sufficient grounds for getting your own "portable" IPv6 address space. At least not the way I read it. While it is true that the addresses would not be used up anytime soon with this alternative address allocation scheme, I have understood the fear to be that the routing table space would be consumed too quickly in this scenario. Apparently, in some regions getting the LIR status, multiple service provider connections, and your own AS# is considered to be "too easy" or "too cheap", so the practice would proliferate, and routing table explosion would be the result. However, as far as I know, none of the "alternative" ways to do multihoming in the IPv6 world provide a service with similar characteristics to the one we currently have in IPv4. In a way, this is a reflection of the fact that routing in IPv6 is just "more of the same" compared to IPv4, and that the routing and particularly multihoming issues from IPv4 have not been solved in IPv6. The current IPv6 address allocation policy nevertheless appears to try to implement routing aggregation through the RIR IPv6 allocation policy, in that only the "big guys" can get an allocation from their RIR. A side effect of this is that it will take away smaller ISPs ability to set their own routing policy, because they would need to go to their upstream(s) to get IPv6 addresses, and it seems likely that strict filtering of routing announcements on LIR allocation boundaries will be implemented. Regards, - H?vard From gert at space.net Wed May 29 18:32:55 2002 From: gert at space.net (Gert Doering) Date: Wed, 29 May 2002 18:32:55 +0200 Subject: IPv6 policy and Supernational-LIRs In-Reply-To: <20020529.180337.100006631.he@uninett.no>; from he@uninett.no on Wed, May 29, 2002 at 06:03:37PM +0200 References: <20020529.180337.100006631.he@uninett.no> Message-ID: <20020529183255.F13918@Space.Net> Hi, On Wed, May 29, 2002 at 06:03:37PM +0200, Havard Eidnes wrote: > The current IPv6 address allocation policy nevertheless appears to try > to implement routing aggregation through the RIR IPv6 allocation policy, > in that only the "big guys" can get an allocation from their RIR. Misunderstood. The new policy means that every LIR (that is serious about connecting customers) can get IPv6 space. Yes, (smallish) end customers can not. > A side effect of this is that it will take away smaller ISPs ability to > set their own routing policy, because they would need to go to their > upstream(s) to get IPv6 addresses, and it seems likely that strict > filtering of routing announcements on LIR allocation boundaries will be > implemented. Setting their own "regional" routing policy and doing peering should work fine in such a framework. The question to be asked is "is it so important to be visible world-wide and to impact every single core BGP router world-wide" if the entity in question can't be bothered to become an LIR and document the *plan* to connect 200 customers? Yes, becoming an LIR costs money, but announcing space to the world does so as well - and there ain't no free lunch (and should not be). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45201 (45114) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From he at uninett.no Wed May 29 18:30:56 2002 From: he at uninett.no (Havard Eidnes) Date: Wed, 29 May 2002 18:30:56 +0200 (CEST) Subject: New Document available: RIPE-233 In-Reply-To: References: Message-ID: <20020529.183056.101691505.he@uninett.no> > I would agree that having them in on single block could > make for certain types of capture problems. I have to ask a rhetorical question here, what is a "block" in this context? Is it a single routing announcement? Surely, it cannot be, because the different root name servers are placed at different points in the topology. I'll claim that the actual numeric sequence (or non-sequence) of the IPv6 address blocks allocated to the root name servers do not matter; the identity of the blocks will be well-known anyway, so there is no robustness gain to be had from picking "obscure" or "scattered" numbers. I do however agree with those which have said that a root name server should not have its address changed when it moves between RIR regions; the whole point of this "special" assignment to the root name servers is to avoid *any* renumbering because the DNS bootstrap data is (currently) distributed in a static configuration file. Regards, - H?vard From david at IPRG.nokia.com Wed May 29 22:57:31 2002 From: david at IPRG.nokia.com (David Kessens) Date: Wed, 29 May 2002 13:57:31 -0700 Subject: New Document available: RIPE-233 In-Reply-To: ; from randy@psg.com on Wed, May 29, 2002 at 02:52:40AM -0700 References: <5.1.0.14.0.20020524120612.03f93d38@127.0.0.1> <5.1.0.14.0.20020528071145.046b0e78@127.0.0.1> <20020528132959.C17579@iprg.nokia.com> Message-ID: <20020529135731.C19169@iprg.nokia.com> Randy, Joao, On Wed, May 29, 2002 at 02:52:40AM -0700, Randy Bush wrote: > Joao wrote: > > Actually I think it makes much more operational sense to *not* put > > all the root name servers in one block. > > agreed^2 > > if one believes this scenario, than each having its own normal sized > (i.e. globally routable) block is the only method i can see. [ unless > we want to discuss the anycast path ] I should have been more precise in my wording, I assumed that nobody would even think of not having a globally routed block for each server (except for the anycast model). My suggestion should have been read as that I would prefer that these routable blocks of address space come out of a larger address range set aside for rootnameserver numbering purposes. One of the reasons that people want their own address space for rootnameservers is that it becomes easier to apply policy for the rootnameserver operator but also for the users of the servers. Using one address range for all the different routable blocks of rootnameserver address space makes it easier to recognize that one deals with 'special' address space when one sees such an address and it makes it easier to apply policies on all these special addresses at once (if one desires so) instead of dealing with a list of randomly choosen prefixes. David K. --- From clive at demon.net Thu May 30 09:20:25 2002 From: clive at demon.net (Clive D.W. Feather) Date: Thu, 30 May 2002 08:20:25 +0100 Subject: New Document available: RIPE-233 In-Reply-To: <20020529.183056.101691505.he@uninett.no> References: <20020529.183056.101691505.he@uninett.no> Message-ID: <20020530072025.GA28471@finch-staff-1.demon.net> Havard Eidnes said: > I'll claim that the actual numeric sequence (or non-sequence) of the > IPv6 address blocks allocated to the root name servers do not matter; > the identity of the blocks will be well-known anyway, so there is no > robustness gain to be had from picking "obscure" or "scattered" > numbers. Actually, I can think of one reason to scatter them: it means that an erroneous route table entry (whether due to someone's error or a router bug) is less likely to take them all out. Whereas if they're all in the same (say) /28, ... -- Clive D.W. Feather | Work: | Tel: +44 20 8371 1138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | NOTE: fax number change From michel at arneill-py.sacramento.ca.us Thu May 30 09:23:16 2002 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 30 May 2002 00:23:16 -0700 Subject: New Document available: RIPE-233 Message-ID: <2B81403386729140A3A899A8B39B046405E0B1@server2000.arneill-py.sacramento.ca.us> Havard, > Havard Eidnes wrote: > I have to ask a rhetorical question here, what is a "block" in > this context? > Is it a single routing announcement? Surely, it cannot be, > because the different root name servers are placed at different > points in the topology. The very purpose of placing them at different points is to have redundancy; so yes, for the same reason they must have different blocks. > I'll claim that the actual numeric sequence (or non-sequence) of > the IPv6 address blocks allocated to the root name servers do not > matter; the identity of the blocks will be well-known anyway, so > there is no robustness gain to be had from picking "obscure" or > "scattered" numbers. There is an advantage to scattered numbers, IMHO. Since they are scattered, nobody will try to aggregate them and suppress the specific announcements. Martian configs do happen; not often but they do. > I do however agree with those which have said that a root name server > should not have its address changed when it moves between RIR regions; > the whole point of this "special" assignment to the root name servers > is to avoid *any* renumbering because the DNS bootstrap data is > (currently) distributed in a static configuration file. There are (at least) two ways to achieve this: 1. Two-space systems (the servers would have a unique identifier and multiple changeable locators). 2. "special assignement" otherwise called PI. I think the RIRs have acted responsibly so far in not showing the bad example of allocating themselves a PI block. A short-term fix to this would be a two-space system where the locator initially assigned could be transformed into the identifier later. Michel. From joao at ripe.net Fri May 31 10:15:49 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Fri, 31 May 2002 10:15:49 +0200 Subject: Status field for inet6num objects Message-ID: [** Mail posted to both APNIC and RIPE lists in the hopes of trying to find a solution suitable for all users of RIPE or RIPE-derived software **] Dear all, the inet6num, like the inetnum object, has a field named "status" which stores some information about the nature or position of a block of addresses in the delegation chain, from the RIR through to the end user. Currently, the status field for inet6num object is generated by the Database software based on the size of the address block and its possible values are: o TLA o SubTLA o NLA o SLA This notation has been deprecated and it is time to adapt the database. Discussions on this matter have identified the usefulness of having the capability to distinguish between allocations made by the RIR, allocations made by an LIR or their customers and assignments to end users. As such, we propose to modify the "status" attribute of the inet6num object to be: a) not-generated. This means users must assign a value to the status attribute when creating the object, just as in the inetnum object b) have the following possible values: RIR-allocated LIR-allocated Assigned to be used according to the following set of rules: The RIR-allocated status can only be used in objects representing allocations created directly by the RIR. The LIR-allocated status can be used by LIRs and their customers to represent blocks of addresses that are not assigned to specific end users. There can be several levels of objects with this status. The Assigned status must be used in objects representing assignments to end users (households, companies, enterprises, etc) We hope that with this modification the information in the Database will more accurately describe the registration of IPv6 address space. A possible transition to the new values could be: 1) RIRs modify status fields for allocations 2) Any new objects and modifications to existing ones must have a value for the status field corresponding to the ones described above. Otherwise the update will fail. 3) RIRs contact LIRs to have the status of assignments and sub-allocations updated. Best regards, Joao Damas RIPE NCC From kurtis at kpnqwest.net Thu May 30 10:07:27 2002 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Thu, 30 May 2002 10:07:27 +0200 (MEST) Subject: IPv6 policy and Supernational-LIRs In-Reply-To: Message-ID: > For IPv6, on the other hand, a supernational registry can only get a single > allocation, irrespective of its size and contributions to the NCC. I don't > recall this policy change being discussed in the RIPE policy making forum (the > LIR WG) being being put in place by the NCC for the then interim IPv6 policy. Which is why I brought the discussion to the forum :) > I am aware that there are few supernational registries and that they are a > pain for the RIPE NCC but this policyy change seems to work against the > aggregation principles we need to follow if we're not going to have the > routing table growth rate we've seen with IPv4. We have had the discussion with RIPE NCC about the usefulness of a Supernational-LIR, and for us this makes things alot easier. In large corporations, it's simply easier to get one bill and one contact, than as in our case - 14 invocies... - kurtis - From kurtis at kpnqwest.net Thu May 30 10:05:09 2002 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Thu, 30 May 2002 10:05:09 +0200 (MEST) Subject: IPv6 policy and Supernational-LIRs In-Reply-To: <20020529111840.K13918@Space.Net> Message-ID: > The problem with that isn't so much the lenght of the number (that's just > "linear memory waste"), the problem that I see is that the number of > ASes actually in use reflect the complexity of the overall topology - > and *that* goes into BGP convergence times much stronger than linearily. Agreed. It was merly a joke. Personally I think that most customers asking for multihoming is actually asking for something completly different. But we have been down that discussion before... > Not all of the /32s might even necessarily be visible globally, upstream > could go through the /28. Well, in our case they would. Problem is that we do not have a /28. My point was to some extent that we should define this better. It's is a single LIR, but the question is what the allocation should be for routing purposes. > The new policy (effective next monday) will permit this - if you come up > with good reasons and some thought about addressing plans and hierarchy, > getting something "large enough" should not be a unsolveable problem. At > least that was the intention - the address space is large enough so that > haggling over "we need a /28" - "no you can only get a /31 plus a /32" > should not occur (unless the "need" for a /28 really isn't justificable). I agree, but RIPE NCC have said we will only get the /35. Best regards, - kurtis - From gert at space.net Fri May 31 11:04:17 2002 From: gert at space.net (Gert Doering) Date: Fri, 31 May 2002 11:04:17 +0200 Subject: IPv6 policy and Supernational-LIRs In-Reply-To: ; from kurtis@kpnqwest.net on Thu, May 30, 2002 at 10:05:09AM +0200 References: <20020529111840.K13918@Space.Net> Message-ID: <20020531110416.S13918@Space.Net> Hi, On Thu, May 30, 2002 at 10:05:09AM +0200, Kurt Erik Lindqvist KPNQwest wrote: [..] > > Not all of the /32s might even necessarily be visible globally, upstream > > could go through the /28. > > Well, in our case they would. Problem is that we do not have a /28. My > point was to some extent that we should define this better. It's is a > single LIR, but the question is what the allocation should be for routing > purposes. [..] > I agree, but RIPE NCC have said we will only get the /35. Try again after the new policy is in place. The old policy had no provisions for anything reasonable, but under the new policy, it should be possible to get a /28. Or maybe even a /20. Or whatever make sense according to a "aggregation is very important, conservation should not be neglected but is not the main issue". Be prepared, though, to invest quite some thoughts into network structure, plans for hierarchical address space distribution, and so on - the NCC will need this to judge whether the request is reasonable, or outragious. (Of course I'd like a /20 too :-) - but there is no way I will get one, as I can't demonstrate any reasonable need for it, and this is perfectly ok with me). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45201 (45114) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299