Re: [address-policy-wg] Status of /24 PI IPv4 from last /8
*Sander Steffann*wrote<mailto:address-policy-wg%40ripe.net?Subject=Re:%20%5Baddress-policy-wg%5D%20Status%20of%20/24%20PI%20IPv4%20from%20last%20/8&In-Reply-To=%3CA3853826-7A62-4EE4-94D6-EBF1A6F5AE88%40steffann.nl%3E>/@ Wed Oct 3 15:17:43 CEST 2012/: Hello Marcin,
/ I'am lost a little bit, what is the current status of policy, that would allow single /24 PI IPv4 assignment from the last /8 ??? / You can find the status here:http://www.ripe.net/ripe/policies/proposals/2012-04 The policy proposal is in the review phase and under discussion until the 8th of October.
Sander Steffann APWG co-chair I'm a little lost too. Are we waiting until RIPE66 or was there supposed to be an update on that? regards, Yannis
On 06/11/2012 10:20, Yannis Nikolopoulos wrote:
*Sander Steffann*wrote<mailto:address-policy-wg%40ripe.net?Subject=Re:%20%5Baddress-policy-wg%5D%20Status%20of%20/24%20PI%20IPv4%20from%20last%20/8&In-Reply-To=%3CA3853826-7A62-4EE4-94D6-EBF1A6F5AE88%40steffann.nl%3E>/@ Wed Oct 3 15:17:43 CEST 2012/:
Hello Marcin,
/ I'am lost a little bit, what is the current status of policy, that would allow single /24 PI IPv4 assignment from the last /8 ??? / You can find the status here: http://www.ripe.net/ripe/policies/proposals/2012-04 The policy proposal is in the review phase and under discussion until the 8th of October.
Sander Steffann APWG co-chair
I'm a little lost too. Are we waiting until RIPE66 or was there supposed to be an update on that?
Yannis, It was clear from the discussion at RIPE65 that there was no consensus in favour of the existing proposal. As author of the proposal, I intend to leave the proposal sit for a short period (maybe a couple of months) before resuming work on it. I think as a community, we need the benefit of some hindsight in terms of figuring out what's best in terms of overall policy. Nick
Nick, I'm not sure that leaving the policy sit is a good idea We already have customers asking for PI space and all we can tell them is to wait. Seeing the "Awaiting Decision from Working Group Chair" on the proposal page, we hoped for a decision soon. Should we advice them to become LIRs instead of waiting for a policy change? George On Tue, Nov 6, 2012 at 12:46 PM, Nick Hilliard <nick@inex.ie> wrote:
*Sander Steffann*wrote<mailto:address-policy-wg%40ripe.net ?Subject=Re:%20%5Baddress-policy-wg%5D%20Status%20of%20/24%20PI%20IPv4%20from%20last%20/8&In-Reply-To=%3CA3853826-7A62-4EE4-94D6-EBF1A6F5AE88% 40steffann.nl%3E>/@ Wed Oct 3 15:17:43 CEST 2012/:
Hello Marcin,
/ I'am lost a little bit, what is the current status of policy, that would allow single /24 PI IPv4 assignment from the last /8 ??? / You can find the status here: http://www.ripe.net/ripe/policies/proposals/2012-04 The policy proposal is in the review phase and under discussion until
On 06/11/2012 10:20, Yannis Nikolopoulos wrote: the 8th of October.
Sander Steffann APWG co-chair
I'm a little lost too. Are we waiting until RIPE66 or was there supposed
to
be an update on that?
Yannis,
It was clear from the discussion at RIPE65 that there was no consensus in favour of the existing proposal. As author of the proposal, I intend to leave the proposal sit for a short period (maybe a couple of months) before resuming work on it. I think as a community, we need the benefit of some hindsight in terms of figuring out what's best in terms of overall policy.
Nick
Hi, On Tue, Nov 06, 2012 at 06:10:22PM +0200, George Giannousopoulos wrote:
I'm not sure that leaving the policy sit is a good idea We already have customers asking for PI space and all we can tell them is to wait.
Seeing the "Awaiting Decision from Working Group Chair" on the proposal page, we hoped for a decision soon. Should we advice them to become LIRs instead of waiting for a policy change?
IPv6 comes to mind. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
* George Giannousopoulos
I'm not sure that leaving the policy sit is a good idea We already have customers asking for PI space and all we can tell them is to wait.
Seeing the "Awaiting Decision from Working Group Chair" on the proposal page, we hoped for a decision soon. Should we advice them to become LIRs instead of waiting for a policy change?
Yes. 2012-03 won't pass soon, and there is no guarantee that it ever will. Judging by the discussion it stirred up at the last RIPE meeting, I believe it has rather slim chances of reaching consensus. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
On 06/11/2012 16:32, Tore Anderson wrote:
2012-03[*] won't pass soon, and there is no guarantee that it ever will. Judging by the discussion it stirred up at the last RIPE meeting, I believe it has rather slim chances of reaching consensus.
I don't think it's all doom and gloom, btw. The comments both on the mailing list and at the APWG session fell into a couple of different categories: - yes - no, but would support after 185.0.0.0/8 is exhausted - no, but would support if potential abuse could be reduced - no, under no circumstances What's clear is that there is no consensus on the current proposal. But I think that it may be possible to satisfy many of the concerns of the people who objected if the proposal were modified to e.g. reduce the possibility of potential abusers, or maybe make it applicable only to reclaimed address space and not 185.0.0.0/8. Nick [*] 2012-04
On 11/6/12 10:48 , Nick Hilliard wrote:
On 06/11/2012 16:32, Tore Anderson wrote:
2012-03[*] won't pass soon, and there is no guarantee that it ever will. Judging by the discussion it stirred up at the last RIPE meeting, I believe it has rather slim chances of reaching consensus.
I don't think it's all doom and gloom, btw. The comments both on the mailing list and at the APWG session fell into a couple of different categories:
- yes - no, but would support after 185.0.0.0/8 is exhausted - no, but would support if potential abuse could be reduced - no, under no circumstances
What's clear is that there is no consensus on the current proposal. But I think that it may be possible to satisfy many of the concerns of the people who objected if the proposal were modified to e.g. reduce the possibility of potential abusers, or maybe make it applicable only to reclaimed address space and not 185.0.0.0/8.
As currently written GPP-IPv4-2011 (AKA RIPE-2011-01) says "The Recovered IPv4 Pool will stay inactive until the first RIR has less than a total of a /9 in its inventory of IPv4 address space." So it may be some time before reclaimed address are available to be issued as PI, if you follow the suggested approach. I'm not completely familiar with the nuances of RIPE's policies, but is it possible for organizations that want PI to get it from the transfer market under RIPE's current policies? If not then that probably needs to be fixed ASAP, they probably shouldn't be shutout of both the last /8 and the transfer market. This was brought up in the discussion of 2012-02, but I don't know if it has been resolved to allow PI through transfers, and in particular inter-RIR transfers. I have no opinion on this policy, as I do not receive resources within the RIPE region. But, I will say I think it is important for end user organizations in the RIPE region to have a viable way to get IPv4 resources, be it from the last /8 or via transfers. I think it is highly problematic if there isn't some mechanism that provides for continued PI resource availability. Thanks -- ================================================= David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 =================================================
On 06/11/2012 17:52, David Farmer wrote:
I think it is highly problematic if there isn't some mechanism that provides for continued PI resource availability.
I agree. Nick
Forget about PIv4. It is deprecated and we don't need it for now. -- Alexey Ivanov 06.11.2012 21:54 - Nick Hilliard написал(а): On 06/11/2012 17:52, David Farmer wrote:
I think it is highly problematic if there isn't some mechanism that provides for continued PI resource availability.
I agree. Nick
On 07/11/2012 08:29, LeaderTelecom Ltd. wrote:
Forget about PIv4. It is deprecated and we don't need it for now.
You may not need it, but there are a lot of other end users in the RIPE service area who disagree and feel that they need it very badly. Nick
Why not continue give PA-addresses in this case? Many customers need them too. We have to be consistent: 1. Continue distribute last /8 for PA & PI. OR 2. Don't distribute last /8 for PA & PI (except LIR which didn't get 1024 IPs from last /8). I think second option is more optimal, while some defficit and increasing prices for IPv4 allow customers run IPv6 faster. p.s. Who will PI-addresses? Why they can't rent them or start use IPv6? -- Alexey Ivanov 07.11.2012 14:24 - Nick Hilliard написал(а): On 07/11/2012 08:29, LeaderTelecom Ltd. wrote:
Forget about PIv4. It is deprecated and we don't need it for now.
You may not need it, but there are a lot of other end users in the RIPE service area who disagree and feel that they need it very badly. Nick
On 07/11/2012 10:38, LeaderTelecom Ltd. wrote:
Why not continue give PA-addresses in this case? Many customers need them too.
Because you can't multihome PA addresses.
We have to be consistent: 1. Continue distribute last /8 for PA & PI. OR 2. Don't distribute last /8 for PA & PI (except LIR which didn't get 1024 IPs from last /8).
I think second option is more optimal, while some defficit and increasing prices for IPv4 allow customers run IPv6 faster.
p.s. Who will PI-addresses? Why they can't rent them or start use IPv6?
They can't rent them because the renting market has not yet developed, and they can't use ipv6 because it's not usable at the moment. Nick
On 11/7/12 12:29 PM, Nick Hilliard wrote:
p.s. Who will PI-addresses? Why they can't rent them or start use IPv6?
They can't rent them because the renting market has not yet developed, and they can't use ipv6 because it's not usable at the moment.
So, they are stuck (all of a sudden, what a surprise). Another option is to start working on IPv6 solutions so the whole thing becomes usable for them - whatever that might be and whatever efforts that may include ;) At some point this really needs to end. Cheers, Jan
On 07/11/2012 11:36, Jan Zorz @ go6.si wrote:
So, they are stuck (all of a sudden, what a surprise).
Another option is to start working on IPv6 solutions so the whole thing becomes usable for them - whatever that might be and whatever efforts that may include ;)
At some point this really needs to end.
I agree but we haven't reached that point yet, and as long as these two graphs: https://www.inex.ie/noncms/img/inex-lan1-ipv6-20121107.png https://www.inex.ie/noncms/img/inex-lan1-ipv4-20121107.png ... differ from each other by a factor of 1000, it's unrealistic to say that: - ipv6 is a viable alternative to IPv4 right now - ipv4 is deprecated / legacy / historic / whatever I know that you're not saying this, but other people on this mailing list are. Don't get me wrong either: I'd love to see much more ipv6 penetration and wider deployment, but we are where we are and we need to deal with policies which are relevant to people today. Incidentally, if you strip out the top 10% of the v6 talkers from those graphs above, the ipv6 graph drops by two orders of magnitude. :-| Nick
Hi, On Wed, Nov 07, 2012 at 12:03:36PM +0000, Nick Hilliard wrote:
On 07/11/2012 11:36, Jan Zorz @ go6.si wrote:
So, they are stuck (all of a sudden, what a surprise).
Another option is to start working on IPv6 solutions so the whole thing becomes usable for them - whatever that might be and whatever efforts that may include ;)
At some point this really needs to end.
I agree but we haven't reached that point yet, and as long as these two graphs:
https://www.inex.ie/noncms/img/inex-lan1-ipv6-20121107.png https://www.inex.ie/noncms/img/inex-lan1-ipv4-20121107.png
... differ from each other by a factor of 1000, it's unrealistic to say that:
- ipv6 is a viable alternative to IPv4 right now - ipv4 is deprecated / legacy / historic / whatever
Actually, looking at traffic graphs is misleading at best. These show whether big telcos that have sat on their huge IPv6 allocations for a long time finally get around to IPv6-enable their customers (or continue stalling), but do not really say anything about the *usability* of IPv6 for Joe Average User. Since the context of this discussion is "WE MUST HAVE IPv4 PI!!!", this statement might need some adjustment to "there is no IPv4 PI, can we do something else?", like "can we use IPv6 PI plus double-IPv4-PA?" or "can we use IPv6 PI plus our ISP's friendly NAT64 translator?"... These seem much more relevant questions to me than "can we look around in the decks below the water line for additional deck chairs?". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On 07/11/2012 12:13, Gert Doering wrote:
Actually, looking at traffic graphs is misleading at best. These show whether big telcos that have sat on their huge IPv6 allocations for a long time finally get around to IPv6-enable their customers (or continue stalling), but do not really say anything about the *usability* of IPv6 for Joe Average User.
Usability is one thing: in general where native ipv6 is provided, it mostly works fine and most problems aren't related to the access layer. But as you correctly point out, it's simply not available for most end users.
Since the context of this discussion is "WE MUST HAVE IPv4 PI!!!", this
Please don't be dismissive about this discussion. There is a serious issue here relating to availability of a resource which provides significant benefit to many people and organisations in the RIPE service region.
statement might need some adjustment to "there is no IPv4 PI, can we do something else?", like "can we use IPv6 PI plus double-IPv4-PA?" or "can we use IPv6 PI plus our ISP's friendly NAT64 translator?"...
These seem much more relevant questions to me than "can we look around in the decks below the water line for additional deck chairs?".
It's less of a deck-chair discussion and more of a discussion about life-boat seats - the relevant point being that there is a small quantity of seats left and the crew/operators have bagged the lot for themselves, leaving the passengers stranded on a sinking ship. Now one way or another that ship will sink and we all know it, but in the interim it is unreasonable to expect that end users who want PI are going to be happy about the situation. Nick
Hi, On Wed, Nov 07, 2012 at 12:54:13PM +0000, Nick Hilliard wrote:
Now one way or another that ship will sink and we all know it, but in the interim it is unreasonable to expect that end users who want PI are going to be happy about the situation.
Anybody who relies on availability of "more IPv4 addresses" for their future business planning is going to be quite unhappy. Should that be a reason to discuss IPv4, or discuss alternatives? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On 07/11/2012 12:58, Gert Doering wrote:
Anybody who relies on availability of "more IPv4 addresses" for their future business planning is going to be quite unhappy.
The same argument was made in the US in the late 1800s after the land rushes ended and the last bits of unassigned land were taken. After all, if there was no more land available, how could the economy survive and grow? But this isn't the point. The point is that there is a modest stash of resources available right now, and that PI requesters are being turned away. Down the road, everyone will be in the same boat: namely that if IPv4 addresses are needed, they will need to be acquired on the market. We're not there yet, though. Nick
Hi, On Wed, Nov 07, 2012 at 01:35:33PM +0000, Nick Hilliard wrote:
On 07/11/2012 12:58, Gert Doering wrote:
Anybody who relies on availability of "more IPv4 addresses" for their future business planning is going to be quite unhappy.
The same argument was made in the US in the late 1800s after the land rushes ended and the last bits of unassigned land were taken. After all, if there was no more land available, how could the economy survive and grow?
By using IPv6. Unlike the landrush in the US we *do* have an alternative, and do not need to find ways to make IPv4 last forever. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On 07/11/2012 13:45, Gert Doering wrote:
By using IPv6.
Unlike the landrush in the US we *do* have an alternative, and do not need to find ways to make IPv4 last forever.
... which brings us straight back to my posting of 13:03:36 CET today. I'm not going to argue another loop of this particular circle. Nick
On 7 Nov 2012, at 13:51, Nick Hilliard <nick@inex.ie> wrote:
I'm not going to argue another loop of this particular circle.
That's a pity. It may be helpful to keep this "debate" burbling along until there's no more IPv4 left or the heat death of the universe. Whichever comes first. :-) We all agree that everyone will be unhappy once v4 runs out. But not everyone will be unhappy to the same extent or at the same time. They will be unhappy though. IMO, it looks like those wanting PI space are the first to be unhappy. They will not be the last.
On Wed, Nov 7, 2012 at 2:45 PM, Gert Doering <gert@space.net> wrote:
Unlike the landrush in the US we *do* have an alternative, and do not need to find ways to make IPv4 last forever.
If anything, allowing IPv4 PI at this stage will speed up IPv4 exhaustion, not slow it down. I don't see this as trying to make it last longer; the reverse is true. There are valid business cases to be made today that include getting IPv4 as long as it's available. Yes, unless they include IPv6 in their business plans they are going to get hurt Real Soon Now (tm), but that's outside of the scope of this argument. The _only_ thing we should be discussing in this particular context is "should we still hand out IPv4 PI as long as IPv4 is still available or should we hand out IPv4 PA, only?" Possible answers include: * Stop handing out IPv4 PI once we reach the last /8 * Stop handing out IPv4 PI once we reach the last /x (12? 16?) * Hand out IPv4 PI from a designated /x in the last /8, stop once that's empty * Hand out IPv4 PI from returned space, only. Don't hand out PI from the last /8 And I am sure there are others. It's painfully obvious that the argument that IPv6 is the way of the future is correct. It's also obvious, to me, that this fact is detached from the question of how the remaining bits and pieces of IPv4 should be used up. To put it differently: Why does anyone who considers IPv4 legacy care about how it's used up? -- Richard
Hi, On Wed, Nov 07, 2012 at 04:41:51PM +0100, Richard Hartmann wrote:
To put it differently: Why does anyone who considers IPv4 legacy care about how it's used up?
Well, I *do* care about the way we use the community's resources in policy building. If everybody gets exhausted doing a new round of IPv4 PI policy every time the "we do IPv4 PI only until <x> happens, and then no more!" mark is reached, other policy proposals do not get the attention they deserve. (By which I'd ask you to please stay away from a PI policy that will do things like "but only in the first /9 of the last /8, not in the second /9" - *iff* the community decides to bring back IPv4 PI, then let's do it for good and for all the remaining space. Doing it for "but not for the last /x" is exactly what we have now - let's not do *that* again). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Hi Gert, I see what you're saying here. At the same time, I think any policy allowing PIv4 from the final /8 would have such a profound impact on what the current final /8 policy is trying to achieve that we should probably review the final /8 policy in its entirety. Yes, I'm fully aware how much pain and effort would go into that. But if we don't we might as well take away the fences and let everyone have a few more glorious weeks of cheap IPv4 resources. Best Remco (No hats) ----- Original Message ----- From: Gert Doering [mailto:gert@space.net] Sent: Wednesday, November 07, 2012 06:17 PM To: Richard Hartmann <richih.mailinglist@gmail.com> Cc: address-policy-wg@ripe.net <address-policy-wg@ripe.net> Subject: Re: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 Hi, On Wed, Nov 07, 2012 at 04:41:51PM +0100, Richard Hartmann wrote:
To put it differently: Why does anyone who considers IPv4 legacy care about how it's used up?
Well, I *do* care about the way we use the community's resources in policy building. If everybody gets exhausted doing a new round of IPv4 PI policy every time the "we do IPv4 PI only until <x> happens, and then no more!" mark is reached, other policy proposals do not get the attention they deserve. (By which I'd ask you to please stay away from a PI policy that will do things like "but only in the first /9 of the last /8, not in the second /9" - *iff* the community decides to bring back IPv4 PI, then let's do it for good and for all the remaining space. Doing it for "but not for the last /x" is exactly what we have now - let's not do *that* again). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.
Hello Gert, On 11/07/2012 08:17 PM, Gert Doering wrote:
Hi,
To put it differently: Why does anyone who considers IPv4 legacy care about how it's used up? Well, I *do* care about the way we use the community's resources in
On Wed, Nov 07, 2012 at 04:41:51PM +0100, Richard Hartmann wrote: policy building.
I'm confused. We should all care about the way the community's resources are used. That's the whole point of this discussion (and this group). What we're now seeing, is new LIRs that never wanted to become LIRs in the first place and just wanted a /24 of PI space. They have no (real) alternative though if they want to multihome (as an LIR/ISP I'm with Nick on this one). How's that fair on them, considering registration and handling fees? As far as IPv6 goes, most of us or on the same boat, no need to state the obvious. As Richard said, the question here is whether we should hand out PI from the last /8 or not. regards, Yannis
On 11/7/12 14:17 , Yannis Nikolopoulos wrote:
Hello Gert,
As Richard said, the question here is whether we should hand out PI from the last /8 or not.
I think there is another viable option; *Allow IPv4 PI from the transfer market But, I by my read of RIPE policy this isn't allow, or its not clear to me that it is allowed when I read the policy. If, I'm wrong about this please correct me. If the RIPE community doesn't want to make IPv4 PI assignments out of its last /8, I think that is defensible. If someone wants something out of the last /8, making them become an LIR seems reasonable as well. However, saying there is no such thing as IPv4 PI any longer is not reasonable when there is a viable transfer market available as a source of addresses. The whole point of creating a IPv4 transfer market was to encourage getting unused or underutilized IPv4 addresses in to the hands of those that need them. End users need for IPv4 PI is just as important and valid of a use for IPv4 as ISP need for IPv4. Shutting IPv4 PI out of the last /8 is one thing, shutting IPv4 PI out of the transfer market is another and doesn't seem justified. -- ================================================= David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 =================================================
*Allow IPv4 PI from the transfer market
Very good idea! -- Alexey Ivanov 08.11.2012 01:57 - David Farmer написал(а): On 11/7/12 14:17 , Yannis Nikolopoulos wrote:
Hello Gert,
As Richard said, the question here is whether we should hand out PI from the last /8 or not.
I think there is another viable option; *Allow IPv4 PI from the transfer market But, I by my read of RIPE policy this isn't allow, or its not clear to me that it is allowed when I read the policy. If, I'm wrong about this please correct me. If the RIPE community doesn't want to make IPv4 PI assignments out of its last /8, I think that is defensible. If someone wants something out of the last /8, making them become an LIR seems reasonable as well. However, saying there is no such thing as IPv4 PI any longer is not reasonable when there is a viable transfer market available as a source of addresses. The whole point of creating a IPv4 transfer market was to encourage getting unused or underutilized IPv4 addresses in to the hands of those that need them. End users need for IPv4 PI is just as important and valid of a use for IPv4 as ISP need for IPv4. Shutting IPv4 PI out of the last /8 is one thing, shutting IPv4 PI out of the transfer market is another and doesn't seem justified. -- ================================================= David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 =================================================
W dniu 07.11.2012 23:02, LeaderTelecom Ltd. pisze:
*Allow IPv4 PI from the transfer market
Very good idea! allow transfer between operators and allow convert from pa space to pi space. and - all will be happy :)
-- Alexey Ivanov
08.11.2012 01:57 - David Farmer написал(а): On 11/7/12 14:17 , Yannis Nikolopoulos wrote:
Hello Gert,
As Richard said, the question here is whether we should hand out PI from the last /8 or not.
I think there is another viable option;
*Allow IPv4 PI from the transfer market
But, I by my read of RIPE policy this isn't allow, or its not clear to me that it is allowed when I read the policy. If, I'm wrong about this please correct me.
If the RIPE community doesn't want to make IPv4 PI assignments out of its last /8, I think that is defensible. If someone wants something out of the last /8, making them become an LIR seems reasonable as well. However, saying there is no such thing as IPv4 PI any longer is not reasonable when there is a viable transfer market available as a source of addresses.
The whole point of creating a IPv4 transfer market was to encourage getting unused or underutilized IPv4 addresses in to the hands of those that need them. End users need for IPv4 PI is just as important and valid of a use for IPv4 as ISP need for IPv4. Shutting IPv4 PI out of the last /8 is one thing, shutting IPv4 PI out of the transfer market is another and doesn't seem justified.
-- ================================================= David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 =================================================
-- Regards, Andrzej 'The Undefined' Dopierała http://andrzej.dopierala.name/
On 11/7/12 16:12 , Andrzej Dopierała wrote:
W dniu 07.11.2012 23:02, LeaderTelecom Ltd. pisze:
*Allow IPv4 PI from the transfer market
Very good idea! allow transfer between operators and allow convert from pa space to pi space. and - all will be happy :)
That depends how the financial transactions are going to work, as a end user I wouldn't give an operator any money unless they had the addresses already. If the users PI need is being used to justify the operator receiving the transfer then will RIPE approve the transfer? I'm not saying it can't work, but I don't think it is as simple as you say. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================
Hi,
I think there is another viable option;
*Allow IPv4 PI from the transfer market
But, I by my read of RIPE policy this isn't allow, or its not clear to me that it is allowed when I read the policy. If, I'm wrong about this please correct me.
No, you are right. The *current* policy doesn't allow IPv4 PI address transfers. Policies can change of course. That's what this list is for :-) Thanks, Sander
Hello. Absolutely right.... Applying for LIR status just for multi-homing where /24 PI space is more than enough is a waste of much bigger IPv4 space, but then again more money for some ..... :> Greg On 2012-11-07 15:17, Yannis Nikolopoulos wrote:
Hello Gert,
On 11/07/2012 08:17 PM, Gert Doering wrote:
Hi,
To put it differently: Why does anyone who considers IPv4 legacy care about how it's used up? Well, I *do* care about the way we use the community's resources in
On Wed, Nov 07, 2012 at 04:41:51PM +0100, Richard Hartmann wrote: policy building.
I'm confused. We should all care about the way the community's resources are used. That's the whole point of this discussion (and this group). What we're now seeing, is new LIRs that never wanted to become LIRs in the first place and just wanted a /24 of PI space. They have no (real) alternative though if they want to multihome (as an LIR/ISP I'm with Nick on this one). How's that fair on them, considering registration and handling fees?
As far as IPv6 goes, most of us or on the same boat, no need to state the obvious. As Richard said, the question here is whether we should hand out PI from the last /8 or not.
regards, Yannis
On Wed, 7 Nov 2012, Gert Doering wrote:
If everybody gets exhausted doing a new round of IPv4 PI policy every time the "we do IPv4 PI only until <x> happens, and then no more!" mark is reached, other policy proposals do not get the attention they deserve.
I agree totally. This seems to happen all the time, people just want to solve the problems of today and care little about the longer term. I'm exhausted by this, so I would like to see a policy that handles all of the space. Also, since people seem to be motivated to get IPv4 space and don't care about IPv6, let's just put a price on IPv4 which is now a scarce resource. I would like RIPE to stop doing justification handling for IPv4. Just stop. It's wasted time for everybody. People have IPv4 addresses, they won't get substantially more, people will game the system to not have to return them. Let people trade them as they want, and new PI (/24) or PA (/22) space costs the equivalent per-IPv4 address cost as getting a new LIR, getting the /22, and paying the fees. This would mean a /24 PI out of the remaining pool costs 1/4 of the /22 LIR cost (which would mean what, around 750 EUR per year) ? Just take the money, keep down on administration, and use the excess money to fund community development projects (R&D, FOSS etc).
(By which I'd ask you to please stay away from a PI policy that will do things like "but only in the first /9 of the last /8, not in the second /9" - *iff* the community decides to bring back IPv4 PI, then let's do it for good and for all the remaining space. Doing it for "but not for the last /x" is exactly what we have now - let's not do *that* again).
I totally agree. -- Mikael Abrahamsson email: swmike@swm.pp.se
* Mikael Abrahamsson
I would like RIPE to stop doing justification handling for IPv4. Just stop. It's wasted time for everybody.
For what it's worth, I agree fully, and I've already prepared a proposal that does exactly this. It's awaiting review by the WG chairs before being formally submitted. If you or anyone else would like to (p)review it to see if it is in a shape you could support, or even help co-author it, that would be much appreciated.
(By which I'd ask you to please stay away from a PI policy that will do things like "but only in the first /9 of the last /8, not in the second /9" - *iff* the community decides to bring back IPv4 PI, then let's do it for good and for all the remaining space. Doing it for "but not for the last /x" is exactly what we have now - let's not do *that* again).
I totally agree.
Partially to this end, my proposal also takes the opportunity to clean up the last /8 policy - making it "the everything policy" - by merging it into or replacing the main policy sections. (It does not seek to actually change the mechanics of the last /8 policy though, only to do some cosmetic reconstructive surgery. This means the two "last /16" reservations for IXPs and unforeseen circumstances remain.) -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
Hello there people! I've read this list for quite a long time now and finally achieved the point when i would like to ask: how do we start voting process, or, say, create a new policy proposal regarding the prohibition of PI/PA space exchange between operators? I strongly agree with my colleagues from LeaderTelecom: the transfers definitely will occur, no matter whether RIPE NCC wants them to or not, but if we create a policy that allows such transfers in a "legal" (from RIPE's perspective) way, than those at least will become organized. If by now policy does not change - i'm very much sure that lots of origin ASNs will travel to new geographic locations :) -- ~~~ WBR, Vitaliy Turovets NOC Lead @TV-Net ISP NOC Lead @Service Outsourcing company +38(093)265-70-55 VITU-RIPE X-NCC-RegID: ua.tv
Hi Vitaliy, * Виталий Туровец
I've read this list for quite a long time now and finally achieved the point when i would like to ask: how do we start voting process, or, say, create a new policy proposal regarding the prohibition of PI/PA space exchange between operators?
Transfer of PA space is already allowed under current policy. There's no explicit *prohibition* of transfer of PI space, there's simply no policy that regulates it. My guess it's simply not there because there was no need for it in the past.
I strongly agree with my colleagues from LeaderTelecom: the transfers definitely will occur, no matter whether RIPE NCC wants them to or not,
The RIPE NCC does not have any preference in the matter. The RIPE NCC simply does what the RIPE Community (that's you and me!) tells it to do.
but if we create a policy that allows such transfers
That's precisely what you would have to do in order to allow for transfer of PI space. I'd suggest you review the following pages, which document the RIPE Policy Development Process: http://www.ripe.net/ripe/policies http://www.ripe.net/ripe/docs/ripe-500 http://www.ripe.net/ripe/policies/policy-development-process-glossary Next, write up a proposal and submit it. Then the Address Policy WG can discuss it to determine whether or not there is consensus for it. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
Hi Tore, To clarify: the original proposed transfer policy had no limitations included whatsoever. We ended up with all the limitations in there as a compromise to get any transfer policy reaching consensus at all within the RIPE NCC service region, being the first region in the world with a transfer policy in place back in the day. As other regions have now adopted transfer policies as well, the one in hte RIPE NCC resion is now by far the most restrictive, and I would encourage anyone to do a proposal to remove some or all of the limitations in current policy. Best Remco (one of the authors of the current transfer policy) On 08-11-12 10:17, "Tore Anderson" <tore.anderson@redpill-linpro.com> wrote:
Hi Vitaliy,
* Виталий Туровец
I've read this list for quite a long time now and finally achieved the point when i would like to ask: how do we start voting process, or, say, create a new policy proposal regarding the prohibition of PI/PA space exchange between operators?
Transfer of PA space is already allowed under current policy.
There's no explicit *prohibition* of transfer of PI space, there's simply no policy that regulates it. My guess it's simply not there because there was no need for it in the past.
I strongly agree with my colleagues from LeaderTelecom: the transfers definitely will occur, no matter whether RIPE NCC wants them to or not,
The RIPE NCC does not have any preference in the matter. The RIPE NCC simply does what the RIPE Community (that's you and me!) tells it to do.
but if we create a policy that allows such transfers
That's precisely what you would have to do in order to allow for transfer of PI space. I'd suggest you review the following pages, which document the RIPE Policy Development Process:
http://www.ripe.net/ripe/policies http://www.ripe.net/ripe/docs/ripe-500 http://www.ripe.net/ripe/policies/policy-development-process-glossary
Next, write up a proposal and submit it. Then the Address Policy WG can discuss it to determine whether or not there is consensus for it.
Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.
By using IPv6.
Unlike the landrush in the US we *do* have an alternative, and do not need to find ways to make IPv4 last forever.
Gert Doering -- NetMaster
Yeap... but... We are an ISP fucusing on individuals (most) and business (minority, but growing). Because of nature of our business, we decided to have central BRAS and large L2 (in future MPLS) network. So, most of our subscribers are connected via "ethernet all the way", native DHCP (no PPPoWhatever). Both - Cisco/Ericsson(RedBack) - for their BRASes have not yet implemented this access method for IPv6.. They have it on roadmap, but it will take a while for first releases and much more before they will be stable enough to put them in production. 2 years at least I suppose.. Now, imagine that there is a lot of ISPs like us with the same problem, however, very often lager scale... (I suppose that Juniper and others are at the same stage). Regards, Marcin
On 11/7/12 8:25 PM, Marcin Kuczera wrote:
Both - Cisco/Ericsson(RedBack) - for their BRASes have not yet implemented this access method for IPv6.. They have it on roadmap, but it will take a while for first releases and much more before they will be stable enough to put them in production.
Not true. Cisco ASR1k and Ericsson Redback works very well with IPv6/IPv4 for access. Tested at least for PPPoE/A users. Cheers, Jan
On 2012-11-07 20:35, Jan Zorz @ go6.si wrote:
On 11/7/12 8:25 PM, Marcin Kuczera wrote:
Both - Cisco/Ericsson(RedBack) - for their BRASes have not yet implemented this access method for IPv6.. They have it on roadmap, but it will take a while for first releases and much more before they will be stable enough to put them in production.
Not true. Cisco ASR1k and Ericsson Redback works very well with IPv6/IPv4 for access. Tested at least for PPPoE/A users.
Jan, please - read it once again, I wrote that - I don't care abut PPPoE/A, *NO PPP* I need NATIVE ETHERNET - in RedBack the call it CLIPS - any hints about that ? Regards, Marcin
Yeap... but...
We are an ISP fucusing on individuals (most) and business (minority, but growing). Because of nature of our business, we decided to have central BRAS and large L2 (in future MPLS) network. So, most of our subscribers are connected via "ethernet all the way", native DHCP (no PPPoWhatever).
Both - Cisco/Ericsson(RedBack) - for their BRASes have not yet implemented this access method for IPv6.. They have it on roadmap, but it will take a while for first releases and much more before they will be stable enough to put them in production. 2 years at least I suppose..
Now, imagine that there is a lot of ISPs like us with the same problem, however, very often lager scale...
(I suppose that Juniper and others are at the same stage).
Regards, Marcin
We have a same problem in one of our ADSL2+ zone :(
Hi,
Yeap... but...
We are an ISP fucusing on individuals (most) and business (minority, but growing). Because of nature of our business, we decided to have central BRAS and large L2 (in future MPLS) network. So, most of our subscribers are connected via "ethernet all the way", native DHCP (no PPPoWhatever).
Both - Cisco/Ericsson(RedBack) - for their BRASes have not yet implemented this access method for IPv6.. They have it on roadmap, but it will take a while for first releases and much more before they will be stable enough to put them in production. 2 years at least I suppose..
I know multiple networks like that. The one that ran out of public IPv4 space is now doing NAT444 with 100.64.0.0/10 combined with 6rd. It's certainly not pretty, but it is easy to convert an existing 'ethernet all the way' network to this by adding a set of central NAT boxes and a set of 6rd border relays. The existing IPv4 infrastructure doesn't have to change. You do need to supply 6rd capable CPEs to customers, but those are available from many vendors these days. - Sander
On 2012-11-07 21:59, Sander Steffann wrote:
Hi,
Yeap... but...
We are an ISP fucusing on individuals (most) and business (minority, but growing). Because of nature of our business, we decided to have central BRAS and large L2 (in future MPLS) network. So, most of our subscribers are connected via "ethernet all the way", native DHCP (no PPPoWhatever).
Both - Cisco/Ericsson(RedBack) - for their BRASes have not yet implemented this access method for IPv6.. They have it on roadmap, but it will take a while for first releases and much more before they will be stable enough to put them in production. 2 years at least I suppose.. I know multiple networks like that. The one that ran out of public IPv4 space is now doing NAT444 with 100.64.0.0/10 combined with 6rd. It's certainly not pretty, but it is easy to convert an existing 'ethernet all the way' network to this by adding a set of central NAT boxes and a set of 6rd border relays. The existing IPv4 infrastructure doesn't have to change. You do need to supply 6rd capable CPEs to customers, but those are available from many vendors these days.
- Sander
Sure, but it is still "chewing gum and co.." solution. Quite expasive spearmint... We have no problem with IPv4, but others do. I'am not complaining about that IPv4 is out, rather that vendors have their bussines plans about IPv6... Regards, Marcin
Hi,
this statement might need some adjustment to "there is no IPv4 PI, can we do something else?", like "can we use IPv6 PI plus double-IPv4-PA?" or "can we use IPv6 PI plus our ISP's friendly NAT64 translator?"...
I think these are the only options that can survive in the medium to long term. At some point in time the final /8 will also be depleted and then everybody will be unhappy. We should start moving in such a direction *now*. Geoff Huston showed us years ago: we were meant to deploy IPv6 before the IPv4 pool ran out. We postponed deployment until we did run out. If we keep postponing solutions that don't rely on IPv4 address space then we will remain in the situation we are in now and the pain will become worse and worse. We have been making policies for specific cases (we now have PA form the final /8, we have IXP space from that /8, we are discussing PI from that /8 now). Maybe we need to take a step back and look at the big picture first. I personally think that it would be very bad if ISPs don't have any IPv4 space for things like central NAT64 boxes or similar services for example. We have the current final /8 policy for that now, but lets look a few steps ahead... - Sander
On 11/7/12 1:13 PM, Gert Doering wrote:
These seem much more relevant questions to me than "can we look around in the decks below the water line for additional deck chairs?".
+10 Cheers, Jan
Why not continue give PA-addresses in this case? Many customers need them too. Because you can't multihome PA addresses.
/24 PA works excelent for multihome. I have a lot examples.
They can't rent them because the renting market has not yet developed, and they can't use ipv6 because it's not usable at the moment.
Just send me contacts and I'll help them. I mean IPv4 PA. It is not a problem at all. -- Alexey Ivanov 07.11.2012 15:29 - Nick Hilliard написал(а): On 07/11/2012 10:38, LeaderTelecom Ltd. wrote:
Why not continue give PA-addresses in this case? Many customers need them too.
Because you can't multihome PA addresses.
We have to be consistent: 1. Continue distribute last /8 for PA & PI. OR 2. Don't distribute last /8 for PA & PI (except LIR which didn't get 1024 IPs from last /8).
I think second option is more optimal, while some defficit and increasing prices for IPv4 allow customers run IPv6 faster.
p.s. Who will PI-addresses? Why they can't rent them or start use IPv6?
They can't rent them because the renting market has not yet developed, and they can't use ipv6 because it's not usable at the moment. Nick
On 07/11/2012 13:34, LeaderTelecom Ltd. wrote:
/24 PA works excelent for multihome. I have a lot examples.
I'm sure it does, until the day that the end user gets into contractual problems with the PA LIR and wants to move transit provider, but can't do so easily because they lose the addresses. PI == provider independent. Nick
Nick,
/24 PA works excelent for multihome. I have a lot examples.
I'm sure it does, until the day that the end user gets into contractual problems with the PA LIR and wants to move transit provider, but can't do so easily because they lose the addresses. PI == provider independent.
We allow to use our PA space with any transit provider. So customers will be provider independent. -- Alexey Ivanov 07.11.2012 17:46 - Nick Hilliard написал(а): On 07/11/2012 13:34, LeaderTelecom Ltd. wrote:
/24 PA works excelent for multihome. I have a lot examples.
I'm sure it does, until the day that the end user gets into contractual problems with the PA LIR and wants to move transit provider, but can't do so easily because they lose the addresses. PI == provider independent. Nick
On 07/11/2012 13:53, LeaderTelecom Ltd. wrote:
We allow to use our PA space with any transit provider. So customers will be provider independent.
So what happens when your customer leaves or gets into a dispute with you? Is the PA assignment your IP address or theirs? If it's yours when they leave you, then it's not provider independent. This is the way that most LIRs operate: PA assignments are valid as long as the end user is a customer of the provider. Once they move to another provider and stop taking services from you, then the address assignment is no longer theirs. This is what provider independent means. Anyone can multihome a /24 from an allocated block, but it will still remain part of a PA allocation. Nick
Dear Nick,
We allow to use our PA space with any transit provider. So customers will be provider independent.
So what happens when your customer leaves or gets into a dispute with you? Is the PA assignment your IP address or theirs?
This is our PA. But why they will leave us if they have agreement only for PA-space (without IP-transit)? I see only 2 cases - price or customer don't need IPs and return back.
If it's yours when they leave you, then it's not provider independent. This is the way that most LIRs operate: PA assignments are valid as long as the end user is a customer of the provider. Once they move to another provider and stop taking services from you, then the address assignment is no longer theirs. This is what provider independent means. Anyone can multihome a /24 from an allocated block, but it will still remain part of a PA allocation.
If customer will not pay to sponsoring LIR - RIPE will request IPs back too. I think using PA space is good option for now. And ASAP start use IPv6. -- Alexey Ivanov 07.11.2012 18:06 - Nick Hilliard написал(а): On 07/11/2012 13:53, LeaderTelecom Ltd. wrote:
We allow to use our PA space with any transit provider. So customers will be provider independent.
So what happens when your customer leaves or gets into a dispute with you? Is the PA assignment your IP address or theirs? If it's yours when they leave you, then it's not provider independent. This is the way that most LIRs operate: PA assignments are valid as long as the end user is a customer of the provider. Once they move to another provider and stop taking services from you, then the address assignment is no longer theirs. This is what provider independent means. Anyone can multihome a /24 from an allocated block, but it will still remain part of a PA allocation. Nick
On 07/11/2012 14:32, LeaderTelecom Ltd. wrote:
I think using PA space is good option for now.
It's good if you're happy to build your business with sticky tape, chewing gum and string. Nick
I think using PA space is good option for now.
It's good if you're happy to build your business with sticky tape, chewing gum and string.
Nick, Insternet based on trust. Do you sign legal agreement with each peer? I think, no. -- Alexey Ivanov 07.11.2012 18:58 - Nick Hilliard написал(а): On 07/11/2012 14:32, LeaderTelecom Ltd. wrote:
I think using PA space is good option for now.
It's good if you're happy to build your business with sticky tape, chewing gum and string. Nick
On 07/11/2012 16:10, LeaderTelecom Ltd. wrote:
Nick, Insternet based on trust. Do you sign legal agreement with each peer? I think, no.
No, but I do for each address space provider and transit provider. You can live if a peer session drops because it's not critical to business. The same is not true for either transit or address space service. Nick
On 11/7/12 3:57 PM, Nick Hilliard wrote:
On 07/11/2012 14:32, LeaderTelecom Ltd. wrote:
I think using PA space is good option for now.
It's good if you're happy to build your business with sticky tape, chewing gum and string.
Well, the big part of IETF was quite busy with standardizing "sticky tape, chewing gum and string" for the last decade probably. I'm sure vendors will soon come out with new&shiny tools on their equipment to easily get around this small issue. They are brilliant at doing that (and of course charging for additional license somehow) :) Cheers, Jan
On 2012-11-07 20:38, Jan Zorz @ go6.si wrote:
On 11/7/12 3:57 PM, Nick Hilliard wrote:
On 07/11/2012 14:32, LeaderTelecom Ltd. wrote:
I think using PA space is good option for now.
It's good if you're happy to build your business with sticky tape, chewing gum and string.
Well, the big part of IETF was quite busy with standardizing "sticky tape, chewing gum and string" for the last decade probably.
I'm sure vendors will soon come out with new&shiny tools on their equipment to easily get around this small issue. They are brilliant at doing that (and of course charging for additional license somehow) :)
Oh yeah, tha't what I also feel. Vendors will find solutions to keep IPv4 forever... Recently I saw a lot of CarrierGrade NAT presentations on conference schedules... Regards, Marcin
On 2012-11-07 14:53, LeaderTelecom Ltd. wrote:
Nick,
/24 PA works excelent for multihome. I have a lot examples.
I'm sure it does, until the day that the end user gets into contractual problems with the PA LIR and wants to move transit provider, but can't do so easily because they lose the addresses. PI == provider independent.
We allow to use our PA space with any transit provider. So customers will be provider independent.
Without beeing yours customer for transit ? If yes, I suppose that you charge them for using your PA addresses. Regards, Marcin
-- Alexey Ivanov
07.11.2012 17:46 - Nick Hilliard написал(а): On 07/11/2012 13:34, LeaderTelecom Ltd. wrote:
/24 PA works excelent for multihome. I have a lot examples.
I'm sure it does, until the day that the end user gets into contractual problems with the PA LIR and wants to move transit provider, but can't do so easily because they lose the addresses. PI == provider independent.
Nick
Hi Marcin,
Without beeing yours customer for transit ? If yes, I suppose that you charge them for using your PA addresses.
I’m pretty sure he is not doing it for free. And with the current market, providing transit to a customer doesn’t mean that they can blindly request additional IP’s without any additional financial contractual agreement I presume. There are already some ISP’s that charge for additional IP addresses on a service. And I would expect that this would become more the standard than the exception . . . Charge extra for IPv4 addresses, provide v6 for free. Regards, Erik Bais
Dear Marcin,
Without beeing yours customer for transit ? If yes, I suppose that you charge them for using your PA addresses.
Correct. We just registry. Most of our customers uses PI-addresses. But for now PA-addresses instead of PI is a good option. -- Alexey Ivanov 07.11.2012 23:28 - Marcin Kuczera написал(а): On 2012-11-07 14:53, LeaderTelecom Ltd. wrote: Nick,
/24 PA works excelent for multihome. I have a lot examples.
I'm sure it does, until the day that the end user gets into contractual problems with the PA LIR and wants to move transit provider, but can't do so easily because they lose the addresses. PI == provider independent.
We allow to use our PA space with any transit provider. So customers will be provider independent. Without beeing yours customer for transit ? If yes, I suppose that you charge them for using your PA addresses. Regards, Marcin -- Alexey Ivanov 07.11.2012 17:46 - Nick Hilliard написал(а): On 07/11/2012 13:34, LeaderTelecom Ltd. wrote:
/24 PA works excelent for multihome. I have a lot examples.
I'm sure it does, until the day that the end user gets into contractual problems with the PA LIR and wants to move transit provider, but can't do so easily because they lose the addresses. PI == provider independent. Nick
On Wed, Nov 07, 2012 at 01:45:55PM +0000, Nick Hilliard wrote:
On 07/11/2012 13:34, LeaderTelecom Ltd. wrote:
/24 PA works excelent for multihome. I have a lot examples.
I'm sure it does, until the day that the end user gets into contractual problems with the PA LIR and wants to move transit provider, but can't do so easily because they lose the addresses. PI == provider independent.
But your original point was: "Because you can't multihome PA addresses." Yes, you can. ;-) Please make your mind about your arguments. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
On 07/11/2012 14:18, Piotr Strzyzewski wrote:
But your original point was: "Because you can't multihome PA addresses." Yes, you can. ;-)
Please make your mind about your arguments.
You can, with the implicit agreement of the LIR who holds the allocation and the explicit agreement of a third party provider. If either choose not to play agree, then your multihoming plans either won't work (third party disagrees) or can be screwed up (LIR disagrees). Either way, it's not provider independent in any meaningful way and can lead to serious business harm if there is a breakdown in any of the arrangements. Nick
On Wed, Nov 07, 2012 at 02:39:31PM +0000, Nick Hilliard wrote:
On 07/11/2012 14:18, Piotr Strzyzewski wrote:
But your original point was: "Because you can't multihome PA addresses." Yes, you can. ;-)
Please make your mind about your arguments.
You can, with the implicit agreement of the LIR who holds the allocation and the explicit agreement of a third party provider. If either choose not to play agree, then your multihoming plans either won't work (third party disagrees) or can be screwed up (LIR disagrees). Either way, it's not provider independent in any meaningful way and can lead to serious business harm if there is a breakdown in any of the arrangements.
So, your point should be: "Because you can't always multihome PA addresses in the easy way.". ;-) Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
* Nick Hilliard
On 06/11/2012 16:32, Tore Anderson wrote:
2012-03[*] won't pass soon, and there is no guarantee that it ever will. Judging by the discussion it stirred up at the last RIPE meeting, I believe it has rather slim chances of reaching consensus.
I don't think it's all doom and gloom, btw.
True. I didn't mean to suggest that this propsal, if amended, could not reach consensus at some point in the future. My main message was that telling one's customers to sit around and wait for that to happen is really bad advice, unless it comes with a big fat warning that the waiting period may be very long, possibly even infinite. If the customer absolutely must acquire multihomable IPv4 address space, becoming an LIR is currently the only way that is certain to succeed in a reasonable time frame. That's what I tell my customers, anyway. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/
On 06/11/2012 18:35, Tore Anderson wrote:
True. I didn't mean to suggest that this propsal, if amended, could not reach consensus at some point in the future. My main message was that telling one's customers to sit around and wait for that to happen is really bad advice, unless it comes with a big fat warning that the waiting period may be very long, possibly even infinite.
There's no "may" about it. The waiting period _will_ be long. 2012-04 will have to go back to initial discussion phase, and the journey from there to policy takes a minimum of 19 weeks. That's assuming it's all plain sailing. Nick
On 11/6/12 5:10 PM, George Giannousopoulos wrote:
We already have customers asking for PI space and all we can tell them is to wait.
tell them "no" or put them in endless wait loop ;) if/when policy changes, take them out of the loop. reality.press Cheers, Jan
participants (20)
-
Andrzej Dopierała -
David Farmer -
Erik Bais -
George Giannousopoulos -
Gert Doering -
Greg -
Hamed Shafaghi -
Jan Zorz ＠ go6.si -
Jim Reid -
LeaderTelecom Ltd. -
Marcin Kuczera -
Mikael Abrahamsson -
Nick Hilliard -
Piotr Strzyzewski -
Remco Van Mook -
Richard Hartmann -
Sander Steffann -
Tore Anderson -
Yannis Nikolopoulos -
Виталий Туровец