- address-policy-wg - mailman.ripe.net

2006-01 & 2006-02 Discussion Period extended until 17 August 2006
by Filiz Yilmaz 06 Jul '06

06 Jul '06

PDP Number: 2006-01 Provider Independent (PI) IPv6 Assignments for End User Organisations and PDP Number: 2006-02 IPv6 Address Allocation and Assignment Policy Dear Colleagues The Discussion Period for proposals 2006-01 and 2006-02 has been extended until 17 August 2006. 2006-01 is intended to provide a solution for organisations that need IPv6 Provider Independent (PI) assignments and 2006-02 is to change the IPv6 Initial Allocation criteria, the End Site definition and assignment of multiple /48s to a single End Site as outlined in the "IPv6 Address Allocation and Assignment Policy". You can find the full proposals at: http://www.ripe.net/ripe/policies/proposals/2006-01.html and http://www.ripe.net/ripe/policies/proposals/2006-02.html We encourage you to review these policy proposals and send your comments to <address-policy-wg(a)ripe.net>. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

RE: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy)
by Koepp, Karsten 27 Jun '06

27 Jun '06

Hi, I support the proposal to take away the 200 customers' number being further in favour of deleting "and c) have a plan for making a reasonable number of /48 assignments within two years" Address assignment is the entire purpose of becoming a LIR. RIPE has 3800 members, this sums up to less than 20k LIRs globally, all being assigned ONE /32. I am curious to see whether chairs can see consensus after reading the whole thread. Can people please stick to the point when feedback on a certain proposal is asked. I guess this was a major objective when introducing the PDP. regards Karsten > -----Original Message----- > From: JORDI PALET MARTINEZ [mailto:jordi.palet@consulintel.es] > Sent: Wednesday, June 07, 2006 2:20 PM > To: address-policy-wg(a)ripe.net > Subject: [address-policy-wg] Re: [policy-announce] 2006-02 New Policy > Proposal (IPv6 Address Allocation and Assignment Policy) > > > Hi, > > I will like to know if anyone has any comments/inputs on this > proposal. > > I tried to follow the suggestions received after the > presentation of the > IPv6 PI policy at the last meeting. > > Thanks ! > > Regards, > Jordi > > > > > > De: Filiz Yilmaz <filiz(a)ripe.net> > > Responder a: <filiz(a)ripe.net> > > Fecha: Wed, 31 May 2006 14:43:05 +0200 > > Para: <policy-announce(a)ripe.net> > > CC: Jordi Palet Martinez <jordi.palet(a)consulintel.es>, Hans > Petter Holen > > <hph(a)oslo.net>, "address-policy-wg(a)ripe.net" > <address-policy-wg(a)ripe.net> > > Asunto: [policy-announce] 2006-02 New Policy Proposal (IPv6 > Address Allocation > > and Assignment Policy) > > > > PDP Number: 2006-02 > > IPv6 Address Allocation and Assignment Policy > > > > Dear Colleagues > > > > A proposed change to RIPE Document ripe-267 is now available for > > discussion. > > > > You can find the full proposal at: > > > > http://www.ripe.net/ripe/policies/proposals/2006-02.html > > > > We encourage you to review this proposal and send your comments to > > <address-policy-wg(a)ripe.net> before 28 June 2006. > > > > > > Regards > > > > Filiz Yilmaz > > RIPE NCC > > Policy Development Officer > > > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org > > This electronic message contains information which may be > privileged or confidential. The information is intended to be > for the use of the individual(s) named above. If you are not > the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, > including attached files, is prohibited. > > >

1 0

2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy)
by Filiz Yilmaz 20 Jun '06

20 Jun '06

PDP Number: 2006-02 IPv6 Address Allocation and Assignment Policy Dear Colleagues A proposed change to RIPE Document ripe-267 is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-02.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 28 June 2006. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

18 35

Re: Possible IAB workshop on routing and addressing participants?
by David Meyer 19 Jun '06

19 Jun '06

