From fotis at mail.cern.ch Fri Feb 15 16:55:25 2008 From: fotis at mail.cern.ch (Fotis Georgatos) Date: Fri, 15 Feb 2008 17:55:25 +0200 Subject: [address-policy-wg] applicability of a request for 60000 IPv4 addresses/systems in one shot... Message-ID: <47B5B5ED.5000101@mail.cern.ch> Dear all, I am a member of a -yet unofficial- effort in Greece, where we are in discussions on the potential of using Greek School Network resources (calculated at >62000 machines) with a scavenging technology developed in-house by NTUA [ref. http://gridathome.sourceforge.net/ & http://www.ntua.gr ] The idea is quite simple: you boot your systems or Virtual Machines with a LiveCD, you get an initial -normally private- IP address, and *then* a public one from a VPN tunnel, with which you implement and use full grid functionality because there's end2end network connectivity. Yes, there is a catch: this scheme requires extra publicly routable address space, if it is to be integrated with the existing grid infrastructure (and there are plenty of good reasons to do so, for us and others). I've been looking at http://www.ripe.net/docs/ipv4-policies.html and it appears to me that "Assignments for Internetworking Experiments" would be viable option to begin with but, under what conditions can we request standard address space for, say, 60000 PCs or Virtual Machines? What should we make clear in order to make this successfull in one shot? ps. Note that currently these resources lie within hundreds (thousands?), of NAT'd networks, in a multi-tier network. Our LiveWN technology can scale extremelly quickly, much faster than commitees in schools/government. :) The reason I am asking you is because we are about to prepare a TDR, Technical Design Report, and wish to confirm the validity of our options. ps2. at current stage IPv6 is not an option due to grid middleware limitations. thank you in advance for your time, Drs. Fotis Georgatos From michael.dillon at bt.com Mon Feb 18 16:20:47 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 18 Feb 2008 15:20:47 -0000 Subject: [BULK] [address-policy-wg] applicability of a request for 60000 IPv4 addresses/systems in one shot... In-Reply-To: <47B5B5ED.5000101@mail.cern.ch> References: <47B5B5ED.5000101@mail.cern.ch> Message-ID: > at current stage IPv6 is not an option due to grid middleware > limitations. 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? Greece is a pioneer in making IPv6 services available to schools Do you want to take a step backwards? Have you asked Athanassios Liakopoulos or Kostas Kalevras or Dimitrios Kalogeras to look at ways of solving your problem with the grid and IPv6? 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 don't think you would be successful in getting an allocation from RIPE under the experimental rules. --Michael Dillon From leo.vegoda at icann.org Thu Feb 21 21:25:17 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 21 Feb 2008 12:25:17 -0800 Subject: [address-policy-wg] =?iso-8859-1?Q?Update_to_the_IPv4_Registry=B9s_Format_and_Content?= Message-ID: This message has been sent to several lists. I apologise for duplicates. IANA has improved the format for the IPv4 Address Space registry. At the same time, the entries that were marked ?Various Registries? have been replaced with references to the Regional Internet Registry (RIR) that provides WHOIS and reverse DNS service for that /8 allocation. If you want to machine-process the IPv4 registry, the new fields are: * Prefix * Designation * Date * Whois * Status * Note where the Date will always be of the form ?YYYY-MM? and the status has the following possible values: RESERVED, LEGACY, ALLOCATED and UNALLOCATED /8 allocations that contain legacy assignments in them that are now managed by the RIRs have the text ?Administered by? in the Designation column. Legacy assignments refer to IP address allocations made before the RIR system was established. Reserved address space held by IANA does not have a date listed. The registry can be found at: http://www.iana.org/assignments/ipv4-address-space If you have questions about the structure of the new format, please send e-mail to iana at iana.org. Kind regards, Leo Vegoda Manager, Number Resources - IANA From fotis at mail.cern.ch Tue Feb 26 18:30:02 2008 From: fotis at mail.cern.ch (Fotis Georgatos) Date: Tue, 26 Feb 2008 19:30:02 +0200 Subject: [address-policy-wg] applicability of a request for 60000 IPv4 addresses/systems in one shot... In-Reply-To: <2dd901c87323$6245a480$3a01a8c0@capulet> References: <47B5B5ED.5000101@mail.cern.ch> <2dd901c87323$6245a480$3a01a8c0@capulet> Message-ID: <47C44C9A.7070207@mail.cern.ch> 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 From michael.dillon at bt.com Tue Feb 26 19:11:48 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 26 Feb 2008 18:11:48 -0000 Subject: [address-policy-wg] applicability of a request for 60000 IPv4 addresses/systems in one shot... In-Reply-To: <47C44C9A.7070207@mail.cern.ch> References: <47B5B5ED.5000101@mail.cern.ch> <2dd901c87323$6245a480$3a01a8c0@capulet> <47C44C9A.7070207@mail.cern.ch> Message-ID: >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). It's too bad that this one particular grid technology is not yet available using IPv6 but this is not the only way to build a grid. I think you are missing an opportunity to partner with developers and do something innovative that would benefit the larger community. > 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. Yes. The thing that worries me about giving any kind of special support to any sort of VM deployment is that it will cause the IPv4 address space to run out sooner. The consumption rate is no longer constrained to the number of CPU chips produced but now can grow faster which leads to a power law increase in demand. > In other words, reserving experimental IPv4 address space is > no longer our first option, since normal IPv4 address space > appears to be doable. Good. It won't be too long before someone suggests changing policies to no longer accept virtual machines as a justification for address space. --Michael Dillon From fotis at mail.cern.ch Tue Feb 26 20:12:39 2008 From: fotis at mail.cern.ch (Fotis Georgatos) Date: Tue, 26 Feb 2008 21:12:39 +0200 Subject: [address-policy-wg] applicability of a request for 60000 IPv4 addresses/systems in one shot... In-Reply-To: References: <47B5B5ED.5000101@mail.cern.ch> <2dd901c87323$6245a480$3a01a8c0@capulet> <47C44C9A.7070207@mail.cern.ch> Message-ID: <47C464A7.5070601@mail.cern.ch> Hi Michael, O/H michael.dillon at bt.com ??????: [...] > The thing that worries me about giving any kind of special support > to any sort of VM deployment is that it will cause the IPv4 > address space to run out sooner. The consumption rate is no > longer constrained to the number of CPU chips produced but > now can grow faster which leads to a power law increase in > demand. Yes, yes and no worries: The reason being that VM resources are much more "elastic" in their deployment and once/if they create an excaustion of address space, it will become possible to do a smoother migration to IPv6, rather than reaching a day-0 where you either get IPv6 or nothing at all. (because in the meantime any VM-based solutions will also improve, since the incentives will be so high and migration paths doable) > It won't be too long before someone suggests changing policies > to no longer accept virtual machines as a justification for > address space. We all fully understand the implications. We wondered if there was already a previous explicit discussion about it (aparrently not, hm?), at policy level, exactly because of the reasons you mentioned above. But, I find the line of thinking that wants life on the Internet to be independent of its physical incarnation is genuinely forward-looking. cheers, Fotis From mario.reale at garr.it Fri Feb 29 17:06:38 2008 From: mario.reale at garr.it (Mario Reale) Date: Fri, 29 Feb 2008 17:06:38 +0100 Subject: [address-policy-wg] applicability of a request for 60000 IPv4 addresses/systems in one shot... Message-ID: <47C82D8E.2080001@garr.it> 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 at garr.it -------------- next part -------------- An HTML attachment was scrubbed... URL: