Policy Proposal 2006-02
Hi all, I just wanted to remind that this policy is in discussion phase until 19th. The policy proposal was updated from a previous version on January 17th, so even if you had said anything regarding this proposal on the previous version, you need to state it again on the current version, so the chairs can sense about it. So, insisting a bit, if you haven't provided yet your view either in favor or against *this version* of the proposal, better do so now. And many thanks in advance for doing so ! Regards, Jordi ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
To make it easier, I'm talking about "IPv6 Address Allocation and Assignment Policy" ... Here is the link to the proposal: http://www.ripe.net/ripe/policies/proposals/2006-02.html Regards, Jordi
De: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Responder a: <jordi.palet@consulintel.es> Fecha: Sun, 18 Mar 2007 16:44:52 +0100 Para: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Conversación: Policy Proposal 2006-02 Asunto: [address-policy-wg] Policy Proposal 2006-02
Hi all,
I just wanted to remind that this policy is in discussion phase until 19th.
The policy proposal was updated from a previous version on January 17th, so even if you had said anything regarding this proposal on the previous version, you need to state it again on the current version, so the chairs can sense about it.
So, insisting a bit, if you haven't provided yet your view either in favor or against *this version* of the proposal, better do so now. And many thanks in advance for doing so !
Regards, Jordi
********************************************** The IPv6 Portal: http://www.ipv6tf.org
Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
********************************************** The IPv6 Portal: http://www.ipv6tf.org
Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
JORDI PALET MARTINEZ wrote:
To make it easier, I'm talking about "IPv6 Address Allocation and Assignment Policy" ... Here is the link to the proposal:
8<------------------------------------ 2. plan to provide IPv6 connectivity to other organisations or to its own/related departments/entities/sites, to which it will make assignments. The assigned prefixes must be longer than the one allocated by RIPE NCC. The LIR must advertise the allocated address block through a single aggregated prefix. This prefix must be advertised within one year of the allocation being made; ----------------------------->8 "The assigned prefixes must be longer than the one allocated by RIPE NCC." is useless as the LIR can't pass a shorter prefix down as they don't have been assigned that portion. The "must be advertised" part causes any non-internet usage to be 'illegal'. Also the "must advertise.. single..prefix" part is currently already not being honored; also you cannot require this and there is currently no way to stop that. A way to stop it would be requiring S-BGP but that will not be done for the coming years. Also most likely S-BGP will still allow the owner of the certificate to announce more specifics. The whole more-specifics business depends on one factor: Money If you pay people enough or it is important enough one can announce it anyway and no RIR is going to stop that. Including that portion is just a lousy way of trying to inhibit routing table growth which will not work; as can be seen by the multitude of longer prefixes being announced into the global IPv6 routing tables already. (*) Lastly "# have a plan for making assignments within two years.", everybody has a PLAN to do something, actually doing it something else. As the number of assignments is removed, there is no way to check up on this, next to there not being any requirement of actually registering these assignments in the RIPE db, thus there is no way to check. Greets, Jeroen * = see http://ris.ripe.net and http://www.sixxs.net/tools/grh/ ;)
Hi Jeroen, See below, in-line. Regards, Jordi
De: Jeroen Massar <jeroen@unfix.org> Organización: Unfix Responder a: <jeroen@unfix.org> Fecha: Sun, 18 Mar 2007 20:05:53 +0000 Para: <jordi.palet@consulintel.es> CC: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] Policy Proposal 2006-02 (IPv6 Address Allocation and Assignment Policy)
JORDI PALET MARTINEZ wrote:
To make it easier, I'm talking about "IPv6 Address Allocation and Assignment Policy" ... Here is the link to the proposal:
8<------------------------------------ 2. plan to provide IPv6 connectivity to other organisations or to its own/related departments/entities/sites, to which it will make assignments. The assigned prefixes must be longer than the one allocated by RIPE NCC. The LIR must advertise the allocated address block through a single aggregated prefix. This prefix must be advertised within one year of the allocation being made; ----------------------------->8
"The assigned prefixes must be longer than the one allocated by RIPE NCC." is useless as the LIR can't pass a shorter prefix down as they don't have been assigned that portion.
The goal of this part of the text is to avoid that a prefix is received and assigned totally to the same customer. So yes, can't pass a shorter prefix, but could pass the same one and this will not be good as it can be a kind of "bypass" of the rule in order to provide an alternative way for doing PI to customer, which is not the intend of this proposal.
The "must be advertised" part causes any non-internet usage to be 'illegal'.
Yes, this has been already raised before. In my opinion is difficult to explain why an ISP could have a need to get a prefix and not use it in Internet. If that's the need (customer demand), then he has three possible alternatives (I'm not saying all are valid, but for sure one among these 3 will fit each possible case): - Use of link-local addresses - Use of ULA - Use of ULA-central (I know this is still not done, but I'm trying to revive it already and you will see soon a new policy proposal on this regards)
Also the "must advertise.. single..prefix" part is currently already not being honored; also you cannot require this and there is currently no way to stop that.
There are many details in may policies that are not being enforced by RIRs. That's debatable I think. Most of the LIRs follow the rules, some others not. I'm not arguing here if this is good or bad, as this part of the text is the same as in the existing proposal (may be different wording but exactly the same meaning). As explained in previous emails, if we want to change that, it will be better to do in a different policy proposal and have a different discussion about that, otherwise it may become difficult to achieve consensus in the main change here (removing the 200 /48).
A way to stop it would be requiring S-BGP but that will not be done for the coming years. Also most likely S-BGP will still allow the owner of the certificate to announce more specifics.
Yes, this is a possibility, but I think there is a more realistic one. Let market decide, if you break aggregation and as a consequence this cost money to the rest of the ISPs, some of them may decide to filter strictly on allocations and not accept more specifics. This already happens today.
The whole more-specifics business depends on one factor: Money If you pay people enough or it is important enough one can announce it anyway and no RIR is going to stop that.
Including that portion is just a lousy way of trying to inhibit routing table growth which will not work; as can be seen by the multitude of longer prefixes being announced into the global IPv6 routing tables already. (*)
Having the text in the policy helps to take measures if needed. Not having that text will not help at all, while keeping the text provide a possible way for the community to take actions, if required, and meanwhile doesn't hurt.
Lastly "# have a plan for making assignments within two years.", everybody has a PLAN to do something, actually doing it something else. As the number of assignments is removed, there is no way to check up on this, next to there not being any requirement of actually registering these assignments in the RIPE db, thus there is no way to check.
The point is not asking LIRs to lie about the "size" of the plan. Some LIRs could have a plan for just a few customer, and actually if they say the true, they will not get an allocation because they don't have a plan for 200 customers. So they could tell to RIPE that they have a plan for 200 customers and get the allocation. This is completely artificial. I don't believe anyone NOT willing to provide services will ask for an allocation. RIPE can check that at any time by asking customer contracts. However I think is wrong to set-up an artificial barrier and say if you are a small ISP and don't have 200 customers, you can't have access to an IPv6 block. I thought all the /48s assignments need to be registered (I may be wrong). So this is not changed by this policy proposal.
Greets, Jeroen
* = see http://ris.ripe.net and http://www.sixxs.net/tools/grh/ ;)
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
JORDI PALET MARTINEZ wrote: [..]
"The assigned prefixes must be longer than the one allocated by RIPE NCC." is useless as the LIR can't pass a shorter prefix down as they don't have been assigned that portion.
The goal of this part of the text is to avoid that a prefix is received and assigned totally to the same customer.
So you want to avoid a /48 to be allocated to an organization who can then use it at their own site? What is the use of changing that then?
So yes, can't pass a shorter prefix, but could pass the same one and this will not be good as it can be a kind of "bypass" of the rule in order to provide an alternative way for doing PI to customer, which is not the intend of this proposal.
You want to avoid "PI" but you also state in the proposal to make the policies the same as other RIRs. Bit strange as they don't have these changes, they have a separate PI policy. So for whom exactly are these changes that are proposed in this proposal? I don't see anyone really being helped by it and especially not the people who have actually been complaining.
The "must be advertised" part causes any non-internet usage to be 'illegal'.
Yes, this has been already raised before.
You stated that all the previous discussion was nullified and that all arguments should be raised again.
In my opinion is difficult to explain why an ISP could have a need to get a prefix and not use it in Internet. If that's the need (customer demand), then he has three possible alternatives (I'm not saying all are valid, but for sure one among these 3 will fit each possible case):
- Use of link-local addresses
Useless for this purpose as it only works on one link and is far from globally unique.
- Use of ULA - Use of ULA-central (I know this is still not done, but I'm trying to revive it already and you will see soon a new policy proposal on this regards)
Neither of these can be globally routed. A company might today want to move to IPv6 and not have their network routed, ULA will then be fine indeed. But what if the user want to change to public addresses? Then they would have to renumber, while they can better get a public registered address space first, not announce it, and then announce it anyway later on. Most networks will end up being connected to the Internet or to another network one day or another, being able to globally route it is thus a requirement for quite some organizations. ULA's thus don't cut it. Unless you want to see those popping up in a BGP near you.
Also the "must advertise.. single..prefix" part is currently already not being honored; also you cannot require this and there is currently no way to stop that.
There are many details in may policies that are not being enforced by RIRs.
Then don't include them. It's like saying that jaywalking is illegal while everybody does it and nobody will actually care. Don't make it too difficult, don't try to bury things in words.
That's debatable I think. Most of the LIRs follow the rules, some others not. I'm not arguing here if this is good or bad, as this part of the text is the same as in the existing proposal (may be different wording but exactly the same meaning).
It is in the original one with different words and they are not enforced either.
As explained in previous emails, if we want to change that, it will be better to do in a different policy proposal and have a different discussion about that, otherwise it may become difficult to achieve consensus in the main change here (removing the 200 /48).
This proposal changes the wording, you can then just as well also completely take out that part instead of fumbling with words.
A way to stop it would be requiring S-BGP but that will not be done for the coming years. Also most likely S-BGP will still allow the owner of the certificate to announce more specifics.
Yes, this is a possibility, but I think there is a more realistic one. Let market decide, if you break aggregation and as a consequence this cost money to the rest of the ISPs, some of them may decide to filter strictly on allocations and not accept more specifics. This already happens today.
If "let the market decide" is the answer then there is a MUCH easier one: just take 8000::/3 and start picking random blocks from there. No need for RIRs to be involved, saves a lot of hassle, and as long as you are large enough (content wise, user wise, money wise) you can get that prefix to be accepted anyway. Same goes for DNS and all other internet resources, they are just numbers. The biggest one wins.
The whole more-specifics business depends on one factor: Money If you pay people enough or it is important enough one can announce it anyway and no RIR is going to stop that.
Including that portion is just a lousy way of trying to inhibit routing table growth which will not work; as can be seen by the multitude of longer prefixes being announced into the global IPv6 routing tables already. (*)
Having the text in the policy helps to take measures if needed.
What can a RIR do against it? Say that the LIR can't use the prefix anymore? How will a RIR do that exactly? Tell them they are bad and evil? Come on, 3ffe::/24 is also still announced and that is now IANA's block again and in effect 'illegal' to be in use. [Bill, did you see the black helicopters around your house already? :) ]
Not having that text will not help at all, while keeping the text provide a possible way for the community to take actions, if required, and meanwhile doesn't hurt.
ISP's are already doing it and nothing is being done against it. They will and are creating their own PI without the 'community' being able to do anything about it: except filtering, which is not happening (yet)
Lastly "# have a plan for making assignments within two years.", everybody has a PLAN to do something, actually doing it something else. As the number of assignments is removed, there is no way to check up on this, next to there not being any requirement of actually registering these assignments in the RIPE db, thus there is no way to check.
The point is not asking LIRs to lie about the "size" of the plan. Some LIRs could have a plan for just a few customer, and actually if they say the true, they will not get an allocation because they don't have a plan for 200 customers. So they could tell to RIPE that they have a plan for 200 customers and get the allocation. This is completely artificial.
If it is artificial then why is it included? If they only have a plan for a few customers then they should say "we only need a /40" to RIPE and should be able to get that /40. Then again, address-space wise there is not much wasted in giving a /32 to everybody who wants it. (16^2 is a lot :)
I don't believe anyone NOT willing to provide services will ask for an allocation.
Why not? Maybe some company just wants address space to be able to say they have it. Just check the current allocations which are allocated but have not been announced in the last couple of years. Maybe they just want to secure their address space for later, how can you know, it is their company not yours.
RIPE can check that at any time by asking customer contracts.
And then they show 2x /33, one for their games department and one for their work department. Doesn't really help does it? As mentioned even if RIPE then finds out that it does not qualify, then what are they going to do?
However I think is wrong to set-up an artificial barrier and say if you are a small ISP and don't have 200 customers, you can't have access to an IPv6 block.
That is why I say: take it out completely. Don't make it more confusing than it already is. Especially not with artificial 'we are going to take it back' which is never going to happen.
I thought all the /48s assignments need to be registered (I may be wrong). So this is not changed by this policy proposal.
Clearly not as there are enough allocations that don't have a single assignment but they are announcing the whole block. Please check BGP before you try to make up a policy. Greets, Jeroen
Hi Jeroen, See below in-line. Regards, Jordi
De: Jeroen Massar <jeroen@unfix.org> Organización: Unfix Responder a: <address-policy-wg-admin@ripe.net> Fecha: Sun, 18 Mar 2007 21:01:43 +0000 Para: <jordi.palet@consulintel.es> CC: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] Policy Proposal 2006-02 (IPv6 Address Allocation and Assignment Policy)
JORDI PALET MARTINEZ wrote: [..]
"The assigned prefixes must be longer than the one allocated by RIPE NCC." is useless as the LIR can't pass a shorter prefix down as they don't have been assigned that portion.
The goal of this part of the text is to avoid that a prefix is received and assigned totally to the same customer.
So you want to avoid a /48 to be allocated to an organization who can then use it at their own site? What is the use of changing that then?
No, I want to avoid if an LIR get a /32 (minimum allocation as per existing policy) that it allocates the complete /32 to a single customer.
So yes, can't pass a shorter prefix, but could pass the same one and this will not be good as it can be a kind of "bypass" of the rule in order to provide an alternative way for doing PI to customer, which is not the intend of this proposal.
You want to avoid "PI" but you also state in the proposal to make the policies the same as other RIRs. Bit strange as they don't have these changes, they have a separate PI policy.
Out of context. What I'm saying is that other RIRs (LACNIC and AfriNIC) don't have already the requirement for 200 /48s, and I think is ridiculous for us to be more strict, especially when this is an artificial limit.
So for whom exactly are these changes that are proposed in this proposal? I don't see anyone really being helped by it and especially not the people who have actually been complaining.
Any LIR that want to do service, but doesn't have a plan for 200 sites and don't want to lie when requesting the prefix.
The "must be advertised" part causes any non-internet usage to be 'illegal'.
Yes, this has been already raised before.
You stated that all the previous discussion was nullified and that all arguments should be raised again.
No. What is not useful here is the "yes I'm in favor" or "I'm against" for the previous version of the proposal. Discussion is always useful, and in fact, this version tried to accommodate all the discussions in the previous version.
In my opinion is difficult to explain why an ISP could have a need to get a prefix and not use it in Internet. If that's the need (customer demand), then he has three possible alternatives (I'm not saying all are valid, but for sure one among these 3 will fit each possible case):
- Use of link-local addresses
Useless for this purpose as it only works on one link and is far from globally unique.
I clearly stated that I'm not saying all are valid, but one among these 3 ...
- Use of ULA - Use of ULA-central (I know this is still not done, but I'm trying to revive it already and you will see soon a new policy proposal on this regards)
Neither of these can be globally routed. A company might today want to move to IPv6 and not have their network routed, ULA will then be fine indeed. But what if the user want to change to public addresses? Then they would have to renumber, while they can better get a public registered address space first, not announce it, and then announce it anyway later on.
No need to renumber, they just need to use one more prefix (a global one), and keep using the existing ULA addressing if they still need it for internal routing, keeping separate overlay networks, or whatever. I think that somebody who plans adequately, will perfectly know if they need a global prefix in one year term, and they can announce it even if they decide not to allow incoming/outgoing traffic to the rest of the network. The proposal is not asking to explicitly make all the internal network to be visible, just to announce the prefix. Also we are not asking RIPE to verify to every RIR every detail that they need complain with every policy at every minute. Some flexibility is reasonable, and that provides in most of the cases, extra time to comply with the policy, without any impact in the community.
Most networks will end up being connected to the Internet or to another network one day or another, being able to globally route it is thus a requirement for quite some organizations. ULA's thus don't cut it. Unless you want to see those popping up in a BGP near you.
Filter them, in fact this should be a strong rule already in place in every router, same as per link-locals, etc.
Also the "must advertise.. single..prefix" part is currently already not being honored; also you cannot require this and there is currently no way to stop that.
There are many details in may policies that are not being enforced by RIRs.
Then don't include them. It's like saying that jaywalking is illegal while everybody does it and nobody will actually care. Don't make it too difficult, don't try to bury things in words.
That's debatable I think. Most of the LIRs follow the rules, some others not. I'm not arguing here if this is good or bad, as this part of the text is the same as in the existing proposal (may be different wording but exactly the same meaning).
It is in the original one with different words and they are not enforced either.
So what is the problem then ? If we actually have a problem on this, let's take it step by step, with another policy proposal. I learn the lesson that trying to make very complex changes in policy proposals is a "no way".
As explained in previous emails, if we want to change that, it will be better to do in a different policy proposal and have a different discussion about that, otherwise it may become difficult to achieve consensus in the main change here (removing the 200 /48).
This proposal changes the wording, you can then just as well also completely take out that part instead of fumbling with words.
I will be happy with that, but the consensus that I perceived is that the community don't like that. They want to have at least a plan, and I think is fair. I think we must rely on RIPE NCC staff to accept the plan or ask for further justification if its fuzzy.
A way to stop it would be requiring S-BGP but that will not be done for the coming years. Also most likely S-BGP will still allow the owner of the certificate to announce more specifics.
Yes, this is a possibility, but I think there is a more realistic one. Let market decide, if you break aggregation and as a consequence this cost money to the rest of the ISPs, some of them may decide to filter strictly on allocations and not accept more specifics. This already happens today.
If "let the market decide" is the answer then there is a MUCH easier one: just take 8000::/3 and start picking random blocks from there. No need for RIRs to be involved, saves a lot of hassle, and as long as you are large enough (content wise, user wise, money wise) you can get that prefix to be accepted anyway. Same goes for DNS and all other internet resources, they are just numbers. The biggest one wins.
I think you are being too extreme. What I'm saying is something already happening and not being a chaos. What you propose, will be a chaos :-(
The whole more-specifics business depends on one factor: Money If you pay people enough or it is important enough one can announce it anyway and no RIR is going to stop that.
Including that portion is just a lousy way of trying to inhibit routing table growth which will not work; as can be seen by the multitude of longer prefixes being announced into the global IPv6 routing tables already. (*)
Having the text in the policy helps to take measures if needed.
What can a RIR do against it? Say that the LIR can't use the prefix anymore? How will a RIR do that exactly? Tell them they are bad and
SBGP is not enough ? Some (just a few) LIRs filtering the prefix will make it unusable.
evil? Come on, 3ffe::/24 is also still announced and that is now IANA's block again and in effect 'illegal' to be in use.
I don't see those prefixes, are filtered out, and many people do the same, I guess. So not an issue, not useful for who is using those prefixes. I think right now only 1 entity in the world in just 7.5 months since released, not bad, actually it took less than 3 months as I recall, to get only 1 entity announcing it.
[Bill, did you see the black helicopters around your house already? :) ]
Not having that text will not help at all, while keeping the text provide a possible way for the community to take actions, if required, and meanwhile doesn't hurt.
ISP's are already doing it and nothing is being done against it. They will and are creating their own PI without the 'community' being able to do anything about it: except filtering, which is not happening (yet)
I can tell you that some are getting filtered. Even people receiving /48 PI from ARIN has issues, as they told me two weeks ago. May be they will be lucky and will get sorted out, but filtering works.
Lastly "# have a plan for making assignments within two years.", everybody has a PLAN to do something, actually doing it something else. As the number of assignments is removed, there is no way to check up on this, next to there not being any requirement of actually registering these assignments in the RIPE db, thus there is no way to check.
The point is not asking LIRs to lie about the "size" of the plan. Some LIRs could have a plan for just a few customer, and actually if they say the true, they will not get an allocation because they don't have a plan for 200 customers. So they could tell to RIPE that they have a plan for 200 customers and get the allocation. This is completely artificial.
If it is artificial then why is it included?
I'm not sure what text are you reading. No longer 200 included. That was artificial and we need to get rid off it.
If they only have a plan for a few customers then they should say "we only need a /40" to RIPE and should be able to get that /40.
Not under existing policy. And if we agree on that, it will need to be in a different policy proposal offering different allocation lengths depending on the number of possible customers, or whatever. I'm not saying yes or not, just take each thing step by step if we want to move after so many years and so many failures and work of so many people to remove this artificial barrier.
Then again, address-space wise there is not much wasted in giving a /32 to everybody who wants it. (16^2 is a lot :)
I don't believe anyone NOT willing to provide services will ask for an allocation.
Why not? Maybe some company just wants address space to be able to say they have it. Just check the current allocations which are allocated but have not been announced in the last couple of years.
People is getting ready, it takes time, and priorities change, but they will use it. If not, following policy, could be reclaimed, if the community decides to do so.
Maybe they just want to secure their address space for later, how can you know, it is their company not yours.
I don't think this is a general rule, and actually I think it is easier for small ISPs to start providing the service than for bigger ones. Smaller ones tend to me much more "agile".
RIPE can check that at any time by asking customer contracts.
And then they show 2x /33, one for their games department and one for their work department. Doesn't really help does it?
No, existing policy ask for justification if you assign more than /48 to a single customer, so it will not work, even they will be in troubles before doing the assignment because RIPE NCC will not accept a justification for a /33 for their games department unless they demonstrate that a /48 is not enough.
As mentioned even if RIPE then finds out that it does not qualify, then what are they going to do?
Reclaim the space, check with the community, whatever. We should be doing the same with IPv4, and may be sooner or later we will end up doing so. But if we don't have a way to "secure" it in the policy, if time arrives could never do that.
However I think is wrong to set-up an artificial barrier and say if you are a small ISP and don't have 200 customers, you can't have access to an IPv6 block.
That is why I say: take it out completely. Don't make it more confusing than it already is. Especially not with artificial 'we are going to take it back' which is never going to happen.
See my previous comment, I will agree with that, but inputs received are that the people to prefer to make sure that there is a plan at least.
I thought all the /48s assignments need to be registered (I may be wrong). So this is not changed by this policy proposal.
Clearly not as there are enough allocations that don't have a single assignment but they are announcing the whole block.
Ok, but then take it as a different issue, and as a member of the community, ask why LIRs don't do that, and if there is no need for it remove that part of the policy, etc. As said, let's work step by step.
Please check BGP before you try to make up a policy.
:-)
Greets, Jeroen
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
[Bill, see somewhere half way through this rumble, a Q about why 3ffe::/24 is still alive and announced ;) ] JORDI PALET MARTINEZ wrote:
"The assigned prefixes must be longer than the one allocated by RIPE NCC." is useless as the LIR can't pass a shorter prefix down as they don't have been assigned that portion. <----- white space is useful The goal of this part of the text is to avoid that a prefix is received and assigned totally to the same customer. <----- white space is useful So you want to avoid a /48 to be allocated to an organization who can then use it at their own site? What is the use of changing that then?
No, I want to avoid if an LIR get a /32 (minimum allocation as per existing policy) that it allocates the complete /32 to a single customer.
Why would you want to avoid that? Maybe they can justify the need for it? Most sites won't be able to do that though, it is a bit too much. But as you like looking at other regions, in those other regions several large corporations (that is without primary objective being ISP) have received an allocation. Do you really think that they are going to play ISP for other companies? As you want to equal the policies out, according to your proposal, did you take this in consideration with the above line? Also they still have to justify this to the RIR, so why is this line needed again? It is just an artificial barrier.
So yes, can't pass a shorter prefix, but could pass the same one and this will not be good as it can be a kind of "bypass" of the rule in order to provide an alternative way for doing PI to customer, which is not the intend of this proposal. <----- white space is useful You want to avoid "PI" but you also state in the proposal to make the policies the same as other RIRs. Bit strange as they don't have these changes, they have a separate PI policy.
Out of context. What I'm saying is that other RIRs (LACNIC and AfriNIC) don't have already the requirement for 200 /48s, and I think is ridiculous for us to be more strict, especially when this is an artificial limit.
If you don't have even a PLAN to ever use 200 of the /48's out of the 65536 that you will be assigned, then what is the use of getting a /32 of address space? If people only require a /48 then give them a /48, if they require a /40, give them a /40. Don't waste address space; yes there is enough, but throwing it away is futile too.
The "must be advertised" part causes any non-internet usage to be 'illegal'. Yes, this has been already raised before. <----- white space is useful You stated that all the previous discussion was nullified and that all arguments should be raised again.
No. What is not useful here is the "yes I'm in favor" or "I'm against" for the previous version of the proposal. Discussion is always useful, and in fact, this version tried to accommodate all the discussions in the previous version.
Saying "yes" or "no" without argumentation is useless. And I've made enough arguments to show why. [..]
I clearly stated that I'm not saying all are valid, but one among these 3
Why name something when you know it is not valid or even relevant? [..]
No need to renumber, they just need to use one more prefix (a global one), and keep using the existing ULA addressing if they still need it for internal routing, keeping separate overlay networks, or whatever.
Ever ran a network larger than ~25 computers? Multiple prefixes on the same link leads to a lot of issues that a lot of people want to avoid. It is a great idea, it is great that the possibility exists, but it is not so great in practice. If having those multiple addresses, in multiple prefixes was easy to do then there would not be a huge multihoming discussion, people would be using it don't you think? Ever tried running multiple prefixes of the same host and making sure your source address selection is correct on all the platforms that are in a large business!?
I think that somebody who plans adequately, will perfectly know if they need a global prefix in one year term, and they can announce it even if they decide not to allow incoming/outgoing traffic to the rest of the network.
So you do think that planning is a good idea? Then planning for 200 /48's in a LIR should not be a problem would it?
The proposal is not asking to explicitly make all the internal network to be visible, just to announce the prefix.
Announce it where? If it is 'announced' internally it might just be a static route. Really the RIR's have nothing do with with routing, Network Operators take care of that. As I mentioned before, they decide what gets blocked, announced, accepted etc, it is their network, not the RIR's. If they get payed enough or deem a site important enough they will route the prefix, how many times a RIR will say they can't or not. Same goes for protocols, proto-people don't like bittorrent, but everybody uses it, that is the freedom of the Internet.
Also we are not asking RIPE to verify to every RIR every detail that they need complain with every policy at every minute. Some flexibility is reasonable, and that provides in most of the cases, extra time to comply with the policy, without any impact in the community.
You actually are saying what (as you mention courts in your proposal) every court will dislike: that a RIR can, because of this wording, randomly pick out a LIR and pick on them whatever they want. Now that is illegal business practices.
Most networks will end up being connected to the Internet or to another network one day or another, being able to globally route it is thus a requirement for quite some organizations. ULA's thus don't cut it. Unless you want to see those popping up in a BGP near you.
Filter them, in fact this should be a strong rule already in place in every router, same as per link-locals, etc.
That is why the 6bone (3ffe::/24 that is) is still reachable at most sites. And also why there are people having loads of problems with 69.0.0.0/8 (See http://69box.atlantic.net/). The C&W folks, who got the first /20 can also tell you how long it took them to get their perfectly valid prefix unfiltered. And the IPv6 BGP is only comprising of a relatively small number of ISP's at the moment. Filter is NOT good. It will hurt, not today, but it will tomorrow. [..]
So what is the problem then ?
As I mentioned, thus again: the sentence is useless, take it out.
If we actually have a problem on this, let's take it step by step, with another policy proposal. I learn the lesson that trying to make very complex changes in policy proposals is a "no way".
And you know very well how long it takes to make a proposal and to get people to more or less agree on it. If the old one was 'good enough' and 'the same' then why did you change the wording?
As explained in previous emails, if we want to change that, it will be better to do in a different policy proposal and have a different discussion about that, otherwise it may become difficult to achieve consensus in the main change here (removing the 200 /48). <----- white space is useful This proposal changes the wording, you can then just as well also completely take out that part instead of fumbling with words.
I will be happy with that, but the consensus that I perceived is that the community don't like that.
They want to have at least a plan, and I think is fair. Funny that you say that 'having is a plan is fair', while the whole
Your perception of something is not the final answer. point of this proposal is to remove having a plan, as, according to the proposal, that would be bad in the courts. Which court btw? Do remember that there is no such thing as an Internet court. The plan is anyway implicit, if you don't have a need for address space then you should not get it in the first place as you don't show demand to actually use the address space. The 200 number is there solely to delimit between organizations getting a /32 or ones who are only endsites and should get a /40 or a /48. It might be out of thin air but it is a reasonable measure. Maybe a better number for getting a /32 is actually 20.000 sites, as then one is actually filling up that /32 of address space. It is only a PLAN. Nobody will enforce it, nobody can enforce it (except for other ISP's, if they don't like you they won't accept/route/transit your prefix, if a RIR assigned it or not)
I think we must rely on RIPE NCC staff to accept the plan or ask for further justification if its fuzzy.
Which is what they are already doing and have been doing for years.
A way to stop it would be requiring S-BGP but that will not be done for the coming years. Also most likely S-BGP will still allow the owner of the certificate to announce more specifics. <----- white space is useful Yes, this is a possibility, but I think there is a more realistic one. Let market decide, if you break aggregation and as a consequence this cost money to the rest of the ISPs, some of them may decide to filter strictly on allocations and not accept more specifics. This already happens today. <----- white space is useful If "let the market decide" is the answer then there is a MUCH easier one: just take 8000::/3 and start picking random blocks from there. No need for RIRs to be involved, saves a lot of hassle, and as long as you are large enough (content wise, user wise, money wise) you can get that prefix to be accepted anyway. Same goes for DNS and all other internet resources, they are just numbers. The biggest one wins.
I think you are being too extreme. What I'm saying is something already happening and not being a chaos. What you propose, will be a chaos :-(
I don't propose that (did I fill in some form somewhere?) it is what one could do if one really wanted to. If, say, Google would take 198.18.0.0/15 and start serving YouTube and Gmail from it, stopping access over IPv4, I am very confident that a lot of ISP's will start routing it for them. Same goes for IPv6. The RIR's have no power over the routing system, and there is also nobody who can sue anybody over it. (Fastweb using 23.0.0.0/8 and a number of others for instance)
The whole more-specifics business depends on one factor: Money If you pay people enough or it is important enough one can announce it anyway and no RIR is going to stop that.
Including that portion is just a lousy way of trying to inhibit routing table growth which will not work; as can be seen by the multitude of longer prefixes being announced into the global IPv6 routing tables already. (*) <----- white space is useful Having the text in the policy helps to take measures if needed. What can a RIR do against it? Say that the LIR can't use the prefix anymore? How will a RIR do that exactly? Tell them they are bad and
SBGP is not enough ? Some (just a few) LIRs filtering the prefix will make it unusable.
No, because a LIR is typically a leaf. Now if a *transit* would filter it, then it would wreak havoc. But fortunately transits get payed by their customers, who are the leafs, thus if they complain hard enough, or simply not pay, then it will be restored again. Again: there is no single power on the Internet. For that matter, there is no single "Internet". The "Internet" is what people perceive as useful and try to use. Next to that, prefixes can also be used internally of course, which is why I mentioned that the 'announce' clause is useless too. Announce it where? on the local IX, which is that WRT54GS in the cupboard connecting me and my neighbors? It is an IX, as they have IPv6 /48's and we interconnect and we are also multiple parties.
evil? Come on, 3ffe::/24 is also still announced and that is now IANA's block again and in effect 'illegal' to be in use.
I don't see those prefixes, are filtered out, and many people do the same, I guess.
Not enough people, see GRH.
So not an issue, not useful for who is using those prefixes.
If it is not useful, why does somebody then announce them? Bill can you give an answer? :)u
I think right now only 1 entity in the world in just 7.5 months since released, not bad, actually it took less than 3 months as I recall, to get only 1 entity announcing it.
Because I and some other people have been actively bashing people to get it out of their routing systems. A lot of places where not even AWARE that 6bone was going away, even though it was very clearly announced. Oh, before you ask, even people holding and announcing pTLA's didn't know about it; a large amount of the folks who shutdown after 6-6-6 where in that camp. Why? -> they didn't care less or simply forgot all about it.
[Bill, did you see the black helicopters around your house already? :) ]
Not having that text will not help at all, while keeping the text provide a possible way for the community to take actions, if required, and meanwhile doesn't hurt. <----- white space is useful ISP's are already doing it and nothing is being done against it. They will and are creating their own PI without the 'community' being able to do anything about it: except filtering, which is not happening (yet)
I can tell you that some are getting filtered. Even people receiving /48 PI from ARIN has issues, as they told me two weeks ago. May be they will be lucky and will get sorted out, but filtering works.
So here you say yourself that filtering is hurting people, but you still want people to filter as you mention above!? Quite a bit of a contradiction don't you think?
Lastly "# have a plan for making assignments within two years.", everybody has a PLAN to do something, actually doing it something else. As the number of assignments is removed, there is no way to check up on this, next to there not being any requirement of actually registering these assignments in the RIPE db, thus there is no way to check. <------- this one was missing which made you confused The point is not asking LIRs to lie about the "size" of the plan. Some LIRs could have a plan for just a few customer, and actually if they say the true, they will not get an allocation because they don't have a plan for 200 customers. So they could tell to RIPE that they have a plan for 200 customers and get the allocation. This is completely artificial. If it is artificial then why is it included?
I'm not sure what text are you reading. No longer 200 included. That was artificial and we need to get rid off it.
Mind the quoting, all the 200's where your text, I only wrote a single line: "If it is artificial then why is it included?" I suggest that you don't fumble the quoting by removing white space between the replies, that saves on this muttering. Note the line with "<---" for clarity.
If they only have a plan for a few customers then they should say "we only need a /40" to RIPE and should be able to get that /40.
Not under existing policy. And if we agree on that, it will need to be in a different policy proposal offering different allocation lengths depending on the number of possible customers, or whatever.
Then can this proposal and write one which actually makes sense.
I'm not saying yes or not, just take each thing step by step if we want to move after so many years and so many failures and work of so many people to remove this artificial barrier.
Doesn't work if there are so many wrong things with this proposal, and the things I mentioned you still have not addressed.
Then again, address-space wise there is not much wasted in giving a /32 to everybody who wants it. (16^2 is a lot :)
I don't believe anyone NOT willing to provide services will ask for an allocation. <----- white space is useful Why not? Maybe some company just wants address space to be able to say they have it. Just check the current allocations which are allocated but have not been announced in the last couple of years.
People is getting ready, it takes time, and priorities change, but they will use it. If not, following policy, could be reclaimed, if the community decides to do so.
People _are_ getting ready, but more because they have to to win their government contracts than that they see an actual need. Reclamation does not happen. The cost is too high and the winnings are too futile. Especially for IPv6 this is the case, at least for the years too come till we run out of 2000::/3 ;)
Maybe they just want to secure their address space for later, how can you know, it is their company not yours.
I don't think this is a general rule, and actually I think it is easier for small ISPs to start providing the service than for bigger ones. Smaller ones tend to me much more "agile".
What you are actually saying with the above is that a small company doesn't need to have 5 layers of management approve things. A large company can also get address space now, set up a tunnel broker internally, or use ISATAP or a similar technology and start providing IPv6 to their clients without much of a problem. Which is actually how a number of large ISP's solved their IPv6 issue.
RIPE can check that at any time by asking customer contracts. And then they show 2x /33, one for their games department and one for their work department. Doesn't really help does it?
No, existing policy ask for justification if you assign more than /48 to a single customer, so it will not work, even they will be in troubles before doing the assignment because RIPE NCC will not accept a justification for a /33 for their games department unless they demonstrate that a /48 is not enough.
Then why remove the plan if they can't use the assignment anyway? This also comes back to the "do not assign larger than own prefix" line, if the RIR can decide then why include it?
As mentioned even if RIPE then finds out that it does not qualify, then what are they going to do?
Reclaim the space, check with the community, whatever.
"whatever", indeed. Have you ever seen address space being reclaimed? Ever tried to calculate how much effort it would be?
We should be doing the same with IPv4, and may be sooner or later we will end up doing so. But if we don't have a way to "secure" it in the policy, if time arrives could never do that.
Did you ever read slides from Geoff Huston or various of the other people talking about IPv4 address depletion and that reclamation is more trouble than it is worth?
I thought all the /48s assignments need to be registered (I may be wrong). So this is not changed by this policy proposal. <--- white space is useful Clearly not as there are enough allocations that don't have a single assignment but they are announcing the whole block.
Ok, but then take it as a different issue, and as a member of the community, ask why LIRs don't do that, and if there is no need for it remove that part of the policy, etc.
Simple: they don't want to put in a public database who their customers are.
As said, let's work step by step.
Then the first good step is to can this proposal and write a proposal which makes sense. Argumentation in the various emails I, and others, have already sent about this.
Please check BGP before you try to make up a policy.
:-)
Smileys don't help, have you already checked it by now? http://www.sixxs.net/tools/grh/ has a lot of information for you. And of course don't forget to check http://ris.ripe.net which is also a great service to get at least a little bit of background in these matters. Greets, Jeroen
The "must be advertised" part causes any non-internet usage to be 'illegal'.
I disagree. The text states "This prefix must be advertised within one year of the allocation being made". It doesn't state where the announcement should be made. If the prefix is announced on a private network, then the LIR has satisfied their obligation to this clause.
As the number of assignments is removed, there is no way to check up on this, next to there not being any requirement of actually registering these assignments in the RIPE db, thus there is no way to check.
The alternative at the moment is that people lie about their requirements - as they do, regularly. The bottom line here is that unlike ipv4, there is no practical scarcity of ipv6 address space. The statement that you refer to means in practice: "as a LIR, you are entitled to an ipv6 address block, so long as you tell us that you have plans to do something, at some stage". Is this a bad thing? Are you really saying that RIPE should create barriers to allocating ipv6 space to LIRs? If you want barriers, could you please explain why? Why shouldn't a bona-fide LIR be allocated a first ipv6 /32 as a matter of course? What are they becoming LIRs for, if not to sub-assign address space? As an interim solution, I'm in favour of this proposal as it stands and believe that it should go though. We've wrangled about it long enough, without making a large amount of headway. Meanwhile, LIRs are being forced to lie to get ipv6 space, which IMHO is plain stupid. However, I would like to see a proposal in the future to remove the requirement prohibiting de-aggregation. Firstly, routing table announcement policies are not RIPE's business. Secondly, de-aggregation and ipv6 table size will simply not be as much of a problem in ipv6 as ipv4, because a) there is no supply constraint and therefore no reason to split larger blocks, b) we've come a long way since ipv4 assignment started and now have good policies in place which will strongly encourage aggregation and c) most larger operators are - by policy - going to filter on RIR allocation boundaries for PA ipv6 space anyway, which means that in practice de-aggregation is not going to be very useful. Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie
Nick Hilliard wrote:
The "must be advertised" part causes any non-internet usage to be 'illegal'.
I disagree. The text states "This prefix must be advertised within one year of the allocation being made". It doesn't state where the announcement should be made. If the prefix is announced on a private network, then the LIR has satisfied their obligation to this clause.
True, one could read it like that indeed. As Randy Bush tends to say 'which Internet'. But that is not the intent of the letter. If you are reading like that, then the "200 issue" is not an issue either, as then I will name every mouse in the world a organization and assign them all a /48.
As the number of assignments is removed, there is no way to check up on this, next to there not being any requirement of actually registering these assignments in the RIPE db, thus there is no way to check.
The alternative at the moment is that people lie about their requirements - as they do, regularly.
Which is why I say to drop it completely. Don't ask for anything of the sort.
The bottom line here is that unlike ipv4, there is no practical scarcity of ipv6 address space.
The problem is that there is an expected shortage in 'routing table size'. For the rest there is no other problem.
The statement that you refer to means in practice: "as a LIR, you are entitled to an ipv6 address block, so long as you tell us that you have plans to do something, at some stage".
So here you want to infer something from a shorter bit of text again? While with the above sentence you want to keep it to the letter and claim that it is everywhere? Reading texts the way you like it at the moment that you want it is not what is meant with the text. You are not okay with ignoring the 200 issue, which is only a plan, and who doesn't have a plan, but you do want other text to be changed because you can't read over it!?
Is this a bad thing? Are you really saying that RIPE should create barriers to allocating ipv6 space to LIRs? If you want barriers, could you please explain why?
I have never mentioned such a thing. Please quote me if and where I did. Short summary of my vision: - Anyone who can pay $fee to RIR should be able to get a /48 or larger. - Size depends on what needs they have. and that is all. The fee is still there mainly there so that not every Joe Smuck goes around getting address space, a little barrier (monopoly anyone :) There is no way around that. Clearly there are people who currently complain already that LIR fees are too high, while their bandwidth bills are much much much higher and that they can probably cover those costs with ease with their income. If they can't, they are most likely in the wrong business.
Why shouldn't a bona-fide LIR be allocated a first ipv6 /32 as a matter of course?
Because address space should be given out on a 'per-need' basis, not on a 'you paid 1500 eur a year here have space' kind of deal. If they only need a single /48 (which currently is the minimum to give to a site, until the /56 proposal goes through) then they should only ge t a /48. If they have a huge plan of requiring at one stage way more address space, then they are planning for at least 200 sites (/32 has 65k of them) and then they should be able to get a /32.
What are they becoming LIRs for, if not to sub-assign address space?
Most LIR's are LIR so that they have address space for their own business, not for other businesses. That is, they delegate chunks of their PA space down to their customers. Which is NOT *PI*, which is what most people who are complaining at the moment want. PI Is also what ARIN has given to their members, no change was made in the PA policy. RIPE folks can probably give the stats on how many LIR's actually give PI out and how many PA's have been 'sub-assigned'.
As an interim solution, I'm in favour of this proposal as it stands and believe that it should go though.
As I asked Jordi: which type of organizations does this policy help to get address space and which ones are still left in the cold ?
We've wrangled about it long enough, without making a large amount of headway. Meanwhile, LIRs are being forced to lie to get ipv6 space, which IMHO is plain stupid.
Good that you did not PGP sign that eh ;) What is plain stupid is that you lied for it. If you are not going to use a /32, or whatever amount of address space that you received, then why did you lie for it? What you should have done is made a proposal in which you would not have to lie. Submit it and then not revoke it.
However, I would like to see a proposal in the future to remove the requirement prohibiting de-aggregation.
Which is what I mentioned what has to be changed, or more specifically, simply be dropped from the revised text.
Firstly, routing table announcement policies are not RIPE's business. Secondly, de-aggregation and ipv6 table size will simply not be as much of a problem in ipv6 as ipv4, because a) there is no supply constraint and therefore no reason to split larger blocks
Ever heard of the magical words "Traffic Engineering"? As that is the cause of lots of /24s being announced, not because so many people have their small multihomed blocks.
b) we've come a long way since ipv4 assignment started and now have good policies in place which will strongly encourage aggregation
Which policies are those?
and c) most larger operators are - by policy - going to filter on RIR allocation boundaries for PA ipv6 space anyway,
This is clearly not the case, look at the current BGP tables. Both the IPv4 and IPv6 ones btw... Greets, Jeroen
Ever heard of the magical words "Traffic Engineering"? As that is the cause of lots of /24s being announced, not because so many people have their small multihomed blocks.
<offtopic> In this case, I meant no good reason due to address space assignment constraints. Yes, traffic engineering issues will always exist, just as no-export does. </offtopic> Nick
participants (3)
-
Jeroen Massar -
JORDI PALET MARTINEZ -
Nick Hilliard