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

[OT] IPv4 addresses in RIPE database.
by Marcin Gondek 22 Mar '08

22 Mar '08

Hello All, Which policy, rule or document of RIPE describes that if ISP giving to customer more than one IP address then those addresses have to/should be saved into RIPE database as independent entry of inetnum? Or there is no rule, and ISP doing it because they want to make "clear view" of used IP addresses. Thanks in advance. PS: I tried to find on RIPE website. Question is about IPv4. -- Marcin Gondek / Drixter e-utp.net NIP: PL1181589645 REGON: 140584662 Tel. +48602159929 Fax. +48222012418 <mailto:office@e-utp.net> office(a)e-utp.net <http://www.e-utp.net> http://www.e-utp.net

2 2

2007-01 End User Relationships
by michael.dillon＠bt.com 17 Mar '08

17 Mar '08

I strongly support proposal 2007-01 which states this on the web page: ----------- This proposal states that a contractual relationship between an End User and a sponsoring LIR or the RIPE NCC must be established before the End User receives Internet number resources (Autonomous System (AS) Number, Provider Independent (PI) IPv4 and IPv6, Internet Exchange Point (IXP) and anycasting assignments) directly from the RIPE NCC. It also states that the text in the policy should mention more explicitly that PI assignments can not be sub-assigned. ------------ I've been personally stuck in the middle of PI applications by end users and I don't believe that we, as an LIR, add any value to the process. In some cases, I believe we just create problems because we end up passing on messages between RIPE and the End User instead of allowing the two parties to communicate directly. After all, PI means Provider Independent, and since LIRs are providers, shouldn't the End User be independent of us when they apply for their addresses? Also, I have had experience on several occasions, of helping End Users in the ARIN region apply for PI allocations there. My role was to advise, explain, educate and to review their applications before they submitted them to ARIN. Every one of these End Users were eventually successful in their application, in fact one of them got it approved the same day they applied. The reason I am telling you this is to point out, that giving End Users a direct relationship with RIPE, does not mean that the LIRs are blocked from the whole process. If the End User is a customer, we can still help them by advising, explaining, educating and reviewing the applications before they go to RIPE. --Michael Dillon

1 0

Conflict over right to use IP addresses in The Netherlands
by Sander Steffann 13 Mar '08

13 Mar '08

Hi, FYI: There is a conflict in The Netherlands about who can use certain IP addresses. When the company DIS Hosting went bankrupt, they were bought by Real Hosting. Real Hosting is now the holder of the IP blocks previously used by DIS Hosting. Now it turns out that another company, Fiberworld, is using IP space from this block... Real Hosting and Fiberworld could not come to an agreement about the ownership / transfer of those IP addresses, so Fiberworld started a lawsuit. A judge has ruled that Fiberworld must be allowed the use of the IP addresses for 30 days, so they have time to prove they have the right to use those addresses. An article about this (in Dutch): http://www.ispam.nl/archives/1703/rechtszaak-om-ip-adressen-van-dis-hosting/ - Sander

5 6

Proposal 2006-05 minimum /24 allocation
by Sander Steffann 12 Mar '08

12 Mar '08

Hi Michael, > I see that the review phase for this proposal ends in a few days. Actually it ended a year ago :) This proposal has been waiting for policy 2007-01 since then. I am glad to hear your thoughts about this proposal. We will have to wait with deciding about consensus until 2007-01 is done though. Thanks! Sander

1 0

Enabling Methods for Reallocation of IPv4 Resources
by michael.dillon＠bt.com 12 Mar '08

12 Mar '08

