Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01)
Hi all, Sorry confused stats. Ignore the previous email ... As the discussion period for this proposal (http://www.ripe.net/ripe/policies/proposals/2006-01.html) is almost over, I will like to ask for the latest inputs in order to further decide how to proceed. Filiz arranged some stats about the discussion (thanks a lot for that !) last July, and afterwards, even if the discussion period has been extended, I don't recall having seen new comments. The stats don't include my own postings:
- there were 9 posts from 8 individuals about it.
- 5 people supported it. 1 of these made some comments though, that he prefers a longer prefix than a /32 clearly in his mail.
- 1 person stated he supports "PI" but he is not supporting this proposal.
- 2 people said "No".
So someone else will like to say anything new or clarify their view in favor or opposition to the proposal ? 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.
On Wed, Sep 27, 2006 at 11:56:10AM +0200, JORDI PALET MARTINEZ wrote:
Hi all,
Sorry confused stats. Ignore the previous email ...
As the discussion period for this proposal (http://www.ripe.net/ripe/policies/proposals/2006-01.html) is almost over, I will like to ask for the latest inputs in order to further decide how to proceed.
Filiz arranged some stats about the discussion (thanks a lot for that !) last July, and afterwards, even if the discussion period has been extended, I don't recall having seen new comments.
The stats don't include my own postings:
- there were 9 posts from 8 individuals about it.
- 5 people supported it. 1 of these made some comments though, that he prefers a longer prefix than a /32 clearly in his mail.
- 1 person stated he supports "PI" but he is not supporting this proposal.
- 2 people said "No".
So someone else will like to say anything new or clarify their view in favor or opposition to the proposal ? I beleive most arguments have been spoken so I see no reason to delve further into this discussion but will instead promptly place my vote in favour of this proposal.
Best regards, Kristian. -- Kristian Larsson KLL-RIPE Network Engineer Net at Once [AS35706] +46 704 910401 kristian@spritelink.se
Jordi, I support PI for IPv6 but I personally do not like the section: "Expiry for Assignments: Assignment blocks made under this proposal to address Multihoming issues must be returned to the RIPE NCC after a maximum period of three years. The three year period will run from the date that an alternative technically valid and deployable solution becomes available and is accepted by the Internet community. Any organisations that want to avoid renumbering would, at this time, be able to opt to become an LIR, if they qualify, and be allocated the same prefix." I'd recommend copying the accepted ARIN PI policy verbatim. One could discuss /32 or /48 but I would prefer a global policy over a regional policy. I won't be at the next RIPE meeting (have other commitments) but as one of the authors of NATO's IPv6 adoption plan I do not like the Expiry section although I understand that its there as a compromise. (We recommend in our plan for NATO to adopt the LIR route instead). So this is my vote: I support PI for IPv6 but I do not support this proposal. I recommend to follow ARIN which has beaten us to it... Best regards, Marc van Selm On Wednesday 27 September 2006 11:56, JORDI PALET MARTINEZ wrote:
Hi all,
Sorry confused stats. Ignore the previous email ...
As the discussion period for this proposal (http://www.ripe.net/ripe/policies/proposals/2006-01.html) is almost over, I will like to ask for the latest inputs in order to further decide how to proceed.
Filiz arranged some stats about the discussion (thanks a lot for that !) last July, and afterwards, even if the discussion period has been extended, I don't recall having seen new comments.
The stats don't include my own postings:
- there were 9 posts from 8 individuals about it.
- 5 people supported it. 1 of these made some comments though, that he prefers a longer prefix than a /32 clearly in his mail.
- 1 person stated he supports "PI" but he is not supporting this proposal.
- 2 people said "No".
So someone else will like to say anything new or clarify their view in favor or opposition to the proposal ?
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.
-- -- This mail is personal -- All statements in this mail are made from my own personal perspective and do not necessarily reflect my employer's opinions or policies.
I support PI for IPv6 but I personally do not like the section:
"Expiry for Assignments:
I agree that putting in an expiry date for non-experimental allocations is a bad idea. The only time an expiry date makes sense is when the allocation is being used for some kind of network research on a temporary basis. RIPE has the opportunity to change its policies at any time and if it is necessary to claw back those allocations then it could be done by a future change of policy. The people who make that future policy will be better informed about the situation than we are because they will have factual data about PI allocations. We can only guess about what will happen. It is far better to make sure that all organizations who receive assignments or allocations direct from RIPE have some kind of contractual obligation to RIPE and that contract includes the obligation to maintain accurate contact information. It doesn't mean that they have to publish the information, just make sure RIPE knows when they move or get bought by someone else so that if the policy changes in the future, we know where to contact them. This way we avoid the swamp problem where nobody knows how to contact many of the orgs that received swamp allocations. They may still exist at new addresses with a new name but we have lost touch. --Michael Dillon
Michael.Dillon@btradianz.com wrote:
I support PI for IPv6 but I personally do not like the section:
"Expiry for Assignments:
Nor do I. In particular I am missing a common understanding of how this is supposed to work in real life, regarding the path of submitting a request. Both from the point of view of a potential conflict of interest if we assume the same arrangement like for v4-PI, i.e. find a friendly LIR in good standing and ask them to submit the request on their account. This particularly delicate if the *assignment* size would remain at /32 as proposed, equal to the LIRs *allocation* size. And this approach of requesting resources "by proxy" has unwanted side effects like financial implications or loss of contact with the holder of the PI block. One of the real show-stoppers for me is (quote from the Proposal): "Any organisations that want to avoid renumbering would, at this time, be able to opt to become an LIR, if they qualify, and be allocated the same prefix." I am sorry, this doesn't cut it. So here is another formal change request: "An organisation that intends to request IPv6 PI Addresses under "this" policy have to become a Member of the RIPE NCC. The address assignment remains valid as long as the ... you know :-)" Cancelling the contractual relationship with the NCC should have the "usual" consequences, including those still to be developed like expiration of the digital certificate or RevDNS service, or address recalamtion, or... Btw, - what we are doing here is sort of opening a (controlled?) way around the 200 Customer Rule. Wilfried.
Hi Marc, Thanks a lot for your comments. Let me try to explain my motivation for the expiry date: Being honest with ourselves. The point is that some people don't like PI (including myself), while some other people may believe that may be (or not) an alternative technical solution in the future. Setting a temporary policy say everybody "this is only until we have a solution". In fact it is not required *because* the community can just cancel this policy when this solution is available, but it seem to me more honest to say in advance what is our plan (which anyway, can be changed in the future). Somehow, in my point of view, it may help to avoid some PI assignments if they are not *really* needed, or when regular assignments are possible (for example your own case, suggesting that because the type of infrastructure/organization, its better to go for becoming an LIR). Regarding the /32 or /48, I think we had very long discussions on that. I just don't believe the /48 will be reachable from all the networks, because many filter longer prefixes than /32, and this is not going to change easily, so consequently, I don't think people requiring PI, will take the risk. Is a non-sense asking for PI but not being sure it will be visible everywhere ... I've some cases of critical infrastructures which have got /48 instead of /32 and they are not visible, quite nice and *critical* for a critical infrastructure :-( Last, but not least, I also will prefer a "common" policy across the different regions, but I think we can't call it "global", because ICANN process, and in any case, it may be very difficult to coordinate that if not too late and impossible ... Regards, Jordi
De: Marc van Selm <marc.van.selm@nc3a.nato.int> Responder a: <address-policy-wg-admin@ripe.net> Fecha: Thu, 28 Sep 2006 09:50:30 +0200 Para: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01)
Jordi,
I support PI for IPv6 but I personally do not like the section:
"Expiry for Assignments: Assignment blocks made under this proposal to address Multihoming issues must be returned to the RIPE NCC after a maximum period of three years. The three year period will run from the date that an alternative technically valid and deployable solution becomes available and is accepted by the Internet community. Any organisations that want to avoid renumbering would, at this time, be able to opt to become an LIR, if they qualify, and be allocated the same prefix."
I'd recommend copying the accepted ARIN PI policy verbatim. One could discuss /32 or /48 but I would prefer a global policy over a regional policy.
I won't be at the next RIPE meeting (have other commitments) but as one of the authors of NATO's IPv6 adoption plan I do not like the Expiry section although I understand that its there as a compromise. (We recommend in our plan for NATO to adopt the LIR route instead). So this is my vote: I support PI for IPv6 but I do not support this proposal. I recommend to follow ARIN which has beaten us to it...
Best regards, Marc van Selm
On Wednesday 27 September 2006 11:56, JORDI PALET MARTINEZ wrote:
Hi all,
Sorry confused stats. Ignore the previous email ...
As the discussion period for this proposal (http://www.ripe.net/ripe/policies/proposals/2006-01.html) is almost over, I will like to ask for the latest inputs in order to further decide how to proceed.
Filiz arranged some stats about the discussion (thanks a lot for that !) last July, and afterwards, even if the discussion period has been extended, I don't recall having seen new comments.
The stats don't include my own postings:
- there were 9 posts from 8 individuals about it.
- 5 people supported it. 1 of these made some comments though, that he prefers a longer prefix than a /32 clearly in his mail.
- 1 person stated he supports "PI" but he is not supporting this proposal.
- 2 people said "No".
So someone else will like to say anything new or clarify their view in favor or opposition to the proposal ?
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.
--
-- This mail is personal -- All statements in this mail are made from my own personal perspective and do not necessarily reflect my employer's opinions or policies.
********************************************** 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: [ ... ]
Last, but not least, I also will prefer a "common" policy across the different regions, but I think we can't call it "global", because ICANN process, and in any case, it may be very difficult to coordinate that if not too late and impossible ...
That is actually an issue I'd like to comment on. Regarding the use of words, what we can *try* to achieve across the regions is a thing that is called "globally coordinated". The first time we applied that approach to come up with (almost) identical, or at least very similar, polocies in all regions was the (dreaded) "200 Customer rule" for IPv6 PA Allocations. Whether it was wise to work towards such a compromise, which in retrospect left many in the community unhappy, is a different story... So - is anyone in a position to summarize for us which regions are doing that already (ARIN afair, others?) and what the size detais are, or which regions are working towards such a policy (RIPE obviously is). Can the NCC help out here? Wilfried.
Hi Wilfried, I think I can do it, having been in all the RIR meeting since this started 2-3 years ago ... So in short, at the time being has been implemented only in ARIN, but is in last call also in APNIC since a couple of weeks ago (last meeting), as an IPv6 PI policy (using /48) policy achieved consensus. I've submitted basically the same proposal in LACNIC, AfriNIC and RIPE service regions, and there is no any other similar proposal in those regions. I also submitted it in APNIC but didn't achieved consensus (another proposal did, as indicated above). Regards, Jordi
De: "Wilfried Woeber, UniVie/ACOnet" <Woeber@CC.UniVie.ac.at> Organización: UniVie - ACOnet Responder a: <Woeber@CC.UniVie.ac.at> Fecha: Thu, 28 Sep 2006 12:00:39 +0000 Para: <jordi.palet@consulintel.es> CC: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01)
JORDI PALET MARTINEZ wrote:
[ ... ]
Last, but not least, I also will prefer a "common" policy across the different regions, but I think we can't call it "global", because ICANN process, and in any case, it may be very difficult to coordinate that if not too late and impossible ...
That is actually an issue I'd like to comment on.
Regarding the use of words, what we can *try* to achieve across the regions is a thing that is called "globally coordinated". The first time we applied that approach to come up with (almost) identical, or at least very similar, polocies in all regions was the (dreaded) "200 Customer rule" for IPv6 PA Allocations.
Whether it was wise to work towards such a compromise, which in retrospect left many in the community unhappy, is a different story...
So - is anyone in a position to summarize for us which regions are doing that already (ARIN afair, others?) and what the size detais are, or which regions are working towards such a policy (RIPE obviously is).
Can the NCC help out here?
Wilfried.
********************************************** 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.
Hello, Jordi already answered the question specifically about this proposal. There is a presentation scheduled during RIPE 53 next week, on 5 October, for Thursday Plenary session. It will give a summary about this proposal and others that are common across regions. Kind regards, Filiz Yilmaz RIPE NCC Policy Development Officer Wilfried Woeber, UniVie/ACOnet wrote:
JORDI PALET MARTINEZ wrote:
[ ... ]
Last, but not least, I also will prefer a "common" policy across the different regions, but I think we can't call it "global", because ICANN process, and in any case, it may be very difficult to coordinate that if not too late and impossible ...
That is actually an issue I'd like to comment on.
Regarding the use of words, what we can *try* to achieve across the regions is a thing that is called "globally coordinated". The first time we applied that approach to come up with (almost) identical, or at least very similar, polocies in all regions was the (dreaded) "200 Customer rule" for IPv6 PA Allocations.
Whether it was wise to work towards such a compromise, which in retrospect left many in the community unhappy, is a different story...
So - is anyone in a position to summarize for us which regions are doing that already (ARIN afair, others?) and what the size detais are, or which regions are working towards such a policy (RIPE obviously is).
Can the NCC help out here?
Wilfried.
JORDI PALET MARTINEZ wrote: [ ... ]
Regarding the /32 or /48, I think we had very long discussions on that. I just don't believe the /48 will be reachable from all the networks, because many filter longer prefixes than /32, and this is not going to change easily, so consequently, I don't think people requiring PI, will take the risk. Is a non-sense asking for PI but not being sure it will be visible everywhere ... I've some cases of critical infrastructures which have got /48 instead of /32 and they are not visible, quite nice and *critical* for a critical infrastructure :-(
I am *very* reluctant to accept the reasoning that we have to distribute "big" blocks (for any definition of big), because some ISPs have developed a habit of installing filters which are not compatible, or rather "properly take into account", developing address distribution mechanisms. I'd rather see a discussion regarding the "primary" target for this policy. Btw, my reasoning below is related to the "LIR/no LIR/LIR later" issue which I will address in a different message. So what's our target? I read the proposal as primarily being relevant to (quote from the proposal) "End User Organisations". This is what we usually refer to as a Site. And a Site usually gets a /48. Ignoring the discussions regarding *this* paricular default for the moment. For me, the conclusion is to use the /48 assingment size under this policy - unless a "globally coordinated" approach would suggest otherwise, of course. So here is a formal change request from my end to replace /32 by /48, in particular as there is a provision for requesting more, if necessary (quote from the proposal): "The minimum size of the assignment is /32. However, a larger assignment can be provided if duly documented and justified." While I do support the general idea of PI-Assignments for IPv6, I do *not* support this proposal as it is worded *right now*. Wilfried.
Hi Wilfried, Thanks again for your inputs. I fully understand your point, but you need to balance it with being temporary. We are not allocating this space for ever. Also it is not clear to me that a few hundreds of extras /32 will make a difference in terms of lifetime, specially having in a few years alternative technical solutions (again we are doing a temporary thing). On the other way around, what operators do to filter or not, is not our problem (as RIPE community), and we can't do nothing against that, so, do you really think it make sense to arrange a policy that may work only in some networks ? Let's be realistic ! One possibility will be to allocate /48 but keep reserved the remaining /32. If the applicant justify that the /48 is getting filtered, then he may opt to justify to obtain the /32. Is this a possible compromise solution ? Regards, Jordi
De: "Wilfried Woeber, UniVie/ACOnet" <Woeber@CC.UniVie.ac.at> Organización: UniVie - ACOnet Responder a: <Woeber@CC.UniVie.ac.at> Fecha: Thu, 28 Sep 2006 12:14:56 +0000 Para: <jordi.palet@consulintel.es> CC: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01)
JORDI PALET MARTINEZ wrote:
[ ... ]
Regarding the /32 or /48, I think we had very long discussions on that. I just don't believe the /48 will be reachable from all the networks, because many filter longer prefixes than /32, and this is not going to change easily, so consequently, I don't think people requiring PI, will take the risk. Is a non-sense asking for PI but not being sure it will be visible everywhere ... I've some cases of critical infrastructures which have got /48 instead of /32 and they are not visible, quite nice and *critical* for a critical infrastructure :-(
I am *very* reluctant to accept the reasoning that we have to distribute "big" blocks (for any definition of big), because some ISPs have developed a habit of installing filters which are not compatible, or rather "properly take into account", developing address distribution mechanisms.
I'd rather see a discussion regarding the "primary" target for this policy. Btw, my reasoning below is related to the "LIR/no LIR/LIR later" issue which I will address in a different message.
So what's our target? I read the proposal as primarily being relevant to (quote from the proposal) "End User Organisations". This is what we usually refer to as a Site. And a Site usually gets a /48. Ignoring the discussions regarding *this* paricular default for the moment.
For me, the conclusion is to use the /48 assingment size under this policy - unless a "globally coordinated" approach would suggest otherwise, of course.
So here is a formal change request from my end to replace /32 by /48, in particular as there is a provision for requesting more, if necessary (quote from the proposal):
"The minimum size of the assignment is /32. However, a larger assignment can be provided if duly documented and justified."
While I do support the general idea of PI-Assignments for IPv6, I do *not* support this proposal as it is worded *right now*.
Wilfried.
********************************************** 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.
On Thu, 28 Sep 2006, JORDI PALET MARTINEZ wrote:
Hi Wilfried,
Hi All,
Thanks again for your inputs.
I fully understand your point, but you need to balance it with being temporary. We are not allocating this space for ever.
Imho, that's a risky thing to say. :-)) Afaik, experiments can be extended, and then extended, and later extended a bit more...
Also it is not clear to me that a few hundreds of extras /32 will make a difference in terms of lifetime, specially having in a few years alternative technical solutions (again we are doing a temporary thing).
Out of plain curiosity: are really those alternatives bound to happen in say 5-10 years?
On the other way around, what operators do to filter or not, is not our problem (as RIPE community), and we can't do nothing against that, so, do you really think it make sense to arrange a policy that may work only in some networks ? Let's be realistic !
Here i fully agree with Wilfried! If operator A is filtering out PI network B, then customer C (which is paying operator A) is entitled to complain and "suggest" operator A to correct its filtering (or he can always find a new operator, with a better customer needs' focus!)
One possibility will be to allocate /48 but keep reserved the remaining /32. If the applicant justify that the /48 is getting filtered, then he may opt to justify to obtain the /32. Is this a possible compromise solution ?
A lot more reasonable yes, but if he needs an upgrade from /48 -> /40 he should get a /40, not immediately a /32. :-)
Regards, Jordi
Regards, ./Carlos -------------- Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (196663/675), naming (millions) and... people!"
¡Hola Jordi! JORDI PALET MARTINEZ wrote:
Hi Wilfried,
Thanks again for your inputs.
I fully understand your point, but you need to balance it with being temporary. We are not allocating this space for ever.
It is a noble mindset to assume just a transient issue, but in reality nothing tends to last longer than a quick hack :-)
Also it is not clear to me that a few hundreds of extras /32 will make a difference in terms of lifetime,
No, I agree. But whay are we having the discussion on /48, /56, /?? then and the impact of different values of HD_ratio on the lifetime of IPv6? It won't fly to propose reducing /48 to say a /56 for the "masses" of *PA* space users and in parallel give away a /32 for a *PI* Site at the same time.
specially having in a few years alternative technical solutions (again we are doing a temporary thing).
Right now I am not holding my breath. Not because I don't belive in a solution being theoretically possible, but rather looking at the fact that nobody cares, really. Still readin the CIDR Report, anyone ;-)
On the other way around, what operators do to filter or not, is not our problem (as RIPE community),
Exactly, but my conclusion is different :-)
and we can't do nothing against that, so, do you really think it make sense to arrange a policy that may work only in some networks ? Let's be realistic !
I can't see why "this" address space is sooo different. We always have to deal with ISPs that don't track real life developments. And there may be ISPs which - for whaterever "good" reason - may want to block those address ranges. Playing silly games with the *size* won't make a big difference. What *will* make a difference is full integration into the regular set of proactive provisions trying to minimize those *accidental* problems. Like announcing a test prefix from the range, alerting people that assignemnts from a different block of addresses will commence soon, and the like. This is business as usal already in our Service Region. The rest is an issue for a trouble ticket and for obtaining support from your upstream(s) you are paying money to, in particular for providing *end-to-end* connectivity :-)
One possibility will be to allocate /48 but keep reserved the remaining /32. If the applicant justify that the /48 is getting filtered, then he may opt to justify to obtain the /32. Is this a possible compromise solution ?
Come on, what's in a "justify" to get a free upgrade to "business class"? Your ISP(s) would be more than happy to "prove" that. Their product development folks might even offer that as a commercial service :-) I'm convinced that the NCC will be doing "The Right Thing[TM]" to make sure there's room to grow, and maybe even to upgrade such an End-Site PI block to a regular LIR PA block. Actually that might be conflicting goals, and may involve re-numbering :-(
Regards, Jordi
Saludos, Wilfried.
On 28-sep-2006, at 14:35, JORDI PALET MARTINEZ wrote:
One possibility will be to allocate /48 but keep reserved the remaining /32. If the applicant justify that the /48 is getting filtered, then he may opt to justify to obtain the /32. Is this a possible compromise solution ?
History, both in IPv4 and IPv6, has shown that keeping space in reserve to accommodate future request doesn't work very well: people often end up announcing several blocks anyway. So let's not waste the space and make filtering harder by doing this. Also, since a /48 is an incredible amount of space to begin with, coming back for more should be rare in IPv6. The advantage of only giving out /48s with no unused space between them is that if, for instance, 12000 /48s are given out, that will be from a single /34 and allowing /48s from a /34 allows 16384 routes, while allowing /48s from a /20 (because for every /48 of 12000 a /32 is kept in reserve) allows 268 million routes, more than enough to overload any reasonable routing system in an attack.
Hello, While I do support the general idea of PI-Assignments for IPv6 (mainly as a way of facilitating certain networks to move into IPv6...), at the moment i do *NOT* support this 2006-01 proposal due to some specific wording, already mentioned by other participants. I'm also in favour of going with /48s, and grow from there if needed. Best Regards, ./Carlos -------------- Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (196663/675), naming (millions) and... people!"
...but it seem to me more honest to say in advance what is our plan (which anyway, can be changed in the future).
Exactly! Al plans are subject to change so it is not a question of honesty.
Somehow, in my point of view, it may help to avoid some PI assignments if they are not *really* needed, or when regular assignments are possible (for example your own case, suggesting that because the type of infrastructure/organization, its better to go for becoming an LIR).
This is why the PI policy requires the sponsoring LIR to suggest alternate solutions to the applicant and the PI form asks the applicant if the LIR did discuss alternate solutions with them. I don't believe that an expiry date is an "honest" way to address this issue. If it is an issue then the policy should address it directly.
Regarding the /32 or /48, I think we had very long discussions on that. I just don't believe the /48 will be reachable from all the networks,
This automatically causes the policy to expire because if people notice that a policy doesn't work, they will get rid of it at some future time. On the other hand, we do not have the wisdom to see the future so we should not assume that reachability will be a problem. And if it is not a problem, then it is foolish for the policy to automatically expire.
Last, but not least, I also will prefer a "common" policy across the different regions, but I think we can't call it "global", because ICANN process, and in any case, it may be very difficult to coordinate that if not too late and impossible ...
The only way to achieve a common policy is to muddle through, make lots of mistakes, keep an eye on the other 4 RIRs and be willing to fix mistakes by changing policy WHEN WE HAVE THE INFORMATION to see what is really a mistake and what is not. We cannot legislate common policy in advance. And we will get to a common policy quicker if we accept that it is hard to write a 100% perfect policy but it is OK to have 50% of perfection the first time and then fix it later with a new proposal. --Michael Dillon
At 10:56 27/09/2006, JORDI PALET MARTINEZ wrote:
Hi all,
Sorry confused stats. Ignore the previous email ...
As the discussion period for this proposal (http://www.ripe.net/ripe/policies/proposals/2006-01.html) is almost over, I will like to ask for the latest inputs in order to further decide how to proceed.
Filiz arranged some stats about the discussion (thanks a lot for that !) last July, and afterwards, even if the discussion period has been extended, I don't recall having seen new comments.
The stats don't include my own postings:
- there were 9 posts from 8 individuals about it.
- 5 people supported it. 1 of these made some comments though, that he prefers a longer prefix than a /32 clearly in his mail.
- 1 person stated he supports "PI" but he is not supporting this proposal.
- 2 people said "No".
So someone else will like to say anything new or clarify their view in favor or opposition to the proposal ?
Jordi, I also support this proposal. -- Tim
Jordi, On 27 Sep 2006, at 11:56GMT+02:00, JORDI PALET MARTINEZ wrote: [...]
So someone else will like to say anything new or clarify their view in favor or opposition to the proposal ?
The current draft policy text in your proposal includes this paragraph: "Expiry for Assignments: Assignment blocks made under this proposal to address Multihoming issues must be returned to the RIPE NCC after a maximum period of three years. The three year period will run from the date that an alternative technically valid and deployable solution becomes available and is accepted by the Internet community. Any organisations that want to avoid renumbering would, at this time, be able to opt to become an LIR, if they qualify, and be allocated the same prefix." We have reviewed this text from the perspective of the organisation implementing the proposed reclaim process. There are a few areas where we are not sure what is intended. Firstly, in the summary section of your proposal you state that PI assignments are useful because they facilitate multihoming and ease the process of changing upstream provider. However, the expiry clause in your draft text starts with the phrase "Assignment blocks made under this proposal to address Multihoming issues". Does this mean that only those prefixes assigned to enable multihoming would be subject to reclaim by the RIPE NCC? Would assignments made to allow stable addressing when changing from one upstream to another not be subject to reclaim? Does the alternative technological solution need to solve the multihoming problem or the address stability problem, or both? Also, can you help us understand what you mean by "is accepted by the Internet community"? Would you expect us to survey network operators for their opinions on the suitability of proposed solutions, or should we look to other methods of determining acceptance, like a RIPE document going through the RIPE PDP? Many thanks, -- leo vegoda Registration Services Manager RIPE NCC
Hi Leo, Thanks a lot for your inputs. See below, in-line. Regards, Jordi
De: leo vegoda <leo@ripe.net> Responder a: <address-policy-wg-admin@ripe.net> Fecha: Thu, 28 Sep 2006 13:55:31 +0200 Para: <jordi.palet@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01)
Jordi,
On 27 Sep 2006, at 11:56GMT+02:00, JORDI PALET MARTINEZ wrote:
[...]
So someone else will like to say anything new or clarify their view in favor or opposition to the proposal ?
The current draft policy text in your proposal includes this paragraph:
"Expiry for Assignments: Assignment blocks made under this proposal to address Multihoming issues must be returned to the RIPE NCC after a maximum period of three years. The three year period will run from the date that an alternative technically valid and deployable solution becomes available and is accepted by the Internet community. Any organisations that want to avoid renumbering would, at this time, be able to opt to become an LIR, if they qualify, and be allocated the same prefix."
We have reviewed this text from the perspective of the organisation implementing the proposed reclaim process. There are a few areas where we are not sure what is intended. Firstly, in the summary section of your proposal you state that PI assignments are useful because they facilitate multihoming and ease the process of changing upstream provider. However, the expiry clause in your draft text starts with the phrase "Assignment blocks made under this proposal to address Multihoming issues". Does this mean that only those prefixes assigned to enable multihoming would be subject to reclaim by the RIPE NCC? Would assignments made to allow stable addressing when changing from one upstream to another not be subject to reclaim?
That was the idea in principle, to reclaim only those used for multihoming. However, I just realized that depending on the technical solution, it may be the case that this solution also solves the other scenarios, then we could reclaim all. To be honest, I'm not quite sure myself. We could probably tidy up the wording to keep that open, depending on the community decision at the time of the technical solution is "accepted".
Does the alternative technological solution need to solve the multihoming problem or the address stability problem, or both?
We don't know yet, it may be or may be not, that's the point ...
Also, can you help us understand what you mean by "is accepted by the Internet community"? Would you expect us to survey network operators for their opinions on the suitability of proposed solutions, or should we look to other methods of determining acceptance, like a RIPE document going through the RIPE PDP?
I think the ideal will be to follow the RIPE PDP for that, however, a survey may always be useful in order to help in the PDP process. One doesn't exclude the other, and the final text, if this proposal become accepted should probably define that. Remember that my point about the "temporarily" is that any policy can be changed or amended thru the PDP process, but seems to me more honest doing it upfront. Otherwise, why we have "temporary policies" ? It will not make any sense ...
Many thanks,
-- leo vegoda Registration Services Manager RIPE NCC
********************************************** 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.
participants (10)
-
Carlos Friacas -
Filiz Yilmaz -
Iljitsch van Beijnum -
JORDI PALET MARTINEZ -
Kristian Larsson -
leo vegoda -
Marc van Selm -
Michael.Dillon＠btradianz.com -
Tim Streater -
Wilfried Woeber, UniVie/ACOnet