RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues)
Let me try to understand: (A) We don't disagree that he might actually deserve more than /32 (B) According to my understanding of previous discussions I had on this topic, RIPE might actually have already reserved extra space for his future needs (C) According to the current rules he can't get another /32 for a total of /31 without using most of the current /32 (and hoping his next /32 will be adjacent) (D) Someone is seriously suggesting he returns the current /32 and asks for a brand new /31 which he will likely get. Was someone reading too much Kafka or The Good Soldier Švejk lately? Ivan
-----Original Message----- From: Jan Zorz @ Go6.si [mailto:jan@go6.si] Sent: Monday, July 18, 2011 5:13 PM To: Ivan Pepelnjak; 'Sander Steffann'; 'Yannis Nikolopoulos' Subject: RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues)
Going to production it was said :)
I did a long discussion with Alex Le Heux (RIPE IPRA) about the same issue, his advice was that.
Jan
Ivan Pepelnjak <ipepelnjak@gmail.com> wrote:
Extremely helpful advice from the ops perspective.
Trade in your /32 and get something bigger under initial alloc conditions... :)
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Hi Ivan,
Let me try to understand:
(A) We don't disagree that he might actually deserve more than /32 (B) According to my understanding of previous discussions I had on this topic, RIPE might actually have already reserved extra space for his future needs (C) According to the current rules he can't get another /32 for a total of /31 without using most of the current /32 (and hoping his next /32 will be adjacent) (D) Someone is seriously suggesting he returns the current /32 and asks for a brand new /31 which he will likely get.
All correct. The current policy doesn't permit the RIPE NCC to give out extra address space for an existing allocation until the HD ratio has been reached. They are allowed to give more than a /32 when someone requests a new allocation though. I have had this same issue and I got the same answer. After reading the policies with this in mind I can only conclude that the RIPE NCC is implementing the policy correctly. If we want the NCC to do something else someone has to write a policy proposal. Thanks, Sander
On Mon, Jul 18, 2011 at 8:25 AM, Sander Steffann <sander@steffann.nl> wrote:
Hi Ivan,
Let me try to understand:
(A) We don't disagree that he might actually deserve more than /32 (B) According to my understanding of previous discussions I had on this topic, RIPE might actually have already reserved extra space for his future needs (C) According to the current rules he can't get another /32 for a total of /31 without using most of the current /32 (and hoping his next /32 will be adjacent) (D) Someone is seriously suggesting he returns the current /32 and asks for a brand new /31 which he will likely get.
All correct. The current policy doesn't permit the RIPE NCC to give out extra address space for an existing allocation until the HD ratio has been reached. They are allowed to give more than a /32 when someone requests a new allocation though. I have had this same issue and I got the same answer.
After reading the policies with this in mind I can only conclude that the RIPE NCC is implementing the policy correctly. If we want the NCC to do something else someone has to write a policy proposal.
FYI, a number of folks had this same issue in the ARIN region, and as a result policy ARIN-2010-12 (https://www.arin.net/policy/proposals/2010_12.html) was proposed, adopted, and implemented to address the problem. -Scott
On Mon, Jul 18, 2011 at 05:25:49PM +0200, Sander Steffann wrote:
The current policy doesn't permit the RIPE NCC to give out extra address space for an existing allocation until the HD ratio has been reached.
And this translates to "you have to support at least ~6.2 million customers with the /32 before being eligliable for more". Unfortunately, for shops that are living in the same order of magnitude size wise, this does not really translate to pretty and future-proof addressing concepts with polished internal aggregation on site and aggregation router levels, depending on how many sites and aggregation routers you have, what's your growth you need to account for in those numbers, and what's the variance of # of customers per aggregation router (leading to DHCPv6-PD pool sizing). Changing /48 to /56 as size-of-measurement is one problem, but raising the HD ratio from 0.8 to 0.94 was the killer. For us, it's the difference between a ~/22 (former) and a /32 (now). 10 bits less to design a scaling internal addressing plan without introducing kludges and/or having to largely re-shuffle large parts every couple of years. Another theoretical advantage of IPv6 compared to IPv4 practically (in part) down the drain. Good that we saved some scarce addresses. :-/ [no, I'm not advocating senseless waste - but what's "wasting" and "making use of a technology to realize improvements in operational cost" is probably very much in the eye of the beholder]
They are allowed to give more than a /32 when someone requests a new allocation though.
"the allocation size will be based on the number of existing users and the extent of the organisation's infrastructure." I wonder wether the HD ratio 0.94 rule will be the one this is being judged by. Abovementioned latter criteria is _very_ subjective. :-)
After reading the policies with this in mind I can only conclude that the RIPE NCC is implementing the policy correctly. If we want the NCC to do something else someone has to write a policy proposal.
I haven't heard anyone complaining about too small allocations with HD ratio 0.8 in effect. Perhaps the truth lies somewhere between 0.8 and 0.94. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Hi,
And this translates to "you have to support at least ~6.2 million customers with the /32 before being eligliable for more".
Well, ~5.9 million if you are giving all customers a /56. But if you are giving all customers a /56 you have 16 million /56's to use. That is a 37% usage of the block. It's already a lot better than the 80% rule in IPv4-space.
Changing /48 to /56 as size-of-measurement is one problem
What is the problem? If you hand out /56's to a customer you count '1 /56 assigned'. If you hand out a /48 to a customer you count '256 /56's assigned'. - Sander PS: I do agree with you that we should use the address space that IPv6 is providing
Daniel wrote:
[no, I'm not advocating senseless waste - but what's "wasting" and "making use of a technology to realize improvements in operational cost" is probably very much in the eye of the beholder]
I must agree here. If you do the math, you come up with "we do have enough addresses, even if we give any human on earth hundreds of /48" (and I hope nobody really wants to do). But as we are at the luxury point where saving address space isn't really that big issue, why shoud we make network design more difficult by introducing artificial obstacles that possible saves some addresse? From my point of view IPv6 address policy should focus on: a) making IPv6 easy deployable b) keeping the dfz table as small as possible without restrains to IPv6 deployment c) allowing clean network design even if that comes with the cost of a reasonable amount of additional address space usage Obviously, we also should keep in mind that the IPv6 space is huge but finite so we should make sure that we will not run low on address space at some point. To sum things up, I think the HD-Ratio of .94 is not what we want as it makes future deployment more difficult without any real reason. However, a mayor issue right now, where most ISPs are in the process to design and roll out IPv6 to their end-customers real soon, is that once they started to assign networks to very few customers some time ago, they cannot apply for an additional network without either lying to the NCC (about assignments to customers that have not been made yet) or create a crude design, then start rollout, stop rollout when addressspace is used, request additional addresses and then redesign the entire network (or be stuck with your crude design you came up with to work around the 'to few addresses to do a proper design' issue). So what we really need is to allow the NCC to make assignments based on reasonable guesses if the resulting prefix size (of both, the existing prefix(es) and the newly requested prefix) will be reasonable in HD-Ratio terms. Best regards, Immo Wehrenberg
Hi WG, Op 19 jul 2011, om 00:04 heeft Immo 'FaUl' Wehrenberg het volgende geschreven:
Daniel wrote:
[no, I'm not advocating senseless waste - but what's "wasting" and "making use of a technology to realize improvements in operational cost" is probably very much in the eye of the beholder]
I must agree here. If you do the math, you come up with "we do have enough addresses, even if we give any human on earth hundreds of /48" (and I hope nobody really wants to do). But as we are at the luxury point where saving address space isn't really that big issue, why shoud we make network design more difficult by introducing artificial obstacles that possible saves some addresse? From my point of view IPv6 address policy should focus on: a) making IPv6 easy deployable b) keeping the dfz table as small as possible without restrains to IPv6 deployment c) allowing clean network design even if that comes with the cost of a reasonable amount of additional address space usage
Obviously, we also should keep in mind that the IPv6 space is huge but finite so we should make sure that we will not run low on address space at some point.
To sum things up, I think the HD-Ratio of .94 is not what we want as it makes future deployment more difficult without any real reason.
I think Immo has given a good summary of what I heard on this list and from some people at the last RIPE meeting. Scott also brought this to our attention:
FYI, a number of folks had this same issue in the ARIN region, and as a result policy ARIN-2010-12 (https://www.arin.net/policy/proposals/2010_12.html) was proposed, adopted, and implemented to address the problem.
Considering the amount of messages here related to this subject I think we should start working towards a formal policy proposal. Jan Žorž has already started working on a related proposal (see his message a few minutes ago on this list) so I think it might be a good idea to start from there. Thanks, Sander
The RIPE currently reserves a /29 for every initial /32. So as long as there is a policy that allows expansion of the initial assignment based upon a sound network design there should not be any issue to bump it up to a bigger block. Jasper -----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Sander Steffann Sent: Monday, July 18, 2011 5:26 PM To: Ivan Pepelnjak Cc: 'Jan Zorz @ Go6.si'; 'Yannis Nikolopoulos'; ipv6-wg@ripe.net; address-policy-wg@ripe.net Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) Hi Ivan,
Let me try to understand:
(A) We don't disagree that he might actually deserve more than /32 (B) According to my understanding of previous discussions I had on this topic, RIPE might actually have already reserved extra space for his future needs (C) According to the current rules he can't get another /32 for a total of /31 without using most of the current /32 (and hoping his next /32 will be adjacent) (D) Someone is seriously suggesting he returns the current /32 and asks for a brand new /31 which he will likely get.
All correct. The current policy doesn't permit the RIPE NCC to give out extra address space for an existing allocation until the HD ratio has been reached. They are allowed to give more than a /32 when someone requests a new allocation though. I have had this same issue and I got the same answer. After reading the policies with this in mind I can only conclude that the RIPE NCC is implementing the policy correctly. If we want the NCC to do something else someone has to write a policy proposal. Thanks, Sander Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer
On 7/19/11 9:38 AM, Jasper Jans wrote:
The RIPE currently reserves a /29 for every initial /32. So as long as there is a policy that allows expansion of the initial assignment based upon a sound network design there should not be any issue to bump it up to a bigger block. Hi,
As presented, discussed and suggested at RIPE62 in Amsterdam, we are currently working on policy change proposal, that would rise the minimum IPv6 allocation size to /29 and automatically made of use that "reserved" /29 space for each legacy /32 allocation (that would almost never be used otherwise). Primary reason for that proposal was wasteful transition mechanisms (like 6RD...), but this change also solves some of issues, rised in this thread. Stay tuned :) Cheers, Jan Zorz Go6 Slovenia
Hello again, On 07/19/2011 10:56 AM, Jan Zorz @ go6.si wrote:
On 7/19/11 9:38 AM, Jasper Jans wrote:
The RIPE currently reserves a /29 for every initial /32. So as long as there is a policy that allows expansion of the initial assignment based upon a sound network design there should not be any issue to bump it up to a bigger block. Hi,
As presented, discussed and suggested at RIPE62 in Amsterdam, we are currently working on policy change proposal, that would rise the minimum IPv6 allocation size to /29 and automatically made of use that "reserved" /29 space for each legacy /32 allocation (that would almost never be used otherwise).
would this mean that all LIRs that got an initial /32 will get "upgraded" to a /29 ? If not, it doesn't really solve the issue at hand. cheers, Yannis
Primary reason for that proposal was wasteful transition mechanisms (like 6RD...), but this change also solves some of issues, rised in this thread.
Stay tuned :)
Cheers, Jan Zorz Go6 Slovenia
Hi,
would this mean that all LIRs that got an initial /32 will get "upgraded" to a /29 ? If not, it doesn't really solve the issue at hand.
That is the idea :) Sander
On 07/19/2011 11:47 AM, Sander Steffann wrote:
Hi,
would this mean that all LIRs that got an initial /32 will get "upgraded" to a /29 ? If not, it doesn't really solve the issue at hand. That is the idea :) Sander ok, great :)
On 7/19/11 10:43 AM, Yannis Nikolopoulos wrote:
would this mean that all LIRs that got an initial /32 will get "upgraded" to a /29 ?
Yes. Jan
Good :-) G/ -----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Jan Zorz @ go6.si Sent: 19 July 2011 09:57 To: ipv6-wg@ripe.net; address-policy-wg@ripe.net Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) On 7/19/11 9:38 AM, Jasper Jans wrote:
The RIPE currently reserves a /29 for every initial /32. So as long as there is a policy that allows expansion of the initial assignment based upon a sound network design there should not be any issue to bump it up to a bigger block. Hi,
As presented, discussed and suggested at RIPE62 in Amsterdam, we are currently working on policy change proposal, that would rise the minimum IPv6 allocation size to /29 and automatically made of use that "reserved" /29 space for each legacy /32 allocation (that would almost never be used otherwise). Primary reason for that proposal was wasteful transition mechanisms (like 6RD...), but this change also solves some of issues, rised in this thread. Stay tuned :) Cheers, Jan Zorz Go6 Slovenia
Hallo Jan, du schrobst:
On 7/19/11 9:38 AM, Jasper Jans wrote:
The RIPE currently reserves a /29 for every initial /32. So as long as there is a policy that allows expansion of the initial assignment based upon a sound network design there should not be any issue to bump it up to a bigger block. Hi,
As presented, discussed and suggested at RIPE62 in Amsterdam, we are currently working on policy change proposal, that would rise the minimum IPv6 allocation size to /29 and automatically made of use that "reserved" /29 space for each legacy /32 allocation (that would almost never be used otherwise).
Primary reason for that proposal was wasteful transition mechanisms (like 6RD...), but this change also solves some of issues, rised in this thread.
For me that sounds like this is curing symptoms snstead of the real cause. I would suggest to add a clause that a) NCC can hand out new allocations if the addressing plan for the new addresses is sound and b) that simplifying administrational causes should also be an valid reason for address need (such as wastful transition mechanisms like 6rd or assigning /36 per pop eventhough not all pops have more then 2048 /48 to be assigned but for the sake of a clear network design). We do have enough addresses and we will not get short on them any time if we don't to something incredibly stupid So lets not create artifical obstacles. IPv6 is designed to allow that. Don't give that benefit away by some IPv4-we-don't-have-enough-addresses-and-must-save-addresses-at-all-costs habbits. In IPv6 thats just not necessary anymore, there are enough addresses and making things complicated in order to save addresses is just not reasonable! regards, Immo
On 7/20/11 12:37 PM, Immo 'FaUl' Wehrenberg wrote:
For me that sounds like this is curing symptoms snstead of the real cause. I would suggest to add a clause that a) NCC can hand out new allocations if the addressing plan for the new addresses is sound and b) that simplifying administrational causes should also be an valid reason for address need (such as wastful transition mechanisms like 6rd or assigning /36 per pop eventhough not all pops have more then 2048 /48 to be assigned but for the sake of a clear network design).
With rising smallest initial alloc /29 we do not "cure" this problem, we just make it a bit smaller :) But let's discuss that when we publish the policy change proposal.
We do have enough addresses and we will not get short on them any time if we don't to something incredibly stupid So lets not create artifical obstacles. IPv6 is designed to allow that. Don't give that benefit away by some IPv4-we-don't-have-enough-addresses-and-must-save-addresses-at-all-costs habbits. In IPv6 thats just not necessary anymore, there are enough addresses and making things complicated in order to save addresses is just not reasonable!
talking to convinced. /jan
I think we will keep having having these issues until the minimum subnet assignment (outside point to point links) can be smaller than /64 which is an astronomical waste of public addresses for a home or business assignment. This may be too late to fix for the current block of globally routable addresses, but minimum subnet size is worth reconsidering by the IETF for the future blocks. -Ahmed -------------------------------------------------- From: "Jasper Jans" <Jasper.Jans@espritxb.nl> Sent: Tuesday, July 19, 2011 10:38 AM To: "Sander Steffann" <sander@steffann.nl>; "Ivan Pepelnjak" <ip@ioshints.info> Cc: "'Jan Zorz @ Go6.si'" <jan@go6.si>; "'Yannis Nikolopoulos'" <dez@otenet.gr>; <ipv6-wg@ripe.net>; <address-policy-wg@ripe.net> Subject: RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues)
The RIPE currently reserves a /29 for every initial /32. So as long as there is a policy that allows expansion of the initial assignment based upon a sound network design there should not be any issue to bump it up to a bigger block.
Jasper
-----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Sander Steffann Sent: Monday, July 18, 2011 5:26 PM To: Ivan Pepelnjak Cc: 'Jan Zorz @ Go6.si'; 'Yannis Nikolopoulos'; ipv6-wg@ripe.net; address-policy-wg@ripe.net Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues)
Hi Ivan,
Let me try to understand:
(A) We don't disagree that he might actually deserve more than /32 (B) According to my understanding of previous discussions I had on this topic, RIPE might actually have already reserved extra space for his future needs (C) According to the current rules he can't get another /32 for a total of /31 without using most of the current /32 (and hoping his next /32 will be adjacent) (D) Someone is seriously suggesting he returns the current /32 and asks for a brand new /31 which he will likely get.
All correct. The current policy doesn't permit the RIPE NCC to give out extra address space for an existing allocation until the HD ratio has been reached. They are allowed to give more than a /32 when someone requests a new allocation though. I have had this same issue and I got the same answer.
After reading the policies with this in mind I can only conclude that the RIPE NCC is implementing the policy correctly. If we want the NCC to do something else someone has to write a policy proposal.
Thanks, Sander
Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer
The RIPE currently reserves a /29 for every initial /32. So as long as there is a policy that allows expansion of the initial assignment based upon a sound network design there should not be any issue to bump it up to a bigger block.
Jasper
-----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Sander Steffann Sent: Monday, July 18, 2011 5:26 PM To: Ivan Pepelnjak Cc: 'Jan Zorz @ Go6.si'; 'Yannis Nikolopoulos'; ipv6-wg@ripe.net; address-policy-wg@ripe.net Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues)
Hi Ivan,
Let me try to understand:
(A) We don't disagree that he might actually deserve more than /32 (B) According to my understanding of previous discussions I had on
You want to change how IPv6 SLAAC works? And ND? G/ -----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Ahmed Abu-Abed Sent: 19 July 2011 11:16 To: RIPE IPv6 Cc: address-policy-wg@ripe.net Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) I think we will keep having having these issues until the minimum subnet assignment (outside point to point links) can be smaller than /64 which is an astronomical waste of public addresses for a home or business assignment. This may be too late to fix for the current block of globally routable addresses, but minimum subnet size is worth reconsidering by the IETF for the future blocks. -Ahmed -------------------------------------------------- From: "Jasper Jans" <Jasper.Jans@espritxb.nl> Sent: Tuesday, July 19, 2011 10:38 AM To: "Sander Steffann" <sander@steffann.nl>; "Ivan Pepelnjak" <ip@ioshints.info> Cc: "'Jan Zorz @ Go6.si'" <jan@go6.si>; "'Yannis Nikolopoulos'" <dez@otenet.gr>; <ipv6-wg@ripe.net>; <address-policy-wg@ripe.net> Subject: RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) this
topic, RIPE might actually have already reserved extra space for his future needs (C) According to the current rules he can't get another /32 for a total of /31 without using most of the current /32 (and hoping his next /32
will be adjacent) (D) Someone is seriously suggesting he returns the current /32 and asks for a brand new /31 which he will likely get.
All correct. The current policy doesn't permit the RIPE NCC to give out extra address space for an existing allocation until the HD ratio has been reached. They are allowed to give more than a /32 when someone requests a new allocation though. I have had this same issue and I got the same answer.
After reading the policies with this in mind I can only conclude that the RIPE NCC is implementing the policy correctly. If we want the NCC to do something else someone has to write a policy proposal.
Thanks, Sander
Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer
The RIPE currently reserves a /29 for every initial /32. So as long as there is a policy that allows expansion of the initial assignment based upon a sound network design there should not be any issue to bump it up to a bigger block.
Jasper
-----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Sander Steffann Sent: Monday, July 18, 2011 5:26 PM To: Ivan Pepelnjak Cc: 'Jan Zorz @ Go6.si'; 'Yannis Nikolopoulos'; ipv6-wg@ripe.net; address-policy-wg@ripe.net Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues)
Hi Ivan,
Let me try to understand:
(A) We don't disagree that he might actually deserve more than /32 (B) According to my understanding of previous discussions I had on
Some years ago... in other mail like this... "You want to change how IPv4 routing works? And RIP? http://tools.ietf.org/html/rfc4632 ;-) kix "Gunter Van de Velde (gvandeve)" Para <gvandeve@cisc "Ahmed Abu-Abed" o.com> <ahmed@tamkien.com>, "RIPE Enviado por: IPv6" <ipv6-wg@ripe.net> ipv6-wg-admin@ cc ripe.net <address-policy-wg@ripe.net> Asunto RE: [ipv6-wg] additional IPv6 19/07/2011 allocation (ripe-512 issues) 11:29 Clasificación You want to change how IPv6 SLAAC works? And ND? G/ -----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Ahmed Abu-Abed Sent: 19 July 2011 11:16 To: RIPE IPv6 Cc: address-policy-wg@ripe.net Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) I think we will keep having having these issues until the minimum subnet assignment (outside point to point links) can be smaller than /64 which is an astronomical waste of public addresses for a home or business assignment. This may be too late to fix for the current block of globally routable addresses, but minimum subnet size is worth reconsidering by the IETF for the future blocks. -Ahmed -------------------------------------------------- From: "Jasper Jans" <Jasper.Jans@espritxb.nl> Sent: Tuesday, July 19, 2011 10:38 AM To: "Sander Steffann" <sander@steffann.nl>; "Ivan Pepelnjak" <ip@ioshints.info> Cc: "'Jan Zorz @ Go6.si'" <jan@go6.si>; "'Yannis Nikolopoulos'" <dez@otenet.gr>; <ipv6-wg@ripe.net>; <address-policy-wg@ripe.net> Subject: RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) this
topic, RIPE might actually have already reserved extra space for his future needs (C) According to the current rules he can't get another /32 for a total of /31 without using most of the current /32 (and hoping his next /32
will be adjacent) (D) Someone is seriously suggesting he returns the current /32 and asks for a brand new /31 which he will likely get.
All correct. The current policy doesn't permit the RIPE NCC to give out extra address space for an existing allocation until the HD ratio has been reached. They are allowed to give more than a /32 when someone requests a new allocation though. I have had this same issue and I got the same answer.
After reading the policies with this in mind I can only conclude that the RIPE NCC is implementing the policy correctly. If we want the NCC to do something else someone has to write a policy proposal.
Thanks, Sander
Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer
_____________________________________________________________________ Mensaje analizado y protegido por Telefonica Grandes Clientes
On 19 July 2011 10:42, <rodolfo.garciapenas@telefonica.es> wrote:
Some years ago... in other mail like this... "You want to change how IPv4 routing works? And RIP?
That's fine but thats not a function of RIPE but rather 'other places' J -- James Blessing 07989 039 476
Hi,
Some years ago... in other mail like this... "You want to change how IPv4 routing works? And RIP?
That's fine but thats not a function of RIPE but rather 'other places'
The RIPE IPv6 WG (ipv6-wg@ripe.net) has volunteered for continuing this discussion :-) Sander
On 7/19/11 11:16 AM, Ahmed Abu-Abed wrote:
I think we will keep having having these issues until the minimum subnet assignment (outside point to point links) can be smaller than /64 which is an astronomical waste of public addresses for a home or business assignment.
Maybe it's me, but I really don't understand what are you talking about. Can you please elaborate a bit on this? Cheers, Jan
Hi,
On 7/19/11 11:16 AM, Ahmed Abu-Abed wrote:
I think we will keep having having these issues until the minimum subnet assignment (outside point to point links) can be smaller than /64 which is an astronomical waste of public addresses for a home or business assignment.
Maybe it's me, but I really don't understand what are you talking about. Can you please elaborate a bit on this?
Please take this off-list as this is out of scope for RIPE. Thanks :) Sander
Jasper wrote: The RIPE currently reserves a /29 for every initial /32. So as long as there is a policy that allows expansion of the initial assignment based upon a sound network design there should not be any issue to bump it up to a bigger block. GV> An issue I see with this policy is that it does not support pro-active address planning for the longer term and may end up in fragmented non-summarizable address space within an organization. Mainly because the newly required address space will be different block and will as result require new address planning policy within the organization itself. G/
Hi Gunter,
GV> An issue I see with this policy is that it does not support pro-active address planning for the longer term and may end up in fragmented non-summarizable address space within an organization. Mainly because the newly required address space will be different block and will as result require new address planning policy within the organization itself.
I don't understand your comment. The idea of the policy proposal is to automatically grow the existing /32 to a /29. That results in a single /29 for an ISP. - Sander
Inline: GV> -----Original Message----- From: Sander Steffann [mailto:sander@steffann.nl] Sent: 19 July 2011 11:33 To: Gunter Van de Velde (gvandeve) Cc: Jasper Jans; Ivan Pepelnjak; Jan Zorz @ Go6.si; Yannis Nikolopoulos; ipv6-wg@ripe.net; address-policy-wg@ripe.net Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) Hi Gunter,
GV> An issue I see with this policy is that it does not support pro-active address planning for the longer term and may end up in fragmented non-summarizable address space within an organization. Mainly because the newly required address space will be different block and will as result require new address planning policy within the organization itself.
I don't understand your comment. The idea of the policy proposal is to automatically grow the existing /32 to a /29. That results in a single /29 for an ISP. GV> That would be perfect.. I was just reading the comments sequentially... and just assumed that when an ISP gets through the HD ratio stuff on his first /32, that he will gets the neighbor /32. In that case the ISP needs to make a new address plan policy, which would not be as clean as if he would have had a /31 to start off with. With the /29 there would be no issue at all on this matter. G/
On 7/19/11 11:36 AM, Gunter Van de Velde (gvandeve) wrote:
GV> That would be perfect.. I was just reading the comments sequentially... and just assumed that when an ISP gets through the HD ratio stuff on his first /32, that he will gets the neighbor /32. In that case the ISP needs to make a new address plan policy, which would not be as clean as if he would have had a /31 to start off with. With the /29 there would be no issue at all on this matter.
I suspect many LIRs got their /32 just because they could get the allocation and in reality did not have a clue what they really need for deployment and are now stuck with HD ratio. Question for RIPE-NCC staff: do we have any data or estimation/approximation, how many LIRs wanted additional alloc because of this reason and got it with trade? How many are asking for it? Would /29 cover majority of this "trades"? Are there any clueless LIRs, that got /32, but today with presenting real data they would get more than /29? We need some statistics here, if possible. Cheers, Jan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jan, Jan Zorz @ go6.si wrote:
On 7/19/11 11:36 AM, Gunter Van de Velde (gvandeve) wrote:
GV> That would be perfect.. I was just reading the comments sequentially... and just assumed that when an ISP gets through the HD ratio stuff on his first /32, that he will gets the neighbor /32. In that case the ISP needs to make a new address plan policy, which would not be as clean as if he would have had a /31 to start off with. With the /29 there would be no issue at all on this matter.
I suspect many LIRs got their /32 just because they could get the allocation and in reality did not have a clue what they really need for deployment and are now stuck with HD ratio.
Question for RIPE-NCC staff: do we have any data or estimation/approximation, how many LIRs wanted additional alloc because of this reason and got it with trade?
1 LIR has been able to justify an expansion of their initial /32 (back in 2004). 15 LIRs gave back their initially requested /32 in exchange for a larger allocation. Furthermore 23 LIRs got a first allocation larger than /32.
How many are asking for it?
Just a handful.
Would /29 cover majority of this "trades"?
Out of the 15 cases mentioned above only 1 would have fitted in a /29. All the other allocation were much larger.
Are there any clueless LIRs, that got /32, but today with presenting real data they would get more than /29?
We can not see how many LIRs would now get a larger allocation as it depends on data that we do not have (assignment size - /48 or /64?, number of customers, growth etc). However when we receive a /32 allocation request, and it's clear that the LIR will need more than a /32 based on the information they provide, we advise the LIR about the fact that the requested amount may not be covering their current needs. I hope this helps Best regards Andrea Cima RIPE NCC
We need some statistics here, if possible.
Cheers, Jan
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAk4lk0kACgkQXOgsmPkFrjPGXgCfdCviOSBkfjxWV/lFZYKpjDlf R2QAoJLHylcsqAgKqNV7EVS/TwacKlI9 =Mu0L -----END PGP SIGNATURE-----
On 7/19/11 4:23 PM, Andrea Cima wrote:
Would /29 cover majority of this "trades"?
Out of the 15 cases mentioned above only 1 would have fitted in a /29. All the other allocation were much larger.
Andrea, hi Thnx for the data. This one is interesting, but still not sure what it says to us. <Presumption> From my understanding, I would say that those who are really big and got /32 initial alloc goes and make an effort to trade-in /32 and "fight" for something big. It's a matter of "is it worth the effort?" decision - and get something larger than /29 Is it worth the effort for /31 or /30? Or they rather call the wizards to fit their networking plans into /32 and use HD ratio later? </Presumption> My question is, do we fix some/any of this guys with /29 min. alloc.?
Are there any clueless LIRs, that got /32, but today with presenting real data they would get more than /29?
We can not see how many LIRs would now get a larger allocation as it depends on data that we do not have (assignment size - /48 or /64?, number of customers, growth etc). However when we receive a /32 allocation request, and it's clear that the LIR will need more than a /32 based on the information they provide, we advise the LIR about the fact that the requested amount may not be covering their current needs.
So, you look into IPv4 data to determine the size of LIR? Thnx for info, very usefull. Cheers, Jan Zorz
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jan, Jan Zorz @ go6.si wrote:
On 7/19/11 4:23 PM, Andrea Cima wrote:
Would /29 cover majority of this "trades"?
Out of the 15 cases mentioned above only 1 would have fitted in a /29. All the other allocation were much larger.
Andrea, hi
Thnx for the data. This one is interesting, but still not sure what it says to us.
<Presumption> From my understanding, I would say that those who are really big and got /32 initial alloc goes and make an effort to trade-in /32 and "fight" for something big. It's a matter of "is it worth the effort?" decision - and get something larger than /29
Is it worth the effort for /31 or /30? Or they rather call the wizards to fit their networking plans into /32 and use HD ratio later? </Presumption>
My question is, do we fix some/any of this guys with /29 min. alloc.?
According to our experience only LIRs that needed a block much larger than /29 found it worth the effort to return their /32. Best regards, Andrea Cima RIPE NCC
Are there any clueless LIRs, that got /32, but today with presenting real data they would get more than /29?
We can not see how many LIRs would now get a larger allocation as it depends on data that we do not have (assignment size - /48 or /64?, number of customers, growth etc). However when we receive a /32 allocation request, and it's clear that the LIR will need more than a /32 based on the information they provide, we advise the LIR about the fact that the requested amount may not be covering their current needs.
So, you look into IPv4 data to determine the size of LIR?
Thnx for info, very usefull.
Cheers, Jan Zorz
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAk4m0+EACgkQXOgsmPkFrjOgswCgn/eC9fQWxWQ2izaD/jymUYyL 9ZoAniUUcCpGEJe2qE/AXodaOJnAJcDO =gdu7 -----END PGP SIGNATURE-----
Hi Andrea, Your wrote:
According to our experience only LIRs that needed a block much larger than /29 found it worth the effort to return their /32.
I don't know how I should understand you statement. Should I take it to mean that the policy is impeding LIRs who would otherwise qualify for larger allocations from getting them because they will have to renumber their whole network? Or something else? Thanks, Leo Vegoda
On 7/20/11 6:30 PM, Leo Vegoda wrote:
Hi Andrea,
Your wrote:
According to our experience only LIRs that needed a block much larger than /29 found it worth the effort to return their /32.
I don't know how I should understand you statement. Should I take it to mean that the policy is impeding LIRs who would otherwise qualify for larger allocations from getting them because they will have to renumber their whole network? Or something else?
Idea... If you are LIR that had no clue and got /32 but now when you know that you need more and can justify that, you could ask RIPE-NCC IPRA to get back your original /32, start looking into your justification under initial alloc policy and if you justify for anything up to (including) /29, IPRA allocates you justified block starting exactly where "returned" /32 started. Problem solved, no need to renumber. Do we need to put this into policy (if accepted) or would BCP work (as this can be best current practice :) )? Cheers, Jan Zorz
On 7/20/11 6:49 PM, Jan Zorz @ go6.si wrote:
Idea...
If you are LIR that had no clue and got /32 but now when you know that you need more and can justify that, you could ask RIPE-NCC IPRA to get back your original /32, start looking into your justification under initial alloc policy and if you justify for anything up to (including) /29, IPRA allocates you justified block starting exactly where "returned" /32 started.
Problem solved, no need to renumber.
Do we need to put this into policy (if accepted) or would BCP work (as this can be best current practice :) )? ...of course if /29 minimum initial allocation policy proposal change fails... (forgot to mention).
jan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Leo, Leo Vegoda wrote:
Hi Andrea,
Your wrote:
According to our experience only LIRs that needed a block much larger than /29 found it worth the effort to return their /32.
I don't know how I should understand you statement. Should I take it to mean that the policy is impeding LIRs who would otherwise qualify for larger allocations from getting them because they will have to renumber their whole network? Or something else?
There are a number of LIRs who received a /32 in the past who later realise that they might have qualified for a larger initial allocation. We allow these LIRs to return their /32 and then evaluate their request based on the data they submit. In the case that these LIRs do not want to return that /32, the normal IPv6 additional allocation policy applies and we will allocate them more space if and when they qualify under that policy. In practice this means that their existing /32 has to be used up to the HD-ratio. We presented this at RIPE 62 in the 'Feedback from RIPE NCC Registration Services'. http://ripe62.ripe.net/programme/meeting-plan/address-policy Best regards, Andrea Cima RIPE NCC
Thanks,
Leo Vegoda
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAk4oE8oACgkQXOgsmPkFrjNhKACfW/hAMDns051ma1PQPyWnLHIF jgEAn1MFUD0I1HBPJztZ63OWDimcuwNV =+Zrx -----END PGP SIGNATURE-----
Hi Andrea, [...]
According to our experience only LIRs that needed a block much larger than /29 found it worth the effort to return their /32.
I don't know how I should understand you statement. Should I take it to mean that the policy is impeding LIRs who would otherwise qualify for larger allocations from getting them because they will have to renumber their whole network? Or something else?
There are a number of LIRs who received a /32 in the past who later realise that they might have qualified for a larger initial allocation. We allow these LIRs to return their /32 and then evaluate their request based on the data they submit.
In the event that the LIR plans to qualify for an allocation that will fit inside the /29 you have reserved for them, do you allow them to receive a block from the same /29? That is, do you allow them to do the "return and new initial allocation" as a book keeping exercise or will they normally need to renumber? Thanks, Leo
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Leo, Leo Vegoda wrote:
Hi Andrea,
[...]
According to our experience only LIRs that needed a block much larger than /29 found it worth the effort to return their /32. I don't know how I should understand you statement. Should I take it to mean that the policy is impeding LIRs who would otherwise qualify for larger allocations from getting them because they will have to renumber their whole network? Or something else? There are a number of LIRs who received a /32 in the past who later realise that they might have qualified for a larger initial allocation. We allow these LIRs to return their /32 and then evaluate their request based on the data they submit.
In the event that the LIR plans to qualify for an allocation that will fit inside the /29 you have reserved for them, do you allow them to receive a block from the same /29? That is, do you allow them to do the "return and new initial allocation" as a book keeping exercise or will they normally need to renumber?
We treat "return and new initial allocation" the same as a normal initial allocation request. This includes, as with all initial allocation requests, reserving space for future growth, in the past by reserving three bits and currently using the binary chop algorithm. Simply expanding an LIR's current allocation would constitute an additional allocation and would follow the established additional allocation policy and procedure and would require the LIR to demonstrate that they have utilised their current allocation up to the threshold defined by the HD-ratio. Should it turn out that an LIR who received a /32 since the implementation of the binary chop algorithm would have qualified for a larger allocation, we could consider allocating the "new" larger block overlapping with their /32. However, most of these "return and new initial allocation" cases concern relatively old /32 allocations so we do not expect to have to do this very often, if at all. Best regards, Andrea Cima RIPE NCC
Thanks,
Leo
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAk4paxoACgkQXOgsmPkFrjP0BQCcDIbhGhqIr6O2UiGhpQ+tUiTs TRYAn3dWTKCkuPU6T0ORQyVg2L9LRd5L =z6MP -----END PGP SIGNATURE-----
Hi,
GV> That would be perfect.. I was just reading the comments sequentially... and just assumed that when an ISP gets through the HD ratio stuff on his first /32, that he will gets the neighbor /32. In that case the ISP needs to make a new address plan policy, which would not be as clean as if he would have had a /31 to start off with. With the /29 there would be no issue at all on this matter.
That is what is happening now. A proposal for changing this is on the way :) Sander
On Jul 18, 2011, at 9:38 PM, Jasper Jans wrote:
The RIPE currently reserves a /29 for every initial /32.
Is this really true? When the RIRs and IANA were discussing the /12 allocations, the RIRs claimed one of the reasons they needed /12s was because they would all be using the "bisection method" of allocation to remove the need for reservation. It would be sad to hear RIPE still hadn't followed through. Regards, -drc
On 7/19/11 7:55 PM, David Conrad wrote:
On Jul 18, 2011, at 9:38 PM, Jasper Jans wrote:
The RIPE currently reserves a /29 for every initial /32.
Is this really true?
Well, from my source of information - yes (for legacy allocations).
When the RIRs and IANA were discussing the /12 allocations, the RIRs claimed one of the reasons they needed /12s was because they would all be using the "bisection method" of allocation to remove the need for reservation. It would be sad to hear RIPE still hadn't followed through.
Again, from my source, since some months or maybe a year, RIPE-NCC allocates IPv6 on "bit-boundry" (or bisection) method, so reservation is not needed anymore. But legacy allocations made us think of /29 :) /jan
Dear Colleagues,
When the RIRs and IANA were discussing the /12 allocations, the RIRs claimed one of the reasons they needed /12s was because they would all be using the "bisection method" of allocation to remove the need for reservation. It would be sad to hear RIPE still hadn't followed through.
Again, from my source, since some months or maybe a year, RIPE-NCC allocates IPv6 on "bit-boundry" (or bisection) method, so reservation is not needed anymore. But legacy allocations made us think of /29 :)
For a long time, the RIPE NCC's internal IP address management system would not easily allow us to implement the binary chop algorithm and we made each IPv6 allocation inside a reservation that was three bits larger than the allocation itself, ie. a /32 allocation inside a /29 reservation. In December 2010 we deployed a new system and since then we have been allocating IPv6 using the binary chop algorithm: ripencc|DE|ipv6|2a03:4000::|32|20101202|allocated ripencc|NL|ipv6|2a03:4800::|32|20101215|allocated ripencc|DE|ipv6|2a03:5000::|32|20101207|allocated ripencc|RU|ipv6|2a03:5800::|32|20101215|allocated ripencc|NL|ipv6|2a03:6000::|32|20101202|allocated ripencc|IT|ipv6|2a03:6800::|32|20101215|allocated Eventually, the algorithm will begin allocating in the middle of these available blocks, for example 2a03:4400::/32, 2a03:4c00::/32, etc. Best regards, Alex Le Heux RIPE NCC
Hi, On Tue, Jul 19, 2011 at 07:55:20AM -1000, David Conrad wrote:
On Jul 18, 2011, at 9:38 PM, Jasper Jans wrote:
The RIPE currently reserves a /29 for every initial /32.
Is this really true? When the RIRs and IANA were discussing the /12 allocations, the RIRs claimed one of the reasons they needed /12s was because they would all be using the "bisection method" of allocation to remove the need for reservation.
Well, how memories change. I seem to remember that I lobbied for /12s (or bigger) because allocations of one-/23-at-a-time were just a stupid and human life-time wasting way to handle things... ("The IPv4 Way"). gert -- have you enabled 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
On Jul 19, 2011, at 9:26 AM, Gert Doering wrote:
On Tue, Jul 19, 2011 at 07:55:20AM -1000, David Conrad wrote:
On Jul 18, 2011, at 9:38 PM, Jasper Jans wrote:
The RIPE currently reserves a /29 for every initial /32.
Is this really true? When the RIRs and IANA were discussing the /12 allocations, the RIRs claimed one of the reasons they needed /12s was because they would all be using the "bisection method" of allocation to remove the need for reservation.
Well, how memories change.
?
I seem to remember that I lobbied for /12s (or bigger) because allocations of one-/23-at-a-time were just a stupid and human life-time wasting way to handle things... ("The IPv4 Way").
"One of the reasons". Regards, -drc
Download the "delegated-ripencc-extended-*" file from http://albatross.ripe.net/delegated-extended/ cat delegated-ripencc-extended-20110718 | grep ipv6 | cut -d\| -f4,5,7 | sort | more *|19392 2001:1400::|32|allocated 2001:1401::|32|available 2001:1402::|31|available 2001:1404::|30|available 2001:1408::|32|allocated 2001:1409::|32|available 2001:140a::|31|available 2001:140c::|30|available 2001:1410::|32|allocated 2001:1411::|32|available 2001:1412::|31|available 2001:1414::|30|available 2001:1418::|32|allocated 2001:1419::|32|available 2001:141a::|31|available 2001:141c::|30|available 2001:1420::|32|allocated kix David Conrad <drc@virtualiz ed.org> Para Enviado por: Jasper Jans ipv6-wg-admin@ <Jasper.Jans@espritxb.nl> ripe.net cc ipv6-wg@ripe.net, "address-policy-wg@ripe.net 20/07/2011 Working Group" 10:09 <address-policy-wg@ripe.net> Asunto Re: [address-policy-wg] RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) Clasificación On Jul 18, 2011, at 9:38 PM, Jasper Jans wrote:
The RIPE currently reserves a /29 for every initial /32.
Is this really true? When the RIRs and IANA were discussing the /12 allocations, the RIRs claimed one of the reasons they needed /12s was because they would all be using the "bisection method" of allocation to remove the need for reservation. It would be sad to hear RIPE still hadn't followed through. Regards, -drc _____________________________________________________________________ Mensaje analizado y protegido por Telefonica Grandes Clientes
It looks like RIPE NCC does the same thing (assigning 1 block and "reserving" the next three) with IPv6 PI blocks: ripencc|CZ|ipv6|2001:67c:22d0::|48|20110531|assigned ripencc|EU|ipv6|2001:67c:22d4::|48|20110531|assigned ripencc|SI|ipv6|2001:67c:22d8::|48|20110601|assigned ripencc|NL|ipv6|2001:67c:22dc::|48|20110601|assigned Best regards, Paul Hoogsteder Breedband Delft/Meanie
Download the "delegated-ripencc-extended-*" file from http://albatross.ripe.net/delegated-extended/
cat delegated-ripencc-extended-20110718 | grep ipv6 | cut -d\| -f4,5,7 | sort | more *|19392 2001:1400::|32|allocated 2001:1401::|32|available 2001:1402::|31|available 2001:1404::|30|available 2001:1408::|32|allocated 2001:1409::|32|available 2001:140a::|31|available 2001:140c::|30|available 2001:1410::|32|allocated 2001:1411::|32|available 2001:1412::|31|available 2001:1414::|30|available 2001:1418::|32|allocated 2001:1419::|32|available 2001:141a::|31|available 2001:141c::|30|available 2001:1420::|32|allocated
kix
David Conrad <drc@virtualiz ed.org> Para Enviado por: Jasper Jans ipv6-wg-admin@ <Jasper.Jans@espritxb.nl> ripe.net cc ipv6-wg@ripe.net, "address-policy-wg@ripe.net 20/07/2011 Working Group" 10:09 <address-policy-wg@ripe.net> Asunto Re: [address-policy-wg] RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) Clasificación
On Jul 18, 2011, at 9:38 PM, Jasper Jans wrote:
The RIPE currently reserves a /29 for every initial /32.
Is this really true? When the RIRs and IANA were discussing the /12 allocations, the RIRs claimed one of the reasons they needed /12s was because they would all be using the "bisection method" of allocation to remove the need for reservation. It would be sad to hear RIPE still hadn't followed through.
Regards, -drc
_____________________________________________________________________ Mensaje analizado y protegido por Telefonica Grandes Clientes
Hi, My understanding based on conversations with RIPE NCC is slightly different. The initial allocation is made based purely on number of subscribers, and does not take HD ratio into account. (I argued this extensively when applying for our initial allocation). This is more restrictive than the policies for obtaining an additional allocation. Bran.
Hi Ivan,
Let me try to understand:
(A) We don't disagree that he might actually deserve more than /32 (B) According to my understanding of previous discussions I had on this topic, RIPE might actually have already reserved extra space >for his future needs (C) According to the current rules he can't get another /32 for a total of /31 without using most of the current /32 (and hoping his >next /32 will be adjacent) (D) Someone is seriously suggesting he returns the current /32 and asks for a brand new /31 which he will likely get.
All correct. The current policy doesn't permit the RIPE NCC to give out extra address space for an existing allocation until the HD ratio >has been reached. They are allowed to give more than a /32 when someone requests a new allocation though. I have had this same issue and >I got the same answer.
After reading the policies with this in mind I can only conclude that the RIPE NCC is implementing the policy correctly. If we want the >NCC to do something else someone has to write a policy proposal.
Thanks, Sander
-- Brandon Daly Network Engineer, Zen Internet T: 0845 058 9030 F: 0845 058 9005 W: www.zen.co.uk Visit our new and improved Help & Support site - www.zen.co.uk/support A wealth of information from updating your contact details or tracking the status of your order to setting up a wireless network or configuring email accounts. This message is private and confidential. If you have received this message in error, please notify us and remove it from your system. Zen Internet Limited may monitor email traffic data and also the content of email for the purposes of security. Zen Internet Limited is registered in England and Wales, Sandbrook Park, Sandbrook Way, Rochdale, OL11 1RY Company No. 03101568 VAT Reg No. 686 0495 01
participants (20)
-
Ahmed Abu-Abed -
Alex Le Heux -
Andrea Cima -
boggits -
Brandon Daly -
Daniel Roesen -
David Conrad -
Gert Doering -
Gunter Van de Velde (gvandeve) -
Immo 'FaUl' Wehrenberg -
Immo 'FaUl' Wehrenberg -
Ivan Pepelnjak -
Jan Zorz ＠ go6.si -
Jasper Jans -
Leo Vegoda -
Paul Hoogsteder -
rodolfo.garciapenas＠telefonica.es -
Sander Steffann -
Scott Leibrand -
Yannis Nikolopoulos