I've been looking at policy proposal 2007-08 about transfering addresses between LIRs directly. I'm not sure what the current status of this is, but it is one of a family of similar proposals before ARIN and APNIC. In the other RIRs, people who support this type of transfer proposal seem to consider it to be the first step towards trading in IP address contracts, i.e. creating a market for buying and selling contracts which give the right to use IP addresses. I've been reading through the MiFID directives and some of the English language material covering MiFID, trying to figure out whether these IP address contracts would fall under the MiFID guidelines. Of course, EU guidelines are not the same as laws, and the laws in this area enable a regulator, who then goes on to make regulations. I have come to the conclusion that the Dutch law is the one that is most likely to currently apply, since RIPE is run out of Amsterdam and since the policy proposal calls on RIPE to register these transfers. My knowledge of the Germanic languages is not good enough to really make sense of the Dutch legislation. I wonder if someone who speaks Dutch, or who is a native speaker of German or a Scandinavian language, could have a look at the text of the Dutch law here <http://www.st-ab.nl/wetten/0490_Wet_financiele_dienstverlening_Wfd.htm> to see if the definitions cover the sale of contracts which give the right to use IP addresses. I'm pretty sure that "effect" in Article 1(i) defines what is a "security" but since MiFID has a lot of text about which kind of organizations and activities are covered by the new rules, I suspect you would need to read more than the definition of this one term. Since many people seem to have a vision of an IP address trading market that functions similar to a securities market like Euronext, I think that we need some proper legal guidance that tells us the boundaries for RIPE policy. If we step over those boundaries, then the MiFID rules will apply to everything that we do with IPv4 address allocations. --Michael Dillon

3 3

Proposal 2006-05 minimum /24 allocation
by michael.dillon＠bt.com 11 Mar '08

11 Mar '08

I see that the review phase for this proposal ends in a few days. http://www.ripe.net/ripe/policies/proposals/2006-05.html I would like to speak in favour of allowing end users to get a minimum of a /24 allocation when routing is an issue. For instance, a customer with an application running out of a data centre has their own AS number and wants to get PI space from RIPE. Since data centres typically hide their architecture using RFC 1918 space behind NAT and load balancers, etc., it doesn't make sense to allocate a longer prefix just because their publicly visible machines fit in less than a /24. For instance, if RIPE were to allocate a /26 (64 addresses) rather than a /24 (256 addresses), the number of addresses saved is only 192 which is such a small number that it cannot be considered significant on the larger scale. The issue of routing table slots is irrelevant since the End User intends to announce their prefix whatever its length is. I don't believe that there is any advantage to conserving such small amounts of space. Instead of dancing around the issue and forcing people into creative host accounting to justify a /24, let's just make it simple and offer that as the minimum when, and only when, the End User can show that routing is an issue. I would not be surprised to find that RIPE requires such End Users to already have an Asnum or apply for one at the same time. That seems reasonable. ------------------------------------------------------- Michael Dillon RadianzNet Capacity Forecast & Plan -- BT Design 66 Prescot St., London, E1 8HG, UK Mobile: +44 7900 823 672 Internet: michael.dillon(a)bt.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 http://www.btradianz.com Use the wiki: http://collaborate.intra.bt.com/

3 2

2007-01 Draft Documents Published (Direct Internet Resource Assignments to End Users from the RIPE NCC)
by Filiz Yilmaz 09 Mar '08

09 Mar '08

PDP Number: 2007-01 Direct Internet Resource Assignments to End Users from the RIPE NCC Dear Colleagues, The draft documents for the proposal described in 2007-01 have been published. Please note that this is a new version of the proposal. The impact analysis that was conducted for this proposal has also been published. The proposal states that a contractual relationship between an End User and a sponsoring Local Internet Registry (LIR) or the RIPE NCC must be established before the End User receives Internet number resources (Autonomous System (AS) Numbers, Provider Independent (PI) IPv4 and IPv6 address space, Internet Exchange Point (IXP) and anycasting assignments) directly from the RIPE NCC. It also states that the text in the policy should mention more explicitly that PI assignments cannot be sub-assigned. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-01.html and the draft documents at: http://www.ripe.net/ripe/draft-documents/ripe-424-draft.html http://www.ripe.net/ripe/draft-documents/ripe-421-draft.html http://www.ripe.net/ripe/draft-documents/ripe-389-draft.html http://www.ripe.net/ripe/draft-documents/ripe-256-draft.html We encourage you to read the draft documents and send any comments to address-policy-wg(a)ripe.net before 3 April 2008. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

3 2

2008-03 New Policy Proposal (2007-06 and 2007-07 are withdrawn)
by Filiz Yilmaz 03 Mar '08

03 Mar '08

