April 2006 - address-policy-wg

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

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

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

RE: Question
by Bound, Jim 24 Apr '06

24 Apr '06

Tony, Excellent response and educational for sure. It is my belief that the corporate business model today for operating networks may be broken and I think you supported that below? If not my apologies for bad parsing? Their models were fine for an IPv4 world where NAT was required and some even confuse NAT with securing ones network (and some programs in the U.S. Government) and that is simply bad policy and view. In the interim can this be resolved by RIRs creating some kind of additional wording that address reclaim will be done in manner that is negotiable, and do no harm to corporate or government business operations? This would buy us time to work on the issue and stop the FUD around this topic? Also I am willing to sponsor a world wide IPv6 Forum BOF on PI and addressing you can lead as ajunct to one of our regular meetings you can lead for an entire day and we get the right players in the room. So think about that as another option too. But do enjoy the beach this thread does not have to be resolved this week :--) Really want to hear from all of you and discussion Terry D., Latif, Yanick, Dave G. Mike B. etc. Thanks /jim > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Friday, April 07, 2006 7:57 PM > To: 'PPML'; address-policy-wg(a)ripe.net > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The New > Internet based on IPv6")'; 'Davis, Terry L'; > ollivier.robert(a)eurocontrol.fr; narten(a)us.ibm.com; 'Brig, > Michael P CIV DISA GES-E'; Pouffary, Yanick; 'Green, David B > RDECOM CERDEC STCD SRI' > Subject: RE: Question > > A public answer to a private question as I have been sitting > on a beach for awhile without the laptop and missed some > related conversations ... :) > > > Is the outcome really open for discussion on the PI issue? > It doesn't > > sound like it is. > > In the minds of some the route scaling issue outweighs any > argument for PI. > When taken to its extreme, there is a valid point that a > broken routing system serves no one. At the same time the > dogmatic stance by the ISPs enforcing lock-in is just as > broken both for large organizations with financial or legal > requirements for operational stability, and the individual > consumer/small business with limited budgets looking for true > competition. The hard part is finding the middle ground in a > way that limits the exposure to a potential routing collapse. > > I personally refuse to declare some needs legitimate and > others not, as the only point of such differentiation is to > establish a power broker. When all uses are legitimate, the > problem boils down to the technical approach that can be > scaled as necessary to contain growth in the routing system. > This is the logic that leads me to the bit-interleaved geo > that can be aggregated in varying size pockets as necessary > using existing BGP deployments. We can start flat and > implement aggregation over time when a region becomes too > large to handle. One nice side effect of this geo approach is > that it mitigates the continuing political demands for > sovereign rights to IPv6 space. > > Any aggregation approach will force the business models to > change from current practice. That is not as bad a thing as > the alarmists will make it out to be, because their > accountants are claiming the current model is a broken money > looser as it is (which if so means they will eventually > change anyway). The primary difference is that there will > need to be aggregation intermediaries between the last-mile > and transit providers. The current model eliminates these > middle-men by trading off their routing mitigation service > against a larger routing table (actually they already exist > in the right places but are currently limited to layer2 media > aggregators). The anti-PI bunch is trying to use social > engineering to directly counter the bottom line business > reality that the customer will always win in the end. > Rather than accept this situation and constructively work on > the necessary business model and technology developments, > they effectively stall progress by staunchly claiming there > is no acceptable technical approach that works within the > current business structure. > > Making the RIRs be the police deciding who qualifies for PI > and who does not just adds to their workload and raises > costs. The beneficiaries of this gatekeeper approach are the > ISPs that claim they need full routing knowledge everywhere, > while the cost burden for supporting the waste-of-time > qualification/evaluation work is borne by the applicant. > Given that the most vocal and organized membership in the RIR > community are the ISPs it is easy to understand why it would > seem like the PI issue is already decided as closed. I tend > to believe it will just drag out until enough of the > corporate world becomes aware of the IPv4 exhaustion in light > of their growth needs that they collectively appear at their > RIR and demand an immediate solution. Unfortunately this > 'wait till the last minute' tactic will likely result in a > reactionary quickie with its own set of long term side effects. > > A while back I tried to hold a BOF on geo PI in the IETF, but > was told that > shim6 was the anointed solution. Now that at least nanog has > told the IAB where to put shim6 it might be possible to get > the current IESG to reconsider. In any case the result would > be a technical approach that would still require RIRs to > establish policies around. As long as they are dominated by > the ISPs it will be difficult to get real PI. > > Tony > >

15 25

Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive
by Thomas Narten 22 Apr '06

22 Apr '06

"Stephen Sprunk" <stephen(a)sprunk.org> writes: > OTOH, it's ridiculously easy to get PIv4 space today (512 hosts and two > pipes or tunnels), and there's not all that many companies doing it. It's > not growing much either. The doors are already wide open for a land rush > and nobody is taking ARIN up on it. Why does everyone assume it'll happen > with v6 if it's not happening with v4, which _is_ useful today? Because today, people are a lot more network savvy, and they now understand the potential value of getting real PI space. Moreover, anyone who understands history, realizes that getting PI space may become harder in the future, rather than easier. Consequently, it would be a smart business move to get PI space ASAP, in case the rules change down the road. i.e, a rather prudent investment. Thomas

3 2

Re: HD-ratio Proposal - Last Call has ended. Cosensus not reached.
by Hans Petter Holen 20 Apr '06

20 Apr '06

RIPE NCC Policy Coordinator wrote: > PDP Number: 2005-01 > HD-ratio Proposal > > Dear Hans Petter > > This is to remind you that the "Last Call" period for the proposed > change to RIPE Document ripe-368 has ended. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2005-1.html > > Please reply to this e-mail to let me know how you would like to proceed. > > * Consensus has been reached. We should publish the policy. > > * Consensus has not been reached. You want to > > * withdraw the policy; > > * return to the review phase (please tell us what duration to set for > the review period); or > The chairs of the Address policy working group have consulted and are divided on the matter of this policy. The outcome of this discussion and consultation with wg-chairs and RIPE Chair in general is that we see a clear consensus in favor of the current proposal. We do see a growing opposition based on the perception of how this will influence future address allocations to emerging regions. I will therefor return the policy to the review phase, for further discussion on the mailing-list and on the upcoming RIPE meeting. As a side note the matter of how RIPE should relate to other organizations in our policy making process I would like to make the following remark; RIPE policy is made by individual contributions to mailing lists and at RIPE meetings. Not by meetings of other organizations. Our discussions should be based on technical arguments in the relevant RIPE fora. Best Regards, Hans Petter Holen Address Policy Chair

2 2

New Document available: RIPE-376
by RIPE NCC Document Announcement Service 20 Apr '06

20 Apr '06

<<< our apologies for duplicate e-mails >>> New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-376 Title: Assigned Numbers Authority (IANA) Policy for Allocation of IPv6 Blocks to Regional Internet Registries Author: AfriNIC APNIC ARIN LACNIC RIPE NCC Date: 19 April 2006 Format: PDF=10551 TXT=4280 Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- This document describes the policy governing the allocation of IPv6 address space from the IANA to the Regional Internet Registries (RIRs). This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with this policy. Such requirements will be specified by appropriate agreements between ICANN and the NRO. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL: http://www.ripe.net/ripe/docs/ripe-376.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-376.pdf PDF version ftp://ftp.ripe.net/ripe/docs/ripe-376.txt plain text version Kind Regards, Jeroen Bet RIPE NCC Content Webmaster

1 0