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

2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources)
by Filiz Yilmaz 12 Nov '07

12 Nov '07

PDP Number: 2007-08 Enabling Methods for Reallocation of IPv4 Resources Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. This proposal outlines a framework to migrate previously allocated IPv4 resources from one Local Internet Registry (LIR) to another LIR within the RIPE NCC Service Region. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-08.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 20 November 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

14 24

Commercial IPv6 firewall support
by michael.dillon＠bt.com 07 Nov '07

07 Nov '07

Some people have claimed that they cannot yet sell IPv6 Internet access because there is no IPv6 firewall support. According to this ICANN study: http://www.icann.org/committees/security/sac021.pdf this is not quite true. At least 30% of the 42 vendors surveyed, had IPv6 support. According to this talk <http://www.guug.de/veranstaltungen/ecai6-2007/slides/2007-ECA-I6-Status -IPv6-Firewalling-PeterBieringer-Talk.pdf> many open-source and commercial firewalls supporting IPv6 are available. IPCop is based on Linux <http://www.ipcop.org/index.php?module=pnWikka&tag=IPCopScreenshots> m0n0wall is based on FreeBSD <http://m0n0.ch/wall/screenshots.php> pfSense is also based on FreeBSD <http://pfsense.com/index.php?id=26> FWBuilder is a management tool that builds filter setups for several different firewalls. <http://www.fwbuilder.org/archives/cat_screenshots.html> Checkpoint FW1 NGX R65 on SecurePlatform supports IPv6 FortiGate supports IPv6 in FortiOS 3.0 and up. Juniper SSG (formerly Netscreen) supports IPv6 in ScreenOS 6.0 and up. Cisco ASA (formerly PIX) supports IPv6 in version 7.0 and up. I suspect that the people complaining about IPv6 support are partially complaining because they have older hardware that the vendor does not plan to upgrade to IPv6 support until they have all features implemented in their newer products, and partially complaining because their vendor has not implemented some feature which they happen to use. Commercial firewall support may be lagging behind OS and router support, but not by much. And if commercial vendors are not responsive, maybe you should try pricing out an open source solution with a consultant. I believe there is a gap here that startup firewall companies could fill if they understand the enterprise market. --Michael Dillon

3 3

Hi, i need information
by Juan Felipe Botero Vega 07 Nov '07

07 Nov '07

Hi, I am working in a common project between the UPC (University Polithecnic of Catalonia, Spain) and Heanet (Ireland's National Education and Research Network). I know this is not a RPSL forum, but i need to know something about this language. In the RFC 2622 RPSL is well defined, but i don't have clear if it is possible to use RPSL for internal routing. My question is: is it possible to use RPSL to perform the following actions: 1. Configure a router announcing it's the networks it has connected to. 2. Configure the routing protocols in each router (this question depends directly of the previous one) 3. Configure the *routing policies *inside the network (i am not referring to BGP policies but policies of access control in each router inside a network). This could be applied also to OSPF areas?? Thanks for your attention.

2 1

2005-08 Proposal Accepted (Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy)
by Filiz Yilmaz 05 Nov '07

05 Nov '07

PDP Number: 2005-08 Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy Dear Colleagues Consensus has been reached on the proposal described in 2005-08 and it is accepted by the RIPE community. This proposal is to amend the RIPE IPv6 address allocation policies regarding the definition of the default size of End Site allocations, the threshold value for End Site allocation efficiency, and the method of calculation of the End Site allocation efficiency metric. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-08.html We will implement this new policy in approximately three weeks and notify you when it becomes effective. Thank you for your input. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

Re: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources)
by jwkckid1＠ix.netcom.com 04 Nov '07

04 Nov '07

Max and all, why can't it be enforced now? Why can these unused IP's be reclimed or at least parto of them? -----Original Message----- >From: Max Tulyev <president(a)ukraine.su> >Sent: Nov 3, 2007 4:40 PM >To: address-policy-wg(a)ripe.net >Subject: Re: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) > >Iljitsch van Beijnum wrote: >>> Leo has already proved that a (fairly simple) reclamation job takes a >>> lot of time and resource. This is for a /8 that no one much wanted and >>> no one much used. >> >> Was that the 14/8 thing? Only 129 individual addresses out of 16777216 >> where used. Maybe just reclaiming the other 16777087 would have been >> more efficient. > >May be. But sorry, you can't enforce it now. You even have no time to >make an implemented in the real life policy that can reclaim any block >before free IP space will be finished. > >So, we have to live with market. Not only because of it. The only we >can do is to make that market white and clear. > >-- >WBR, >Max Tulyev (MT6561-RIPE, 2:463/253@FIDO) > 'Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1(a)ix.netcom.com