[Sorry about the wide distribution/duplicates. Just trying to reach as many of the folks who may be interested as possible --dmm] Folks, The IAB is considering holding a routing and addressing workshop, perhaps in the fall 2006 time frame (see the draft invite below). We're in the process of collecting potential participants, so please pass along any the names of folks that that you think would be productive participants. Thanks, --dmm (for the IAB) ---- Greetings, The IAB is sponsoring a workshop on "Scalable Routing and Addressing Architectures for the Internet" in order to foster interchange between the operator, standards, vendor, and research communities on this important topic. You are being invited to participate in this effort. This workshop effort will consist of mailing list discussions in advance of, and after a face to face meeting. The technical goals of this effort are outlined below. We believe these are the critical elements to fostering a constructive discussion of important routing and addressing technical work going forward and are soliciting workshop participation to work towards those goals. Should you decide to join us in this workshop, you will be expected to attend the face to face meeting [0], contribute to (and possibly present at) that meeting, as well as follow and participate in the mailing list discussions. The most important objective of the workshop is to foster and encourage innovative thinking in an area where there has been little fundamental change for the last twelve years. As such, the primary goals of the workshop include the following two items: (i). Produce a concise problem statement that will serve as the input to future work on this topic. This problem statement will include, among other things, a list of the problems with the current routing and addressing architecture. These include (but are not limited to): - The difficulty in changing provider due to PA/CIDR addressing schemes - The lack of effective multi-homing support - Limited capability to protect against either the spoofing of individual host IP addresses or entire IP address blocks - The limited ability to secure the routing system itself, and (ii). Produce a prioritized list of requirements, all of which must be met by a next generation routing and addressing architecture. A sample list might include (in no particular order): - Retaining the connectionless datagram model of IP routing - Allow users (small and large) to freely switch between providers without substantial service interruption - Include survival of higher-layer connections and associations when connectivity to individual providers changes - Allow both users and ISPs to influence path selection according to traffic management and classification requirements - Provide better support for mobility and nomadicity - Provide architected instrumentation facilities - Allow at least one-to-many multicast - Prevent source address spoofing - Provide a rational economic basis for deployment - Secure the routing infrastructure, including the authentication of updates and the unauthorized injection of information into the routing system - Define scalability requirements for a next generation routing system - Have architected transition mechanisms and be incrementally deployable (where possible) During the workshop, scribes will be assigned to summarize the discussion. Post-workshop, scribes will be expected to participate in finalizing the workshop report. All participants will be expected to review the draft workshop report before publication. The workshop is <date, <logistics. Please reply within the next week indicating your willingness to participate in this workshop. Please indicate whether (and to what extent) you'd be able to participate (we'd like an explicit 'no' if you will not be able to), and what you feel is your area of expertise. If you can not participate, please suggest potential alternatives or substitutes. [0] Attendees will also need to arrange and pay for their own travel and accommodations.

1 0

Re: [address-policy-wg] Comments on 2006-01 (IPv6 Address Allocation and Assignment Policy)
by Tim Streater 16 Jun '06

16 Jun '06

At 15:14 15/06/2006, Michael.Dillon(a)btradianz.com wrote: >The current swamp is a block in which the allocations >are not structured according to network topology. All >IPv6 blocks are structured, at the highest level, according >to continental-scale areas. At a more detailed level, >PI blocks smaller than a /32, could be allocated >according to some kind of topological addressing plan. >For instance, RIPE could have a Scandinavia aggregate, >CIS aggregate, Central aggregate (FR, DE, BE, CH, NL, PL, AT), >Western aggregate (UK, IE, ES, PT) and Southeast aggregate >(Ex-Yugoslavia, GR, TR, IL). We have one router in almost every country you listed and some you haven't, all within Europe. Do we get 5 /32 then? In addition, one of the networks we manage which also covers a large area is planned to be handed off to its own managing entity, complete with the infrastructure. So we'd like PI v6 space please to address it. And for it and our primary network we plan to allocate 0 addresses to 0 customers for the next 2, 10, 20, infinity years. -- Tim

2 1

2005-03 Policy Proposal Withdrawn (IPv6 Initial Allocation)
by Filiz Yilmaz 09 Jun '06

09 Jun '06

PDP Number: 2005-03 IPv6 Initial Allocation Dear Colleagues The proposal 2005-03, IPv6 Initial Allocation, has been withdrawn by the proposer who thought this proposal is superceded by poposal 2006-02, IPv6 Address Allocation and Assignment Policy. The proposal is archived now and you can find it at: http://www.ripe.net/ripe/policies/proposals/2005-3.html Regards Filiz Yilmaz RIPE NCC Policy Development Officer

2 1

2006-01 Discussion Period extended until 28 June 2006 (Provider Independent (PI) IPv6 Assignments for End User Organisations)
by Filiz Yilmaz 31 May '06

31 May '06

PDP Number: 2006-01 Provider Independent (PI) IPv6 Assignments for End User Organisations Dear Colleagues The Discussion Period for the proposal 2006-01 has been extended until 28 June 2006 as the proposal text has been edited. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-01.html We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

New ROUTE-SET and RIPE document: Address Space Managed by the RIPE NCC
by leo vegoda 31 May '06

31 May '06

[Apologies for duplicates] Dear Colleagues, We have updated the RIPE document "Address Space Managed by the RIPE NCC" to include references to a ROUTE-SET object describing the address space allocated to the RIPE NCC by the IANA. The new version is ripe-380 and can be found on our web site at: https://www.ripe.net/docs/ripe-ncc-managed-address-space.html We hope the ROUTE-SET object is useful. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

RIPE 52 Report available
by Paul Rendek 31 May '06

31 May '06

[Apologies for duplicate e-mails] Dear Colleagues, The RIPE 52 Meeting Report is now online at: http://www.ripe.net/ripe/meetings/ripe-52/report.html Regards, Paul Rendek Head of Member Services & Communications RIPE NCC

1 0

2005-01 Policy Proposal Withdrawn (HD-ratio Proposal)
by Filiz Yilmaz 30 May '06

30 May '06

PDP Number: 2005-01 HD-ratio Proposal Dear Colleagues The proposal 2005-01 has been withdrawn. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/archive/ Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

Mike Simkins is out of the office.
by Mike.Simkins＠sungard.com 29 May '06

29 May '06

I will be out of the office starting 26/05/2006 and will not return until 30/05/2006. I will respond to your message when I return. If you have an urgent issue - please call the IOC at 1-800-41-1181 where someone will be able to help you immediately

1 0

Contact e-mail Address Requirements at RIPE et al.
by Jeff Scribner 27 May '06

27 May '06

BlankGentlemen: >From time to time our security department has had to expend considerable effort to find working e-mail addresses for organizations responsible for IP addresses controlled by RIPE. In some instances, no working address could be found or a time consuming visit to a web site form was required for contact. Every organization controlling an IP address with a listing at RIPE should be required to list at least one working contact e-mail address where notifications of abuse emanating from that IP address can be sent. RIPE should be allocated money and personnel to enforce this rule. In addition, all persons and organizations assigned an IP address should be required to take vigorous action to prevent abusive messages from originating at that IP address. RIPE should be allocated money and personnel to enforce this rule and, if necessary, to shut down any IP address or group of addresses having excessive instances of abuse. This policy should also be followed by ARIN, APNIC, AFRNIC, LACNIC, etc. and would result in less spam and abuse and more rapid correction thereof. Regards, Jeffrey L. Scribner ASI Enterprises, Inc. 9660 Falls of the Neuse Road Suite 138-123 Raleigh, North Carolina 27615-2473 Telephone 919-844-6404 Cell 919-264-6404 Fax Server 501-643-9064 jscribner(a)asienterprises.com http://www.asienterprises.com

1 0

Draft Minutes: RIPE 52 Address Policy WG session
by Catherine Carr 25 May '06

25 May '06

Dear Colleagues Draft Minutes from the Address Policy Working Group session at RIPE 52 can be found at: http://www.ripe.net/ripe/wg/address-policy/r52-minutes.html Please check the minutes for errors or omissions. Comments and corrections can be sent directly to this list or to one of the WG chairs personally. Additionally, archives of the webcast can be found at: mms://webcast.ripe.net/ripe-52/ap.wmv http://www.ripe.net/ripe/meetings/ripe-52/webcast-files/ap.wmv http://www.ripe.net/ripe/meetings/ripe-52/podcasts/ap.mp3 There is also a copy of the Jabber/IRC session available at: http://www.ripe.net/ripe/meetings/ripe-52/transcripts/ap.txt Kind regards, -- Catherine Carr RIPE NCC IP Resource Analyst

1 0

41/8 announcement
by Ernest B. M 22 May '06

22 May '06

Apologies for duplicates] Dear Colleagues, Please note that AfriNIC received the IPv4 address range 41.0.0.0/8 from the IANA in April 2005. You may wish to adjust any filters you have in place accordingly. Reachability tests can be conducted with 41.223.252.1 as a target IP address. Kind Regards, Ernest, AfriNIC.