PDP Number: 2008-03 Global Policy for the Allocation of the Remaining IPv4 Address Space Dear Colleagues, Following the feedback received during RIPE 55, the proposers of proposals 2007-06 and 2007-07 withdrew them and jointly created a new one. This proposal is now published and available for discussion. The proposal describes the process for the allocation of the remaining IPv4 space from IANA to the RIRs. When a minimum amount of available space is reached, one /8 will be allocated from IANA to each RIR, replacing the current IPv4 allocation policy. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-03.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 3 March 2008. Withdrawn proposals are archived and can still be found at: http://www.ripe.net/ripe/policies/proposals/2007-07.html and http://www.ripe.net/ripe/policies/proposals/2007-06.html Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 1

Re: [address-policy-wg] applicability of a request for 60000 IPv4 addresses/systems in one shot...
by Mario Reale 29 Feb '08

29 Feb '08

Dear Fotis, >Others have done so (EUCHINAGRID project, afaik) and they only thing >they came up to has been, at best, a patch that can provide private-IPv4 >over IPv6. But, private we've got already, so that's not any progress. to be more precise, what EuChinaGRID did was not to provide patches to provide private-IPv4 over IPv6. Within EuChinaGRID we did essentially 2 things: First, we deployed gLite and GOS on a testbed and studied the behavior using IPv6. In doing this studies, we also exploited NAT-PT to perform specific Client-Server studies. Second, since Research and Education network are IPv6 native , we are carrying out several tests, native IPv6, especially within the Chinese part of out project. Regards, Mario Reale EuChinaGRID / Work Package 2 -- Mario Reale Consortium GARR ------------------------ The Italian Academic and Research Network http://www.garr.it Via dei Tizii, 6 I - 00186 ROMA Italy Phone: +39 06 4962 2537 Fax: +39 06 4962 2044 EMail: mario.reale(a)garr.it

1 0

Re: [address-policy-wg] applicability of a request for 60000 IPv4 addresses/systems in one shot...
by Fotis Georgatos 26 Feb '08

26 Feb '08

Dear Michael et al, > Have you investigated how much work would be needed to make the > grid work over IPv6, or perhaps use an IPv6 VPN to connect sites > but use IPv4 over the VPN to use the grid? Others have done so (EUCHINAGRID project, afaik) and they only thing they came up to has been, at best, a patch that can provide private-IPv4 over IPv6. But, private we've got already, so that's not any progress. > Have you asked Athanassios Liakopoulos or Kostas Kalevras > or Dimitrios Kalogeras to look at ways of solving your problem > with the grid and IPv6? Yes, with a majority of them I had already discussed. And we all agree that if there was IPv4 support in glite it would have been so much better. (Or, if we were grid middleware developers, which we are clearly not). > The bottom line is that experimental allocations are made for > experiments > that benefit the whole Internet, not just a few schools in one country. I believe that understanding this as a school experiment is a bit flawed: Has anybody ever done a large VPN-for-VMs IPv4 adress space allocation? I have never heard of something like that (end2end) but perhaps it exists; and am well aware though of some -open/public- IPv6 tunneling solutions. Collecting knowledge from such an endeavour, were thousands of systems with end2end capability run contained in VMs, I believe is worthy for many, the more as multi-cores change the way we understand systems management. In the meantime, we had some more discussions and found out that making a request for public IPv4 address space is OK solely for Virtual Machines, even if the underlying machines already are on public IPv4 address space, as long as the request is indeed justified by real use - and documented. In other words, reserving experimental IPv4 address space is no longer our first option, since normal IPv4 address space appears to be doable. This is something for which we weren't sure earlier, if someone in this wg knows otherwise - in respect to the adress_policy - please let us know. I thank you, and also other recipients in this list, that took time to reply, some privately. Just to clarify what had been the issue, two extra answers: > * If these machines are already internet connected, then no *additional* IP > could be needed The >62000 machines are functioning within 1000s of NATs, in a 10.x.y.z scheme > * If these machines are not already internet connected then having an IP is > the least of yoru worries - you have to think how you are going to *route* > to them :) That's done and works just fine already for many years. There you go. cheers, Fotis

2 2