3 3

Re: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources)
by jwkckid1＠ix.netcom.com 04 Nov '07

04 Nov '07

Max and all, That's my guess also Max. >;) -----Original Message----- >From: Max Tulyev <president(a)ukraine.su> >Sent: Nov 3, 2007 4:42 PM >To: address-policy-wg(a)ripe.net >Subject: Re: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) > > >Iljitsch van Beijnum wrote: >> I'm quickly approaching my posting limit for the day (week?) but I can't >> resist telling you the following story: >> >> I recently found myself somewhere where BitTorrent is severely >> throttled. Although I can download over HTTP at megabytes per second, >> BitTorrent downloads wouldn't go faster than 10 kilobytes per second. >> >> Turns out that the newest Azureus (BitTorrent application) supports >> IPv6. Enabled this and lo and behold: I got about 75 peers, 5 of which >> were IPv6, the rest IPv4. Of the IPv6 peers, one had a regular IPv6 >> address, the other four 6to4 addresses. Even though the 70 IPv4 peers >> could only give me 10 kB/s, the 5 IPv6 peers pushed my download well >> beyond 100 kB/s. > >May be that's just because of your rating in these peering networks? ;) > >-- >WBR, >Max Tulyev (MT6561-RIPE, 2:463/253@FIDO) > 'Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1(a)ix.netcom.com

1 0

RE: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources)
by Tim Streater 03 Nov '07

03 Nov '07

At 15:14 29/10/2007, Mark Pace Balzan wrote: > > > > IPv6 Internet is working even now, but completely useless. Because of > > there is no resources at all. > > > > In my opinion, the concrete goal is make 51% of _resources_ > > (not users) > > to be reachable through IPv6 before we run out of IPv4. If it > > succeeds, > > other 49% will go with "the majority", if not - IPv6 migration > > completely fails and something other (NAT, secondary market of IPv4, > > higher level proxies over non-IP protocols, ...) will be implemented > > instead. > > > >my 2c worth: > >v4 and v6 will co-exist for a while, whether we like it or not, and >therefore v4 and v6 stuff will need a way to get to each other depending >on the service at hand. They will co-exist for a long while due to lack of pressure from the users. If v4 really runs out, there will start to be some parts of the Internet that are not accessible to some users. Then they will complain to their ISP and something starts to happen. Then it gets in the mainstream press, at which point you may see a more rapid transition. Plenty of people will however say, why should I bother to get a new xxx box when I can reach all sites I care about. Unless the govts get involved, of course. -- Tim

7 10

Policy proposal - Cooperative distribution of the end of the IPv4 free pool.
by Tony Hain 31 Oct '07

31 Oct '07