2 1

Proposal 2005-2 comment
by John L Crain 13 May '06

13 May '06

Just one brief comment in that section A.2. needs to be updated. There are currently five RIR's since the addition of AfriNIC. Here is the section: A.2. Policy Harmonisation Three out of four RIRs (APNIC, ARIN and LACNIC) have policies allowing assignments to network critical infrastructure. All three policies classify TLD name servers as critical infrastructure. Extracts from these policies can be found in Appendices I through III. John

1 0

Just say *NO* to PI space -- or how to make it less destructive
by Pekka Savola 12 May '06

12 May '06

Hi, I don't support PI space to end-sites. We have to get rid of the notion that a random end-site has any business whatsoever in mucking with the global routing tables, either by making it much larger than need be or by polluting it with needless dynamicity. Example of the latter: deploying inbound traffic engineering adjustment solutions which result in thousands of daily flaps in the advertisements, as shown by Huston's analysis. We have way too much trouble with clueless ISPs to also add (or continue to add) end-sites to the mix... .... Now, from practical point of view, it seems there is strong "need" for PI, and it might be a PI policy of some kind might actually get through. If so, the policy should be such that it minimizes the bad effects of PI and encourages people to use other solutions if those are viable for them (unfortunately, the only way to achieve that appears to be $$$$), in particular (in the rough order of importance): 1. Each assignment must be accompanied by a recurring fee (at least 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts (compared to other costs) to anyone who actually needs this multihoming solution. However, this ensures at least some minimum usage barrier ("those who don't really need this can use different multihoming solutions"), and recovery of the resources back to RIR after the company has gone bankrupt or no longer needs the addresses. If you don't know where to put the extra money, donate it to ISOC or something. 2. one-size-fits-all assignments, period. You get a /48 or /32 (I don't have much preference here), but you must not be able to justify for larger space. This is to avoid the organization from getting a larger block and chopping it into smaller pieces and polluting the global routing table with more specifics which would get past prefix length filters. 3. assignments from a separate address block, set aside for PI. To ease strict "assignment-size only" filtering of these blocks. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

32 86

The flexibility of IPv4 routing
by Florian Weimer 11 May '06

11 May '06

According to this article: <http://www.renesys.com/blog/2006/04/tracking_plane_flight_on_inter.shtml> Connexion uses BGP and the Internet routing table to implement IP mobility: | So how did they solve it? They assigned a /24 (256 globally visible IP | addresses) to each plane. They announce that network from the origin | site (in my case, Europe since I took off from Germany). When the | plane is between the two satellites and in view of each, it is | programmed to re-connect to the North American satellite. So traffic | is always getting to the ground the fastest it can, minimizing | latency. Certainly a cool hack, although I'm not sure if the leak of the /24s to the global routing table is intended. It's not necessary to minimize latency. Perhaps Connexion does not operate an intercontinental AS, though -- which would mean that two planes using different head stations could not communicate with each other at the IP layer. Anyway, I wish you guys could bring this kind of flexibility to the IPv6 world. 8-)

2 2

2005-12 New Draft Document Published (4-Byte AS Number Policy)
by Filiz Yilmaz 10 May '06

10 May '06

PDP Number: 2005-12 4-Byte AS Number Policy Dear Colleagues We have published a draft document for the proposal described in 2005-12. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2005-12.html and the draft document at: http://ripe.net/ripe/draft-documents/2005-12-draft.html We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 7 June 2006. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

