From dr at cluenet.de Tue Mar 1 00:15:20 2011 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 1 Mar 2011 00:15:20 +0100 Subject: [address-policy-wg] Re: IPv6 allocations for 6RD In-Reply-To: <9FC46597D80C48919ADC9BEBD89A7159@mTOSH> References: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> <9FC46597D80C48919ADC9BEBD89A7159@mTOSH> Message-ID: <20110228231520.GB27543@srv03.cluenet.de> On Mon, Feb 28, 2011 at 02:44:53PM +0200, Ahmed Abu-Abed wrote: > Note that the /64 limitation is specific to 6RD protocol as I explained > in an earlier email. I fail to find this email, could you provide archive pointers or explain again? I'm not aware of any instrinct /64 limitation of 6RD, and existing implementations prove the contrary. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From dr at cluenet.de Tue Mar 1 00:47:46 2011 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 1 Mar 2011 00:47:46 +0100 Subject: [address-policy-wg] Re: IPv6 allocations for 6RD In-Reply-To: <20110228142042.GL30227@Space.Net> References: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> <20110228142042.GL30227@Space.Net> Message-ID: <20110228234746.GC27543@srv03.cluenet.de> On Mon, Feb 28, 2011 at 03:20:42PM +0100, Gert Doering wrote: > - what 6rd implementations are there "out in the market" today? > (both provider and CPE side) I know of (and can are not under NDA) _and_ got my hands on: BR: Cisco ASR1k CPE: AVM FritzBox > - what approach do they take? "always use 32 bits for mapping" or > the configurable approach from the i-d quoted above (IPv4MaskLen > 0)? Cisco IOS (on ASR1k): fully flexible configurable AVM: currently fixed /63 (as they may use routed mode between LAN and WiFi, thus two /64s needed) with full 32bit IPv4 mapping, in future flexible on v4-mapping width and delegated subnet size down to /63 or even /64. Ideally, IFF we would use 6RD, we'd like to have a single /24 block to support full 32bit IPv4 address mapping while providing a /56 to customers. Fiddling around with all your different IPv4 PA aggregates, splitting 6RD domains and trying to find halfway suitable space for those in your "normal" IPv6 allocation to support 6RD is.... well, a significant cost for operational point of view, making 6RD actually not that "rapid" and cheap to deploy. The present RIPE policies do add non-negliable indirect cost to deploy 6RD. At least if your plan is to go proper dual-stack "everywhere" over time and you want to use a nice-and-shiny addressing scheme for your allocation, not disturbed by large 6RD blocks. See other folks' recent comments here. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From ahmed at tamkien.com Tue Mar 1 09:24:46 2011 From: ahmed at tamkien.com (Ahmed Abu-Abed) Date: Tue, 1 Mar 2011 10:24:46 +0200 Subject: [address-policy-wg] Re: IPv6 allocations for 6RD In-Reply-To: <20110228231520.GB27543@srv03.cluenet.de> References: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> <9FC46597D80C48919ADC9BEBD89A7159@mTOSH> <20110228231520.GB27543@srv03.cluenet.de> Message-ID: According to RFC 5969 for 6rd: " Embedding less than the full 32 bits of a CE IPv4 address is possible only when an aggregated block of IPv4 addresses is available for a given 6rd domain. This may not be practical with global IPv4 addresses, but is quite likely in a deployment where private addresses are being assigned to CEs. " So the /64 limitation for 6rd applies when an aggregated block of IPv4 addresses is not being used. Regards, -Ahmed From: Daniel Roesen Sent: Tuesday, March 01, 2011 1:15 AM To: address-policy-wg at ripe.net Subject: [address-policy-wg] Re: IPv6 allocations for 6RD On Mon, Feb 28, 2011 at 02:44:53PM +0200, Ahmed Abu-Abed wrote: > Note that the /64 limitation is specific to 6RD protocol as I explained > in an earlier email. I fail to find this email, could you provide archive pointers or explain again? I'm not aware of any instrinct /64 limitation of 6RD, and existing implementations prove the contrary. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dr at cluenet.de Tue Mar 1 09:42:35 2011 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 1 Mar 2011 09:42:35 +0100 Subject: [address-policy-wg] Re: Re: IPv6 allocations for 6RD In-Reply-To: References: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> <9FC46597D80C48919ADC9BEBD89A7159@mTOSH> <20110228231520.GB27543@srv03.cluenet.de> Message-ID: <20110301084235.GA3258@srv03.cluenet.de> On Tue, Mar 01, 2011 at 10:24:46AM +0200, Ahmed Abu-Abed wrote: > According to RFC 5969 for 6rd: > > " Embedding less than the full 32 bits of a CE IPv4 address is possible > only when an aggregated block of IPv4 addresses is available for a > given 6rd domain. This may not be practical with global IPv4 > addresses, but is quite likely in a deployment where private > addresses are being assigned to CEs. " > > So the /64 limitation for 6rd applies when an aggregated block of IPv4 > addresses is not being used. I cannot read that in there. Above paragraphs talks about sub-32bit mapping of IPv4 endpoint addresses. This is orthogonal to what the prefix size for your customer delegation is. Example: your 6RD domain is a /27 IPv4 block. You can serve that with an IPv6 /51 block, giving each 6RD customer a /56. IPv4 /27 == 5 relevant bits (host addressing), 51+5=56. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From mattias.gyllenvarg at bredband2.se Tue Mar 1 10:36:34 2011 From: mattias.gyllenvarg at bredband2.se (Wyatt Mattias Gyllenvarg) Date: Tue, 01 Mar 2011 10:36:34 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <9916E4B6-8CC9-4BDC-9784-26555A5B80CE@townsley.net> References: <4D652694.4050401@bredband2.se> <3F545002E3DA4FF7B951A7CAA36C7655@mTOSH> <20110224153157.GH30227@Space.Net> <9916E4B6-8CC9-4BDC-9784-26555A5B80CE@townsley.net> Message-ID: <4D6CBE22.9040806@bredband2.se> We agree with Mark on every point. This is the reality we work with. I would accept a time frame for last implementaion and also a time frame for when native6 has to be operational. Med V?nliga H?lsningar - Best regards Mattias Gyllenvarg Network Operations Center Bredband2 ---------------------- end of line --------------------------- On 2011-02-25 16:31, Mark Townsley wrote: > This is not the first time this has come up on this list. It came up a few months back at ARIN as well, and resulted in a policy change that now allows subsequent allocations to ISPs that already have begun deployment within a /32 allocated in the past, but need additional space for continued deployment (for whatever reason, of which 6rd was one of the motivational factors presented). ARIN rejected mention of 6rd specifically as there were understandable objections to mentioning one particular transition technology over another, but it was certainly present in the open discussion leading up to the change. > > But, regardless of what ARIN has done, the issues boil down to this: > > Native residential IPv6 is proving difficult today. This is particularly problematic for IPoE DSL deployments where the vast majority of equipment deployed in the past 0-5 years which relies on snooping of DHCP, ARP, IMGP, etc. in order to operate in a split-horizon mode with subscribers connected into the same VLAN has largely no support for IPv6, DHCPv6, Neighbor Discovery, MLD, etc. Ironically, architectures based on "last-generation" PPP or simpler 1:1 VLAN models tend to work much better with IPv6 than the latest-greatest architectures that were built up in the past decade. This is true not only in DSL, but throughout the industry as somewhere after the dot-com boom and before the recent realization of IPv4 address exhaustion, much of the industry forgot to keep IPv6 in mind while inventing lots of new stuff. As such, overlays are needed, and 6rd is a particularly well-suited one for residential deployments. At the moment, 6rd is responsible for the majority of ISP-supported IPv6 traffic on the Internet today (based verbal comments from a very large content provider that supports v6), and based on the number of SPs I see successfully turning up 6rd vs. native service, I expect this will continue to be the case for at least the next few years. > > With a /32, 6rd easily supports a single /64 to a site. 6rd includes the ability to be more efficient with the address mapping algorithm, but this comes with additional overhead in provisioning that the ISP must endure. I know of SPs that have managed to plan for fairly efficient mappings by setting up several 6rd domains. However, others have difficulties in doing so, and at the end of the day mapping a full 32 bits into the IPv6 prefix is *always* simpler and easier. > > If an ISP cannot get a prefix shorter than /32 to operate 6rd within, at some point a decision is made between operational complexity of multiple 6rd domains, cost of native IPv6, cost and scalability of stateful tunnels such as TSP or L2TP, all vs. 6rd with a /64 to the customer. What I'm worried about is that the latter will win, and we'll end up with no subnets in the home. A /64 IPv6 service seriously complicates the design of IPv6 in home networks that have more than a single LAN (including those that simply have a "home" and "guest" SSID).... unless we just give up and have the CPE NAT IPv6, which is another real possibility if we let /64 become the least common denominator service to the home. > > All of this is why I would be in strong support of a policy that would allow a /28 to an ISP that requires 6rd in order to deploy IPv6 to its customer base and actually does so within, say, 6-12 months (the most significant limiting factor outside of the direct control of the ISP would be the CPE itself; ISPs which own their own CPE should have a plan for 6rd in future releases, and those without direct control on the CPE should be able to at least point their customers to a 6rd compatible CPE model if they choose to buy one). This allows an ISP that cannot deploy native IPv6 in the near term to deploy IPv6 with 6rd and still allow at least a /60 to the home, which is far, far, better than /64. It's hard enough to get CPE to do IPv6 correctly, and I would really like to avoid them having to get creative enough to figure out how to do IPv6 with a single /64. > > As a sidenote: Medium to Large ISPs in the RIPE region are managing to get the space they need for 6rd under existing policies that allow for planning /48s to all sites. As such, the above would effectively end up being a policy change for "smaller" ISPs. To combat fear that the sum of these small ISPs would exhaust all of our v6 address space, we could draw up requirements to identify blocking factors to native IPv6 or 6rd with multiple domains where the alternative would be either no IPv6 or IPv6 with a /64. I'd even go so far as to give preferential treatment to ISPs that can show they will have to resort to CGN deployment before IPv6 could otherwise be deployed. > > I'd rather avoid all that complexity though. I think a policy of allowing a /28 to an ISP that is going to deploy and support IPv6 to their users within a short period of time (with a threat of taking it back if they don't!), is not a bad way to spend our address space over the next few years (which is another time limit we could put on the policy). From what I can see, I think we could get a pretty good IPv6 adoption return on that investment. > > - Mark > > From andrea at ripe.net Tue Mar 1 16:25:29 2011 From: andrea at ripe.net (Andrea Cima) Date: Tue, 01 Mar 2011 16:25:29 +0100 Subject: [address-policy-wg] Re: New IPv4 block allocated to RIPE NCC In-Reply-To: <4D67EC50.6040908@cymru.com> References: <4D4FBBDA.8040704@ripe.net> <4D5961A6.6030201@cymru.com> <4D5A73E0.8020804@ripe.net> <4D5AC87D.9060603@cymru.com> <4D5BF778.50709@ripe.net> <4D67EC50.6040908@cymru.com> Message-ID: <4D6D0FE9.3010905@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Tim, Tim Wilde wrote: > On 2/16/2011 10:12 AM, Andrea Cima wrote: >> Historically these pilot prefixes have never been listed in the >> delegated-latest file. However I agree with you that they should. >> We will add these temporary allocations to the delegated-latest file in >> the coming days. > > Greetings Andrea, > > Do you have any idea of a timeline for these blocks to be added to the > delegated-latest file? I just checked the most recent file and still do > not see any allocations within 185/8, including the debogon tests. The prefixes are now included in the delegated-latest file. If you have any further questions please let me know. Best regards, Andrea Cima RIPE NCC > Thanks, > Tim Wilde > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAk1tD+kACgkQXOgsmPkFrjO2FQCdEmt+hJ+xW2CxFKZBYf/8ywBo q0MAoL8yPD9+zFVP8IuOD7dCjEeW8S4/ =/4G9 -----END PGP SIGNATURE----- From twilde at cymru.com Tue Mar 1 17:24:26 2011 From: twilde at cymru.com (Tim Wilde) Date: Tue, 01 Mar 2011 11:24:26 -0500 Subject: [address-policy-wg] Re: New IPv4 block allocated to RIPE NCC In-Reply-To: <4D6D0FE9.3010905@ripe.net> References: <4D4FBBDA.8040704@ripe.net> <4D5961A6.6030201@cymru.com> <4D5A73E0.8020804@ripe.net> <4D5AC87D.9060603@cymru.com> <4D5BF778.50709@ripe.net> <4D67EC50.6040908@cymru.com> <4D6D0FE9.3010905@ripe.net> Message-ID: <4D6D1DBA.1050606@cymru.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/1/2011 10:25 AM, Andrea Cima wrote: > The prefixes are now included in the delegated-latest file. Great, thank you very much! Best regards, Tim Wilde - -- Tim Wilde, Senior Software Engineer, Team Cymru, Inc. twilde at cymru.com | +1-630-230-5433 | http://www.team-cymru.org/ -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAk1tHboACgkQluRbRini9tgmRgCdEnLTfv8WruJnQ3f/aT0JiLMt /6QAnjeySS8WpCW5ycEScLwmZUlcFH7B =73dt -----END PGP SIGNATURE----- From fweimer at bfk.de Thu Mar 3 10:30:07 2011 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 03 Mar 2011 09:30:07 +0000 Subject: [address-policy-wg] IPv6 PI for profit, webhosting and route deaggregation In-Reply-To: (Jim Reid's message of "Thu\, 17 Feb 2011 09\:54\:05 +0000") References: Message-ID: <82lj0w1rhc.fsf@mid.bfk.de> * Jim Reid: > There's no reason to repeat the same mistakes with IPv6 allocation > policy as we did with IPv4. Doling out lots of non-aggregatable IPv6 > PI allocations will just give us a re-run of today's IPv4 routing > table scalability horrors. With IPv4, you can aggregate routes before installing them into the FIB (because only few of the routing decisions are semantically meaningful), at least if the CPU which computes the FIB is a bit more beefy than what is built into your smartphone. If your vendor still isn't doing that, it might make sense to consider switching vendors, or at least use it as a negotiating tool for getting better deals on upgrades. So IPv4 isn't that bad, even technically, if you think about it. But it turns out that the current IPv6 allocation practice prevents running with aggregated FIBs---there's a hole after each PA allocation. The hole is visible because you're expected to generated ICMP unreachables for packets target there, so you can't lump two PA prefixes together, even if they share the same next hop. This is yet another case of premature optimization gone wrong. IPv6 history is full of well-meaning optimization attempts, but curiously few actually are an improvement over IPv4, and some are downright harmful (like the header layout "for optimized forwarding"). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer at bfk.de Thu Mar 3 10:44:24 2011 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 03 Mar 2011 09:44:24 +0000 Subject: [address-policy-wg] IPv6 PI resource question! In-Reply-To: <4D5C4B78.70601@inex.ie> (Nick Hilliard's message of "Wed\, 16 Feb 2011 22\:11\:04 +0000") References: <4D5C4B78.70601@inex.ie> Message-ID: <82d3m81qtj.fsf@mid.bfk.de> * Nick Hilliard: > One of the more common hardware components for performing IP address > lookups is called TCAM - ternary content addressable memory. It > performs a similar function to an associative array in a language like > PHP, except it's implemented in hardware. It's ridiculously fast and > ridiculously expensive, and because it's so expensive, router > manufacturers tend not to put large quantities into their lookup > engines. Very nice explanation, thanks! Cost is probably not that much of an issue. I suspect that the bits-per-Watt number is still extremely poor for current TCAMs (data sheets do not quote them), which means that you can only use a limited number of them in parallel. Especially for IPv6, alternative implementations are probably quite competitive, such as hardware-assisted tries or hybrid schemes relying mostly on DRAM. You can also take a few shortcuts if you encode the current IPv6 addressing architecture in silicon. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From sander at steffann.nl Thu Mar 3 12:36:23 2011 From: sander at steffann.nl (Sander Steffann) Date: Thu, 3 Mar 2011 12:36:23 +0100 Subject: [address-policy-wg] IPv6 PI for profit, webhosting and route deaggregation In-Reply-To: <82lj0w1rhc.fsf@mid.bfk.de> References: <82lj0w1rhc.fsf@mid.bfk.de> Message-ID: <7D49ADD8-0A7B-4092-9371-E9EC5CD65B47@steffann.nl> > So IPv4 isn't that bad, even technically, if you think about it. But > it turns out that the current IPv6 allocation practice prevents > running with aggregated FIBs---there's a hole after each PA > allocation. The hole is visible because you're expected to generated > ICMP unreachables for packets target there, so you can't lump two PA > prefixes together, even if they share the same next hop. This is yet > another case of premature optimization gone wrong. This would mean that one ISP de-aggregating their /32 won't cause many problems. Those could be auto-aggregated in the FIB. - Sander From nick at inex.ie Thu Mar 3 12:55:00 2011 From: nick at inex.ie (Nick Hilliard) Date: Thu, 03 Mar 2011 11:55:00 +0000 Subject: [address-policy-wg] IPv6 PI for profit, webhosting and route deaggregation In-Reply-To: <82lj0w1rhc.fsf@mid.bfk.de> References: <82lj0w1rhc.fsf@mid.bfk.de> Message-ID: <4D6F8194.1070908@inex.ie> On 03/03/2011 09:30, Florian Weimer wrote: > With IPv4, you can aggregate routes before installing them into the > FIB (because only few of the routing decisions are semantically > meaningful), at least if the CPU which computes the FIB is a bit more > beefy than what is built into your smartphone. If your vendor still > isn't doing that, it might make sense to consider switching vendors, > or at least use it as a negotiating tool for getting better deals on > upgrades. You can certainly do this with lookup engines. Problem is that if you do it, you're breaking the deterministic rib->fib relationship model and replacing it with a nondeterministic system, which will probably work very well in almost all situations, but which has corner cases which fail catastrophically once you run out of lookup engine bits. Looking at it another way, automatic route aggregation creates overcommit between the RIB and the FIB. If that overcommit charge is exercised, things will break horribly. Nick From fweimer at bfk.de Thu Mar 3 13:13:15 2011 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 03 Mar 2011 12:13:15 +0000 Subject: [address-policy-wg] IPv6 PI for profit, webhosting and route deaggregation In-Reply-To: <4D6F8194.1070908@inex.ie> (Nick Hilliard's message of "Thu\, 03 Mar 2011 11\:55\:00 +0000") References: <82lj0w1rhc.fsf@mid.bfk.de> <4D6F8194.1070908@inex.ie> Message-ID: <82zkpcz9k4.fsf@mid.bfk.de> * Nick Hilliard: > You can certainly do this with lookup engines. Problem is that if you > do it, you're breaking the deterministic rib->fib relationship model > and replacing it with a nondeterministic system, which will probably > work very well in almost all situations, but which has corner cases > which fail catastrophically once you run out of lookup engine bits. I'm not convinced. The TCAM data structure have no relationship with the RIB anymore (and the compilation process has not always been bug-free), either. Aggregation is just a table mangling that could be performed in a transparent fashion. It's an interesting question if you can implement efficient deletes with aggregation. But then, you could fake that with a brute-force approach. > Looking at it another way, automatic route aggregation creates > overcommit between the RIB and the FIB. If that overcommit charge is > exercised, things will break horribly. I think the point is to push it so far away that you won't hit it. There are always some limits. The important question is whether you encounter them during (reasonable) life-time of the device. In any case, I would expect that current TCAM-based implementations could be exhausted before their nominal capacity is reached with a carefully crafted list of routes. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From adriano at rybnet.pl Mon Mar 7 13:30:58 2011 From: adriano at rybnet.pl (Adrian Czapek) Date: Mon, 07 Mar 2011 13:30:58 +0100 Subject: [address-policy-wg] IPv6 PI resource question - Not for ISP but hosting Message-ID: <4D74D002.3020608@rybnet.pl> My similar request was rejected for the same reasons. Although I did not get a proposal to sub-allocate PA address space from my allocation and deaggreage it over BGP, as Mathieu got, but let's assume that I would get such proposal if I asked for it. What puzzles me, what is the meaning of that action? Let's check the options: 1. They become LIR, they got their allocation - result: +1 prefix i global routing table. 2. They gets PA suballocation from other LIR and deaggreate it - result +1 prefix in global routing table. 3. They gets PI address space - +1 prefix in global routing table. As can be clearly seen above, global routing table growth is not an issue here, since IPRA suggests to deaggregate PA sub-allocations. So, what is an issue here, beacuse I have a strange feeling that only issue are $$ lost by certain RIR due to certain companies refusing to become LIR?! Regards -- Adrian From ebais at a2b-internet.com Mon Mar 7 14:31:42 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 7 Mar 2011 14:31:42 +0100 Subject: [address-policy-wg] IPv6 PI resource question - Not for ISP but hosting In-Reply-To: <4D74D002.3020608@rybnet.pl> References: <4D74D002.3020608@rybnet.pl> Message-ID: <007a01cbdccb$ff783190$fe6894b0$@com> Hi Adrian, > As can be clearly seen above, global routing table growth is not an > issue here, since IPRA suggests to deaggregate PA sub-allocations. So, > what is an issue here, beacuse I have a strange feeling that only issue > are $$ lost by certain RIR due to certain companies refusing to become LIR?! My point exactly. It looks like the current policy discriminates on money instead of the suggested routing table growth. If a company decides to buy their way into the community, by becoming a LIR, nobody cares anymore about the routing table growth. That means that the current policy isn't working in the interest of IPv6 adoption as each PI v6 end-user should have a multi-homed environment. And I know enough companies that have no intention of using PI for that specific reason yet. They want to have portable globally unique IP space with the option to grow into a situation in the future to multi-home or at least have the option to change ISP's without having to renumber their complete infrastructure. Having said this, the current requirement (multi-homing) is a way to avoid pet IT projects. I'm currently in the process of writing a policy change document on the policy RIPE-512 that would remove the multi-homing requirement and suggests an increase of the PI IPv6 cost to 250 euro per yearly maintenance fee for the LIR. The increased cost for the LIR for a PI IPv6 prefix, should have a similar effect. The increased cost isn't something that the RIPE community can decide on, that has to go through the AGM meeting (voted by LIR Members). However by suggesting this within the policy we can get this on the agenda. Erik Bais From adriano at rybnet.pl Mon Mar 7 15:27:34 2011 From: adriano at rybnet.pl (Adrian Czapek) Date: Mon, 07 Mar 2011 15:27:34 +0100 Subject: [address-policy-wg] IPv6 PI resource question - Not for ISP but hosting In-Reply-To: <007a01cbdccb$ff783190$fe6894b0$@com> References: <4D74D002.3020608@rybnet.pl> <007a01cbdccb$ff783190$fe6894b0$@com> Message-ID: <4D74EB56.6060903@rybnet.pl> > Having said this, the current requirement (multi-homing) is a way to > avoid pet IT projects. > > I'm currently in the process of writing a policy change document on > the policy RIPE-512 that would remove the multi-homing requirement > and suggests an increase of the PI IPv6 cost to 250 euro per yearly > maintenance fee for the LIR. The increased cost for the LIR for a PI > IPv6 prefix, should have a similar effect. > It's fine, but it will not fix the problem of hosting companies that do not want to become LIR (mainly for financial reasons) just to get their own IPv6 address space. We have to realize that the transition to IPv6 depends on content availability. As long as hosting companies will have impeded access to something as basic as IP addresses, we can forget about transition at all. Regards -- Adrian From arne at ripe.net Thu Mar 10 16:16:40 2011 From: arne at ripe.net (Arne Kiessling) Date: Thu, 10 Mar 2011 16:16:40 +0100 Subject: [address-policy-wg] New RIPE NCC Procedural Document Available Message-ID: <4D78EB58.4020203@ripe.net> Dear Colleagues, The RIPE NCC has published the new procedural document ripe-511, "Implementation of RIPE Policy 'Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region' - Phase 3". This document describes the RIPE NCC procedure when contacting End Users of independent Internet number resources who have not yet entered into a contractual relationship with sponsoring Local Internet Registry (LIR) or the RIPE NCC. It also describes the possible consequences if End Users of independent Internet number resources fail to respond when approached by the RIPE NCC or are not compliant with the policies of the RIPE community. The new document is available at: http://www.ripe.net/ripe/docs/ripe-511 -- Kind Regards Arne Kiessling IP Resource Analyst RIPE Network Coordination Centre From remi.despres at free.fr Thu Mar 10 19:01:56 2011 From: remi.despres at free.fr (=?iso-8859-1?Q?R=E9mi_Despr=E9s?=) Date: Thu, 10 Mar 2011 19:01:56 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> Message-ID: <291F32D0-9F93-44FC-AB7E-792F936332B3@free.fr> Le 28 f?vr. 2011 ? 10:29, Randy Bush a ?crit : >> I strongly support the idea of assigning a smaller prefix to ISPs >> which are in a state of deploying IPv6 but need to use transitional >> mechanism for (some of) their customers. > > only problem is that 6rd is not a transition mechanism. it is an > anti-transition mechanism. Whatever you call it, it remains an effective way to rapidly offer native IPv6 addresses, and real IPv6 service, to customers. RD From remi.despres at free.fr Thu Mar 10 19:10:28 2011 From: remi.despres at free.fr (=?iso-8859-1?Q?R=E9mi_Despr=E9s?=) Date: Thu, 10 Mar 2011 19:10:28 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <20110228142042.GL30227@Space.Net> References: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> <20110228142042.GL30227@Space.Net> Message-ID: Le 28 f?vr. 2011 ? 15:20, Gert Doering a ?crit : > Hi, > > On Mon, Feb 28, 2011 at 10:13:51AM +0100, Kurt Smolderen wrote: >> I strongly support the idea of assigning a smaller prefix to ISPs >> which are in a state of deploying IPv6 but need to use transitional >> mechanism for (some of) their customers. Mark has described one of >> the problems very clear in his email: if an ISP has only a /32 >> prefix and needs to use all 32 IPv4 bits in the 6rd configuration, >> only a /64 can be delivered to the home instead of the desired /56 >> or /48. Needing all 32 bits is for instance the case when an ISP >> offers internet connectivity to some of its customers via a partnership >> with another ISP. > > Without commenting on the general idea of allocating a larger chunk of > addresses to ISPs, I want to make sure that the underlying facts are > presented correctly. > > While RFC 5569 (the 6rd RFC) takes the "naive" approach of blindly mapping > IPv4 <-> IPv6 using the whole 32bits, it doesn't *have* to be that way It doesn't have to, right. But, if being native permits to deploy good IPv6 service to the masses before other means to do it are available, being naive is better than being overly purist. For ISPs that have been assigned several IPv4 prefixes (as many have been), the "naive" approach remains the simplest one to operate. Regards, RD From hank at efes.iucc.ac.il Thu Mar 10 20:11:36 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 10 Mar 2011 21:11:36 +0200 (IST) Subject: [address-policy-wg] Re: [ncc-services-wg] New RIPE NCC Procedural Document Available In-Reply-To: <4D78EB58.4020203@ripe.net> References: <4D78EB58.4020203@ripe.net> Message-ID: On Thu, 10 Mar 2011, Arne Kiessling wrote: What happens if the resource is in the routing table, and the resource holder doesn't respond, nor does their upstream provider? Will RIPE NCC ever "Delete all relevant objects in the RIPE Database including aut-num/inetnum, domain and route objects"? Can I make a suggestion? RIPE NCC should make a site - broken down by country code of those resources that they are unable to contact. Just as you send out these notices, you can post a notice that country xx has 25 unknown resources and RIPE NCC asks the help of its members in trying to contact the resource holder. Giving this extra 3 month effort should then validate anything RIPE NCC would do to the resource after this period. Regards, Hank > Dear Colleagues, > > The RIPE NCC has published the new procedural document ripe-511, > "Implementation of RIPE Policy 'Contractual Requirements for Provider > Independent Resource Holders in the RIPE NCC Service Region' - Phase 3". > > This document describes the RIPE NCC procedure when contacting End Users of > independent Internet number resources who have not yet entered into a > contractual relationship with sponsoring Local Internet Registry (LIR) or the > RIPE NCC. > > It also describes the possible consequences if End Users of independent > Internet number resources fail to respond when approached by the RIPE NCC or > are not compliant with the policies of the RIPE community. > > The new document is available at: > http://www.ripe.net/ripe/docs/ripe-511 > > > From ahmed at tamkien.com Sun Mar 13 07:26:41 2011 From: ahmed at tamkien.com (Ahmed Abu-Abed) Date: Sun, 13 Mar 2011 09:26:41 +0300 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> <20110228142042.GL30227@Space.Net> Message-ID: <7A05388495C24A20A247029864850C46@mTOSH> If simplicity in IPv6 transition means initially offering IPv6-over-IPv4 to subscribers while meeting 2 fundamental requirements, namely end-user prefix delegation and commercial hardware CPE support, then there are 3 protocols that can be used depending on the service provider requirements: 6rd, TSP and L2TP. If implementing 6rd, service providers may need an allocation larger than /32 as the 6rd protocol embeds the users IPv4 address, or part there of, in their IPv6 address. Regards, -Ahmed From: R?mi Despr?s Sent: Thursday, March 10, 2011 9:10 PM To: Gert Doering Cc: Kurt Smolderen ; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD Le 28 f?vr. 2011 ? 15:20, Gert Doering a ?crit : > Hi, > > On Mon, Feb 28, 2011 at 10:13:51AM +0100, Kurt Smolderen wrote: >> I strongly support the idea of assigning a smaller prefix to ISPs >> which are in a state of deploying IPv6 but need to use transitional >> mechanism for (some of) their customers. Mark has described one of >> the problems very clear in his email: if an ISP has only a /32 >> prefix and needs to use all 32 IPv4 bits in the 6rd configuration, >> only a /64 can be delivered to the home instead of the desired /56 >> or /48. Needing all 32 bits is for instance the case when an ISP >> offers internet connectivity to some of its customers via a partnership >> with another ISP. > > Without commenting on the general idea of allocating a larger chunk of > addresses to ISPs, I want to make sure that the underlying facts are > presented correctly. > > While RFC 5569 (the 6rd RFC) takes the "naive" approach of blindly mapping > IPv4 <-> IPv6 using the whole 32bits, it doesn't *have* to be that way It doesn't have to, right. But, if being native permits to deploy good IPv6 service to the masses before other means to do it are available, being naive is better than being overly purist. For ISPs that have been assigned several IPv4 prefixes (as many have been), the "naive" approach remains the simplest one to operate. Regards, RD -------------- next part -------------- An HTML attachment was scrubbed... URL: From remi.despres at free.fr Sun Mar 13 10:22:30 2011 From: remi.despres at free.fr (=?iso-8859-1?Q?R=E9mi_Despr=E9s?=) Date: Sun, 13 Mar 2011 10:22:30 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <7A05388495C24A20A247029864850C46@mTOSH> References: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> <20110228142042.GL30227@Space.Net> <7A05388495C24A20A247029864850C46@mTOSH> Message-ID: Le 13 mars 2011 ? 07:26, Ahmed Abu-Abed a ?crit : > If simplicity in IPv6 transition means initially offering IPv6-over-IPv4 to subscribers while meeting 2 fundamental requirements, namely end-user prefix delegation and commercial hardware CPE support, then there are 3 protocols that can be used depending on the service provider requirements: 6rd, TSP and L2TP. > > If implementing 6rd, service providers may need an allocation larger than /32 as the 6rd protocol embeds the users IPv4 address, or part there of, in their IPv6 address. Agreed. Assigning prefixes shorter than /32 to ISP's that accelerate IPv6 deployment with 6rd is IMHO the right choice to promote IPv6 with native addresses. Regards, RD > > Regards, > -Ahmed > > > From: R?mi Despr?s > Sent: Thursday, March 10, 2011 9:10 PM > To: Gert Doering > Cc: Kurt Smolderen ; address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] IPv6 allocations for 6RD > > > Le 28 f?vr. 2011 ? 15:20, Gert Doering a ?crit : > > > Hi, > > > > On Mon, Feb 28, 2011 at 10:13:51AM +0100, Kurt Smolderen wrote: > >> I strongly support the idea of assigning a smaller prefix to ISPs > >> which are in a state of deploying IPv6 but need to use transitional > >> mechanism for (some of) their customers. Mark has described one of > >> the problems very clear in his email: if an ISP has only a /32 > >> prefix and needs to use all 32 IPv4 bits in the 6rd configuration, > >> only a /64 can be delivered to the home instead of the desired /56 > >> or /48. Needing all 32 bits is for instance the case when an ISP > >> offers internet connectivity to some of its customers via a partnership > >> with another ISP. > > > > Without commenting on the general idea of allocating a larger chunk of > > addresses to ISPs, I want to make sure that the underlying facts are > > presented correctly. > > > > While RFC 5569 (the 6rd RFC) takes the "naive" approach of blindly mapping > > IPv4 <-> IPv6 using the whole 32bits, it doesn't *have* to be that way > > It doesn't have to, right. > But, if being native permits to deploy good IPv6 service to the masses before other means to do it are available, being naive is better than being overly purist. > For ISPs that have been assigned several IPv4 prefixes (as many have been), the "naive" approach remains the simplest one to operate. > > Regards, > RD > > From arne at ripe.net Mon Mar 14 15:56:28 2011 From: arne at ripe.net (Arne Kiessling) Date: Mon, 14 Mar 2011 15:56:28 +0100 Subject: [address-policy-wg] Updated RIPE NCC Procedural Document Available Message-ID: <4D7E2C9C.4080102@ripe.net> Dear Colleagues, The RIPE NCC has published an updated procedural document, ripe-518, "Implementation of RIPE Policy 'Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region' - Phase 3". This document replaces ripe-511, which was published recently. The updated document is available at: http://www.ripe.net/ripe/docs/ripe-518 -- Kind Regards Arne Kiessling IP Resource Analyst RIPE Network Coordination Centre From hank at efes.iucc.ac.il Mon Mar 14 16:13:20 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 14 Mar 2011 17:13:20 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] Updated RIPE NCC Procedural Document Available In-Reply-To: <4D7E2C9C.4080102@ripe.net> Message-ID: <5.1.0.14.2.20110314171024.00c0dda8@efes.iucc.ac.il> At 15:56 14/03/2011 +0100, Arne Kiessling wrote: Rather than doing a diff can you indicate what are the changes? Thanks, Hank >Dear Colleagues, > >The RIPE NCC has published an updated procedural document, ripe-518, >"Implementation of RIPE Policy 'Contractual Requirements for Provider >Independent Resource Holders in the RIPE NCC Service Region' - Phase 3". > >This document replaces ripe-511, which was published recently. The updated >document is available at: > >http://www.ripe.net/ripe/docs/ripe-518 > > >-- >Kind Regards > >Arne Kiessling >IP Resource Analyst >RIPE Network Coordination Centre From arne at ripe.net Tue Mar 15 14:39:26 2011 From: arne at ripe.net (Arne Kiessling) Date: Tue, 15 Mar 2011 14:39:26 +0100 Subject: [address-policy-wg] Re: [ncc-services-wg] Updated RIPE NCC Procedural Document Available In-Reply-To: <5.1.0.14.2.20110314171024.00c0dda8@efes.iucc.ac.il> References: <5.1.0.14.2.20110314171024.00c0dda8@efes.iucc.ac.il> Message-ID: <4D7F6C0E.7040708@ripe.net> Dear Hank, Thank you for your email. We updated the procedural document because ripe-511 contained a redundant paragraph that was also referencing another procedural document (ripe-475) that was obsoleted. This is the paragraph that was removed from ripe-511 and is no longer visible in ripe-518: "If the required feedback is not received after three months and several attempts by the RIPE NCC to contact the resource holder including reminders by email and using different contact details registered in the RIPE Database related to the resource, or if a resource holder has not signed an agreement with either a sponsoring LIR or the RIPE NCC within three months of confirming via the web interface that they are going to sign an agreement, the RIPE NCC may start the deregistration of the resource according to the de-registration timeframes described in section 4.1.1 of "Independent Internet Number Resources - Contractual Relationship Changes between sponsoring LIR and End User"." -- Kind Regards Arne Kiessling IP Resource Analyst RIPE Network Coordination Centre Hank Nussbacher wrote: > At 15:56 14/03/2011 +0100, Arne Kiessling wrote: > > Rather than doing a diff can you indicate what are the changes? > > Thanks, > Hank > >> Dear Colleagues, >> >> The RIPE NCC has published an updated procedural document, ripe-518, >> "Implementation of RIPE Policy 'Contractual Requirements for Provider >> Independent Resource Holders in the RIPE NCC Service Region' - Phase 3". >> >> This document replaces ripe-511, which was published recently. The >> updated document is available at: >> >> http://www.ripe.net/ripe/docs/ripe-518 >> >> >> -- >> Kind Regards >> >> Arne Kiessling >> IP Resource Analyst >> RIPE Network Coordination Centre > From emadaio at ripe.net Fri Mar 18 15:31:37 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Fri, 18 Mar 2011 15:31:37 +0100 Subject: [address-policy-wg] 2010-05 Policy Proposal Withdrawn (Global Policy for IPv4 Allocation by the IANA post exhaustion) Message-ID: <20110318143138.354B26A002@postboy.ripe.net> Dear Colleagues, The global policy proposal 2010-05, "Global Policy for IPv4 Allocation by the IANA post exhaustion", has been withdrawn. It is now archived and can be found at: http://www.ripe.net/ripe/policies/proposals/2010-05 The reason for withdrawal is: it was agreed with the proposer that the lack of community feedback and the impossibility of the proposal becoming globally accepted due to recent developments in the global PDP at the time were sufficient reasons to have it withdrawn. Regards Emilio Madaio Policy Development Officer RIPE NCC From ahmed at tamkien.com Mon Mar 21 10:36:06 2011 From: ahmed at tamkien.com (Ahmed Abu-Abed) Date: Mon, 21 Mar 2011 11:36:06 +0200 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> <20110228142042.GL30227@Space.Net> <7A05388495C24A20A247029864850C46@mTOSH> Message-ID: <307DD74F489F4F0C8FD589E2BFF11CD2@mTOSH> This implies that if assigning prefixes shorter than /32 is not possible, then other transition protocols such as TSP or L2TP can be used to enable rapid IPv6 transition. TSP in particular is quite easy to deploy over any type IPv4 access network and with existing CPEs as it can work behind the ISP access modem. Regards, -Ahmed From: R?mi Despr?s Sent: Sunday, March 13, 2011 11:22 AM To: Ahmed Abu-Abed Cc: RIPE Address Policy Subject: Re: [address-policy-wg] IPv6 allocations for 6RD Le 13 mars 2011 ? 07:26, Ahmed Abu-Abed a ?crit : > If simplicity in IPv6 transition means initially offering IPv6-over-IPv4 to subscribers while meeting 2 fundamental requirements, namely end-user prefix delegation and commercial hardware CPE support, then there are 3 protocols that can be used depending on the service provider requirements: 6rd, TSP and L2TP. > > If implementing 6rd, service providers may need an allocation larger than /32 as the 6rd protocol embeds the users IPv4 address, or part there of, in their IPv6 address. Agreed. Assigning prefixes shorter than /32 to ISP's that accelerate IPv6 deployment with 6rd is IMHO the right choice to promote IPv6 with native addresses. Regards, RD > > Regards, > -Ahmed > > > From: R?mi Despr?s > Sent: Thursday, March 10, 2011 9:10 PM > To: Gert Doering > Cc: Kurt Smolderen ; address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] IPv6 allocations for 6RD > > > Le 28 f?vr. 2011 ? 15:20, Gert Doering a ?crit : > > > Hi, > > > > On Mon, Feb 28, 2011 at 10:13:51AM +0100, Kurt Smolderen wrote: > >> I strongly support the idea of assigning a smaller prefix to ISPs > >> which are in a state of deploying IPv6 but need to use transitional > >> mechanism for (some of) their customers. Mark has described one of > >> the problems very clear in his email: if an ISP has only a /32 > >> prefix and needs to use all 32 IPv4 bits in the 6rd configuration, > >> only a /64 can be delivered to the home instead of the desired /56 > >> or /48. Needing all 32 bits is for instance the case when an ISP > >> offers internet connectivity to some of its customers via a partnership > >> with another ISP. > > > > Without commenting on the general idea of allocating a larger chunk of > > addresses to ISPs, I want to make sure that the underlying facts are > > presented correctly. > > > > While RFC 5569 (the 6rd RFC) takes the "naive" approach of blindly mapping > > IPv4 <-> IPv6 using the whole 32bits, it doesn't *have* to be that way > > It doesn't have to, right. > But, if being native permits to deploy good IPv6 service to the masses before other means to do it are available, being naive is better than being overly purist. > For ISPs that have been assigned several IPv4 prefixes (as many have been), the "naive" approach remains the simplest one to operate. > > Regards, > RD > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emadaio at ripe.net Mon Mar 21 17:43:53 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 21 Mar 2011 17:43:53 +0100 Subject: [address-policy-wg] 2011-01 New Policy Proposal (Global Policy for post exhaustion IPv4 mechanisms by the IANA) Message-ID: <20110321164353.C05936A003@postboy.ripe.net> Dear Colleagues, A new Global Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-01/ We encourage you to review this proposal and send your comments to before 18 April 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC From boggits at gmail.com Mon Mar 21 17:48:33 2011 From: boggits at gmail.com (boggits) Date: Mon, 21 Mar 2011 16:48:33 +0000 Subject: [address-policy-wg] 2011-01 New Policy Proposal (Global Policy for post exhaustion IPv4 mechanisms by the IANA) In-Reply-To: <20110321164353.C05936A003@postboy.ripe.net> References: <20110321164353.C05936A003@postboy.ripe.net> Message-ID: On 21 March 2011 16:43, Emilio Madaio wrote: > We encourage you to review this proposal and send your comments to > before 18 April 2011. Since we've had a joyful time with this proposal before, what happens if we pass it *but* ICANN fail to get the IANA contract this time round? J -- James Blessing 07989 039 476 From gert at space.net Mon Mar 21 18:22:04 2011 From: gert at space.net (Gert Doering) Date: Mon, 21 Mar 2011 18:22:04 +0100 Subject: [address-policy-wg] 2011-01 New Policy Proposal (Global Policy for post exhaustion IPv4 mechanisms by the IANA) In-Reply-To: References: <20110321164353.C05936A003@postboy.ripe.net> Message-ID: <20110321172204.GD30227@Space.Net> HI, On Mon, Mar 21, 2011 at 04:48:33PM +0000, boggits wrote: > On 21 March 2011 16:43, Emilio Madaio wrote: > > > We encourage you to review this proposal and send your comments to > > before 18 April 2011. > > Since we've had a joyful time with this proposal before, It's actually a new and revised one :-) - which purposely only covers global policy, and none of the fun bits about local rules for returning address space or transfers. > what happens if we pass it *but* ICANN fail to get the IANA contract > this time round? Since the proposal doesn't actually talk that much about *ICANN* (except for initial adoption of this policy), I'm not sure if we have a problem here - if the ICANN function is moved elsewhere, this policy will go with it. The only problematic bit is timing, that is, we take half a year to finish reaching consensus, and right in the middle the IANA function is no longer at ICANN. When is the contract renewal due? Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From marty at akamai.com Mon Mar 21 18:32:15 2011 From: marty at akamai.com (Hannigan, Martin) Date: Mon, 21 Mar 2011 13:32:15 -0400 Subject: [address-policy-wg] 2011-01 New Policy Proposal (Global Policy for post exhaustion IPv4 mechanisms by the IANA) In-Reply-To: <20110321172204.GD30227@Space.Net> Message-ID: On 3/21/11 1:22 PM, "Gert Doering" wrote: > HI, > > On Mon, Mar 21, 2011 at 04:48:33PM +0000, boggits wrote: >> On 21 March 2011 16:43, Emilio Madaio wrote: >> >>> We encourage you to review this proposal and send your comments to >>> before 18 April 2011. >> >> Since we've had a joyful time with this proposal before, > > It's actually a new and revised one :-) - which purposely only covers > global policy, and none of the fun bits about local rules for returning > address space or transfers. It does, but it seems to be more of a tossing of a political football than an effort to find a common ground. There are other aspects of this proposal that have been deemed unacceptable previously. >> what happens if we pass it *but* ICANN fail to get the IANA contract >> this time round? > > Since the proposal doesn't actually talk that much about *ICANN* (except > for initial adoption of this policy), I'm not sure if we have a problem > here - if the ICANN function is moved elsewhere, this policy will go with > it. The agreements that put the global policy process into action are specifically linked to ICANN: http://www.nro.net/wp-content/uploads/2004/10/aso-mou-signed.pdf I don't know if these are transferable, would be transferred, or would be accepted as part of a function transfer. I guess that would be dealt with in any follow-up RFP to facilitate a transfer of the functions -- if that's what happens. > > The only problematic bit is timing, that is, we take half a year to > finish reaching consensus, and right in the middle the IANA function > is no longer at ICANN. When is the contract renewal due? > Or two years. It could get quite confusing to have something in process and have a major change occur such as the moving of the IANA function. Best, -M< From boggits at gmail.com Mon Mar 21 18:31:47 2011 From: boggits at gmail.com (boggits) Date: Mon, 21 Mar 2011 17:31:47 +0000 Subject: [address-policy-wg] 2011-01 New Policy Proposal (Global Policy for post exhaustion IPv4 mechanisms by the IANA) In-Reply-To: <20110321172204.GD30227@Space.Net> References: <20110321164353.C05936A003@postboy.ripe.net> <20110321172204.GD30227@Space.Net> Message-ID: On 21 March 2011 17:22, Gert Doering wrote: > The only problematic bit is timing, that is, we take half a year to > finish reaching consensus, and right in the middle the IANA function > is no longer at ICANN. ? When is the contract renewal due? Current contract expires 30 September 2011 the Gov started consultation on the renewal in Feb J -- James Blessing 07989 039 476 From jim at rfc1035.com Mon Mar 21 19:05:35 2011 From: jim at rfc1035.com (Jim Reid) Date: Mon, 21 Mar 2011 18:05:35 +0000 Subject: [address-policy-wg] The IANA contract and 2011-01 In-Reply-To: References: <20110321164353.C05936A003@postboy.ripe.net> Message-ID: <4BFC2112-7952-4054-B985-7EE513315D4A@rfc1035.com> On 21 Mar 2011, at 16:48, boggits wrote: > Since we've had a joyful time with this proposal before, what happens > if we pass it *but* ICANN fail to get the IANA contract this time > round? Hopefully nothing. IANA will no doubt continue to implement the consensus policies that have been developed by the community, just as it's always done. I would expect that this would be a key condition of the IANA contract being awarded to some other organisation. From boggits at gmail.com Mon Mar 21 19:08:09 2011 From: boggits at gmail.com (boggits) Date: Mon, 21 Mar 2011 18:08:09 +0000 Subject: [address-policy-wg] The IANA contract and 2011-01 In-Reply-To: <4BFC2112-7952-4054-B985-7EE513315D4A@rfc1035.com> References: <20110321164353.C05936A003@postboy.ripe.net> <4BFC2112-7952-4054-B985-7EE513315D4A@rfc1035.com> Message-ID: On 21 March 2011 18:05, Jim Reid wrote: > On 21 Mar 2011, at 16:48, boggits wrote: > >> Since we've had a joyful time with this proposal before, what happens >> if we pass it *but* ICANN fail to get the IANA contract this time round? > > Hopefully nothing. IANA will no doubt continue to implement the consensus > policies that have been developed by the community, just as it's always > done. I would expect that this would be a key condition of the IANA contract > being awarded to some other organisation. One would hope so, but the wording of the policy explicitly references the organisation, a minor wordsmithing to take this into account could resolve that... J -- James Blessing 07989 039 476 From randy at psg.com Tue Mar 22 07:44:54 2011 From: randy at psg.com (Randy Bush) Date: Mon, 21 Mar 2011 23:44:54 -0700 Subject: [address-policy-wg] 2011-01 New Policy Proposal (Global Policy for post exhaustion IPv4 mechanisms by the IANA) In-Reply-To: References: <20110321172204.GD30227@Space.Net> Message-ID: > It does, but it seems to be more of a tossing of a political football > than an effort to find a common ground. There are other aspects of > this proposal that have been deemed unacceptable previously. ^ by the arin vigilantes From tuomi at ventiro.se Wed Mar 30 10:25:27 2011 From: tuomi at ventiro.se (Jan Tuomi) Date: Wed, 30 Mar 2011 10:25:27 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? Message-ID: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> Hi, A have made a request for a IPv6 PI / 48 allocation for my hosting facility. I am mostly hosting shared services, but I also have a lot of Co-located services for my customers. I am already multihomed to have redundancy from two ISPs for IPv4 and I am going to setup the IPv6 Network the same way. My ASN is 196704, and I am multihoming trough IP-Only (AS12552) and Telenor (AS8434). My sponsoring LIR says that I can get an assignment from their PA-space right away, BUT then I would not be multi-homed, so that is NOT an option. The answer I get from you (RIPE) is: You mentioned that several of the subnets will be used to provide services to your customers (LEON Hosting, Co-location/Dedicated servers). Unfortunately current IPv6 address assignment and allocation policy does not permit the use of IPv6 PI address space for these services. At this time IPv6 PI address space cannot be used for any service where a customer would receive a subnet of IP space (including a single IP). Therefore it cannot be used for colocation services, dedicated servers, SSL certificates etc. There is currently a discussion on exactly this subject within the RIPE community. Ventiro AB are welcome to sign up for the mailing list and join the discussion. You can find the mailing list here: http://www.ripe.net/ripe/mail/ripe-lists/address-policy-wg I need to be multihomed because i feel its safer to have redandancy from separate upstreams with separate infrastructure than buying the redundancy from one provider. My business is to keep servers running in my hosting facility, part of them owned by me, part of them owned by the customers. Some servers are shared among several customers, some are dedicated to one customer only. With todays technology as far as I know I must have separate IPs for SSL-enabled services. Is it RIPEs hidden agenda to put small hosting facilitys out of business with IPv6 and force all customers to use the bigger ISPs? When I requested my IPv4 PI allocation, I was already planning to also run with IPv6 to be prepared for the future and somehow try to help with the transition to IPv6, so people dont have the arguments that we dont use IPv6 because there is no services, its now so much services from a global point of view, but it wouldnt be IPv4 only.... So what should I do? What are my options? // Janne _______________________ V E N T I R O ______ Janne Tuomi, tuomi at ventiro.se Tel: +46-11-36 52 00 GSM: +46-70-224 6000 Fax: +46-11-36 52 05 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4697 bytes Desc: not available URL: From james.blessing at despres.co.uk Wed Mar 30 10:37:08 2011 From: james.blessing at despres.co.uk (James Blessing) Date: Wed, 30 Mar 2011 09:37:08 +0100 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> Message-ID: On 30 March 2011 09:25, Jan Tuomi wrote: > So what should I do??What are my options? Join RIPE as an LIR, get your own /32 PA space that you can then provide to your customers J -- James Blessing 07989 039 476 From nuno.vieira at nfsi.pt Wed Mar 30 10:33:42 2011 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Wed, 30 Mar 2011 09:33:42 +0100 (WEST) Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> Message-ID: <9d26ea5e-5534-4a8e-a2e8-60ad82969fd1@zimbra.nfsi.pt> The way to go is for you to establish as an LIR. (Small or Extra Small). http://www.ripe.net/lir-services/member-support/become-a-member regards, --nvieira ----- Original Message ----- > Hi, > A have made a request for a IPv6 PI / 48 allocation for my hosting > facility. > I am mostly hosting shared services, but I also have a lot of > Co-located services for my customers. > I am already multihomed to have redundancy from two ISPs for IPv4 and > I am going to setup the IPv6 Network the same way. > My ASN is 196704, and I am multihoming trough IP-Only (AS12552) and > Telenor (AS8434). > My sponsoring LIR says that I can get an assignment from their > PA-space right away, BUT then I would not be multi-homed, so that is > NOT an option. > The answer I get from you (RIPE) is: > You mentioned that several of the subnets will be used to provide > services to your customers (LEON Hosting, Co-location/Dedicated > servers). > Unfortunately current IPv6 address assignment and allocation policy > does not permit the use of IPv6 PI address space for these services. > At this time IPv6 PI address space cannot be used for any service > where a customer would receive a subnet of IP space (including a > single IP). Therefore it cannot be used for colocation services, > dedicated servers, SSL certificates etc. > There is currently a discussion on exactly this subject within the > RIPE community. Ventiro AB are welcome to sign up for the mailing > list and join the discussion. You can find the mailing list here: > http://www.ripe.net/ripe/mail/ripe-lists/address-policy-wg > I need to be multihomed because i feel its safer to have redandancy > from separate upstreams with separate infrastructure than buying the > redundancy from one provider. > My business is to keep servers running in my hosting facility, part > of them owned by me, part of them owned by the customers. > Some servers are shared among several customers, some are dedicated > to one customer only. > With todays technology as far as I know I must have separate IPs for > SSL-enabled services. > Is it RIPEs hidden agenda to put small hosting facilitys out of > business with IPv6 and force all customers to use the bigger ISPs? > When I requested my IPv4 PI allocation, I was already planning to > also run with IPv6 to be prepared for the future and somehow try to > help with the transition to IPv6, so people dont have the arguments > that we dont use IPv6 because there is no services, its now so much > services from a global point of view, but it wouldnt be IPv4 > only.... > So what should I do? What are my options? > // Janne -------------- next part -------------- An HTML attachment was scrubbed... URL: From pymaunier at neotelecoms.com Wed Mar 30 10:43:44 2011 From: pymaunier at neotelecoms.com (Pierre-Yves Maunier) Date: Wed, 30 Mar 2011 10:43:44 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> Message-ID: <20110330084344.GD3202@cilaos> On Wed, Mar 30, 2011 at 10:25:27AM +0200, Jan Tuomi wrote: > > So what should I do? What are my options? > > // Janne > If you wand multihomed IPv6 and assign blocks to your customers, become a LIR and get a /32. I'm a sponsoring LIR, and I turned down several times some of my customers asking for PI ressources because I knew that their request would not fit the RIPE policies and that their only way was PA from my space or become LIR. Mainly it's because the cannot justify the space their requesting (for IPv4) or they want to do end-user-assignement (for IPv4/IPv6) which is your case here. I helped some of them to become LIR, they got their /21 PA IPv4 and their /32 PA IPv6. Regards, -- Pierre-Yves Maunier AS8218 IP/Project Engineer pymaunier at neotelecoms.com Neotelecoms 21 rue La Bo?tie, 75008 Paris, France From adriano at rybnet.pl Wed Mar 30 10:56:15 2011 From: adriano at rybnet.pl (Adrian Czapek) Date: Wed, 30 Mar 2011 10:56:15 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <20110330084344.GD3202@cilaos> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <20110330084344.GD3202@cilaos> Message-ID: <4D92F02F.4000708@rybnet.pl> W dniu 2011-03-30 10:43, Pierre-Yves Maunier pisze: > I helped some of them to become LIR, they got their /21 PA IPv4 and their /32 PA IPv6. > And 1.5k ? invoice to pay, yearly. Regards -- Adrian From adriano at rybnet.pl Wed Mar 30 10:59:58 2011 From: adriano at rybnet.pl (Adrian Czapek) Date: Wed, 30 Mar 2011 10:59:58 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> Message-ID: <4D92F10E.9060309@rybnet.pl> > So what should I do? What are my options? > Best option: take /48 from your LIR and deaggregate it (announce to the world under your ASN) Regards -- Adrian From Tero.Toikkanen at nebula.fi Wed Mar 30 10:58:58 2011 From: Tero.Toikkanen at nebula.fi (Tero Toikkanen) Date: Wed, 30 Mar 2011 08:58:58 +0000 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> Message-ID: Hi, As far as I'm concerned, there seems to be a strange discrepancy between IPv4 PI and IPv6 PI. Apparently Janne has already successfully obtained IPv4 PI and has now requested IPv6 PI, declaring the same intended use. Could someone please point out where in the policy documents it says one can use IPv4 PI for hosting, but not IPv6 PI? I'm having a hard time finding such terms. ____________________________________ Tero Toikkanen Nebula Oy From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Jan Tuomi Sent: 30. maaliskuuta 2011 11:25 To: address-policy-wg at ripe.net Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? Hi, A have made a request for a IPv6 PI / 48 allocation for my hosting facility. I am mostly hosting shared services, but I also have a lot of Co-located services for my customers. I am already multihomed to have redundancy from two ISPs for IPv4 and I am going to setup the IPv6 Network the same way. My ASN is 196704, and I am multihoming trough IP-Only (AS12552) and Telenor (AS8434). My sponsoring LIR says that I can get an assignment from their PA-space right away, BUT then I would not be multi-homed, so that is NOT an option. The answer I get from you (RIPE) is: You mentioned that several of the subnets will be used to provide services to your customers (LEON Hosting, Co-location/Dedicated servers). Unfortunately current IPv6 address assignment and allocation policy does not permit the use of IPv6 PI address space for these services. At this time IPv6 PI address space cannot be used for any service where a customer would receive a subnet of IP space (including a single IP). Therefore it cannot be used for colocation services, dedicated servers, SSL certificates etc. There is currently a discussion on exactly this subject within the RIPE community. Ventiro AB are welcome to sign up for the mailing list and join the discussion. You can find the mailing list here: http://www.ripe.net/ripe/mail/ripe-lists/address-policy-wg I need to be multihomed because i feel its safer to have redandancy from separate upstreams with separate infrastructure than buying the redundancy from one provider. My business is to keep servers running in my hosting facility, part of them owned by me, part of them owned by the customers. Some servers are shared among several customers, some are dedicated to one customer only. With todays technology as far as I know I must have separate IPs for SSL-enabled services. Is it RIPEs hidden agenda to put small hosting facilitys out of business with IPv6 and force all customers to use the bigger ISPs? When I requested my IPv4 PI allocation, I was already planning to also run with IPv6 to be prepared for the future and somehow try to help with the transition to IPv6, so people dont have the arguments that we dont use IPv6 because there is no services, its now so much services from a global point of view, but it wouldnt be IPv4 only.... So what should I do? What are my options? // Janne _______________________ V E N T I R O ______ Janne Tuomi, tuomi at ventiro.se Tel: +46-11-36 52 00 GSM: +46-70-224 6000 Fax: +46-11-36 52 05 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5179 bytes Desc: not available URL: From sergey at devnull.ru Wed Mar 30 11:04:22 2011 From: sergey at devnull.ru (Sergey Myasoedov) Date: Wed, 30 Mar 2011 11:04:22 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <4D92F10E.9060309@rybnet.pl> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <4D92F10E.9060309@rybnet.pl> Message-ID: <1584000671.20110330110422@devnull.ru> Adrian, see the RIPE-510 document. You probably will have a connectivity problem. Wednesday, March 30, 2011, 10:59:58 AM, you wrote: >> So what should I do? What are my options? AC> Best option: take /48 from your LIR and deaggregate it (announce to the AC> world under your ASN) -- Sergey From adriano at rybnet.pl Wed Mar 30 11:08:02 2011 From: adriano at rybnet.pl (Adrian Czapek) Date: Wed, 30 Mar 2011 11:08:02 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> Message-ID: <4D92F2F2.2060905@rybnet.pl> W dniu 2011-03-30 10:58, Tero Toikkanen pisze: > Hi, > > As far as I?m concerned, there seems to be a strange discrepancy between > IPv4 PI and IPv6 PI. Apparently Janne has already successfully obtained > IPv4 PI and has now requested IPv6 PI, declaring the same intended use. > Could someone please point out where in the policy documents it says one > can use IPv4 PI for hosting, but not IPv6 PI? I?m having a hard time > finding such terms. > http://www.ripe.net/ripe/docs/ripe-512#_8._IPv6_Provider Most important is the last sentence: The PI assignment cannot be further assigned to other organisations. And according to IPRA, if you provide hosting services on your own infratructure to other companies, you are sub-allocating part of your PI address space to them, so you cannot use PI address space for that purpose. Regards -- Adrian From pymaunier at neotelecoms.com Wed Mar 30 11:08:51 2011 From: pymaunier at neotelecoms.com (Pierre-Yves Maunier) Date: Wed, 30 Mar 2011 11:08:51 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <4D92F10E.9060309@rybnet.pl> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <4D92F10E.9060309@rybnet.pl> Message-ID: <20110330090851.GE3202@cilaos> On Wed, Mar 30, 2011 at 10:59:58AM +0200, Adrian Czapek wrote: > >So what should I do? What are my options? > > > > Best option: take /48 from your LIR and deaggregate it (announce to > the world under your ASN) > Not the best for me. I think a couple of people are filtering /48s which are not in a PI reserved space (like 2001:678::/29), so this is not the best option for multihoming. Some LIRs also don't want their PA space to be announced by other ASes. -- Pierre-Yves Maunier AS8218 IP/Project Engineer pymaunier at neotelecoms.com Neotelecoms 21 rue La Bo?tie, 75008 Paris, France From pymaunier at neotelecoms.com Wed Mar 30 11:13:12 2011 From: pymaunier at neotelecoms.com (Pierre-Yves Maunier) Date: Wed, 30 Mar 2011 11:13:12 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <6A02EC6B-C0F3-43E4-B37E-AECF8298722D@bondis.org> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <20110330084344.GD3202@cilaos> <6A02EC6B-C0F3-43E4-B37E-AECF8298722D@bondis.org> Message-ID: <20110330091312.GF3202@cilaos> On Wed, Mar 30, 2011 at 11:08:06AM +0200, Joao Damas wrote: > > On 30 Mar 2011, at 10:43, Pierre-Yves Maunier wrote: > > > On Wed, Mar 30, 2011 at 10:25:27AM +0200, Jan Tuomi wrote: > >> > >> So what should I do? What are my options? > >> > >> // Janne > >> > > > > If you wand multihomed IPv6 and assign blocks to your customers, become a LIR and get a /32. > > > > .... > > I helped some of them to become LIR, they got their /21 PA IPv4 and their /32 PA IPv6. > > > this is really strange and weird. I have always thought that RIPE policies aimed at good address stewardship (so far this has been linked to conservation, under IPv4) and some consideration to route table size contention (promote aggregation). > > Responses like this over the last weeks seem to indicate that RIPE NCC's business practices seem to taking over as a more important consideration ("you can't get a /48 if that's all you need and it makes sense, but if you pay the RIPE NCC you can get a /32 and some scarce IPv4 bundled in to boot"). > > If I were a regulator not intimately involved in RIPE's doings, I sure would be raising an eyebrow, or both. > > Would it be time to revisit the coherency of this whole thing as a whole? > > Joao I agree with you but on my side, I only help customers to become LIR when they plan to have a good usage of their IPS. For example : I definitly won't help any customer to have a /21 PA based only on their multihoming needs and if they can only justify only a /27. I agree again, it's weird. It's not possible to have a /24 PI for your own needs if you can only justify a /27 but you can get a /21 PA becoming a LIR. -- Pierre-Yves Maunier AS8218 IP/Project Engineer pymaunier at neotelecoms.com Neotelecoms 21 rue La Bo?tie, 75008 Paris, France From fweimer at bfk.de Wed Mar 30 11:13:42 2011 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 30 Mar 2011 09:13:42 +0000 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <4D92F2F2.2060905@rybnet.pl> (Adrian Czapek's message of "Wed\, 30 Mar 2011 11\:08\:02 +0200") References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <4D92F2F2.2060905@rybnet.pl> Message-ID: <82vcz1nf7d.fsf@mid.bfk.de> * Adrian Czapek: > And according to IPRA, if you provide hosting services on your own > infratructure to other companies, you are sub-allocating part of your > PI address space to them, so you cannot use PI address space for that > purpose. With that interpretation, isn't it impossible to use IPv6 PI space to provide addresses to personal computers? But seriously---does the working group think that IPv6 PI space should not be used for hosting customer web sites, and that the current policy does not allow this? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From joao at bondis.org Wed Mar 30 11:08:06 2011 From: joao at bondis.org (Joao Damas) Date: Wed, 30 Mar 2011 11:08:06 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <20110330084344.GD3202@cilaos> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <20110330084344.GD3202@cilaos> Message-ID: <6A02EC6B-C0F3-43E4-B37E-AECF8298722D@bondis.org> On 30 Mar 2011, at 10:43, Pierre-Yves Maunier wrote: > On Wed, Mar 30, 2011 at 10:25:27AM +0200, Jan Tuomi wrote: >> >> So what should I do? What are my options? >> >> // Janne >> > > If you wand multihomed IPv6 and assign blocks to your customers, become a LIR and get a /32. > > .... > I helped some of them to become LIR, they got their /21 PA IPv4 and their /32 PA IPv6. this is really strange and weird. I have always thought that RIPE policies aimed at good address stewardship (so far this has been linked to conservation, under IPv4) and some consideration to route table size contention (promote aggregation). Responses like this over the last weeks seem to indicate that RIPE NCC's business practices seem to taking over as a more important consideration ("you can't get a /48 if that's all you need and it makes sense, but if you pay the RIPE NCC you can get a /32 and some scarce IPv4 bundled in to boot"). If I were a regulator not intimately involved in RIPE's doings, I sure would be raising an eyebrow, or both. Would it be time to revisit the coherency of this whole thing as a whole? Joao From Tero.Toikkanen at nebula.fi Wed Mar 30 11:17:31 2011 From: Tero.Toikkanen at nebula.fi (Tero Toikkanen) Date: Wed, 30 Mar 2011 09:17:31 +0000 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <82vcz1nf7d.fsf@mid.bfk.de> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <4D92F2F2.2060905@rybnet.pl> <82vcz1nf7d.fsf@mid.bfk.de> Message-ID: > > And according to IPRA, if you provide hosting services on your own > > infratructure to other companies, you are sub-allocating part of your > > PI address space to them, so you cannot use PI address space for that > > purpose. > > With that interpretation, isn't it impossible to use IPv6 PI space to provide > addresses to personal computers? > > But seriously---does the working group think that IPv6 PI space should not > be used for hosting customer web sites, and that the current policy does not > allow this? http://www.ripe.net/ripe/docs/ripe-509#----pa-vs--pi-address-space "PI space cannot be re-assigned or further assigned to other parties." The text is the same for IPv4 PI and IPv6 PI, but you still can't get both for the same use. Why not? In my opinion the policy is the same for both, but it seems it's not interpreted in the same way. ____________________________________ Tero Toikkanen Nebula Oy From joao at bondis.org Wed Mar 30 11:27:10 2011 From: joao at bondis.org (Joao Damas) Date: Wed, 30 Mar 2011 11:27:10 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <4D92F2F2.2060905@rybnet.pl> <82vcz1nf7d.fsf@mid.bfk.de> Message-ID: <7B049BFF-F950-4844-8910-3A47C194938B@bondis.org> On 30 Mar 2011, at 11:17, Tero Toikkanen wrote: >>> And according to IPRA, if you provide hosting services on your own >>> infratructure to other companies, you are sub-allocating part of your >>> PI address space to them, so you cannot use PI address space for that >>> purpose. >> >> With that interpretation, isn't it impossible to use IPv6 PI space to provide >> addresses to personal computers? >> >> But seriously---does the working group think that IPv6 PI space should not >> be used for hosting customer web sites, and that the current policy does not >> allow this? > > http://www.ripe.net/ripe/docs/ripe-509#----pa-vs--pi-address-space > > "PI space cannot be re-assigned or further assigned to other parties." Even that is seemingly subject to weird and unclear interpretation. For instance if you rent/lease equipment for others to use (but remain the owner of such equipment as what you are selling is the service), according to IPRAs at the RIPE NCC it is OK to use PI space if the equipment is reachable via a LAN but not if the site is remote (e.g. using DSL), even if from a network point of view it is all the same net. Apparently, in some cases, policy application may be subject to the color of the physical cable used. See presentation during AOB at the APWG at the last RIPE Meeting. Joao From gert at space.net Wed Mar 30 11:44:16 2011 From: gert at space.net (Gert Doering) Date: Wed, 30 Mar 2011 11:44:16 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <6A02EC6B-C0F3-43E4-B37E-AECF8298722D@bondis.org> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <20110330084344.GD3202@cilaos> <6A02EC6B-C0F3-43E4-B37E-AECF8298722D@bondis.org> Message-ID: <20110330094416.GA30227@Space.Net> Hi, On Wed, Mar 30, 2011 at 11:08:06AM +0200, Joao Damas wrote: > this is really strange and weird. I have always thought that RIPE policies aimed at good address stewardship (so far this has been linked to conservation, under IPv4) and some consideration to route table size contention (promote aggregation). Conservation is not one of the primary goals for IPv6. Routing table size (=aggregation) *is* - which is why the consensus of this group, some years ago, was "be restrictive on PI". Now, this particular problem ("datacenter business") has been showing up a few times in the last 1.5 years, and in the end, it boils down to a number of considerations that are NOT easily solved. - the distinction between PA and PI is, conceptually, "PA is for ISPs that want to number (their) customers" "PI is for customers that want to number their own(!) network in an independent way" --> and this is why the chunk size is much bigger for PA, because it's meant to give an ISP a chunk that is so large that they will not need to come back for more space in the near future (-> which is good for routing aggregation), even taking lots of customers with a /48-each into account. PI is a /48, because "that's enough for one customer". - PI has been positioned as "cheap", so it's not a major hurdle for small "non-isp" companies that want/need independent address space - PA is "expensive", because it's only given to LIRs, and all the LIRs around share the expense of having the RIPE NCC do their job --> so, if a large number of ISPs change to run their IPv6 business on PI space, and stop paying LIR fees, all *other* LIRs have to pay *more* (the NCC's expenses pretty much stay the same, and get distributed to less paying members). So from a fairness point of view, there's good reason to ask everybody who is running an ISP-like business to become a LIR, and pay their share, staggered by "ISP size". - there's another twist to it: we want to encourage access providers (DSL, cable, ...) to give their customers a /56 or /48 - which the current PA policy permits just fine. Now if they could get a PI block to number their 5 million DSL users, these customers would end up with single-IPv6-assignments and IPv6 NAT... (We see this in IPv4 today, access ISPs that run all of their DSL network on PI space, as the IPv4 policy has a clause that permits doing so [transit networks to the customer are considered "part of the PI", and if all you give the customer is a single IP for their router...]) ... so, given this, "just open PI space and give everbody who asks their /48" is not without risks and costs - talking about good stewardship, and such :-) > Responses like this over the last weeks seem to indicate that > RIPE NCC's business practices seem to taking over as a more important > consideration ("you can't get a /48 if that's all you need and it > makes sense, but if you pay the RIPE NCC you can get a /32 and some > scarce IPv4 bundled in to boot"). You don't get the IPv4 space unless you demonstrate need. It's not like the IPv4 PA allocation is automatic. > If I were a regulator not intimately involved in RIPE's doings, > I sure would be raising an eyebrow, or both. Well - the PI policies are *exactly* what the community(!) made them... > Would it be time to revisit the coherency of this whole thing as a whole? Definitely. There's a "change the PI policy" proposal coming up, and Sander and I are trying to come up with good ideas to get the whole complex better "balanced out". Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From gert at space.net Wed Mar 30 11:53:41 2011 From: gert at space.net (Gert Doering) Date: Wed, 30 Mar 2011 11:53:41 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <4D92F2F2.2060905@rybnet.pl> <82vcz1nf7d.fsf@mid.bfk.de> Message-ID: <20110330095341.GB30227@Space.Net> Hi, On Wed, Mar 30, 2011 at 09:17:31AM +0000, Tero Toikkanen wrote: > http://www.ripe.net/ripe/docs/ripe-509#----pa-vs--pi-address-space > > "PI space cannot be re-assigned or further assigned to other parties." > > The text is the same for IPv4 PI and IPv6 PI, but you still can't get both for the same use. Why not? In my opinion the policy is the same for both, but it seems it's not interpreted in the same way. Actually, there's a significant difference and that has been pointed out a number of times on the list and at the last RIPE meetings. The IPv4 policy has this sentence: http://www.ripe.net/ripe/docs/ripe-509#----network-infrastructure-and-end-user-networks 6.2 Network Infrastructure and End User Networks IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure. When an End User has a network using public address space this must be registered separately with the contact details of the End User. ... and this specific clause is not in the IPv6 policy, so "networks used to number end customers" are considered "part of the assignment to this end customer". (Which makes sense for DSL and cable etc. networks, where you really want to assign a /56 or /48 anyway, and not start tricking around with single-address-assignment from PI blocks) Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From tuomi at ventiro.se Wed Mar 30 11:54:55 2011 From: tuomi at ventiro.se (Jan Tuomi) Date: Wed, 30 Mar 2011 11:54:55 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <4D92F2F2.2060905@rybnet.pl> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <4D92F2F2.2060905@rybnet.pl> Message-ID: <05A36A19-DD6E-4955-BBDB-F7712DBEBE11@ventiro.se> On 30 mar 2011, at 11.08, Adrian Czapek wrote: > W dniu 2011-03-30 10:58, Tero Toikkanen pisze: >> Hi, >> >> As far as I?m concerned, there seems to be a strange discrepancy between >> IPv4 PI and IPv6 PI. Apparently Janne has already successfully obtained >> IPv4 PI and has now requested IPv6 PI, declaring the same intended use. >> Could someone please point out where in the policy documents it says one >> can use IPv4 PI for hosting, but not IPv6 PI? I?m having a hard time >> finding such terms. >> > http://www.ripe.net/ripe/docs/ripe-512#_8._IPv6_Provider > > Most important is the last sentence: > The PI assignment cannot be further assigned to other organisations. > > And according to IPRA, if you provide hosting services on your own infratructure to other companies, you are sub-allocating part of your PI address space to them, so you cannot use PI address space for that purpose. > > Regards > -- > Adrian > So what this means is that if a customer puts their server in my facility I am sub-allocating? To sub-allocate I have to be an LIR and request an own PA-space? For each customer I have to assign their own /64 and register it in the ripe-database? Setting up an SSL-webhost is also sub-allocating? so to set up an ssl-host I have to again allocate an own /64 for the host, register it in the database, set up VLANS and routing on the webserver and network equipment since its a different IP-network? this will cause a lot of problem with stateful inspection in the firewall because i need to use multiple default gateways on the same server. So in the end I have to set up a whole new webbserver for each customer who needs SSL to get things running smoothly? hmm.. seems that I have to forget about IPv6 and continue running IPv4 only.... // Janne _______________________ V E N T I R O ______ Janne Tuomi, tuomi at ventiro.se Tel: +46-11-36 52 00 GSM: +46-70-224 6000 Fax: +46-11-36 52 05 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4697 bytes Desc: not available URL: From tuomi at ventiro.se Wed Mar 30 12:21:54 2011 From: tuomi at ventiro.se (Jan Tuomi) Date: Wed, 30 Mar 2011 12:21:54 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <20110330094416.GA30227@Space.Net> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <20110330084344.GD3202@cilaos> <6A02EC6B-C0F3-43E4-B37E-AECF8298722D@bondis.org> <20110330094416.GA30227@Space.Net> Message-ID: <0B2CCA97-68C1-478A-AA40-B883BF5F51B3@ventiro.se> Hello, On 30 mar 2011, at 11.44, Gert Doering wrote: > Hi, > > On Wed, Mar 30, 2011 at 11:08:06AM +0200, Joao Damas wrote: >> this is really strange and weird. I have always thought that RIPE policies aimed at good address stewardship (so far this has been linked to conservation, under IPv4) and some consideration to route table size contention (promote aggregation). > > Conservation is not one of the primary goals for IPv6. > > Routing table size (=aggregation) *is* - which is why the consensus of > this group, some years ago, was "be restrictive on PI". What is the difference in allocating one /48 PI-block or one /32 PA-block from a routing table size view? there still is one route in both cases because I need multihoming.... > Now, this particular problem ("datacenter business") has been showing up > a few times in the last 1.5 years, and in the end, it boils down to a > number of considerations that are NOT easily solved. > > - the distinction between PA and PI is, conceptually, > > "PA is for ISPs that want to number (their) customers" > > "PI is for customers that want to number their own(!) network in an > independent way" Should I consider myself as an ISP? I am not selling internet access to my customers locations, the customers is running their servers in my facility, in my rack, on my switches, firewalls and routers, they dont have physical access without me or someone from my staff being present. From my point of view, it is MY OWN network, not theirs. > > - PI has been positioned as "cheap", so it's not a major hurdle for > small "non-isp" companies that want/need independent address space > > - PA is "expensive", because it's only given to LIRs, and all the LIRs > around share the expense of having the RIPE NCC do their job > > --> so, if a large number of ISPs change to run their IPv6 business on > PI space, and stop paying LIR fees, all *other* LIRs have to pay *more* > (the NCC's expenses pretty much stay the same, and get distributed to > less paying members). So from a fairness point of view, there's good > reason to ask everybody who is running an ISP-like business to become > a LIR, and pay their share, staggered by "ISP size". But the price is the same... EXTRA SMALL, LIR: Sign-up Fee (? 2000) + Service Fee (? 1,300) EXTRA SMALL, Direct Assignment User: Administration Fee (? 2000) + Service Fee (? 1,300) So it would be any difference, I got the question of becoming a DAU and pay directly to RIPE or set up a contract with one of my ISPs. I choosed the last one because it was a little bit cheaper (not much), seemed easier to get a swedish invoice from a swedish company, and not to bug RIPE with more end user administration than necesary... Is it about that? Did I make the wrong choice in not becoming a DUA directly against RIPE? // Janne -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4697 bytes Desc: not available URL: From Tero.Toikkanen at nebula.fi Wed Mar 30 12:28:19 2011 From: Tero.Toikkanen at nebula.fi (Tero Toikkanen) Date: Wed, 30 Mar 2011 10:28:19 +0000 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <20110330095341.GB30227@Space.Net> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <4D92F2F2.2060905@rybnet.pl> <82vcz1nf7d.fsf@mid.bfk.de> <20110330095341.GB30227@Space.Net> Message-ID: > The IPv4 policy has this sentence: > > http://www.ripe.net/ripe/docs/ripe-509#----network-infrastructure-and- > end-user-networks > > 6.2 Network Infrastructure and End User Networks > > IP addresses used solely for the connection of an End User to a service > provider (e.g. point-to-point links) are considered part of the service > provider's infrastructure. These addresses do not have to be registered with > the End User's contact details but can be registered as part of the service > provider's internal infrastructure. > When an End User has a network using public address space this must be > registered separately with the contact details of the End User. > > ... and this specific clause is not in the IPv6 policy, so "networks used to > number end customers" are considered "part of the assignment to this end > customer". > > (Which makes sense for DSL and cable etc. networks, where you really want > to assign a /56 or /48 anyway, and not start tricking around with single- > address-assignment from PI blocks) Right. Thanks for clearing this up Gert. In any case, this should be clearer in the policies as it is easy to get confused because IPv4 PI != IPv6 PI in terms of what you can do with it. Also, policy interpretation within RIPE NCC should be sorted out (unless it already is), as I distinctly remember getting IPv6 PI for a customer for hosting purposes a year ago. ____________________________________ Tero Toikkanen Nebula Oy From ebais at a2b-internet.com Wed Mar 30 12:32:59 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 30 Mar 2011 12:32:59 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <05A36A19-DD6E-4955-BBDB-F7712DBEBE11@ventiro.se> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <4D92F2F2.2060905@rybnet.pl> <05A36A19-DD6E-4955-BBDB-F7712DBEBE11@ventiro.se> Message-ID: <002201cbeec5$d72b53a0$8581fae0$@com> Hi Jan, If you are providing SSL hosting on your shared, dedicated of VPS webservers, you are allowed to use PI space, as long as you don't provide blocks to a specific customers to use. That is considered assigning, so if you use a first come, first served assignment strategy on PI IP's, that is acceptable for PI is my experience with the IPRA's. If your customer is hosting SSL sites on their equipment (read: you are providing collocation), you would need to sign up as a LIR for now, as your customer isn't multi-homed (I assume) and that is (still) another requirement for IPv6 PI. I have a policy change requested through the formal channels to remove the multi-homing requirement for PI IPv6, so expect some more discussion on PI IPv6 on the list soon. Regards, Erik Bais From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Jan Tuomi Sent: Wednesday, March 30, 2011 11:55 AM To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? On 30 mar 2011, at 11.08, Adrian Czapek wrote: > W dniu 2011-03-30 10:58, Tero Toikkanen pisze: >> Hi, >> >> As far as I'm concerned, there seems to be a strange discrepancy between >> IPv4 PI and IPv6 PI. Apparently Janne has already successfully obtained >> IPv4 PI and has now requested IPv6 PI, declaring the same intended use. >> Could someone please point out where in the policy documents it says one >> can use IPv4 PI for hosting, but not IPv6 PI? I'm having a hard time >> finding such terms. >> > http://www.ripe.net/ripe/docs/ripe-512#_8._IPv6_Provider > > Most important is the last sentence: > The PI assignment cannot be further assigned to other organisations. > > And according to IPRA, if you provide hosting services on your own infratructure to other companies, you are sub-allocating part of your PI address space to them, so you cannot use PI address space for that purpose. > > Regards > -- > Adrian > So what this means is that if a customer puts their server in my facility I am sub-allocating? To sub-allocate I have to be an LIR and request an own PA-space? For each customer I have to assign their own /64 and register it in the ripe-database? Setting up an SSL-webhost is also sub-allocating? so to set up an ssl-host I have to again allocate an own /64 for the host, register it in the database, set up VLANS and routing on the webserver and network equipment since its a different IP-network? this will cause a lot of problem with stateful inspection in the firewall because i need to use multiple default gateways on the same server. So in the end I have to set up a whole new webbserver for each customer who needs SSL to get things running smoothly? hmm.. seems that I have to forget about IPv6 and continue running IPv4 only.... // Janne _______________________ V E N T I R O ______ Janne Tuomi, tuomi at ventiro.se Tel: +46-11-36 52 00 GSM: +46-70-224 6000 Fax: +46-11-36 52 05 _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1498/3537 - Release Date: 03/29/11 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuomi at ventiro.se Wed Mar 30 13:02:12 2011 From: tuomi at ventiro.se (Jan Tuomi) Date: Wed, 30 Mar 2011 13:02:12 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <002201cbeec5$d72b53a0$8581fae0$@com> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <4D92F2F2.2060905@rybnet.pl> <05A36A19-DD6E-4955-BBDB-F7712DBEBE11@ventiro.se> <002201cbeec5$d72b53a0$8581fae0$@com> Message-ID: <6BDB472E-58F2-433D-9669-B908A450E2C6@ventiro.se> Hi Erik, Why remove the multi-homing requirement? if you are not multihomed you could go with the PA-space you get from your single upstream provider? My problem is that I actually am multi-homed, therefor I need IPv6-PI.... And if my customers have their servers in my facility they also are multihomed? So they could request for their own PI? that really doesnt make sensee, that would really clog down the routing tables.... The hosting network is today set up so each customer get their own IPv4 /29 of Private addresses, then I NAT a public IP on a first come-first served basis. The reason they have an own IPv4 Net on the inside is to gain some security between servers in the facility... With IPv6 I obviously dont want to use NAT, so I will set up a small IPv6 Network for each server, just as i do with IPv4, but without the NAT-part.. So instead of setting up a singe IP to the server I set up a network, but basically its the same... so the change request about removing multi-homing requirement doesnt make sense in my case.... I think the requirement is a good thing because i dont see ANy reason to get PI-space if you are not multihomed. // Janne _______________________ V E N T I R O ______ Janne Tuomi, tuomi at ventiro.se Tel: +46-11-36 52 00 GSM: +46-70-224 6000 Fax: +46-11-36 52 05 On 30 mar 2011, at 12.32, Erik Bais wrote: > Hi Jan, > > > > If you are providing SSL hosting on your shared, dedicated of VPS webservers, you are allowed to use PI space, as long as you don?t provide blocks to a specific customers to use. That is considered assigning, so if you use a first come, first served assignment strategy on PI IP?s, that is acceptable for PI is my experience with the IPRA?s. > > > > If your customer is hosting SSL sites on their equipment (read: you are providing collocation), you would need to sign up as a LIR for now, as your customer isn?t multi-homed (I assume) and that is (still) another requirement for IPv6 PI. > > > > I have a policy change requested through the formal channels to remove the multi-homing requirement for PI IPv6, so expect some more discussion on PI IPv6 on the list soon. > > > > Regards, > > Erik Bais > > > > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Jan Tuomi > Sent: Wednesday, March 30, 2011 11:55 AM > To: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? > > > > On 30 mar 2011, at 11.08, Adrian Czapek wrote: > > > W dniu 2011-03-30 10:58, Tero Toikkanen pisze: > >> Hi, > >> > >> As far as I?m concerned, there seems to be a strange discrepancy between > >> IPv4 PI and IPv6 PI. Apparently Janne has already successfully obtained > >> IPv4 PI and has now requested IPv6 PI, declaring the same intended use. > >> Could someone please point out where in the policy documents it says one > >> can use IPv4 PI for hosting, but not IPv6 PI? I?m having a hard time > >> finding such terms. > >> > > http://www.ripe.net/ripe/docs/ripe-512#_8._IPv6_Provider > > > > Most important is the last sentence: > > The PI assignment cannot be further assigned to other organisations. > > > > And according to IPRA, if you provide hosting services on your own infratructure to other companies, you are sub-allocating part of your PI address space to them, so you cannot use PI address space for that purpose. > > > > Regards > > -- > > Adrian > > > > > So what this means is that if a customer puts their server in my facility I am sub-allocating? > To sub-allocate I have to be an LIR and request an own PA-space? > For each customer I have to assign their own /64 and register it in the ripe-database? > > Setting up an SSL-webhost is also sub-allocating? so to set up an ssl-host I have to again allocate an own /64 for the host, register it in the database, set up VLANS and routing on the webserver and network equipment since its a different IP-network? this will cause a lot of problem with stateful inspection in the firewall because i need to use multiple default gateways on the same server. So in the end I have to set up a whole new webbserver for each customer who needs SSL to get things running smoothly? > > hmm.. seems that I have to forget about IPv6 and continue running IPv4 only.... > > // Janne > > _______________________ V E N T I R O ______ > Janne Tuomi, tuomi at ventiro.se > Tel: +46-11-36 52 00 > GSM: +46-70-224 6000 > Fax: +46-11-36 52 05 > > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1204 / Virus Database: 1498/3537 - Release Date: 03/29/11 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4697 bytes Desc: not available URL: From gert at space.net Wed Mar 30 13:14:09 2011 From: gert at space.net (Gert Doering) Date: Wed, 30 Mar 2011 13:14:09 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <05A36A19-DD6E-4955-BBDB-F7712DBEBE11@ventiro.se> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <4D92F2F2.2060905@rybnet.pl> <05A36A19-DD6E-4955-BBDB-F7712DBEBE11@ventiro.se> Message-ID: <20110330111409.GC30227@Space.Net> Hi, On Wed, Mar 30, 2011 at 11:54:55AM +0200, Jan Tuomi wrote: > So what this means is that if a customer puts their server in my facility I am sub-allocating? Yes. > To sub-allocate I have to be an LIR and request an own PA-space? Yes. As the definition of PI is "this is for you, and for you alone". (See the other long mail I've sent why this is not such a trivial matter) > For each customer I have to assign their own /64 and register it in the ripe-database? You have to document it in a way that you can show the documentation to the RIPE IPRAs, but it does not have to be in the RIPE-DB (for IPv6). Whether you assign a /64 or a /60 (think "customer with a firewall and a load balancer and a backend network for the database") is a matter of local taste. If you run multiple customers in a shared network, you can of course give every customer just a single IPv6 address (not going into technicalities on cross-customer protection here). > Setting up an SSL-webhost is also sub-allocating? This is very grey area. Technically, it's "giving an address to a 3rd party", but personally I'd see this is as "it's still the same machine under *your* control". But we already know that datacenter has all the range from "very obviously *not* sub-allocation" to "very obviously this *is* sub-allocation", and as such, distinction between "what is OK" and "what is not" is tricky at best. Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3583 bytes Desc: not available URL: From gert at space.net Wed Mar 30 13:17:19 2011 From: gert at space.net (Gert Doering) Date: Wed, 30 Mar 2011 13:17:19 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <4D92F2F2.2060905@rybnet.pl> <82vcz1nf7d.fsf@mid.bfk.de> <20110330095341.GB30227@Space.Net> Message-ID: <20110330111719.GD30227@Space.Net> Hi, On Wed, Mar 30, 2011 at 10:28:19AM +0000, Tero Toikkanen wrote: > Also, policy interpretation within RIPE NCC should be sorted out (unless > it already is), as I distinctly remember getting IPv6 PI for a customer > for hosting purposes a year ago. Nothing wrong with "I run my own datacenter and host my own servers there, and want to number them with my own IPv6 PI space". The bit where you provide services "to other parties" is where things get problematic, when the policy has a "no sub-allocations / sub-assignments to 3rd parties" clause. (No need to enumerate the large amount of different possible ways to run "a hosting business" here) Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From ebais at a2b-internet.com Wed Mar 30 13:18:44 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 30 Mar 2011 13:18:44 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <6BDB472E-58F2-433D-9669-B908A450E2C6@ventiro.se> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <4D92F2F2.2060905@rybnet.pl> <05A36A19-DD6E-4955-BBDB-F7712DBEBE11@ventiro.se> <002201cbeec5$d72b53a0$8581fae0$@com> <6BDB472E-58F2-433D-9669-B908A450E2C6@ventiro.se> Message-ID: <003b01cbeecc$3b795ea0$b26c1be0$@com> Hi Jan, I come across customers who want to get into IPv6 and have their own IP addresses. However they don't want to multi-home (yet), they want to have the flexibility to change providers if needed without having to re-number their complete infrastructure / vpn devices / dns servers etc etc The only way for those customers to help them currently is to tell them to: A: become a LIR, pay 3300 euro sign-up and yearly cost for the first year. And nobody will ask if you are going to multi-home or not. There are plenty of LIR's who are not multi-homed or just have some other company run their IP space under another AS. B: Request PI IPv6, invest in multi-homing equipment and knowledge, connect to a competitor and proceed. As LIR's don't have the requirement to multihome their IP space, means that the community is in agreement that this PI IPv6 space required a hurdle in order to stop a wild-growth on the IPv6 routing table growth, however if someone pays their way into the community (become a LIR), nobody cares anymore about the routing table growth and we gladly take your money and proceed. Having said that, this is a financial decision and not a technical routing table growth mediation rule. And it should be treated as such. The proposal change I've done is to remove the multi-homing requirement, and ask the GM meeting to increase the cost for PI IPv6 from 50 euro to 250 euro to keep all things equal. That would still allow customers who want their own PI IPv6 to be able to request it for their own infrastructure, without having them to force them into my competitors arms or having them to shell-out 3300 euro to become a LIR, if they don't want to become a LIR for their specific reasons. There is no difference for those kind of customers in the routing table if you would receive a /32 (new LIR) or a /48 (new PI IPv6 without multi-homing). On the part of colocation services as what you are doing / describing (your customer financially OWNS their servers), that is against the intention of PI (both IPv4 and IPv6) space. And as such your request got denied is my guess. Regards, Erik Bais From: Jan Tuomi [mailto:tuomi at ventiro.se] Sent: Wednesday, March 30, 2011 1:02 PM To: Erik Bais Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? Hi Erik, Why remove the multi-homing requirement? if you are not multihomed you could go with the PA-space you get from your single upstream provider? My problem is that I actually am multi-homed, therefor I need IPv6-PI.... And if my customers have their servers in my facility they also are multihomed? So they could request for their own PI? that really doesnt make sensee, that would really clog down the routing tables.... The hosting network is today set up so each customer get their own IPv4 /29 of Private addresses, then I NAT a public IP on a first come-first served basis. The reason they have an own IPv4 Net on the inside is to gain some security between servers in the facility... With IPv6 I obviously dont want to use NAT, so I will set up a small IPv6 Network for each server, just as i do with IPv4, but without the NAT-part.. So instead of setting up a singe IP to the server I set up a network, but basically its the same... so the change request about removing multi-homing requirement doesnt make sense in my case.... I think the requirement is a good thing because i dont see ANy reason to get PI-space if you are not multihomed. // Janne _______________________ V E N T I R O ______ Janne Tuomi, tuomi at ventiro.se Tel: +46-11-36 52 00 GSM: +46-70-224 6000 Fax: +46-11-36 52 05 On 30 mar 2011, at 12.32, Erik Bais wrote: Hi Jan, If you are providing SSL hosting on your shared, dedicated of VPS webservers, you are allowed to use PI space, as long as you don't provide blocks to a specific customers to use. That is considered assigning, so if you use a first come, first served assignment strategy on PI IP's, that is acceptable for PI is my experience with the IPRA's. If your customer is hosting SSL sites on their equipment (read: you are providing collocation), you would need to sign up as a LIR for now, as your customer isn't multi-homed (I assume) and that is (still) another requirement for IPv6 PI. I have a policy change requested through the formal channels to remove the multi-homing requirement for PI IPv6, so expect some more discussion on PI IPv6 on the list soon. Regards, Erik Bais From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Jan Tuomi Sent: Wednesday, March 30, 2011 11:55 AM To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? On 30 mar 2011, at 11.08, Adrian Czapek wrote: > W dniu 2011-03-30 10:58, Tero Toikkanen pisze: >> Hi, >> >> As far as I'm concerned, there seems to be a strange discrepancy between >> IPv4 PI and IPv6 PI. Apparently Janne has already successfully obtained >> IPv4 PI and has now requested IPv6 PI, declaring the same intended use. >> Could someone please point out where in the policy documents it says one >> can use IPv4 PI for hosting, but not IPv6 PI? I'm having a hard time >> finding such terms. >> > http://www.ripe.net/ripe/docs/ripe-512#_8._IPv6_Provider > > Most important is the last sentence: > The PI assignment cannot be further assigned to other organisations. > > And according to IPRA, if you provide hosting services on your own infratructure to other companies, you are sub-allocating part of your PI address space to them, so you cannot use PI address space for that purpose. > > Regards > -- > Adrian > So what this means is that if a customer puts their server in my facility I am sub-allocating? To sub-allocate I have to be an LIR and request an own PA-space? For each customer I have to assign their own /64 and register it in the ripe-database? Setting up an SSL-webhost is also sub-allocating? so to set up an ssl-host I have to again allocate an own /64 for the host, register it in the database, set up VLANS and routing on the webserver and network equipment since its a different IP-network? this will cause a lot of problem with stateful inspection in the firewall because i need to use multiple default gateways on the same server. So in the end I have to set up a whole new webbserver for each customer who needs SSL to get things running smoothly? hmm.. seems that I have to forget about IPv6 and continue running IPv4 only.... // Janne _______________________ V E N T I R O ______ Janne Tuomi, tuomi at ventiro.se Tel: +46-11-36 52 00 GSM: +46-70-224 6000 Fax: +46-11-36 52 05 _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1498/3537 - Release Date: 03/29/11 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Wed Mar 30 13:30:08 2011 From: gert at space.net (Gert Doering) Date: Wed, 30 Mar 2011 13:30:08 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <0B2CCA97-68C1-478A-AA40-B883BF5F51B3@ventiro.se> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <20110330084344.GD3202@cilaos> <6A02EC6B-C0F3-43E4-B37E-AECF8298722D@bondis.org> <20110330094416.GA30227@Space.Net> <0B2CCA97-68C1-478A-AA40-B883BF5F51B3@ventiro.se> Message-ID: <20110330113008.GE30227@Space.Net> Hi, On Wed, Mar 30, 2011 at 12:21:54PM +0200, Jan Tuomi wrote: > > Conservation is not one of the primary goals for IPv6. > > > > Routing table size (=aggregation) *is* - which is why the consensus of > > this group, some years ago, was "be restrictive on PI". > > What is the difference in allocating one /48 PI-block or one /32 > PA-block from a routing table size view? there still is one route > in both cases because I need multihoming.... Sure, and the PI policy requires "multihoming" for that reason - to permit PI for the cases that were clearly understood at that time: if someone wants/needs to do BGP-based multihoming, they will consume a routing table slot anyway. Now *this* discussion didn't start with "the multihoming requirement" but with "what can I use PI for" - which is a different restriction, and I tried to explain that these are interconnected and it is not that easy to untangle things in a way that the end result is better than what we have now. > > Now, this particular problem ("datacenter business") has been showing up > > a few times in the last 1.5 years, and in the end, it boils down to a > > number of considerations that are NOT easily solved. > > > > - the distinction between PA and PI is, conceptually, > > > > "PA is for ISPs that want to number (their) customers" > > > > "PI is for customers that want to number their own(!) network in an > > independent way" > > Should I consider myself as an ISP? I am not selling internet > access to my customers locations, the customers is running their > servers in my facility, in my rack, on my switches, firewalls and > routers, they dont have physical access without me or someone from > my staff being present. > From my point of view, it is MY OWN network, not theirs. Sounds like you're providing "Internet Services" to your customers - you make sure that their web presence can be reached from "the Internet". As I have tried to explain - this is where the distinction PA/PI came from, and indeed, you seem to match a loose definition of "ISP" quite well - an ISP isn't only "runs DSL lines to folks". We know that datacenter is problematic, as the boundaries between "this is MY NETWORK and MY SERVERS" and "this is MY NETWORK and THEIR servers" and "this is MY NETWORK connecting to THEIR firewall, and THEIR network behind the firewall" is floating. > > - PI has been positioned as "cheap", so it's not a major hurdle for > > small "non-isp" companies that want/need independent address space > > > > - PA is "expensive", because it's only given to LIRs, and all the LIRs > > around share the expense of having the RIPE NCC do their job > > > > --> so, if a large number of ISPs change to run their IPv6 business on > > PI space, and stop paying LIR fees, all *other* LIRs have to pay *more* > > (the NCC's expenses pretty much stay the same, and get distributed to > > less paying members). So from a fairness point of view, there's good > > reason to ask everybody who is running an ISP-like business to become > > a LIR, and pay their share, staggered by "ISP size". > > But the price is the same... > EXTRA SMALL, LIR: Sign-up Fee (? 2000) + Service Fee (? 1,300) > EXTRA SMALL, Direct Assignment User: Administration Fee (? 2000) + Service Fee (? 1,300) PI costs 50 EUR/year per assignment if you go through a sponsoring LIR (which is the recommended way of doing it) in RIPE fees, plus some extra that the sponsoring LIR is usually adding as a handling fee. If you intend on becoming a Direct Assignment User, go for "LIR", and stop worrying on PA vs. PI and sub-assignments. > Is it about that? Did I make the wrong choice in not becoming a DUA directly against RIPE? Well, if you're a hosting provider, and the question is "DUA or LIR", go for LIR. If the question is "PI via a local LIR" vs. "become a LIR yourself", there's a larger monetary difference, and some argue that this is too expensive and will drive them out of business. We *are* listening to that, but have no easy answer yet. Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3583 bytes Desc: not available URL: From gert at space.net Wed Mar 30 13:40:03 2011 From: gert at space.net (Gert Doering) Date: Wed, 30 Mar 2011 13:40:03 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <003b01cbeecc$3b795ea0$b26c1be0$@com> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <4D92F2F2.2060905@rybnet.pl> <05A36A19-DD6E-4955-BBDB-F7712DBEBE11@ventiro.se> <002201cbeec5$d72b53a0$8581fae0$@com> <6BDB472E-58F2-433D-9669-B908A450E2C6@ventiro.se> <003b01cbeecc$3b795ea0$b26c1be0$@com> Message-ID: <20110330114003.GF30227@Space.Net> Hi, On Wed, Mar 30, 2011 at 01:18:44PM +0200, Erik Bais wrote: > As LIR's don't have the requirement to multihome their IP space, means that > the community is in agreement that this PI IPv6 space required a hurdle in > order to stop a wild-growth on the IPv6 routing table growth, however if > someone pays their way into the community (become a LIR), nobody cares > anymore about the routing table growth and we gladly take your money and > proceed. That (money) is not the specific point why there is no multihoming requirement for a LIR. Consider a LIR with 4000 customers that wants to change upstream - they not only have to renumber their own network, but also renumber 4000 customers, which is roughly 4001 times the amount of work compared to "one end customer needs to renumber". This community has decided that the burden of renumbering every now and then is considered acceptable for an end customer (given that we need to balance with the routing table, and there are MANY MORE end customers than LIRs - the routing system will not be able to handle "every end customer is using PI space"), but that LIRs are to be "the aggregation points" in the routing system, and the routing system will handle "1 route per LIR" just fine. Earlier proposals saw a strict limitation to "at maximum 8192 Top Level Aggregates are permitted into the routing system", but nobody has ever been able to define "who is an important-enough ISP to get a TLA and who is not, and has to closely tie their business to a competitor" - so we changed that to "every LIR is considered equally important and can get their own address block" (with an implied "to number their customers"). I'm not saying that we can't change the way it is now, mainly trying to explain how things came to be. Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From joao at bondis.org Wed Mar 30 13:48:27 2011 From: joao at bondis.org (Joao Damas) Date: Wed, 30 Mar 2011 13:48:27 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <20110330111409.GC30227@Space.Net> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <4D92F2F2.2060905@rybnet.pl> <05A36A19-DD6E-4955-BBDB-F7712DBEBE11@ventiro.se> <20110330111409.GC30227@Space.Net> Message-ID: <3121319D-D987-4728-8F18-C3D41ACB2BDA@bondis.org> On 30 Mar 2011, at 13:14, Gert Doering wrote: > Hi, > > On Wed, Mar 30, 2011 at 11:54:55AM +0200, Jan Tuomi wrote: >> So what this means is that if a customer puts their server in my facility I am sub-allocating? > > Yes. No, you said before the addresses were for your own network, and the network remains yours independently of what hosts you connect to you. Hosting customers are not expecting to carry their individual server IP addresses with them when they change colo because they are part of the colo, so no, you are no sub-alloacting. >> Setting up an SSL-webhost is also sub-allocating? > > This is very grey area. Technically, it's "giving an address to a 3rd > party", not quite, as you remain the address holder. Do you charge each customer for their quota of airco in the facility explicitly? > but personally I'd see this is as "it's still the same machine > under *your* control". it definitely is the same network, at least as long as the customer does not have a router between your net and their equipment. Joao From joao at bondis.org Wed Mar 30 13:50:00 2011 From: joao at bondis.org (Joao Damas) Date: Wed, 30 Mar 2011 13:50:00 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <6BDB472E-58F2-433D-9669-B908A450E2C6@ventiro.se> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <4D92F2F2.2060905@rybnet.pl> <05A36A19-DD6E-4955-BBDB-F7712DBEBE11@ventiro.se> <002201cbeec5$d72b53a0$8581fae0$@com> <6BDB472E-58F2-433D-9669-B908A450E2C6@ventiro.se> Message-ID: <3295E9C4-8E64-416A-B5FE-418F2A2625A9@bondis.org> On 30 Mar 2011, at 13:02, Jan Tuomi wrote: > Hi Erik, > > Why remove the multi-homing requirement? if you are not multihomed you could go with the PA-space you get from your single upstream provider? I guess it is because, as IPv6 moves from using Powerpoint as its main transport to using Ethernet, people are finding out that renumbering is just as hard in IPv4 as it is in IPv6, so people want to be *Provider Independent* Joao From sander at steffann.nl Wed Mar 30 14:46:32 2011 From: sander at steffann.nl (Sander Steffann) Date: Wed, 30 Mar 2011 14:46:32 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <003b01cbeecc$3b795ea0$b26c1be0$@com> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <4D92F2F2.2060905@rybnet.pl> <05A36A19-DD6E-4955-BBDB-F7712DBEBE11@ventiro.se> <002201cbeec5$d72b53a0$8581fae0$@com> <6BDB472E-58F2-433D-9669-B908A450E2C6@ventiro.se> <003b01cbeecc$3b795ea0$b26c1be0$@com> Message-ID: <90F1D8DA-D4FF-46AD-A3FF-FAFB8543C9D1@steffann.nl> Hi, > A: become a LIR, pay 3300 euro sign-up and yearly cost for the first year. And nobody will ask if you are going to multi-home or not. There are plenty of LIR?s who are not multi-homed or just have some other company run their IP space under another AS. They do have to provide IPv6 services to other organizations though: "... have a plan for making sub-allocations to other organisations and/or End Site assignments within two years." - Sander From leo.vegoda at icann.org Wed Mar 30 16:54:34 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 30 Mar 2011 07:54:34 -0700 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <90F1D8DA-D4FF-46AD-A3FF-FAFB8543C9D1@steffann.nl> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <4D92F2F2.2060905@rybnet.pl> <05A36A19-DD6E-4955-BBDB-F7712DBEBE11@ventiro.se> <002201cbeec5$d72b53a0$8581fae0$@com> <6BDB472E-58F2-433D-9669-B908A450E2C6@ventiro.se> <003b01cbeecc$3b795ea0$b26c1be0$@com> <90F1D8DA-D4FF-46AD-A3FF-FAFB8543C9D1@steffann.nl> Message-ID: <00C2FAAB-F851-4F9A-8682-4E800A76A314@icann.org> On Mar 30, 2011, at 5:46 AM, Sander Steffann wrote: >> A: become a LIR, pay 3300 euro sign-up and yearly cost for the first year. And nobody will ask if you are going to multi-home or not. There are plenty of LIR?s who are not multi-homed or just have some other company run their IP space under another AS. > > They do have to provide IPv6 services to other organizations though: > "... have a plan for making sub-allocations to other organisations and/or End Site assignments within two years." A plan isn a plan and not a commitment, though. No-one's going to take the LIR's space away if they miss the target. On that basis, we know that this requirements is purely a form of words and has no real value. Regards, Leo From sander at steffann.nl Wed Mar 30 17:02:31 2011 From: sander at steffann.nl (Sander Steffann) Date: Wed, 30 Mar 2011 17:02:31 +0200 Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? In-Reply-To: <00C2FAAB-F851-4F9A-8682-4E800A76A314@icann.org> References: <2ABEFF2C-BADB-46AF-A6D7-678715758F1B@ventiro.se> <4D92F2F2.2060905@rybnet.pl> <05A36A19-DD6E-4955-BBDB-F7712DBEBE11@ventiro.se> <002201cbeec5$d72b53a0$8581fae0$@com> <6BDB472E-58F2-433D-9669-B908A450E2C6@ventiro.se> <003b01cbeecc$3b795ea0$b26c1be0$@com> <90F1D8DA-D4FF-46AD-A3FF-FAFB8543C9D1@steffann.nl> <00C2FAAB-F851-4F9A-8682-4E800A76A314@icann.org> Message-ID: <9114D7BA-C8E7-407A-80DB-F500D2698423@steffann.nl> Hi Leo, >> They do have to provide IPv6 services to other organizations though: >> "... have a plan for making sub-allocations to other organisations and/or End Site assignments within two years." > > A plan isn a plan and not a commitment, though. > > No-one's going to take the LIR's space away if they miss the target. On that basis, we know that this requirements is purely a form of words and has no real value. I don't agree with you here. If you run a grocery store (or other non ISP business) it might be hard to show believable plan for making sub-allocations or assignments... And there is no target anymore, so there is nothing to miss ;-) - Sander