Policy Proposal Name: Cooperative distribution of the end of the IPv4 free pool. Author name: Tony Hain email: alh-ietf(a)tndh.net telephone: +1-425-468-1061 organization: Cisco Systems Proposal Version: 1.0 Submission Date: Oct-30-2007 Proposal type: new Policy term: permanent Policy summary: This policy will establish a process for RIR-to-RIR redistribution of the tail-end of the IPv4 pool, taking effect after the IANA Reserve is exhausted. Each redistribution Allocation will be triggered by the recipient RIR depleting its reserve to a 30 day supply, and will result in up to a 3 month supply being transferred from the RIR with the longest remaining time before it exhausts its own pool. Policy statement: At the point when any given RIR is within 30 days of depleting its remaining IPv4 pool, a survey will be taken of the other 4 to determine the remaining time before each of them exhausts their pool (including both member use and recent redistribution allocations to other RIRs). The one with the longest window before exhausting its pool will be designated as the source RIR. The recipient RIR will follow procedures for an LIR in the source RIR region to request a block that is expected to be sufficient for up to 3 months, but is no larger than 1/8th of the source RIR's remaining pool. At the point where no RIR can supply a block that is less than 1/8th of their remaining pool that will sustain the recipient RIR for 30 days, the recipient RIR will collect its requests each week, and forward those individual requests to the source RIR designated that week. Rationale: This policy will establish a mechanism for the Allocation of IPv4 address blocks between RIR's, but will not go into effect until the IANA pool has been depleted. It is really bizarre to watch the maneuvering as the global RIR community grapples with 'fairness' of distributing the last few IANA Reserve /8 blocks. On one level this just appears to be petty sibling rivalry, as people are bickering over who gets the last cookie and whimpering about 'fairness'. At the same time, each RIR is chartered to look after the interests of its membership so it is to be expected that they will each want to get as much as possible to meet the needs of their respective membership. Existing practice requires RIR's to acquire blocks from IANA, which leads to the current round of nonsense about optimal distribution of the remaining pool based on elaborate mathematical models. This globally submitted policy proposal attempts to resolve the issue by shifting to an RIR-to-RIR Allocation model after the IANA pool is depleted. This policy would effectively result in each RIR becoming a virtual LIR member of all of the other RIR's for the sole purpose of managing the tail-end of the IPv4 pool. Timetable for implementation: Before 1/1/2009

5 4

RE: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources)
by Niall Murphy 31 Oct '07

31 Oct '07

Michael, all, > > The address space in question is already allocated, hence > > unavailable. The question is how to incent folks to put > > their "allocated but unused" address space back into play. > > Stamping your foot and declaring "markets are bad" > > isn't likely to be too helpful. > And thinking that you can influence address-holders decision making > without pricing an IPv4 at several hundred thousand dollars, is also not > likely to be too helpful. I don't think that anyone knows how the pricing is going to work yet, so I'm going to leave aside discussion of your specific figure. Similarly, "an IPv4" (an IPv4 what?) probably needs clarification, but it's not the substantive issue. Notwithstanding the detail of the numbers, which is obviously a crucial detail, I have to take issue with your assertion is that we cannot influence address-holder decision making without setting a price, and setting it high. The fact is, after IPv4 exhaustion we will still need IPv4 addresses. Address holders who have more IPv4 addresses than they will ever use will have a strong incentive to exchange those addresses for money, and IPv4-dependent organisations will have a strong incentive to purchase them. That's going to happen, make no mistake, because as an industry, we are *nowhere near* where we need to be in order to have an IPv6 world by 2010. So, there's already no question of address holders being uninfluenced. They certainly will be by 2010, if they're not already, and such pricing as emerges in a back-door market does not have to be high in order to provoke the release of addresses in an ad-hoc fashion. It's entirely plausible that a steady drip-feed of low-priced prefixes would suit many organisations better than holding on for higher prices (think cashflow, for example). For these and other reasons, there'll be no question of, for example, the RIR system being frustrated in its attempt to influence address-holders because of too low a price. The danger is not the RIR system and is not the market; the danger is the unregulated market, and the chaos of the current post-exhaustion scenario. > Any organization who contemplates selling a block of IPv4 addresses has > to conside the reality that it would be an extremely constrained market > where the supply is going down and they are not making any new IPv4 > addresses. Indeed - that's exactly right, and that's one of the reasons why it's such a powerful incentive to move to IPv6, which is, IIUYC, where we both want to be. But you must also consider that such a market as we proposed is not intended to be *the* solution: it is explicitly not for continually recycling existing prefixes. It is to provide liquidity to the participants for an undefined period until IPv6 is a workable day-to-day alternative to IPv4. So the fact that the market is constrained *doesn't matter* in the long term - we're inventing our way out of scarcity elsewhere. > This means that if you do sell, and then discover that you > needed those addresses after all, the price to buy them back could be > substantially higher than your sale price. In the face of continually > rising prices, it is risky to sell any addresses at all, unless you are > absolutely certain, at the CEO/board level, that the addresses are not > needed, or if the price that you would receive is at least several > hundred thousand dollars. (Again, I'm not going to talk about the figures here, but that's not a central point in your argument.) If I parse what you're saying correctly, you posit that the danger of accidentally selling addresses that it turns out that you'll need will motivate people to stay away from the market, and therefore cause rising prices and liquidity problems. Well, my argument would be that from an economic point of view, organisations are incentivized to only sell what they explicitly don't need. We all know of organisations that have much more spare than they could possibly use, so it's unclear where the original 'dump everything' motivation could come from. Furthermore, the meta-assertion that "a market might have problems" reinforces the fact that the community *must keep transfers where it can see them*. If they are happening out of sight, we have no direction observation or control of the same set of problems. > This is a recipe for a gold-rush style market followed by liquidity > collapse which will have additional knock-on effects in the real > markets, i.e. share prices. If you watch our talk webcast (when RIPE gets around to putting them up) you'll see more details of our argument here, but in brief the dangers of *not* having a realistic plan in place will cause as much damage to stock prices etc as much as leaving things alone will. I'm in sympathy with you on the topic of avoiding gold-rush markets and liquidity collapses, but I think with a bit of careful planning, we'll be able to avoid both. (If only we'd had that careful planning years ago, then we could have saved ourselves a lot of trouble. But now we're in the position of having no wholly good choices, it's only a question of choosing which set of bad effects we want.) Niall