2005-02 New Draft Document Published (IP Assignments for anycasting DNS)
by Filiz Yilmaz 10 May '06

10 May '06

PDP Number: 2005-02 IP Assignments for anycasting DNS Dear Colleagues We have published two draft documents for the proposal described in 2005-02. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2005-2.html and the draft documents at: http://ripe.net/ripe/draft-documents/2005-02-draft.html http://ripe.net/ripe/draft-documents/2005-02-v6-draft.html We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 7 June 2006. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

IPv4-HD-Ratio proposal
by Thor-Henrik Kvandahl 03 May '06

03 May '06

Hi all, here are my *personal* opinion on this proposal. I do not support this proposal, and my reasons for this are: * This proposal increases the rate of consumption of IPv4. * It favourises the large ISPs. * In the presentation on RIPE 52, Tuesday by Filiz Yilmaz, we where told that this proposal was abandoned by ARIN and APNIC, and one representative from LacNIC also stood up and expressed their conserns. I have not heard anything from AfriNIC, but I cannot see why they would want to implement this policy. I feel if will be arrogant of the RIPE community to disregard the other RIRs conserns and implement this policy. And I also have to agree with Gert Doering who said in the address policy WG that there has been very quiet around this proposal, and that the reason for this can be that ETNO claims thay "unanimously support this proposal". -- Thor-Henrik Kvandahl no.telenor

7 11

VS: [address-policy-wg] IPv4-HD-Ratio proposal
by Storm, Ørnulf 02 May '06

02 May '06

-----Opprinnelig melding----- Fra: Storm, Ørnulf Sendt: 28. april 2006 10:37 Til: address-policy-wg(a)ripe.net Kopi: 'Thor-Henrik Kvandahl' Emne: SV: [address-policy-wg] IPv4-HD-Ratio proposal I also support Thor-Henrik comments. I think it would be a bad idea to make a policy change now that increases the consumption, especially now when it is going towards the end of the lifetime of the IPv4 address space, relatively speaking reference to the work that Geoff Houston has done on predictions of the lifetime of the IPv4 address space. This proposal could be seen as favouring the large ISPs and is working in disfavour of the small ISPs. The IP address space should be assigned in a fairly manner and it appears that this proposal could change this. All participants should have the same conditions when competing with each other. A small ISP in a small country should have same possibilities to get new IP address space as a large ISP in a large country. Therefore, I think that establishing this policy would be the wrong message for the RIPE community to send in these WSIS days with the "world watching". Regards, Ørnulf Storm Network Addresses and Electronic Signatues Norwegian Post and Telecommunications Authority E-mail: ors(a)npt.no Telephone: +47 22824600 Web: www.npt.no -----Opprinnelig melding----- Fra: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] På vegne av Thor-Henrik Kvandahl Sendt: Thursday, April 27, 2006 9:48 AM Til: address-policy-wg(a)ripe.net Emne: [address-policy-wg] IPv4-HD-Ratio proposal Hi all, here are my *personal* opinion on this proposal. I do not support this proposal, and my reasons for this are: * This proposal increases the rate of consumption of IPv4. * It favourises the large ISPs. * In the presentation on RIPE 52, Tuesday by Filiz Yilmaz, we where told that this proposal was abandoned by ARIN and APNIC, and one representative from LacNIC also stood up and expressed their conserns. I have not heard anything from AfriNIC, but I cannot see why they would want to implement this policy. I feel if will be arrogant of the RIPE community to disregard the other RIRs conserns and implement this policy. And I also have to agree with Gert Doering who said in the address policy WG that there has been very quiet around this proposal, and that the reason for this can be that ETNO claims thay "unanimously support this proposal". -- Thor-Henrik Kvandahl no.telenor

