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
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
On 7/19/11 11:25 AM, Gunter Van de Velde (gvandeve) wrote:
You want to change how IPv6 SLAAC works? And ND?
that was my first thought also, but this can't be the idea that Ahmed proposed, it's a bit too far from reality :) Cheers, Jan
Currently the smallest network of physical devices (a home user's subnet) gets the largest block of addresses (/64 in size) from the LIR. There is a logic issue here. Thus we get the need for larger LIR IPv6 allocations. And dependencies on /64 subnets go beyond SLAAC and ND. If/when RIPE has a say on what happens beyond 2000::/3, where /64 subnets are required, then we can come up with ideas on smallest subnet size. Hardware should be sophisticated enough by then to handle such practical needs in case bit alignment is an issue. -Ahmed -------------------------------------------------- From: "Jan Zorz @ go6.si" <jan@go6.si> Sent: Tuesday, July 19, 2011 12:32 PM To: <ipv6-wg@ripe.net> Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues)
On 7/19/11 11:25 AM, Gunter Van de Velde (gvandeve) wrote:
You want to change how IPv6 SLAAC works? And ND?
that was my first thought also, but this can't be the idea that Ahmed proposed, it's a bit too far from reality :)
Cheers, Jan
On 7/19/11 1:10 PM, Ahmed Abu-Abed wrote:
Currently the smallest network of physical devices (a home user's subnet) gets the largest block of addresses (/64 in size) from the LIR. There is a logic issue here.
Thus we get the need for larger LIR IPv6 allocations. And dependencies on /64 subnets go beyond SLAAC and ND.
If/when RIPE has a say on what happens beyond 2000::/3, where /64 subnets are required, then we can come up with ideas on smallest subnet size. Hardware should be sophisticated enough by then to handle such practical needs in case bit alignment is an issue.
Please, stop here. Do not go any further. We are taking all possible measures to discourage development and deployment of devices and mechanisms that would enable use of prefixes shorter than /64 in one link-layer network. For example with initial /32 you could deploy 6RD in one 6RD domain, but would give to user only one /64. In this case sooner or later the need will emerge to develop something that magically enables you to split /64 to more subnets and actually use that. This is all about adding another layer of complexity and indirection to already messy world. That's one of reasons we are discouraging assignments of /64 to a user. Use /56 or /48 instead and avoid the pain later. Cheers, Jan
I am not proposing a change with respect to existing RFCs; we must to live with existing /64 subnets as a minimum allocation. My comments apply for future networks beyond the current 2000::/3 range used by all RIRs. Beyond this range all options are still open. -Ahmed -------------------------------------------------- From: "Jan Zorz @ go6.si" <jan@go6.si> Sent: Tuesday, July 19, 2011 2:23 PM To: <ipv6-wg@ripe.net> Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues)
On 7/19/11 1:10 PM, Ahmed Abu-Abed wrote:
Currently the smallest network of physical devices (a home user's subnet) gets the largest block of addresses (/64 in size) from the LIR. There is a logic issue here.
Thus we get the need for larger LIR IPv6 allocations. And dependencies on /64 subnets go beyond SLAAC and ND.
If/when RIPE has a say on what happens beyond 2000::/3, where /64 subnets are required, then we can come up with ideas on smallest subnet size. Hardware should be sophisticated enough by then to handle such practical needs in case bit alignment is an issue.
Please, stop here. Do not go any further.
We are taking all possible measures to discourage development and deployment of devices and mechanisms that would enable use of prefixes shorter than /64 in one link-layer network.
For example with initial /32 you could deploy 6RD in one 6RD domain, but would give to user only one /64. In this case sooner or later the need will emerge to develop something that magically enables you to split /64 to more subnets and actually use that. This is all about adding another layer of complexity and indirection to already messy world. That's one of reasons we are discouraging assignments of /64 to a user. Use /56 or /48 instead and avoid the pain later.
Cheers, Jan
On 7/19/11 1:44 PM, Ahmed Abu-Abed wrote:
I am not proposing a change with respect to existing RFCs; we must to live with existing /64 subnets as a minimum allocation.
My comments apply for future networks beyond the current 2000::/3 range used by all RIRs. Beyond this range all options are still open.
I don't think so. IPv6 as protocol applies over all ::/0, not only 2000::/3 Why do you think ND and SLAAC would behave differently in 4000::/3 ? Cheers, Jan
Why do you think ND and SLAAC would behave differently in 4000::/3 ? GV> I know just like you it is farfetched, but why not? GV> it just takes somebody to rewrite all ND, SLAAC, DHCP, etc... :-) 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 14:17 To: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) On 7/19/11 1:44 PM, Ahmed Abu-Abed wrote:
I am not proposing a change with respect to existing RFCs; we must to live with existing /64 subnets as a minimum allocation.
My comments apply for future networks beyond the current 2000::/3 range used by all RIRs. Beyond this range all options are still open.
I don't think so. IPv6 as protocol applies over all ::/0, not only 2000::/3 Why do you think ND and SLAAC would behave differently in 4000::/3 ? Cheers, Jan
On 7/19/11 2:25 PM, Gunter Van de Velde (gvandeve) wrote:
Why do you think ND and SLAAC would behave differently in 4000::/3 ?
GV> I know just like you it is farfetched, but why not? GV> it just takes somebody to rewrite all ND, SLAAC, DHCP, etc... :-)
...and have two incompatible protocols in different parts of the same numbering space (::/0), that probably could not even talk to each other. Brilliant. :) /jan
Le 11-07-19 08:17, Jan Zorz @ go6.si a écrit :
On 7/19/11 1:44 PM, Ahmed Abu-Abed wrote:
I am not proposing a change with respect to existing RFCs; we must to live with existing /64 subnets as a minimum allocation.
My comments apply for future networks beyond the current 2000::/3 range used by all RIRs. Beyond this range all options are still open.
I don't think so. IPv6 as protocol applies over all ::/0, not only 2000::/3
Why do you think ND and SLAAC would behave differently in 4000::/3 ?
I think Ahmed is referring to: <RFC4291> Future specifications may redefine one or more sub-ranges of the Global Unicast space for other purposes, but unless and until that happens, implementations must treat all addresses that do not start with any of the above-listed prefixes as Global Unicast addresses. </RFC4291>
Cheers, Jan
-- ========= IETF81 Quebec city: http://ietf81.ca IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN Implementation: http://postellation.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca Space Assigned Number Authority: http://sanaregistry.org
Hi,
I am not proposing a change with respect to existing RFCs; we must to live with existing /64 subnets as a minimum allocation.
My comments apply for future networks beyond the current 2000::/3 range used by all RIRs. Beyond this range all options are still open.
I don't think so. IPv6 as protocol applies over all ::/0, not only 2000::/3
Why do you think ND and SLAAC would behave differently in 4000::/3 ?
indeed. That would be weird and cause all kinds of operational problems. But more importantly - why at all? It's not a waste of addresses, this has been discussed 68060 times on various mailinglists and at other places. The usual answer to such statements simply is "do the math!", for a reason. There are some issues with /64 default segments, like it causes some possible attack vectors on the infrastructure, but there are no issues with the size itself compared to the 128bit we have. So, "do the math!" :-) -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect
I guess there is a IETF requirement that says that SLAAC only works on /64, and same for ND. It is basically an axioma for the RIR to take that into account, as otherwise things will break. Just as Jan mentioned in his main few seconds ago. 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 13:10 To: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) Currently the smallest network of physical devices (a home user's subnet) gets the largest block of addresses (/64 in size) from the LIR. There is a logic issue here. Thus we get the need for larger LIR IPv6 allocations. And dependencies on /64 subnets go beyond SLAAC and ND. If/when RIPE has a say on what happens beyond 2000::/3, where /64 subnets are required, then we can come up with ideas on smallest subnet size. Hardware should be sophisticated enough by then to handle such practical needs in case bit alignment is an issue. -Ahmed -------------------------------------------------- From: "Jan Zorz @ go6.si" <jan@go6.si> Sent: Tuesday, July 19, 2011 12:32 PM To: <ipv6-wg@ripe.net> Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues)
On 7/19/11 11:25 AM, Gunter Van de Velde (gvandeve) wrote:
You want to change how IPv6 SLAAC works? And ND?
that was my first thought also, but this can't be the idea that Ahmed proposed, it's a bit too far from reality :)
Cheers, Jan
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
Don't pull ND into this discussion. How do you make subnets smaller than /64 work on Ethernet links between Cisco routers? SLAAC does depend on /64.
-----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Gunter Van de Velde (gvandeve) Sent: Tuesday, July 19, 2011 11:26 AM To: Ahmed Abu-Abed; RIPE IPv6 Cc: address-policy-wg@ripe.net Subject: RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues)
You want to change how IPv6 SLAAC works? And ND?
G/
On 7/19/11 3:22 PM, Ivan Pepelnjak wrote:
Don't pull ND into this discussion. How do you make subnets smaller than /64 work on Ethernet links between Cisco routers?
SLAAC does depend on /64.
Discussion was end user assignments, not r2r connection segments. jan
ipv6-wg-admin@ripe.net escribió el 19/07/2011 15:29:19:
On 7/19/11 3:22 PM, Ivan Pepelnjak wrote:
Don't pull ND into this discussion. How do you make subnets smaller than /64 work on Ethernet links between Cisco routers?
SLAAC does depend on /64.
Discussion was end user assignments, not r2r connection segments.
IMHO, the remote router could be the customer xDSL router. And you need a */64* for the link. http://www.ripe.net/training/material/IPv6-for-LIRs-Training-Course/IPv6-for... (page 65)
jan
No, you don't. The only protocol that needs /64 is SLAAC. /64 on the connection is a __BEST PRACTICE__ (allowing CPE router to use SLAAC), no more, no less.
-----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of rodolfo.garciapenas@telefonica.es
On 7/19/11 3:22 PM, Ivan Pepelnjak wrote:
Don't pull ND into this discussion. How do you make subnets smaller than /64 work on Ethernet links between Cisco routers?
SLAAC does depend on /64.
Discussion was end user assignments, not r2r connection segments.
IMHO, the remote router could be the customer xDSL router. And you need a */64* for the link.
On 7/19/11 6:45 PM, Ivan Pepelnjak wrote:
No, you don't. The only protocol that needs /64 is SLAAC.
/64 on the connection is a __BEST PRACTICE__ (allowing CPE router to use SLAAC), no more, no less.
Exactly. And I see no point in changing that. To be perfectly honest, you could use link-local for CPE to core communication, but that's another discussion. What we are trying to prevent is ISPs assigning /64 as PD to customers instead of /56 or /48. /jan
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
[ address-policy-wg trimmed from Cc:] On Tue, 2011-07-19 at 11:40 +0200, Sander Steffann wrote:
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.
Actually, if people want to discuss this on the IPv6 working group list I don't mind. The IPv6 list is quite open for all IPv6-related discussions, whether they are related to RIPE or not. :) Thanks! -- Shane
Hi Shane,
Actually, if people want to discuss this on the IPv6 working group list I don't mind. The IPv6 list is quite open for all IPv6-related discussions, whether they are related to RIPE or not. :)
Sorry, this was meant for APWG, not for IPv6-WG. My apologies! 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
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 (21)
-
Ahmed Abu-Abed -
Andrea Cima -
Brandon Daly -
Daniel Roesen -
David Conrad -
Gert Doering -
Gunter Van de Velde (gvandeve) -
Immo 'FaUl' Wehrenberg -
Ivan Pepelnjak -
Ivan Pepelnjak -
Jan Zorz ＠ go6.si -
Jasper Jans -
Leo Vegoda -
Marc Blanchet -
Paul Hoogsteder -
rodolfo.garciapenas＠telefonica.es -
Sander Steffann -
Sascha Lenz -
Scott Leibrand -
Shane Kerr -
Yannis Nikolopoulos