1 0

Re: [address-policy-wg] Commercial IPv6 firewall support
by jwkckid1＠ix.netcom.com 29 Oct '07

29 Oct '07

Nick and all, Chiming in here as a kinda unusual occurance. I agree with Nicks assessment here unfortunately. Seems across a broad business spectrum a disinterest in IPv6 remains or presists. Given, what I believe to be an accurate essesment by Nick below, it would seem that a more concerted effort to make IPv6 more palatable in very short order is advisable. As to how to accomplish that, I do not know. -----Original Message----- >From: Nick Hilliard <nick(a)inex.ie> >Sent: Oct 27, 2007 9:25 AM >To: michael.dillon(a)bt.com >Cc: address-policy-wg(a)ripe.net, ipv6-wg(a)ripe.net >Subject: Re: [address-policy-wg] Commercial IPv6 firewall support > >> Some people have claimed that they cannot yet sell >> IPv6 Internet access because there is no IPv6 firewall >> support. According to this ICANN study: >> http://www.icann.org/committees/security/sac021.pdf >> this is not quite true. At least 30% of the 42 vendors >> surveyed, had IPv6 support. > >There is, of course, "support" and support when talking about any feature, >whether ipv6 related or not. > >As a useful example of what "support" implies, the "support" from one of my >firewall vendors includes basic support for ipv6 packet forwarding and >filtering, but no support for configuring this from the GUI. And no support >for failover / failback on ipv6. And no support for ospfv3. Or DHCPv6. Or >v6 support for VPNs. And so on - you get the idea. There are piles more >features which just aren't there if you use v6. In fact, I would suggest >that there is such a large functionality gap between their ipv4 and ipv6 >support right now, that even if they invested heavily between now and the >current expected dates for ipv4 exhaustion, I seriously doubt that they >would achieve feature parity, not to mind stability parity for these >features. > >I have talked to them about this, and their opinion is that there is no >commercial demand for ipv6, and therefore ipv6 feature parity is on the >feature roadmap. And indeed, it is difficult for the organisation I work >for to demand ipv6 support, when other companies can talk to their vendors >with a EUR100m firewall / networking contract going a-begging. I have >little doubt that this is the reason that MOP got re-enabled by default on a >certain router vendor's products. > > >Them: "We have EUR200m to spend and we want MOP enabled by default". >Vendor: "Three bags full, sir". > >Me: "I want to you spend $50m in development costs to support ipv6, and > then i'll buy some low end kit from you" >Vendor: <laughs hysterically> > >Open source solutions tend to fare better in this regard. Lots of people >may end up using them in a future ipv6 world, but you're not going to end up >seeing F500 companies stampeding to replace their current high-end solutions >with m0n0wall installations, just because they have more-or-less parity >support for ipv4 and ipv6. > >There's a more interesting discussion of this of this linked from: > >http://www.arin.net/meetings/minutes/ARIN_XX/ppm.html > >See the talk entitled "IPv6 Support Among Commercial Firewalls", by Dave >Piscitello. > >Nick > >-- >Network Ability Ltd. | Technical Operations | Tel: +353 1 6169698 >3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 >Dublin 2, Ireland | Exchange Association | Email: nick(a)inex.ie > 'Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1(a)ix.netcom.com

1 0