1 0

comments on IP Assignments for anycasting DNS (2005-2)
by Edward Lewis 27 Apr '06

27 Apr '06

Referring to: http://www.ripe.net/ripe/policies/proposals/2005-2.html The author's email address on the page is "@localhost". A few thoughts on the restrictions on this: "gTLD" usually means "generic Top Level Domain". There are also "sTLD" - sponsored TLD. (Check http://en.wikipedia.org/wiki/GTLD, at the bottom of the page there's a box that breaks gTLDs into sTLDs and other categories.) Sometimes "interesting" zones are not the TLD but one under the TLD. E.g., .co.tld. or .com.tld. I think that these should be eligible. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain...

2 1

AW: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive
by Ruchti, Marcus 27 Apr '06

27 Apr '06

Hi Dennis, I don't think flapping routes will increase due to the assignments of PI space, as in the most cases ISP's are requesting those for customers and offers managed multihoming solutions. So announcing these routes into BGP is the responsibility of an ISP. Regards Marcus Ruchti COLT Telecom -----Ursprüngliche Nachricht----- Von: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] Im Auftrag von Dennis Lundström Gesendet: Donnerstag, 20. April 2006 16:25 An: Pekka Savola Cc: ppml(a)arin.net; address-policy-wg(a)ripe.net; global-v6(a)lists.apnic.net Betreff: Re: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive Hi Pekka. Totally agree with you there. At the moment as we have PI with IPv4, and I'll guess there will be lot's of fuzz dropping It. On the other hand. If PI allocations were no more, then the same people you nag about here would try to become their own ASN:s. And the percentage of peers running on cheap 'o pc-boxes would quite possibly increase. Resulting in that the problem with flapping routes would probably remain, or even get worse. So the problem is really. How do we regulate PI to only be an accepted solution for extreme cases? And still have a fair policy to those who really needs this feature. Best regards. --Dennis Lundström GippNET Pekka Savola wrote: > Hi, > > I don't support PI space to end-sites. We have to get rid of the > notion that a random end-site has any business whatsoever in mucking > with the global routing tables, either by making it much larger than > need be or by polluting it with needless dynamicity. > > Example of the latter: deploying inbound traffic engineering > adjustment solutions which result in thousands of daily flaps in the > advertisements, as shown by Huston's analysis. > > We have way too much trouble with clueless ISPs to also add (or > continue to add) end-sites to the mix... > > .... > > Now, from practical point of view, it seems there is strong "need" for > PI, and it might be a PI policy of some kind might actually get > through. > > If so, the policy should be such that it minimizes the bad effects of > PI and encourages people to use other solutions if those are viable > for them (unfortunately, the only way to achieve that appears to be > $$$$), in particular (in the rough order of importance): > > 1. Each assignment must be accompanied by a recurring fee (at least > 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts > (compared to other costs) to anyone who actually needs this > multihoming solution. However, this ensures at least some minimum > usage barrier ("those who don't really need this can use different > multihoming solutions"), and recovery of the resources back to RIR > after the company has gone bankrupt or no longer needs the addresses. > If you don't know where to put the extra money, donate it to ISOC or > something. > > 2. one-size-fits-all assignments, period. You get a /48 or /32 (I > don't have much preference here), but you must not be able to justify > for larger space. This is to avoid the organization from getting a > larger block and chopping it into smaller pieces and polluting the > global routing table with more specifics which would get past prefix > length filters. > > 3. assignments from a separate address block, set aside for PI. To > ease strict "assignment-size only" filtering of these blocks. > ************************************************************************************* The message is intended for the named addressee only and may not be disclosed to or used by anyone else, nor may it be copied in any way. The contents of this message and its attachments are confidential and may also be subject to legal privilege. If you are not the named addressee and/or have received this message in error, please advise us by e-mailing security(a)colt.net and delete the message and any attachments without retaining any copies. Internet communications are not secure and COLT does not accept responsibility for this message, its contents nor responsibility for any viruses. No contracts can be created or varied on behalf of COLT Telecommunications, its subsidiaries or affiliates ("COLT") and any other party by email Communications unless expressly agreed in writing with such other party. Please note that incoming emails will be automatically scanned to eliminate potential viruses and unsolicited promotional emails. For more information refer to www.colt.net or contact us on +44(0)20 7390 3900.

