2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments)
Dear colleagues, The draft document for version 2.0 of the policy proposal 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has now been published, along with an impact analysis conducted by the RIPE NCC. Some of the differences from version 1.0 include: - AS Numbers can now be assigned for any need that cannot be satisfied with an existing AS Number - The RIPE NCC's need evaluation has been removed - A limit of 1,000 AS Numbers per organisation has been added - There is now a requirement that 16-bit AS Numbers be multihomed after nine months - The requirement that the routing policy must be new and unique has been removed - Related wording adjustments in the summary and rationale of the proposal You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2014-03 And the draft document at: https://www.ripe.net/ripe/policies/proposals/2014-03/draft We encourage you to read the draft document text and send any comments to <address-policy-wg@ripe.net> before 22 January 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC
On 24/12/2014 10:51, Marco Schmidt wrote:
- AS Numbers can now be assigned for any need that cannot be satisfied with an existing AS Number - The RIPE NCC's need evaluation has been removed - A limit of 1,000 AS Numbers per organisation has been added - There is now a requirement that 16-bit AS Numbers be multihomed after nine months - The requirement that the routing policy must be new and unique has been removed - Related wording adjustments in the summary and rationale of the proposal
April 1 is three months away; otherwise, an excellent parody. Nick
Hi, On Wed, Dec 24, 2014 at 04:18:04PM +0000, Nick Hilliard wrote:
April 1 is three months away; otherwise, an excellent parody.
So do I take that as support of the policy, or opposition? And if the latter, what are you unhappy about which couldn't be brought up in the previous round already (since this new version really tries to incorporate all feedback that has been given)? Gert Doering -- APWG chair -- 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 (0)89/32356-444 USt-IdNr.: DE813185279
Perhaps Nick means, Xmas came early this year ;-) Verstuurd vanaf mijn iPad
Op 24 dec. 2014 om 19:14 heeft Gert Doering <gert@space.net> het volgende geschreven:
Hi,
On Wed, Dec 24, 2014 at 04:18:04PM +0000, Nick Hilliard wrote: April 1 is three months away; otherwise, an excellent parody.
So do I take that as support of the policy, or opposition? And if the latter, what are you unhappy about which couldn't be brought up in the previous round already (since this new version really tries to incorporate all feedback that has been given)?
Gert Doering -- APWG chair -- 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 (0)89/32356-444 USt-IdNr.: DE813185279
On 24/12/2014 18:14, Gert Doering wrote:
So do I take that as support of the policy, or opposition? And if the latter, what are you unhappy about which couldn't be brought up in the previous round already (since this new version really tries to incorporate all feedback that has been given)?
It's the evening of dec 24 so I'm not going to go into a whole rigmarole about the theory of bureaucratic policy. But as a general rule, most ripe community addressing policy over the last couple of years has been veering towards relaxation and simplification of rules rather than making them more complicated. This is particularly the case with ipv4, and almost the same with ipv6 from most practical viewpoints. As a community, we're pretty much together that this is a good thing. Then this proposal happens. It invents a magic number - one thousand. Yes, I'm aware of the distant practical basis for this, but let's not pretend that in every other respect the number isn't pulled straight out of the air because it happens to be an ordinal power of the number of fingers on most peoples' hands. Magical, nay divine, power is assigned to this number: thus far shalt thou abuse and no further! It creates a policy requirement to invoke RPSL, possibly one of the most inscrutably ill-defined languages ever devised, but the requirement is so poorly defined that anything could be credibly hurled into the database. E.g. "from AS23456 import AS-NULL". It creates a requirement to state a need for the ASN which the RIPE NCC will forbidden from evaluating. It also creates a requirement for the RIPE NCC to police this need. Not evaluate, mind you - just police it without evaluation. I'm trying to understand how this could possibly work, so in the unlikely event that there are no further emails from this address, you can assume that my brain has imploded due to a neural singularity. It conveniently ignores the awkward reality that in the event that an organisation might ever want 1001 ASNs, they could spend 10 euros registering a second company and continuing on their merry way. Guys and gals, I have shocking news for you: if someone is dishonest enough to abuse the rules using one organisation, they can just as easily abuse the rules with two different organisations and perpetrate twice as much abuse. Application of iteration theory indicates that this abuse may even scale linearly. The sensible approach to this is to relax the policy requirements for asn assignment - in exactly the same way that the ripe community has relaxed the policy requirements for other number resources - and then apply a small fee to help prevent egregious abuse. Note: not stop, because it is not possible to completely people abusing arbitrary rulesets without harming the common good. This is far simpler, most manageable, smaller, more internally consistent and generally more beneficial for the community than proposing byzantine policy. Look I'm sorry, but this policy draft is absurd and flies in the face of reality, common sense and practical application. Please kill it with fire. Nick
Look I'm sorry, but this policy draft is absurd and flies in the face of reality, common sense and practical application. Please kill it with fire.
thank you and if you can't figure it out, gert, i agree with nick, but am far less loquacious. randy
Hi, On Wed, Dec 24, 2014 at 05:02:20PM -0500, Randy Bush wrote:
Look I'm sorry, but this policy draft is absurd and flies in the face of reality, common sense and practical application. Please kill it with fire.
thank you
and if you can't figure it out, gert, i agree with nick, but am far less loquacious.
Nick, Randy, thanks - *that* message was very clear. (And I can see the point. The proposal is trying to work around the mishap that the charging scheme removed the fee for AS numbers, which we as APWG cannot directly decide - but of course the message has been sent at the last AGM and I'm fairly sure it has been heard. No idea what will happen on that front, though...) regards, Gert Doering -- 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 (0)89/32356-444 USt-IdNr.: DE813185279
On Dec 24, 2014, at 16:19, Nick Hilliard <nick@inex.ie> wrote:
Look I'm sorry, but this policy draft is absurd and flies in the face of reality, common sense and practical application. Please kill it with fire.
Nick
+1 Happy Holidays all.
Hey, You seem to give critic on many aspects, but offer solution to one aspect. You believe the magic 1k should be replaced by small fee. Well, that is what the 1k does, it gives non-zero fee to ASN, so that you dont want to request 32b of them. Same functionality without changes to billing procedure. The requirement for reason to request is for those who come after us, so that they will have data to work with. Why are ASNs needed? Does this seem problematic or wrong? I'm ambivalent on the RPSL aspect. How should it be remedied? Removed? Thanks, -- ++ytti
On 24 Dec 2014, at 23:18, Nick Hilliard <nick@inex.ie> wrote:
On 24/12/2014 18:14, Gert Doering wrote: So do I take that as support of the policy, or opposition? And if the latter, what are you unhappy about which couldn't be brought up in the previous round already (since this new version really tries to incorporate all feedback that has been given)?
It's the evening of dec 24 so I'm not going to go into a whole rigmarole about the theory of bureaucratic policy. But as a general rule, most ripe community addressing policy over the last couple of years has been veering towards relaxation and simplification of rules rather than making them more complicated. This is particularly the case with ipv4, and almost the same with ipv6 from most practical viewpoints. As a community, we're pretty much together that this is a good thing.
Then this proposal happens.
It invents a magic number - one thousand. Yes, I'm aware of the distant practical basis for this, but let's not pretend that in every other respect the number isn't pulled straight out of the air because it happens to be an ordinal power of the number of fingers on most peoples' hands. Magical, nay divine, power is assigned to this number: thus far shalt thou abuse and no further!
It creates a policy requirement to invoke RPSL, possibly one of the most inscrutably ill-defined languages ever devised, but the requirement is so poorly defined that anything could be credibly hurled into the database. E.g. "from AS23456 import AS-NULL".
It creates a requirement to state a need for the ASN which the RIPE NCC will forbidden from evaluating.
It also creates a requirement for the RIPE NCC to police this need. Not evaluate, mind you - just police it without evaluation. I'm trying to understand how this could possibly work, so in the unlikely event that there are no further emails from this address, you can assume that my brain has imploded due to a neural singularity.
It conveniently ignores the awkward reality that in the event that an organisation might ever want 1001 ASNs, they could spend 10 euros registering a second company and continuing on their merry way. Guys and gals, I have shocking news for you: if someone is dishonest enough to abuse the rules using one organisation, they can just as easily abuse the rules with two different organisations and perpetrate twice as much abuse. Application of iteration theory indicates that this abuse may even scale linearly.
The sensible approach to this is to relax the policy requirements for asn assignment - in exactly the same way that the ripe community has relaxed the policy requirements for other number resources - and then apply a small fee to help prevent egregious abuse. Note: not stop, because it is not possible to completely people abusing arbitrary rulesets without harming the common good.
This is far simpler, most manageable, smaller, more internally consistent and generally more beneficial for the community than proposing byzantine policy.
Look I'm sorry, but this policy draft is absurd and flies in the face of reality, common sense and practical application. Please kill it with fire.
Nick
Dear Nick, community, On Wed, Dec 24, 2014 at 09:18:22PM +0000, Nick Hilliard wrote:
It invents a magic number - one thousand. Yes, I'm aware of the distant practical basis for this, but let's not pretend that in every other respect the number isn't pulled straight out of the air
Some background: the 1000 number is based on multiplying the highest amount of ASNs assigned to a single organisation by ten (100 * 10), to ensure there is room for growth. The previous version of the policy did not contain the '1000 ASNs limitation'. To that proposal you responded you were going to need "slightly less than 2^32. (ASNs)". Am I to understand you prefer the previous version of the proposal, because it aligns better with your needs?
It creates a policy requirement to invoke RPSL
This is simply not true, this proposal is not creating anything new in that context. Current policy states: "The new unique routing policy should be defined in RPSL language, as used in the RIPE Database." the proposal states: "The routing policy of an Autonomous System should be defined in RPSL in the RIPE Database." Note the word /should/ in the proposed policy. I want to encourage everyone to document the meaningful bits of their routing policy in an accessible way, but as end-user you can also decide to put garbage (or nothing) in the DB. Should the words 'in RPSL' be removed the sentence? Any suggestions? As an active contributor to the current ASN Assignment policy, can you maybe shed some light on why the current policy invoked RPSL the way it does?
<snip>
The sensible approach to this is to relax the policy requirements for asn assignment - ... - and then apply a small fee to help prevent egregious abuse. Note: not stop, because it is not possible to completely people abusing arbitrary rulesets without harming the common good.
So you are using a terrible amount of handwaving and overbreathing to suggest that we refrain from ASN Assignment policy changes until the AGM decides to start charging a yearly fee for ASNs again? What if such a yaerly fee is never introduced?
Look I'm sorry, but this policy draft is absurd and flies in the face of reality, common sense and practical application.
What's absurd is that currently you cannot just get an ASN when you ask for one.
On 25/12/2014 10:39, Job Snijders wrote:
So you are using a terrible amount of handwaving and overbreathing to suggest that we refrain from ASN Assignment policy changes until the AGM decides to start charging a yearly fee for ASNs again?
What if such a yaerly fee is never introduced?
As a more general issue, we need to accept as a community that there is a crossover between RIPE Community policy and RIPE NCC membership policy, and that this is one of those intersections. The initial-idea to implementation-time for a RIPE policy proposal is rarely less than 12 months. Rather than thinking in terms of now or 6 or 12 months time, it's a better idea to formulate policy based on where the RIPE Community might want to be several years down the road. Based on this, the questions we need to ask *now* about what policy we want down the road should revolve around this:
What's absurd is that currently you cannot just get an ASN when you ask for one.
The current policy wording is a bit annoying but we're all used to the idea of providing the RIPE NCC with the correct incantation to get around its restrictions, so the net effect at the moment is that you can get an ASN if you want one. I.e. we're already running with a liberal assignment policy. All things considered, there's not a major problem living with the current policy formulation for another 12 months if that's what it takes to fix the policy properly. As a brief aside, we previously had this problem with fanciful story-telling to obtain IPv4 PI assignments. At the time the community agreed that telling porkie pies to justify assignments was probably neither clever nor compatible with good stewardship of resources. The way to fix this issue is to understand what the main underlying problems are with ASN assignment. They are: 1. no garbage collection 2. limited supply of ASN16s, causing exhaustion in the medium term The limited supply of ASN16s is only a problem because of lousy BGP Community support for ASN32s. If the IETF were to fix this problem, there would no substantial difference between 2-byte and 4-byte ASNs and we'd all be happy with a generic liberal assignment policy for all colours of ASN. In the interim, it's a question of interpretation as to whether it's worth changing the policy to slow down the run-out rate or not, given that the IETF is apparently more interested in the latest shiny baubles than fixing the BGP protocol to support this basic feature. The simplest way to implement garbage collection is to apply a small charge to each resource. The current iteration of this proposal suggests a partial garbage collection method which is IMO unworkable. It's unworkable because the RIPE NCC has never before had a policy of reclaiming resources because the initial application justification was changed, so going back on 20 years of working policy will probably be legally dubious in several of the jurisdictions that the RIPE NCC operates in. There's also a issue surrounding what level of change from the initial assignment criteria would be acceptable for reclaiming the resource. In other words, the proposal doesn't fix the problem of garbage collection; it simply shifts it to the lawyers. This is not clever. The only mechanism guaranteed to work as a garbage collection mechanism across all 76 or so jurisdictions is payment for receipt of good or services. Pretty much every legal system in the world accepts non payment of dues as a basis for breach of contract. Other than striving towards as being simple as possible (but no simpler), it's probably a good idea to align ASN assignment policy with other number resource policy. There's been no good reason suggested as to why ASN assignment policy should head towards more complicated rules when ipv4/ipv6 assignment/allocation policy has already gone in the opposite direction. Nick
Hi, On Thu, Jan 01, 2015 at 05:02:40PM +0000, Nick Hilliard wrote:
On 25/12/2014 10:39, Job Snijders wrote:
So you are using a terrible amount of handwaving and overbreathing to suggest that we refrain from ASN Assignment policy changes until the AGM decides to start charging a yearly fee for ASNs again?
What if such a yaerly fee is never introduced?
As a more general issue, we need to accept as a community that there is a crossover between RIPE Community policy and RIPE NCC membership policy, and that this is one of those intersections. [..] All things considered, there's not a major problem living with the current policy formulation for another 12 months if that's what it takes to fix the policy properly.
So your suggestion would be to stall this proposal until we know what comes out of the next AGM, and then see if we need the clause in question at all, anymore? What if the AGM decides to bring back a yearly recurring charge for ASNs, we loosen up our policy, the AGM decides to remove the charge once again, and Nick No Hats decides to send in 4 billion ASN requests to the NCC (I recall that it was you initially who was worried about the potential for abuse here, so I'm slightly confused what to make out of this now)? Given that we only have indirect influence on the AGM decisions, I can see why the proposers wanted to have a safety net in the parts we get to control... Gert Doering -- APWG chair -- 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 (0)89/32356-444 USt-IdNr.: DE813185279
Hi Gert,
So your suggestion would be to stall this proposal until we know what comes out of the next AGM, and then see if we need the clause in question at all, anymore?
I would not recommend stalling the proposal based on what will be decided. My strong suggestion would be to move forward regardless. The current policy text provides a fix for possible abuse of requesting AS numbers. And if there will be a charge in the future for an AS number via the charging scheme, that number would be easy removed to replace it by the charge for the AS.
What if the AGM decides to bring back a yearly recurring charge for ASNs, we loosen up our policy, the AGM decides to remove the charge once again, and Nick No Hats decides to send in 4 billion ASN requests to the NCC (I recall that it was you initially who was worried about the potential for abuse here, so I'm slightly confused what to make out of this now)?
Let's not try to fix every potential issue here I would say. We can always address that if we see someone sign-up as Mr. No Hats at a RIPE meeting and take him aside ... cluebats are great for providing some insight into a specific direction .. ;-)
Given that we only have indirect influence on the AGM decisions, I can see why the proposers wanted to have a safety net in the parts we get to control...
The proposers didn't wanted this safety net if I recall initially .. that came to the discussion after someone decided he wanted to request the complete number pool ... And he didn't even wanted to do so.. he just played with the idea that it would be possible ... This complete theoretic possible abuse for this specific policy has been entertained long enough I would say .. time to move forward. Regards, Erik Bais
On 13/01/2015 14:46, Gert Doering wrote:
So your suggestion would be to stall this proposal until we know what comes out of the next AGM, and then see if we need the clause in question at all, anymore?
yes, that was my suggestion. The current configuration is stable, so there are no pressing operational reasons to change things in a hurry. If we're going to change, we need to do that's best for N years down the road, not what's best for a couple of months during 2015.
What if the AGM decides to bring back a yearly recurring charge for ASNs, we loosen up our policy, the AGM decides to remove the charge once again,
from previous email:
As a more general issue, we need to accept as a community that there is a crossover between RIPE Community policy and RIPE NCC membership policy, and that this is one of those intersections.
Both the RIPE NCC membership and the AP working group tend to end up with reasonable policies. I'm pretty confident that this isn't going to change any time soon. Nick
On 13/01/2015 14:46, Gert Doering wrote:
So your suggestion would be to stall this proposal until we know what comes out of the next AGM, and then see if we need the clause in question at all, anymore? yes, that was my suggestion. The current configuration is stable, so there are no pressing operational reasons to change things in a hurry. If we're going to change, we need to do that's best for N years down the road, not what's best for a couple of months during 2015. I do not think it is a good idea to stall a policy proposal in order to see if the Board/AGM decides to take into consideration or ignore in the future your presentation/proposal from the previous AGM. I think your suggestion sets a very dangerous precedent where a policy
What if the AGM decides to bring back a yearly recurring charge for ASNs, we loosen up our policy, the AGM decides to remove the charge once again, from previous email:
As a more general issue, we need to accept as a community that there is a crossover between RIPE Community policy and RIPE NCC membership policy, and that this is one of those intersections. Both the RIPE NCC membership and the AP working group tend to end up with reasonable policies. I'm pretty confident that this isn't going to change any time soon. It has already changed from a year to the other and that is why I did not like the proposal you made at the previous AGM. We need to have a charging scheme that is predictable and will not change from a year to
Hi Nick, On 13/01/15 16:57, Nick Hilliard wrote: proposal would be stalled pending a decision that may or not be taken at the next AGM. Regarding the current configuration, well.. it requires the requester of the ASN to come up with a reason that can not be verified by the RIPE NCC and with a predicted set of peers that may or not peer with the assigned ASN. For example, see the e-mail sent to the members-discuss mailing list yesterday by Shahin Gharghi; the current policy requires the requester to list the two ASNs they will peer with, what if some companies can not peer with two ASNs because of local regulations. Do you think that company should not receive the ASN they need? Also, from your e-mail I understand that you are sure the AGM will vote within 'a couple of months' to charge for ASNs. Do you know something that I don't? :) the other. I think that if this policy proposal becomes policy and too many companies start requesting 1000 ASNs, the AGM can react and start charging (either from the first, the second or the 100th ASN) based on numbers that the RIPE NCC will provide. I do not like the idea that a policy proposal can be stalled because someone can imagine a way the proposal/policy could be abused. If it does get abused, we react on that and not on predictions.
Nick
Regards, Elvis -- <http://v4escrow.net> Elvis Daniel Velea Chief Executive Officer Email: elvis@V4Escrow.net <mailto:elvis@v4escrow.net> US Phone: +1 (702) 475 5914 EU Phone: +31 (0) 61458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited.
On 13/01/2015 17:23, Elvis Daniel Velea wrote:
Regarding the current configuration, well.. it requires the requester of the ASN to come up with a reason that can not be verified by the RIPE NCC and with a predicted set of peers that may or not peer with the assigned ASN.
Elvis, you probably know the documentation much better than I do, but the formal requirement for multihoming has been in place since at least RIPE-140, dating from 1996. RIPE-140 refers to existing assignment practices and from what I remember of before that date, there was an informal expectation of multihoming for ASN assignment from the very early days of the Internet, even if it wasn't formally documented. As a community, we managed to arrive at a practical workaround, namely that you can apply for an ASN if you have a plan to multihome and can state a name for a potential peering partner. We all quietly acknowledge that it might not match the spirit of the policy, but it works and has worked for as long as the RIPE NCC has existed. It needs to work because often an organisation needs an ASN even when they're not yet ready to multihome. Again, let me be clear where I'm coming from: if we are going to change a policy which has been in existence for more than 19 years, let's change it to what we want for the next 19, rather than put in place a temporary stopgap with the aim of plugging a leak. If this means being patient for another couple of months until RIPE71, then that's fine by me.
Also, from your e-mail I understand that you are sure the AGM will vote within 'a couple of months' to charge for ASNs. Do you know something that I don't? :)
Then you misread my email: I have no more information than anyone else about how people might vote. Nick
On Tue, Jan 13, 2015 at 05:56:25PM +0000, Nick Hilliard wrote:
As a community, we managed to arrive at a practical workaround, namely that you can apply for an ASN if you have a plan to multihome and can state a name for a potential peering partner. We all quietly acknowledge that it might not match the spirit of the policy, but it works and has worked for as long as the RIPE NCC has existed. It needs to work because often an organisation needs an ASN even when they're not yet ready to multihome.
So, you admit that the policy, as it stands, is ineffective and is honoured in breach more than in observance. The proposed policy does not much more than put in writing the current practice anyway.
to what we want for the next 19, rather than put in place a temporary stopgap with the aim of plugging a leak. If this means being patient for another couple of months until RIPE71, then that's fine by me.
I'm not in favour of making policy at the meetings, not least because I rarely have the opportunity to attend and I consider this an attempt at disenfranchisement. Remember 2007-01!
Then you misread my email: I have no more information than anyone else about how people might vote.
Well I will vote against charging for ASNs, for one. Charging for something one effectively *needs* to operate smells of Ryanair-ish practice to me. What is your plan in case the members vote against this charge? rgds, Sascha Luck
Hi, On Tue, Jan 13, 2015 at 06:23:09PM +0100, Elvis Daniel Velea wrote:
I do not think it is a good idea to stall a policy proposal in order to see if the Board/AGM decides to take into consideration or ignore in the future your presentation/proposal from the previous AGM. I think your suggestion sets a very dangerous precedent where a policy proposal would be stalled pending a decision that may or not be taken at the next AGM.
I think the wording "dangerous precedent" is a bit too strong here - we did that in the past (stall a proposal until something else was decided), and as long as the proposer and WG chair agree on the course, there is nothing wrong here... after all, the proposer can withdraw at any time as well :) . [..]
For example, see the e-mail sent to the members-discuss mailing list yesterday by Shahin Gharghi; the current policy requires the requester to list the two ASNs they will peer with, what if some companies can not peer with two ASNs because of local regulations. Do you think that company should not receive the ASN they need?
One could argue indeed that if you have only a single BGP upstream, an AS number is not strictly needed. But of course this is one of the reasons the proposers had to bring this up - private ASNs or announcing from the upstream's ASN will not always get the job done either.
Also, from your e-mail I understand that you are sure the AGM will vote within 'a couple of months' to charge for ASNs. Do you know something that I don't? :)
Well, Nick and I brought it up at the last AGM, and we made sure the board was awake and listening :-) - so we'll see what happens at the next AGM. [..]
I do not like the idea that a policy proposal can be stalled because someone can imagine a way the proposal/policy could be abused. If it does get abused, we react on that and not on predictions.
Actually we *do* try to make policy in a way that we don't have to scramble to fix the ways it can be abused right afterwards :-) Gert Doering -- APWG chair -- 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 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, I would like to add to the discussion first that I support the idea of the proposal. There has been some discussions by some in the community that there should be some kind of stop mechanism. Both on the Ap-wg ML and during the meeting in London. The discussion itself currently doesn't go over if an AS should be multihomed but about how do we stop abusers that want to demonstrate the need for 2^32 AS numbers ... How scary that might be .. There are other ways to screw things up ... This discussion should be finished by agreeing that there should be stop somewhere ... There has been 2 suggestions to this scary (automation) AS request that Nick might use when the policy comes into place ... Pay per AS or limit the number of AS'n per organisation. This while nothing currently suggests that Nick or someone else actually wants to request 2^32 AS's ... There is always the option to fix this within 6 months via the AGM with a charge per AS if the RIPE NCC has all AS numbers handed out to a scary evil org based on an island.. And if evil corp wants to keep the requested AS numbers when the AGM puts a €100 charge per AS, we will see at that point I think.. The intention of the prevention of the abuse is clear .. The policy won't get any better by having the authors go back and redo the draft (again) to the original because there is no nice solution for this 'possible' abuse .. So, on the intention of the policy: clear support. On the implementation: 1000 AS numbers ( as discussed in London) is a good enough number for the majority of the community. It is the cleanest way to implement this in the policy, nope sorry .. But that was also not suggested as such by the authors. The possible loophole came from the community and when they plugged it, the comment is that the policy text isn't clean enough ? I support the intention of the policy and I have peace with this version as it was the result of a good discusssion in London. Merry x-mas y'all, Erik Bais Send from my sofa with a glass of wine @ hand.
On Thu, Dec 25, 2014 at 01:10:41PM +0100, Erik Bais - A2B Internet wrote:
There has been 2 suggestions to this scary (automation) AS request that Nick might use when the policy comes into place ... Pay per AS or limit the number of AS'n per organisation.
Another possibility would be that n ASN can be assigned to an Organisation without proving any need and any further assignments have to prove need. How much n should be is open to debate of course. This should be more flexible than a fixed limit (who knows, maybe there's an operator that needs >1000 ASN), it also addresses the possibility of the AGM de-fanging a "charging" implementation without the need to go back and make a new policy. rgds, Sascha Luck
Hi, There was a small ruckus on this mailing list about the 1000 ASN limit during the holidays. The whole disagreement is centred around the fact that ASNs are free now. I've read a lot of messages that seem to suggest that there should be some charge related to them that prevents amassing them in the billions. I sort of agree with that, but... Is there someone in this community that feels they should be completely free, no matter how many you have? I'd like to offer some more food for thought. These are not realistic suggestions, but I hope they will close the gap between the two debating sides: How many ASNs can a LIR get using one email or one click on the RIPE portal? My understanding is that even after 2014-03 is implemented, the answer will be one(1). After that email/click, the LIR will go through the Process. I don't think any amount of policy simplification will reduce the work required per Process Instance at both the LIR and the RIR below two minutes. In the crypto(slash)security community this is called the proof-of-work system. So, for a thousand ASNs this would mean about 33 hours. As we want to turn that into money, working at ten Euros per hour the cost would be 330 Euros. You can twist the numbers every which way, but it's hard to twist them so far that the result would be much smaller than Nick's example of setting up another company for 10 Euros (+work.) If we want to make sure that a LIR doesn't automate their email responses to the Process, we can include another random proof-of-work such as "what is the sum of the digits in today's date?", "how much is this ticket number divided by the number of ASNs you already have?" or "when do the cows come home to roost?" Or just a plain old CAPTCHA. Someone suggested that if the ASNs were free and someone got four billion of them, we can fix that post-fact by raising the ASN fee above zero. The same person, in the same sentence, also hinted that this special someone would be based at some tax haven sort of place, where exacting this fee won't really be possible, should the someone refuse to pay the new fee. The resulting reclamation process would leave us without ASNs for a couple of years. Then again, according to my above thesis of ASN acquisition speed, it would take thousands of years for the bad guy to finish all the Processes to get all the ASNs in the first place. There, a couple of cents worth... -- Aleksi Suhonen / Let bogons be bogons.
Hi Aleksi, That one strikes me as well. I don't know how often people arguing about ASN stockpiling really apply for ASN's but my experience is that it takes quite a lot of explanation even to get a second ASN for the same entity. But maybe I am missing something here and the "non multihoming" rule means the NCC will not check anything at all in the future and just give away ASN's to anyone asking for them, no matter how many? On Mon, 19 Jan 2015, Aleksi Suhonen wrote:
Hi,
There was a small ruckus on this mailing list about the 1000 ASN limit during the holidays. The whole disagreement is centred around the fact that ASNs are free now. I've read a lot of messages that seem to suggest that there should be some charge related to them that prevents amassing them in the billions. I sort of agree with that, but...
Is there someone in this community that feels they should be completely free, no matter how many you have?
I'd like to offer some more food for thought. These are not realistic suggestions, but I hope they will close the gap between the two debating sides:
How many ASNs can a LIR get using one email or one click on the RIPE portal? My understanding is that even after 2014-03 is implemented, the answer will be one(1).
After that email/click, the LIR will go through the Process. I don't think any amount of policy simplification will reduce the work required per Process Instance at both the LIR and the RIR below two minutes. In the crypto(slash)security community this is called the proof-of-work system.
So, for a thousand ASNs this would mean about 33 hours. As we want to turn that into money, working at ten Euros per hour the cost would be 330 Euros. You can twist the numbers every which way, but it's hard to twist them so far that the result would be much smaller than Nick's example of setting up another company for 10 Euros (+work.)
If we want to make sure that a LIR doesn't automate their email responses to the Process, we can include another random proof-of-work such as "what is the sum of the digits in today's date?", "how much is this ticket number divided by the number of ASNs you already have?" or "when do the cows come home to roost?" Or just a plain old CAPTCHA.
Someone suggested that if the ASNs were free and someone got four billion of them, we can fix that post-fact by raising the ASN fee above zero. The same person, in the same sentence, also hinted that this special someone would be based at some tax haven sort of place, where exacting this fee won't really be possible, should the someone refuse to pay the new fee.
The resulting reclamation process would leave us without ASNs for a couple of years. Then again, according to my above thesis of ASN acquisition speed, it would take thousands of years for the bad guy to finish all the Processes to get all the ASNs in the first place.
There, a couple of cents worth...
-- Aleksi Suhonen / Let bogons be bogons.
Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm
Hi Daniel,
That one strikes me as well. I don't know how often people arguing about ASN stockpiling really apply for ASN's but my experience is that it takes quite a lot of explanation even to get a second ASN for the same entity.
But maybe I am missing something here and the "non multihoming" rule means the NCC will not check anything at all in the future and just give away ASN's to anyone asking for them, no matter how many?
That is the basic idea: ask for another ASN and you'll get one. Then some participants on this mailing list were worried that someone might request the whole pool. That caused a new version of the proposal to be written with some limits in them. Those limits were chosen in such a way that even the organisation with the largest number of ASNs could request 10x as much as they currently have and still fit in the policy. It is however a 'magic' number. That caused some objections because the policy is now not as clean and simple anymore. So now this working group needs to decide in which direction to move: a very simple and clean policy that is 'ask and you will get', or a policy that places arbitrary limits just in case someone might try to abuse the policy. Or some other form of rate-limiting? If the RIPE NCC started charging for ASNs again then that would be a limiter and a reclaim mechanism. The policy could certainly remain a lot cleaner in that case. Or, just thinking out loud: we could allow the NCC to limit the number of resource requests they accept per week from the same organisation or something like that. With exponential back-off? ;) As a working group we need to decide a few things: - do we want to make it easy to get ASNs? (the answer seems to be "yes") - do we want to place a limit? - do we want a time-based or absolute limit? - do we wait for the next RIPE NCC charging scheme to see if that solves our problems? Cheers, Sander Steffann APWG co-chair
On 19/01/2015 21:42, Sander Steffann wrote:
As a working group we need to decide a few things: - do we want to make it easy to get ASNs? (the answer seems to be "yes") - do we want to place a limit? - do we want a time-based or absolute limit? - do we wait for the next RIPE NCC charging scheme to see if that solves our problems?
and: - do we want to implement garbage collection for unused assignments. Nick
Hi Nick,
Op 19 jan. 2015 om 13:45 heeft Nick Hilliard <nick@inex.ie> het volgende geschreven:
On 19/01/2015 21:42, Sander Steffann wrote: As a working group we need to decide a few things: - do we want to make it easy to get ASNs? (the answer seems to be "yes") - do we want to place a limit? - do we want a time-based or absolute limit? - do we wait for the next RIPE NCC charging scheme to see if that solves our problems?
and:
- do we want to implement garbage collection for unused assignments.
Indeed! Sander
On Mon, Jan 19, 2015 at 01:42:49PM -0800, Sander Steffann wrote:
As a working group we need to decide a few things: - do we want to make it easy to get ASNs? (the answer seems to be "yes")
Yes, please.
- do we want to place a limit?
Probably a good idea.
- do we want a time-based or absolute limit?
A time-based limit has merit, actually. It avoids the "magic number" issue and will certainly prevent a "smash-and-grab" scenario.
- do we wait for the next RIPE NCC charging scheme to see if that solves our problems?
I'm not in favour of this. What I want to see is that the membership fee covers all my dealings with the NCC. In small companies, you often have to get budgetary approval for even EUR50, and I'm in *no* mood to explain to a bean-counter (or the boss's wife) what an ASN is and why I need 50 quid to pay for another one. rgds, Sascha Luck
Cheers, Sander Steffann APWG co-chair
* "Sascha Luck [ml]" <apwg@c4inet.net>
On Mon, Jan 19, 2015 at 01:42:49PM -0800, Sander Steffann wrote:
- do we wait for the next RIPE NCC charging scheme to see if that solves our problems?
I'm not in favour of this. What I want to see is that the membership fee covers all my dealings with the NCC. In small companies, you often have to get budgetary approval for even EUR50, and I'm in *no* mood to explain to a bean-counter (or the boss's wife) what an ASN is and why I need 50 quid to pay for another one.
Hi Sascha, Would an ASN charge be more palatable to you if the membership fee included a quota of 1 (or N) gratis ASNs? Or perhaps that the already existing IPv4/IPv6 PI charge would include 1 gratis ASN per resource? I'm thinking that as long as N is a quite modest number, this does not cause any real abuse potential and at the same time it would make it more likely that the membership would agree to having an ASN fee put in place - as the vast majority of us won't actually have to pay anything more than we do today. (I'm well aware that this is outside of APWG's jurisdiction though. Just thinking out loud, perhaps some board members are listening...) Tore
On Tue, Jan 20, 2015 at 08:00:10AM +0100, Tore Anderson wrote:
Would an ASN charge be more palatable to you if the membership fee included a quota of 1 (or N) gratis ASNs? Or perhaps that the already existing IPv4/IPv6 PI charge would include 1 gratis ASN per resource?
I'm thinking that as long as N is a quite modest number, this does not cause any real abuse potential and at the same time it would make it more likely that the membership would agree to having an ASN fee put in place - as the vast majority of us won't actually have to pay anything more than we do today.
It would make it operationally easier (at least for me), but I still think it's a bad idea to have a policy depend on the charging scheme (or vice versa). Even assuming the NCC proposes an ASN charge *and* the members vote for it, this is not guaranteed to survive the next GM. This gives two possible outcomes: a) there is a (perceived) barrier to changing the charging scheme again because a policy depends on it. Basically, policy infringing on something that should be the exclusive purview of the membership. b) if the charging scheme does get changed regardless, the policy doesn't work and needs changing again. Waste of time and offends Nick's sensible requirement that the policy should be good for n years... All in all, an unelegant solution. Besides, I like the idea of a "flat-rate" charging scheme where you pay yor membership fee and have all your services for the year covered. rgds, Sascha Luck
On 20/01/2015 12:23, Sascha Luck [ml] wrote:
All in all, an unelegant solution. Besides, I like the idea of a "flat-rate" charging scheme where you pay yor membership fee and have all your services for the year covered.
that would be nice, except ASNs are assigned to end users not LIRs. A large number of end users with ASNs are not LIRs. Nick
* Sander Steffann <sander@steffann.nl>
As a working group we need to decide a few things: - do we want to make it easy to get ASNs? (the answer seems to be "yes")
Yep. I'm not opposed to saying that the applicant must have *some* form of technical need for it. Multihoming would be one valid requirement, but it shouldn't be the only qualifying technical need. I liked the first version of the proposal...
- do we want to place a limit?
I agree that it's not ideal.
- do we wait for the next RIPE NCC charging scheme to see if that solves our problems?
Do we have any idea if the board will propose an ASN charge at the Spring GM? (Hi Nigel!) I think waiting would make sense if we know that an ASN charge is in the works. Tore
On Tue, 20 Jan 2015, Tore Anderson wrote:
* Sander Steffann <sander@steffann.nl>
As a working group we need to decide a few things: - do we want to make it easy to get ASNs? (the answer seems to be "yes")
Yep. I'm not opposed to saying that the applicant must have *some* form of technical need for it. Multihoming would be one valid requirement, but it shouldn't be the only qualifying technical need.
Yes, that is where I thought we were. I was aware of the proposal to remove the multihoming as an absolute demand but I thought there would still be some kind of needs based delegation.
I liked the first version of the proposal...
Maybe I have some reading to catch up with. Cheers, Daniel _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm
- do we want to make it easy to get ASNs? (the answer seems to be "yes")
well, easy to get an ASN, and hard to get 42
- do we want to place a limit?
that is one means of damping
- do we want a time-based or absolute limit?
or both
- do we wait for the next RIPE NCC charging scheme to see if that solves our problems?
think for a minute what price would have a damping affect while not being a pita to marjorie who just wants an asn to get her job done. there may not be a good price point that accomplishes both. randy
On Tue, Jan 20, 2015 at 04:29:57PM +0900, Randy Bush wrote:
- do we wait for the next RIPE NCC charging scheme to see if that solves our problems?
think for a minute what price would have a damping affect while not being a pita to marjorie who just wants an asn to get her job done. there may not be a good price point that accomplishes both.
1 euro per year per ASN would already have a strong dampening effect
On Tue, 20 Jan 2015, Randy Bush wrote:
- do we want to make it easy to get ASNs? (the answer seems to be "yes")
well, easy to get an ASN, and hard to get 42
I agree, as long as we talk about end-users here, rather than LIR's. We help quite a few end users to get ANS's and sometimes more than one in the same day. There are no problems today as long as you ask for one (1) ASN per end-user. So while I support the idea that some entities that do not qualify today because of the multihoming demand, I would not like to have more trouble receiving new ASN's for those who get them rather easily today. Cheers, Daniel _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm
On 19/01/2015 02:28, Aleksi Suhonen wrote:
Is there someone in this community that feels they should be completely free, no matter how many you have?
we all want a free lunch.
I'd like to offer some more food for thought. These are not realistic suggestions, but I hope they will close the gap between the two debating sides:
How many ASNs can a LIR get using one email or one click on the RIPE portal? My understanding is that even after 2014-03 is implemented, the answer will be one(1).
(End Users, not just LIRs.)
After that email/click, the LIR will go through the Process. I don't think any amount of policy simplification will reduce the work required per Process Instance at both the LIR and the RIR below two minutes. In the crypto(slash)security community this is called the proof-of-work system. [example deleted]
this certainly creates work for the applicant, possibly enough to slow down the process of ASN acquisition. It also creates work for the RIPE NCC and someone needs to pay the RIPE NCC bills both to develop and to operate the system. This cost will be borne by the LIRs and as a LIR, I'm not much keen on funding this sort of thing. Also the proposal doesn't include any sort of garbage collection mechanism. In a situation where we face short-term depletion of the resource, this is important. Nick
Hi Nick,
Also the proposal doesn't include any sort of garbage collection mechanism. In a situation where we face short-term depletion of the resource, this is important.
2007-01 was supposed to solve that, but its intentions as a reclaim/return incentive are not being implemented for ASNs at the moment. Let's see how the board and the members react to your statement at the last AGM. I'm not sure we should create another garbage collection mechanism. I would prefer the NCC to implement the existing one :) Cheers, Sander
On Mon, Jan 19, 2015 at 01:45:58PM -0800, Sander Steffann wrote:
I'm not sure we should create another garbage collection mechanism. I would prefer the NCC to implement the [2007-01] one
No thanks. The same heap of bureaucratic bullshit that is required to get PI space just to get an *ASN*? Not to mention the lulz that will result when a LIR applies for an ASN and the NCC refuses the request because the same entity can't be on both sides of the contract... Garbage collection can be more easily implemented, just request (annual?) confirmation the resource is still required, if the answer is negative, or there is none, reclaim it. (This could even be extended to PIv6) Also, what did I miss? When did ASNs become such a scarce resource that drastic rationing is required? rgds, Sascha Luck
On Mon, Jan 19, 2015 at 09:32:50PM +0000, Nick Hilliard wrote:
we all want a free lunch.
TANSTAAFL. But *nobody* wants Ryanair, where you pay and then pay again. And again. And again.
this certainly creates work for the applicant, possibly enough to slow down the process of ASN acquisition. It also creates work for the RIPE NCC and someone needs to pay the RIPE NCC
I'm sure this scenario is not beyond the limits of automation. One ASN per LIR, then block any more requests for 24h (or whatever). Any of the NCC software bods want to comment on how hard this could possible be? rgds, Sascha Luck
On 20/01/2015 00:17, Sascha Luck [ml] wrote:
On Mon, Jan 19, 2015 at 09:32:50PM +0000, Nick Hilliard wrote:
we all want a free lunch.
TANSTAAFL. But *nobody* wants Ryanair, where you pay and then pay again. And again. And again.
yes, TANSTAAFL. Doesn't stop me from wanting it though.
this certainly creates work for the applicant, possibly enough to slow down the process of ASN acquisition. It also creates work for the RIPE NCC and someone needs to pay the RIPE NCC
I'm sure this scenario is not beyond the limits of automation. One ASN per LIR, then block any more requests for 24h (or whatever). Any of the NCC software bods want to comment on how hard this could possible be?
The primary consideration should be whether the proposed policy mechanism is sound rather than on how much it would cost the NCC to implement it. I'm not convinced that creating more bureaucracy in an explicit attempt to make it more difficult for people to apply for ASNS is a good basis for creating policy. Nick
Hi, On 19/01/15 22:32, Nick Hilliard wrote: [...]
It also creates work for the RIPE NCC and someone needs to pay the RIPE NCC bills both to develop and to operate the system. This cost will be borne by the LIRs and as a LIR, I'm not much keen on funding this sort of thing. Are you sure this battle of yours is not so that you can go on one-week free trips to Bali paid by the LIRs? (like the IGF a couple of years ago)
I am asking this rude question because, I do not see why you come back with the argument that LIRs should not fund the NCC for assigning free ASNs. The members during the AGM have already decided to remove the 50E fee for ASNs a couple of years ago and you fight with all your strength to put it back on. Also, since we are talking about costs per LIRs, have you not noticed that the price an LIR has been paying has continuously decreased, almost every year? And this has been happening while the RIPE NCC budget has increased every year..
Also the proposal doesn't include any sort of garbage collection mechanism. In a situation where we face short-term depletion of the resource, this is important. There are 32bit ASNs available with the billions.. which short-term depletion are you referring to? The 16bit ASNs have, already, an exception in the proposed policy text "When requesting a 16-bit AS Number, the network must be multihomed within nine months of the assignment. Failure to multihome within this timeframe will result in deregistration of the assignment."
As for the garbage collection, the 50E/assignment will not fix the problem (in most of the cases) because most of the LIRs just pay without bothering to check whether the customer still needs the resource or may want to return it. Maybe the RIPE NCC can actually implement a method where it actually asks the customer or the LIR to confirm (by ticking a box ?) the resource is still needed, on a yearly basis.
Nick
/Elvis
On 20/01/2015 09:04, Elvis Daniel Velea wrote:
Are you sure this battle of yours is not so that you can go on one-week free trips to Bali paid by the LIRs? (like the IGF a couple of years ago)
Elvis, If you have concerns about the RIPE NCC member outreach program, it would be more appropriate to bring them up in a forum where they can be addressed properly, e.g. the ncc members mailing list, at a RIPE NCC General Meeting or directly with RIPE NCC management. Nick
Dear AP-WG, We are abandoning proposal 2014-03 due to our inability to find an acceptable solution which satisfies all parties. Thanks, Saku Ytti Job Snijders Authors of proposal 2014-03 "Remove Multihoming Requirement for AS Number"
participants (16)
-
Aleksi Suhonen
-
Daniel Stolpe
-
Elvis Daniel Velea
-
Elvis Daniel Velea
-
Erik Bais
-
Erik Bais - A2B Internet
-
Gert Doering
-
Hannigan, Martin
-
Job Snijders
-
Marco Schmidt
-
Nick Hilliard
-
Randy Bush
-
Saku Ytti
-
Sander Steffann
-
Sascha Luck [ml]
-
Tore Anderson