2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation"
Hi all, It seems that the consensus is that up to a /29 is the right amount of space for the majority of networks, if that is the case I've think we should add the following: == 5.1.x Organisations that have already received their initial allocations are able to request additional address space up to a /29 without supplying of further documentation as if they were a first time requestor. == The logic being that this solves the problem for networks who deployed before this change and avoids the issues with HD ratio (which I think needs some looking at, but not here) J -- James Blessing 07989 039 476
Hello James, Speeking about concensus is definitely wrong. I'll send a longer critical aanlyses later, Best, Géza On Mon, Nov 14, 2011 at 11:13 AM, James Blessing < james.blessing@despres.co.uk> wrote:
Hi all,
It seems that the consensus is that up to a /29 is the right amount of space for the majority of networks, if that is the case I've think we should add the following:
==
5.1.x
Organisations that have already received their initial allocations are able to request additional address space up to a /29 without supplying of further documentation as if they were a first time requestor.
==
The logic being that this solves the problem for networks who deployed before this change and avoids the issues with HD ratio (which I think needs some looking at, but not here)
J
--
James Blessing 07989 039 476
+1 Remco van Mook Director of Interconnection, Europe remco.vanmook@eu.equinix.com +31 61 135 6365 MOB EQUINIX 51-53 Great Marlborough Street London, W1F 7JT, United Kingdom On 14-11-11 11:13, "James Blessing" <james.blessing@despres.co.uk> wrote:
Hi all,
It seems that the consensus is that up to a /29 is the right amount of space for the majority of networks, if that is the case I've think we should add the following:
==
5.1.x
Organisations that have already received their initial allocations are able to request additional address space up to a /29 without supplying of further documentation as if they were a first time requestor.
==
The logic being that this solves the problem for networks who deployed before this change and avoids the issues with HD ratio (which I think needs some looking at, but not here)
J
--
James Blessing 07989 039 476
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.
+1 Jasper -----Original Message----- From: address-policy-wg-bounces@ripe.net [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of James Blessing Sent: Monday, November 14, 2011 11:13 AM To: Address Policy Working Group Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" Hi all, It seems that the consensus is that up to a /29 is the right amount of space for the majority of networks, if that is the case I've think we should add the following: == 5.1.x Organisations that have already received their initial allocations are able to request additional address space up to a /29 without supplying of further documentation as if they were a first time requestor. == The logic being that this solves the problem for networks who deployed before this change and avoids the issues with HD ratio (which I think needs some looking at, but not here) J -- James Blessing 07989 039 476 Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer
+1 On 14 Nov 2011, at 10:14, "James Blessing" <james.blessing@despres.co.uk> wrote:
Hi all,
It seems that the consensus is that up to a /29 is the right amount of space for the majority of networks, if that is the case I've think we should add the following:
==
5.1.x
Organisations that have already received their initial allocations are able to request additional address space up to a /29 without supplying of further documentation as if they were a first time requestor.
==
The logic being that this solves the problem for networks who deployed before this change and avoids the issues with HD ratio (which I think needs some looking at, but not here)
J
--
James Blessing 07989 039 476
+1 James Blessing wrote:
Hi all,
It seems that the consensus is that up to a /29 is the right amount of space for the majority of networks, if that is the case I've think we should add the following:
==
5.1.x
Organisations that have already received their initial allocations are able to request additional address space up to a /29 without supplying of further documentation as if they were a first time requestor.
==
The logic being that this solves the problem for networks who deployed before this change and avoids the issues with HD ratio (which I think needs some looking at, but not here)
J
-- wbr, Roman Sokolov mailto:rps@cheater.ru
Sounds good for me. Michael Am 14.11.2011 11:13, schrieb James Blessing:
Hi all,
It seems that the consensus is that up to a /29 is the right amount of space for the majority of networks, if that is the case I've think we should add the following:
==
5.1.x
Organisations that have already received their initial allocations are able to request additional address space up to a /29 without supplying of further documentation as if they were a first time requestor.
==
The logic being that this solves the problem for networks who deployed before this change and avoids the issues with HD ratio (which I think needs some looking at, but not here)
J
-- Michael Adams Tel: +49 221 2222 657 Network Engineering & Design Fax: +49 221 2222 7657 NetCologne Geschäftsführer Gesellschaft für Telekommunikation mbH Dr. Hans Konle (Sprecher) Am Coloneum 9 Dipl.-Ing. Karl-Heinz Zankel 50829 Köln HRB 25580, Amtsgericht Köln
On 11/14/11 11:13 AM, James Blessing wrote:
5.1.x
Organisations that have already received their initial allocations are able to request additional address space up to a /29 without supplying of further documentation as if they were a first time requestor.
==
+1 Jan
5.1.x
Organisations that have already received their initial allocations are able to request additional address space up to a /29 without supplying of further documentation as if they were a first time requestor.
+1 ____________________________________ Tero Toikkanen Nebula Oy
I agree. On 14 nov. 2011, at 11:13, James Blessing wrote:
It seems that the consensus is that up to a /29 is the right amount of space for the majority of networks, if that is the case I've think we should add the following:
==
5.1.x
Organisations that have already received their initial allocations are able to request additional address space up to a /29 without supplying of further documentation as if they were a first time requestor.
==
The logic being that this solves the problem for networks who deployed before this change and avoids the issues with HD ratio (which I think needs some looking at, but not here)
Sound reasoning! Kind regards, Job
+1 MVH/Regards Ragnar
-----Opprinnelig melding----- Fra: address-policy-wg-bounces@ripe.net [mailto:address-policy-wg- bounces@ripe.net] På vegne av James Blessing Sendt: 14. november 2011 11:13 Til: Address Policy Working Group Emne: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation"
Hi all,
It seems that the consensus is that up to a /29 is the right amount of space for the majority of networks, if that is the case I've think we should add the following:
==
5.1.x
Organisations that have already received their initial allocations are able to request additional address space up to a /29 without supplying of further documentation as if they were a first time requestor.
==
The logic being that this solves the problem for networks who deployed before this change and avoids the issues with HD ratio (which I think needs some looking at, but not here)
J
--
James Blessing 07989 039 476
On Mon, 14 Nov 2011, James Blessing wrote:
It seems that the consensus is that up to a /29 is the right amount of space for the majority of networks, if that is the case I've think we should add the following:
==
5.1.x
Organisations that have already received their initial allocations are able to request additional address space up to a /29 without supplying of further documentation as if they were a first time requestor.
==
The logic being that this solves the problem for networks who deployed before this change and avoids the issues with HD ratio (which I think needs some looking at, but not here)
I agree with this, and also with the general theme of the proposal of extending the initial allocation size. I do not feel that it is sensible to tie this into a specific transition mechanism so am happy with the more generic proposal that has been put together that will also allow better scalability in long term addressing plans. One thing that I do wonder is whether the (limited) overhead of the NCC processing these requests mean it is more desirable to limit this "re-request" to a single shot per-LIR (which will likely push people to request the whole /29), or whether permitting multiple requests grabbing a /32 at a time (up to the /29) is desirable. Personally I assume that most networks using this policy extension would go for the /29 straight off, but then there maybe further interaction with the charging scheme which dissuades this. -- Tom Hodgson tom@someaddress.net
On 14 November 2011 16:18, Tom Hodgson <tom@someaddress.net> wrote:
One thing that I do wonder is whether the (limited) overhead of the NCC processing these requests mean it is more desirable to limit this "re-request" to a single shot per-LIR (which will likely push people to request the whole /29), or whether permitting multiple requests grabbing a /32 at a time (up to the /29) is desirable. Personally I assume that most networks using this policy extension would go for the /29 straight off, but then there maybe further interaction with the charging scheme which dissuades this.
The logic was to try and remove the guesswork from the process. For someone adjudicating the request its a fairly simple binary logic (in fact its almost programable) and therefore (I assume) a limited amount of impact. It also gets round the "oh bugger" moment where someone who could have gone for a /29 but only went for a /30 because their maths was wrong can't get the space, even though its effectively reserved for their future use, due to the HD rule. As I said if we can deal with the HD rule then I think we can maybe revisit this J -- James Blessing 07989 039 476
Dear Tom,
I agree with this, and also with the general theme of the proposal of extending the initial allocation size. I do not feel that it is sensible to tie this into a specific transition mechanism so am happy with the more generic proposal that has been put together that will also allow better scalability in long term addressing plans.
One thing that I do wonder is whether the (limited) overhead of the NCC processing these requests mean it is more desirable to limit this "re-request" to a single shot per-LIR (which will likely push people to request the whole /29), or whether permitting multiple requests grabbing a /32 at a time (up to the /29) is desirable. Personally I assume that most networks using this policy extension would go for the /29 straight off, but then there maybe further interaction with the charging scheme which dissuades this.
Assuming that the central point of this proposal stays intact, no additional documentation required for expansion up to a /29, the overhead of evaluating and processing these requests for the RIPE NCC would be minimal. Allowing LIRs to request expansion a /32 at a time would not significantly impact our work load. Best regards, Alex Le Heux Policy Implementation Co-ordinator RIPE NCC
+1 Wilhelm Am 14.11.2011 11:13, schrieb James Blessing:
Hi all,
It seems that the consensus is that up to a /29 is the right amount of space for the majority of networks, if that is the case I've think we should add the following:
==
5.1.x
Organisations that have already received their initial allocations are able to request additional address space up to a /29 without supplying of further documentation as if they were a first time requestor.
==
The logic being that this solves the problem for networks who deployed before this change and avoids the issues with HD ratio (which I think needs some looking at, but not here)
J
+1 Op 14-11-2011 11:13, James Blessing schreef:
Hi all,
It seems that the consensus is that up to a /29 is the right amount of space for the majority of networks, if that is the case I've think we should add the following:
==
5.1.x
Organisations that have already received their initial allocations are able to request additional address space up to a /29 without supplying of further documentation as if they were a first time requestor.
==
The logic being that this solves the problem for networks who deployed before this change and avoids the issues with HD ratio (which I think needs some looking at, but not here)
J
-- met vriendelijke groet, Rinse Kloek System and Network Engineer - Solcon Internetdiensten BV Het Spaarne 11 - 8253 PE Dronten - The Netherlands T: +31 88 0032222 - F: +31 88 0032223 - W: www.solcon.nl
On Mon, Nov 14, 2011 at 10:13:28AM +0000, James Blessing wrote:
It seems that the consensus is that up to a /29 is the right amount of space for the majority of networks, if that is the case I've think we
+1 rgds, Sascha
+1 -Florian James Blessing wrote Monday, November 14, 2011 11:13 AM
Hi all,
It seems that the consensus is that up to a /29 is the right amount of space for the majority of networks, if that is the case I've think we should add the following:
==
5.1.x
Organisations that have already received their initial allocations are able to request additional address space up to a /29 without supplying of further documentation as if they were a first time requestor.
==
The logic being that this solves the problem for networks who deployed before this change and avoids the issues with HD ratio (which I think needs some looking at, but not here)
J
--
James Blessing 07989 039 476
On Mon, Nov 14, 2011 at 11:13 AM, James Blessing <james.blessing@despres.co.uk> wrote:
Hi all,
It seems that the consensus is that up to a /29 is the right amount of space for the majority of networks, if that is the case I've think we should add the following: <snip>
It is not that I disagree on that /29 is a good size... but, just to repeat myself and some others. Why are we doing this step by step all over again? Last we went from /35 to /32, now we go from /32 to /29. I guess the next time we'll be talking about this topic is around 2015-2017... Why not do it properly this time around? Like a /26 or so? We got plenty of address space to burn really....
==
5.1.x
Organisations that have already received their initial allocations are able to request additional address space up to a /29 without supplying of further documentation as if they were a first time requestor.
==
The logic being that this solves the problem for networks who deployed before this change and avoids the issues with HD ratio (which I think needs some looking at, but not here)
... but if no one want to use time this time around for making it a /26 or so, the text above get my support to. -- Roger Jorgensen | rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
Hi Roger, Roger Jørgensen wrote: [...]
It is not that I disagree on that /29 is a good size... but, just to repeat myself and some others.
Why are we doing this step by step all over again? Last we went from /35 to /32, now we go from /32 to /29. I guess the next time we'll be talking about this topic is around 2015-2017... Why not do it properly this time around? Like a /26 or so? We got plenty of address space to burn really....
Where does the /26 come from? Or to put it another way, assuming the basis for allocation policy is justified need, what need is considered so universal that no justification is required? Regards, Leo Vegoda
On 14/11/2011 21:55, Leo Vegoda wrote:
Where does the /26 come from? Or to put it another way, assuming the basis for allocation policy is justified need, what need is considered so universal that no justification is required?
apparently 6rd. Or the latest transition mechanism, except that it's such a good address justification mechanism that you don't even need to mention which transition mechanism you're planning to use, or even if you are planning to use a transition mechanism at all. I'm struggling to understand how this proposal meets the Conservation section of the RIPE IPv6 allocation policy: "Although IPv6 provides an extremely large pool of address space, address policies should avoid unnecessarily wasteful practices. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided." It hardly takes much effort to mention to the RIPE NCC that your LIR is applying for a /29 instead of a /32 because it intends to implement 6rd, does it? While I don't have a major problem with giving 3 extra bits of space to implement 6rd, I do have a major problem with: 1. making this the default configuration, even for those LIRs who have no intention of ever deploying 6rd or any other equivalent transition mechanism, 2. removal of the requirement to specify 6rd/other mechanism to justify the extra space, and 3. allocating /26 by default. 102 bits of address space is obscenely wasteful because it is very significantly more than most LIRs will ever require in the lifetime of the universe (yes, I have worked out the scales here). Look, I don't mean to sound like a party pooper, but let's not lose the run of ourselves here. 6rd has very limited deployment at present, and while it shows a lot of promise as a potentially useful transition mechanism, it's not yet at the stage where we should feel tempted to shower LIRs with ridiculous quantities of address bits just because we're feeling a bit inadequate about current ipv6 uptake. I'd like to suggest that 2011-04 be changed so that LIRs can expand their default /32 to a /29 iff they document a requirement for providing 6rd / {another specified ipv6 transition mechanism which requires similar bits of address space} to end-users. Otherwise, a /32 will be assigned by default, and the RIPE NCC can continue on with their current binary chop allocation strategy. Nick
On 11/14/11 11:52 PM, Nick Hilliard wrote:
On 14/11/2011 21:55, Leo Vegoda wrote:
Where does the /26 come from? Or to put it another way, assuming the basis for allocation policy is justified need, what need is considered so universal that no justification is required?
apparently 6rd. Or the latest transition mechanism, except that it's such a good address justification mechanism that you don't even need to mention which transition mechanism you're planning to use, or even if you are planning to use a transition mechanism at all.
Dear Nick, Yes, exactly. Many "early" adopters knew no better and got their /32 in order to start testing IPv6 and today they would need much more to take advantage of some addressing ways that IPv6 can offer - and we had some of them expressing this thought at RIPE62, RIPE63 and here on list. I know I'm repeating myself, but probably we should try to "unlearn" all the speed-bumps we put into IPv4 addressing policy in order to slow down depletion and start distributing IPv6 space as needed, adapting the defaults to the feedback from operational environment and community.
I'm struggling to understand how this proposal meets the Conservation section of the RIPE IPv6 allocation policy:
"Although IPv6 provides an extremely large pool of address space, address policies should avoid unnecessarily wasteful practices. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided."
I would understand this as "do not give /20 to a LIR with 10 users." Note the word "should", therefore this must be taken just as a guidance, not a must.
It hardly takes much effort to mention to the RIPE NCC that your LIR is applying for a /29 instead of a /32 because it intends to implement 6rd, does it?
Then everybody can mention that they are about to deploy 6RD ;) We thought of this, but this just introduces unnecessary cycle in the process.
While I don't have a major problem with giving 3 extra bits of space to implement 6rd, I do have a major problem with:
1. making this the default configuration, even for those LIRs who have no intention of ever deploying 6rd or any other equivalent transition mechanism,
/29 for legacy allocations is reserved. Some LIRs would lower operational costs if they could use it (as nobody else could use that space). For latest allocations on binary chops, large quantities of space are in between allocations and likely in our lifetime we will not come to less than /24 or /25 in between the allocations. Fail to see the problem giving LIRs more space by default.
2. removal of the requirement to specify 6rd/other mechanism to justify the extra space, and
Yes, removing extra cycle...
3. allocating /26 by default. 102 bits of address space is obscenely wasteful because it is very significantly more than most LIRs will ever require in the lifetime of the universe (yes, I have worked out the scales here).
Agree.
Look, I don't mean to sound like a party pooper, but let's not lose the run of ourselves here. 6rd has very limited deployment at present, and while it shows a lot of promise as a potentially useful transition mechanism, it's not yet at the stage where we should feel tempted to shower LIRs with ridiculous quantities of address bits just because we're feeling a bit inadequate about current ipv6 uptake.
Broadcom revealed that in new chipset for CPE IPv6 and 6RD are HW accelerated. Major vendors are offering 6RD core boxes and many operators are testing them. Let's do that properly, if it's unavoidable. 6RD is not the best mechanism ever invented, but making it more complicated and expensive with multiple-6rd-domains because of lack of IPv6 space makes operational life even more complicated.
I'd like to suggest that 2011-04 be changed so that LIRs can expand their default /32 to a /29 iff they document a requirement for providing 6rd / {another specified ipv6 transition mechanism which requires similar bits of address space} to end-users. Otherwise, a /32 will be assigned by default, and the RIPE NCC can continue on with their current binary chop allocation strategy.
Again, so everybody can write into their request "we'll deploy 6RD". This is not solving anything. Please, start unthinking IPv4... RIPE-NCC can continue with exactly the same binary chop even if 2011-04 gets implemented. Cheers, Jan
On Tue, Nov 15, 2011 at 08:59:35AM +0100, Jan Zorz @ go6.si wrote:
Broadcom revealed that in new chipset for CPE IPv6 and 6RD are HW accelerated. Major vendors are offering 6RD core boxes and many operators are testing them. Let's do that properly, if it's unavoidable. 6RD is not the best mechanism ever invented, but making it more complicated and expensive with multiple-6rd-domains because of lack of IPv6 space makes operational life even more complicated.
"properly" as in "easy to deploy" would be to have an extra, eventually temporary, separate /24 for 6RD. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On 11/15/11 10:49 AM, Daniel Roesen wrote:
On Tue, Nov 15, 2011 at 08:59:35AM +0100, Jan Zorz @ go6.si wrote:
Broadcom revealed that in new chipset for CPE IPv6 and 6RD are HW accelerated. Major vendors are offering 6RD core boxes and many operators are testing them. Let's do that properly, if it's unavoidable. 6RD is not the best mechanism ever invented, but making it more complicated and expensive with multiple-6rd-domains because of lack of IPv6 space makes operational life even more complicated.
"properly" as in "easy to deploy" would be to have an extra, eventually temporary, separate /24 for 6RD.
Maybe yes (as this was also my idea initially), but we already went through this discussion and message from community was clear. Cheers, Jan
On 15/11/2011 07:59, Jan Zorz @ go6.si wrote:
I know I'm repeating myself, but probably we should try to "unlearn" all the speed-bumps we put into IPv4 addressing policy in order to slow down depletion and start distributing IPv6 space as needed, adapting the defaults to the feedback from operational environment and community.
I'm not particularly proposing slowing down depletion (there are still lots of /29s in 2000::/3). I'm proposing that if a service provider wants or needs additional space above a /32 for 6rd (or any other transition mechanism), that they state this explicitly in their application. And if they don't, they get a /32. And if it turns out later that they need the /29, the current allocation mechanism will allow them to expand easily without address fragmentation.
Then everybody can mention that they are about to deploy 6RD ;) We thought of this, but this just introduces unnecessary cycle in the process.
Yes, they could state that - but why bother? /32 is way more address space than most LIRs would ever use. Putting a single line of text into an application form hardly strikes me as being an excessive burden. Additionally, it provides the RIPE NCC with information on projected usage, which contributes to good stewardship. Here's what it would require: -- Foo ISP is requesting a /29 because it intends to deploy 6rd. -- Are you genuinely saying that it's too much work to put this into an application form? Nick
On 11/15/11 1:16 PM, Nick Hilliard wrote:
Here's what it would require:
-- Foo ISP is requesting a /29 because it intends to deploy 6rd. --
Should we put this as optional or suggestion? Cheers, Jan
On 15/11/2011 14:26, Jan Zorz @ go6.si wrote:
Should we put this as optional or suggestion?
All RIRs operate on the basis of stated need for their LIR's addressing requirements. 2011-04 suggests increasing the initial allocation from /32 to /29 on the basis that LIRs are going to need to deploy 6rd to their end-users. As an aside, let's stop beating around the bush here: everyone is focussing on 6rd because if it weren't for 6rd, there would be no requirement for 2011-04 - simply because there are no other likely migration mechanisms on the table which a) require lots of extra IP address space and b) look like they might work. Nick
On 18/11/2011 13:57, Nick Hilliard wrote:
On 15/11/2011 14:26, Jan Zorz @ go6.si wrote:
Should we put this as optional or suggestion?
All RIRs operate on the basis of stated need for their LIR's addressing requirements.
2011-04 suggests increasing the initial allocation from /32 to /29 on the basis that LIRs are going to need to deploy 6rd to their end-users.
Damn, clicked <send> on the wrong email #doh Continuing on the thread of thought in this email: -- Not every LIR is going to require an additional allocation for 6rd, simply because not every LIR is going to implement 6rd or any other transition technology. Therefore if 2011-04 is passed as it is, these LIRs are going to get an extra 3 bits of ipv6 address space for no reason. This violates the basis of RIR->LIR allocation policy. You get something for nothing which you frankly don't need and will never use. I'd like to suggest that the default allocation should continue to be /32, but if the LIR makes a claim that they are going to implement 6rd (or another equivalent transition technology which requires lots of address space), then they can receive up to a /29. If AP-WG doesn't want to do this, then we need to change the basic policy of allocation based on stated need to, well, something else. Not quite sure what. Nick /one day, i'll get the hang of this email thing
On 11/18/11 3:04 PM, Nick Hilliard wrote:
I'd like to suggest that the default allocation should continue to be /32, but if the LIR makes a claim that they are going to implement 6rd (or another equivalent transition technology which requires lots of address space), then they can receive up to a /29.
Well done :) This is also Remco's suggestion, /32 as default, up to /29 only if LIR asks - and this is going to new version of 2011-04, that will be posted to your favorite mailinglist shortly :) Cheers, Jan
On 11/18/2011 06:41 PM, Jan Zorz @ go6.si wrote:
I'd like to suggest that the default allocation should continue to be /32, but if the LIR makes a claim that they are going to implement 6rd (or another equivalent transition technology which requires lots of address space), then they can receive up to a /29. This is also Remco's suggestion, /32 as default, up to /29 only if LIR asks
I support this. There's no reason to allocate more than /32 for LIR by default. In special cases, there's no reason to block that allocation, but someone has provide some arguments to support his requirement....
On 11/18/2011 06:41 PM, Jan Zorz @ go6.si wrote:
I'd like to suggest that the default allocation should continue to be /32, but if the LIR makes a claim that they are going to implement 6rd (or another equivalent transition technology which requires lots of address space), then they can receive up to a /29. This is also Remco's suggestion, /32 as default, up to /29 only if LIR asks
I support this. There's no reason to allocate more than /32 for LIR by default. In special cases, there's no reason to block that allocation, but someone has provide some arguments to support his requirement....
On 11/18/11 10:44 PM, Daniel Suchy wrote:
I support this. There's no reason to allocate more than /32 for LIR by default. In special cases, there's no reason to block that allocation, but someone has provide some arguments to support his requirement....
We thought of putting suggestion to mention what LIR will use the space for if request is bigger than /32, but we figured out, that this is too technical requirement to put it into policy. IPRA can always politely ask, what is intended space usage (for documentary reasons, not justification). We could put this in policy proposal as what happens if this reaches consensus, but not in the policy itself. Cheers, Jan
Hallo *, here is an alternative phrasing for this issue. I wrote a while ago in the 6RD discussion, but since I am not affected by this I did not push it trough the policy process. Feel free to update and use it, if it fits your purpose. -- snip --5.2.1. Subsequent allocation criteria Subsequent allocation will be provided when an organisation (i.e. ISP/LIR): a) satisfies the evaluation threshold of past address utilisation interms of the number of sites in units of /56 assignments. The HD-Ratio[RFC 3194] is used to determine the utilisation thresholds thatjustify the allocation of additional address as described below; b) qualifies in accordance with the criteria for an initial allocation of /29. -- snap -- regards, Dan -- Dan Luedtke http://www.danrl.de
On 15 Nov 2011, at 12:16, Nick Hilliard <nick@inex.ie> wrote:
Here's what it would require:
-- Foo ISP is requesting a /29 because it intends to deploy 6rd. --
Are you genuinely saying that it's too much work to put this into an application form?
Seems pretty sensible and practical. Tim
Hi,
Here's what it would require:
-- Foo ISP is requesting a /29 because it intends to deploy 6rd. --
Are you genuinely saying that it's too much work to put this into an application form?
Seems pretty sensible and practical.
Tim
not quite sure i understand the intention, but... if that's all one would need to write into the application form, what's the point of putting it there in the first place if no one verifies the claim? This actually renders the whole thing irrelevant because everyone will just put that in their template or so. (*dejavue* i think someone already mentioned that within the thread) But maybe i lost the context within the thread... I usually stop following threads in deep when they start going in circles at some point :-) Shame on me in that case and please ignore my comment then. I'm still all for the proposal, not being tied to any specific reason or any jumping through hoops. If someone needs even more, the usual documentation needs to be handed in, be it for 6rd or whatever. Don't make policies too complicated for no reason. We're not (yet?) politicians here. One default, not two, or three, or four, or whatever. /29 seems fine for that due to the historical reservations for early allocations. Then we're done, that's the default in the current /3, fullstop. That's what this proposal is about in the first place (my interpretation?) - just mentioning 6RD as ONE possible feature that would benefit from it. The proposal also mentions more bits for proper subnetting/routing design for example. Why is everyone focussing on the 6RD part? -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect
On 16 Nov 2011, at 09:03, Sascha Lenz <slz@baycix.de> wrote:
Why is everyone focussing on the 6RD part?
Perhaps in part due to it being the one technology that has been used to date to enable a significant IPv6 deployment (1.5m users, 18Gbit/s traffic for free.fr, reportedly). Of course 6rd should only have a limited lifetime, but it's reality now. Tim
On 11/16/11 10:03 AM, Sascha Lenz wrote:
That's what this proposal is about in the first place (my interpretation?) - just mentioning 6RD as ONE possible feature that would benefit from it. The proposal also mentions more bits for proper subnetting/routing design for example.
+1
Why is everyone focussing on the 6RD part?
No idea. Just one of incentives (initial one). Cheers, Jan
Am 16.11.2011 12:01, schrieb Jan Zorz @ go6.si:
On 11/16/11 10:03 AM, Sascha Lenz wrote:
That's what this proposal is about in the first place (my interpretation?) - just mentioning 6RD as ONE possible feature that would benefit from it. The proposal also mentions more bits for proper subnetting/routing design for example.
+1
+1
Why is everyone focussing on the 6RD part?
No idea. Just one of incentives (initial one).
+1 cheers, Michael -- Michael Adams Tel: +49 221 2222 657 Network Engineering & Design Fax: +49 221 2222 7657 NetCologne Geschäftsführer Gesellschaft für Telekommunikation mbH Dr. Hans Konle (Sprecher) Am Coloneum 9 Dipl.-Ing. Karl-Heinz Zankel 50829 Köln HRB 25580, Amtsgericht Köln
On 16/11/2011 11:01, Jan Zorz @ go6.si wrote:
On 11/16/11 10:03 AM, Sascha Lenz wrote:
Why is everyone focussing on the 6RD part?
No idea. Just one of incentives (initial one).
Let's stop beating around the bush: everyone is focussing on 6rd because if it weren't for 6rd, there would be no requirement for 2011-04 - simply because there are no other ipv6 migration mechanisms around which a) require vast amounts of extra v6 address space and b) look like they might actually work. As a separate issue, the policy should not be worded to mention 6rd. However, we need to acknowledge that the primary motivation for this proposal is all about enabling 6rd. Nick
On 11/14/11 9:29 PM, Roger Jørgensen wrote:
It is not that I disagree on that /29 is a good size... but, just to repeat myself and some others.
Why are we doing this step by step all over again? Last we went from /35 to /32, now we go from /32 to /29. I guess the next time we'll be talking about this topic is around 2015-2017... Why not do it properly this time around? Like a /26 or so? We got plenty of address space to burn really....
Dear Roger, /29 was chosen for "fairness" factor - every legacy /32 can be expanded to /29 without renumbering, as that is exactly the amount of space "reserved" for every /32. If we decide to go to /26, then only new allocations gets /26, legacy ones need to renumber if expanded. It's a tradeoff in favor of fairness. Cheers, Jan
participants (25)
-
Alex Le Heux -
Anfinsen, Ragnar -
Dan Luedtke -
Daniel Roesen -
Daniel Suchy -
David Freedman -
Florian Fuessl -
James Blessing -
Jan Zorz ＠ go6.si -
Jasper Jans -
Job Snijders -
Leo Vegoda -
Michael Adams -
Nick Hilliard -
Remco Van Mook -
Rinse Kloek -
Roger Jørgensen -
Roman Sokolov -
Sascha Lenz -
Sascha Luck -
Tero Toikkanen -
Tim Chown -
Tom Hodgson -
Turchanyi Geza -
Wilhelm Boeddinghaus