5 4

RE: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space -- or how to make it lessdestructive)
by Michel Py 26 Apr '06

26 Apr '06

Gert, >> Michel Py wrote: >> Most of the more experienced network managers out there will >> tell you this: I don't want to go through this again. > But at the same time, most of the more experienced network > managers have been through it a couple of time, and will > understand the necessity... :-) > (We had to change the IP addresses for our recursive DNS servers > 3 times by now, and making sure all customers update their configs > *was* a nightmare Renumbering DNS servers is 1% of renumbering a large enterprise setup. Imagine if you had them change not only DNS, but all of their DHCP scopes, firewall rules, host files, batches, printers, renumber their active directory controllers (ever tried to change the IP address on a windows box that assumes FSMO roles?) etc etc. > - nevertheless, it was the correct thing to do Good for you. In my world, the correct thing to do is the one that has a positive impact on the bottom line. > Jørgen Hovland wrote: > Renumbering is as easy as you want it to be. I love guys like Jørgen. One day they'll find someone fool enough to let them touch a big network, they'll make a mess, and their management will suddenly understand the value of paying me 2k per day so another disaster does not happen. Michel.

2 1

RE: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space -- or how to make it lessdestructive)
by Michel Py 26 Apr '06

26 Apr '06

> Wilfried Woeber wrote: > Why does the laptop store the *addresses* instead of an (FQ)DN? Mine is configured that way because I want to be able to get in remotely in case of a DNS failure so I can fix the DNS :-D Other reason: VPNs based on FQDNs have a tendency to timeout, especially at the first attempt from a remote location (because the FQDN is not cached and has to go up to the root). Also DNS requests go over UDP, which is unreliable. It happens all the time that Joe Blow traveling somewhere reports the next day that he could not check his email or download the sales report because the VPN was not working (because Joe either is not smart enough to retry or finds it a good excuse to go to the bar instead). Next time he goes out the VPN is configured with the hardcoded IP address of the VPN server. In the end, it does not matter why. It's out there, and has to be dealt with. > Jeroen Massar wrote: > Renumbering is *NOT* simple and *CAN't* be automated (no remote > company will allow you full automatic access to change things in > their setup, think firewall rules for instance...) Indeed. Even if they did, it would be logistically impossible. I'm currently configuring an IPSEC tunnel going to a very large corporation. There are thousands of tunnels, configured on every router brand and model man has ever made; each is unique. An automated tool to change this is not in the realm of possible. This leaves the large company with having to deal with thousands of different people with issues such as half of the techs that originally configured the thing are no longer there, nobody remembers the router's password, etc. Renumbering any sizeable organization is _always_ a very costly proposition. It requires allocating valuable resources for weeks to prepare and more to carry. Plus, in any renumbering I have done some issues popped out for weeks after the renumbering. Renumbering generates a steady flow of trouble tickets that require more resources to deal with _and_ make the network guys look like idiots. Only rookies that have never been in the trenches in the real world consider renumbering easy. Most of the more experienced network managers out there will tell you this: I don't want to go through this again. Michel.

8 9