The final /8 policy proposals, part 3
Hello everyone, It has been quiet for some time now, so I think we should start to discuss the final /8 proposals again. In part 2 of the discussion, we discussed how many addresses an LIR should be able to get from the final /8. I'll try to summarize that part of the discussion. Please correct me if I am wrong or if I missed something: Most people preferred option b: All requests are downscaled by a certain factor Some people preferred option a: Everyone gets one (and only one) fixed size block There were comments that IPv4 would never run out, but let's assume that it will run out. In the worst (best?) case we won't need this final /8 policy, so it doesn't hurt to be prepared when we do need it. Because most people preferred option b, let's discuss some of the details to see if we can make that work. If we are going to downscale address space requests, how should we do that? Some issues: - If a company demonstrates the need for a /20, we could give them (for example) a /26. Smaller organisations would end up with even smaller amounts of address space. Currently prefixes longer than a /24 can not really be routed on 'the Internet' (for some definition of 'Internet'). Do we expect this to change, or do we have to make the minimum allocation size a /24 so that LIRs receiving address space can use it? - Do we want a maximum allocation size? This might be useful to prevent a few large companies to grab most of the address space, but it might also be unnecessary. - Do we want to make exceptions for certain situations where downscaling is not possible? For example a server farm with many HTTPS sites can't use less IP addresses than the number of websites (with the current protocols). I would like to leave PI assignments out od the discussion for now. I think we have enough PA related questions to discuss, but don't worry: we will get to the PI discussion later. As before: please stay on topic. This discussion is hard enough as it is :) Thanks, Sander Steffann APWG co-chair
It has been quiet for some time now, so I think we should start to discuss the final /8 proposals again.
Perhaps we could do better than just repeat the previous discussion. First of all, let's set the context. If we have a policy for the final /8 then this policy will take effect when IANA announces that the global supply of IPv4 addresses has run out. That's why the final /8 is final. At that time there will be a lot of media coverage of IANA's announcement and greater awareness that the RIRs only have a limited regional supply of IPv4 addresses left. At that point in time, RIPE will be able to project its own runout of IPv4, based on past allocation history and its policies. I wonder what that runout date would be? How much IPv4 inventory is RIPE likely to have when it gets a new /8 allocation, and what is the run-rate for IPv4 allocations per month? What period of time are we talking about? This is important, because if the period of time is short enough, we could ask all LIRs to tell RIPE what their IP address requirements are month by month. Then RIPE can see how much the inventory is oversubscribed, and allocate the entire inventory at one time, dividing it up so that everyone runs out at the same time. Why do this? So that we help ISPs who are providing IPv6 Internet access to get market penetration for their services by creating yet another media event. A scheme like a) allocate one fixed block size, or b) starve everyone equally, will result in everyone running out at different times. This makes it harder to get the attention of the market and sell IPv6 services in sufficient volume. The policy to implement this would call for RIPE to halt all IPv4 allocations when IANA issues the final /8, analyze the current situation, publish a runout date and monthly run-rate for the RIPE region, and then call for applications. Once the applications are in, RIPE could publish the amounts requested and LIR identity for each allocation, propose an actual set of allocations that would result in all those RIRs running out at the same time, then call an extraordinary RIPE meeting to vote on what to do with the IPv4 inventory. Let's not try to decide exactly what to do today, when we lack information. Instead, let's push this EXTRAORDINARY decision making into the future where it belongs, at the time when the EXTRAORDINARY event takes place. --Michael Dillon
On 25 Aug 2009, at 09:31, <michael.dillon@bt.com> wrote:
Instead, let's push this EXTRAORDINARY decision making into the future where it belongs, at the time when the EXTRAORDINARY event takes place.
I STRONGLY disgaree with this. It will be very unwise -- I'm being charitable here -- to postpone this fundamentally crucial policy discussion until the extraordinary event occurs. First of all, there is the potential for all sorts of trouble if RIPE tries to invent and then introduce new policies at that critical point. Obvious examples of this trouble include regulatory interventions, lawsuits, investigations by competition authorities and so on. At the point where IANA v4 runs out, expect everyone, particularly lawyers and governments, to take a much, much closer interest in IP addressing and how it's co-ordinated.] Then there's the likely bickering between LIRs. Or between the RIRs. Or some combination of those. Secondly, it's extremely unlikely a consensus on how to manage those dwindling v4 addresses could emerge at that point. When the SS IPv4 starts to sink, the prospect of a reasoned discussion reaching an agreed conclusion about who does and doesn't get space on the lifeboats which can't accommodate everyone don't look good. There's a Titanic analogy in here somewhere. Hopefully it won't involve that wretched Celine Dion song. :-) Finally, and perhaps most importantly, if policy making about the last /8 is to be postponed until that event, it's doubtful that a consensus could be reached in time to make a difference. Assuming there is a difference to be made which is worth it at that point. At the moment it takes the WG and the PDP some months to agree somewhat non-controversial policies: like anycast assignments for TLD DNS. Carving up the remaining IPv4 space is already controversial. After this extraordinary event occurs, will the controversy level be lower, about the same or higher?
Instead, let's push this EXTRAORDINARY decision making into the future where it belongs, at the time when the EXTRAORDINARY event takes place.
I STRONGLY disgaree with this.
It will be very unwise -- I'm being charitable here -- to postpone this fundamentally crucial policy discussion until the extraordinary event occurs.
You missed the bit about gathering some data which could be used to make the decision. Do you think it is wise to decide now, without knowing what the RIPE monthly run-rate is or when RIPE's address supply is projected to runout?
First of all, there is the potential for all sorts of trouble if RIPE tries to invent and then introduce new policies at that critical point.
If RIPE makes new policy NOW that delays decisionmaking until a future event occurs, then there will be no need to invent and introduce new policies in the future. In particular, if we all agree now that it is most fair for the last /8 to be allocated in a way that the recipients of it all run out at roughly the same time, and that agreement sticks over the next couple of years until the event happens, then there is no invention happening in the future, just execution of the plan. In addition, I suggest that the allocation of RIPE's IPv4 inventory after IANA runout, should be confirmed by a general meeting which seems to me to be a very fair and open way to do this.
Obvious examples of this trouble include regulatory interventions, lawsuits, investigations by competition authorities and so on. At the point where IANA v4 runs out, expect everyone, particularly lawyers and governments, to take a much, much closer interest in IP addressing and how it's co-ordinated.]
Precisely. This scrutiny will happen regardless of what RIPE policies are in place. It is for this reason that I am suggesting that the policy for IPv4 allocation after IANA runout, should be done in an even more transparent way than normally. For instance all LIRs lay their cards on the table for all to see by submitting IPv4 requests which are published before a general meeting decides how much to give everyone. IPv4 runout is not business as usual and I believe that it makes sense to handle it as the extraordinary event that it is.
Secondly, it's extremely unlikely a consensus on how to manage those dwindling v4 addresses could emerge at that point.
I believe that RIPE meetings do not make decisions by consensus which is why I proposed this route.
When the SS IPv4 starts to sink, the prospect of a reasoned discussion reaching an agreed conclusion about who does and doesn't get space on the lifeboats which can't accommodate everyone don't look good.
How do you know? We have no crystal balls to predict the future. Why do we need to decide this today, when there is little motivation to reach a decision and not enough information available to make a decision. For instance we do not know what will be the market penetration of IPv6 at the point of IANA runout.
Finally, and perhaps most importantly, if policy making about the last /8 is to be postponed until that event, it's doubtful that a consensus could be reached in time to make a difference.
You missed the part where I said that we change RIPE policy so that when IANA allocates the final /8, RIPE ceases all IPv4 allocation activity under the old rules, and invokes the new ones. No consensus is needed, just execution of the plan and a decision at the EXTRAORDINARY general meeting.
Carving up the remaining IPv4 space is already controversial. After this extraordinary event occurs, will the controversy level be lower, about the same or higher?
Higher. Which is why we need to change policy today so that after IANA runout, a decision will be made by a more efficient method. --Michael Dillon
On 25 Aug 2009, at 10:48, <michael.dillon@bt.com> wrote:
You missed the bit about gathering some data which could be used to make the decision.
I've re-read your message and still can't find the bit where you clearly say when this data gathering and analysis would be done or when informed policy making based on that analysis would take place. The last paragraph in your email left me to conclude you suggested doing this later. I quote:
Let's not try to decide exactly what to do today, when we lack information. Instead, let's push this EXTRAORDINARY decision making into the future where it belongs, at the time when the EXTRAORDINARY event takes place.
Oh well...
Do you think it is wise to decide now, without knowing what the RIPE monthly run-rate is or when RIPE's address supply is projected to runout?
My personal opinion, for what it's worth, is we continue with the current policies for IPv4 until the NCC has no more left. There doesn't seem much point or benefit from tinkering at the margins. I can't see policy changes resulting in a fairer or improved allocation of the remaining space: for some definitions of fair and improve. And as my previous message pointed out, I think there are a number of risks in deviating from those policies when the crunch points are just around the corner.
In addition, I suggest that the allocation of RIPE's IPv4 inventory after IANA runout, should be confirmed by a general meeting which seems to me to be a very fair and open way to do this.
No, it's not a fair or open way to do that. [What about those who can't physically get to the meeting? Web/phone participation doesn't count. Who gets to vote?] It's also incompatible with the current Policy Development Process which is based on list-driven, bottom-up consensus.
Obvious examples of this trouble include regulatory interventions, lawsuits, investigations by competition authorities and so on. At the point where IANA v4 runs out, expect everyone, particularly lawyers and governments, to take a much, much closer interest in IP When the SS IPv4 starts to sink, the prospect of a reasoned discussion reaching an agreed conclusion about who does and doesn't get space on the lifeboats which can't accommodate everyone don't look good.
How do you know? We have no crystal balls to predict the future.
True. However human nature tells us we can expect an "every man for themself" attitude in such scenarios. IIUC game theory and behavioural economics indicate that approach works best for the individual but worst for the group in these scenarios.
Why do we need to decide this today, when there is little motivation to reach a decision and not enough information available to make a decision. For instance we do not know what will be the market penetration of IPv6 at the point of IANA runout.
IMO this is another reason for not even trying to make a decision. The current policy isn't broken and doesn't need fixing. And any tinkering to accommodate scenarios just before or after run-out are not going to make a significant difference. Even if they could take account of all the other imponderables like the then state of IPv6 penetration that you rightly point out can't be predicted. So why bother?
Carving up the remaining IPv4 space is already controversial. After this extraordinary event occurs, will the controversy level be lower, about the same or higher?
Higher.
I'm glad we agree about something Michael. :-)
Which is why we need to change policy today so that after IANA runout, a decision will be made by a more efficient method.
IMO it's going to be impossible to come up with a definition of efficient for this scenario that (a) gets consensus; (b) is meaningful for the last days of v4.
No, it's not a fair or open way to do that. [What about those who can't physically get to the meeting? Web/phone participation doesn't count. Who gets to vote?]
If some people feel that the meeting is not important enough to make an effort to attend, then they don't get a vote. Whether it is because they can't afford to attend or because they've already got full IPv6 services on offer, it makes no difference.
It's also incompatible with the current Policy Development Process which is based on list-driven, bottom-up consensus.
The extraordinary general meeting would not be about changing policy, it would be about an activity plan to divide up the remaining inventory of IPv4 addresses between the applicants who have requested a piece of the final /8.
Why do we need to decide this today, when there is little motivation to reach a decision and not enough information available to make a decision. For instance we do not know what will be the market penetration of IPv6 at the point of IANA runout.
IMO this is another reason for not even trying to make a decision. The current policy isn't broken and doesn't need fixing.
This is also a reasonable approach, i.e. I have suggested option c) but your suggestion of option d) is also worthy of consideration.
I'm glad we agree about something Michael. :-)
Perhaps we agree that simply re-evaluating options a) and b) is not the best way to proceed? --Michael Dillon
Hello Michael,
No, it's not a fair or open way to do that. [What about those who can't physically get to the meeting? Web/phone participation doesn't count. Who gets to vote?]
If some people feel that the meeting is not important enough to make an effort to attend, then they don't get a vote. Whether it is because they can't afford to attend or because they've already got full IPv6 services on offer, it makes no difference.
I want to end this discussion right here. The way RIPE makes its policies is very open, clear and not open for discussion. (At least not now and not on this list) You can find the PDP here: http://www.ripe.net/ripe/docs/pdp.html . This working group will follow the PDP. I agree that the allocation of the last IPv4 addresses is an extraordinary situation, but we will not ignore our own rules because of that. If you do not agree with the PDP I think the RIPE chair (chair@ripe.net) is the right person to talk to. Thank you, Sander Steffann APWG co-chair
Hello Michael,
I want to end this discussion right here. The way RIPE makes its policies is very open, clear and not open for discussion.
I never suggested that RIPE change the way that it makes its policies. Instead I suggested a policy that includes a checkpoint for the general members to approve a future action plan, just before RIPE actually carries out the action plan.
. This working group will follow the PDP.
I have never suggested that the WG should not follow the PDP. I would expect that if RIPE adopts any policy related to special allocation rules after IANA runout, that the policy would be developed according to the PDP. Please note that if you go back to my original suggestion and remove the extraordinary general meeting from it, that does not substantially change the suggestion. This whole confusion about what members meetings can do is a red herring. I'm beginning to wonder why there is such an uproar about the RIPE members making a decision... --Michael Dillon
Hi, On Tue, Aug 25, 2009 at 10:48:37AM +0100, michael.dillon@bt.com wrote:
In addition, I suggest that the allocation of RIPE's IPv4 inventory after IANA runout, should be confirmed by a general meeting which seems to me to be a very fair and open way to do this.
Address Policy is not made at the RIPE General Meeting. *Especially* since the general meeting is not "open" to the whole community. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 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 25 Aug 2009, at 09:31, <michael.dillon@bt.com> wrote:
The policy to implement this would call for RIPE to halt all IPv4 allocations when IANA issues the final /8, analyze the current situation, publish a runout date and monthly run-rate for the RIPE region, and then call for applications.
I can't see this ever flying with the membership. Suppose this hypothetical policy was in force. An LIR has a business need for more IPv4 after this moratorium applied. At that point the NCC is sitting on a stockpile of addresses but isn't handing them out. What will the LIR do? (a) sit back and politely wait an indefinite but probably long time until some analysis is done and the AP WG arrives at a consensus on how the remaining stockpile is to be managed; (b) reach for its lawyers (c) complain to government/regulator about restraint of trade, anti- competitive behaviour, unfair markets, etc. Somehow I can't see an LIR doing (a). Even if this was the best solution from a global perspective -- tragedy of the commons and all that -- it seems unlikely the LIR will sit on its hands while it loses customers to another LIR that has IPv4 space available.
Suppose this hypothetical policy was in force. An LIR has a business need for more IPv4 after this moratorium applied. At that point the NCC is sitting on a stockpile of addresses but isn't handing them out. What will the LIR do? (a) sit back and politely wait an indefinite but probably long time until some analysis is done and the AP WG arrives at a consensus on how the remaining stockpile is to be managed; (b) reach for its lawyers (c) complain to government/regulator about restraint of trade, anti- competitive behaviour, unfair markets, etc.
All of the above. But they will also file an application with RIPE which will be included in the list of LIR applications that RIPE publishes before holding the general meeting which will decide how much address space to give out. The wheels of the legal and regulatory system spin slowly, and it is highly likely that the general meeting will be over before any judicial authorities review the complaint. In addition, RIPE has lawyers too, as do other LIRs who are willing to wait for a fair solution to play out. The fair solution is for everyone to get the same amount of time to continue growing their IPv4 stockpile. To do that we need to know RIPE's run-rate, and the run-rates of every LIR that needs some IPv4 allocations after the IANA runout. Instead of making up arbitrary allocations sizes today, we can balance the time factor and round off to the nearest /24. --Michael Dillon
On 25 Aug 2009, at 10:54, <michael.dillon@bt.com> wrote:
The fair solution is for everyone to get the same amount of time to continue growing their IPv4 stockpile.
That kind of implies we stick with the current policies as-is.
To do that we need to know RIPE's run-rate, and the run-rates of every LIR that needs some IPv4 allocations after the IANA runout. Instead of making up arbitrary allocations sizes today, we can balance the time factor and round off to the nearest /24.
While this data would be useful, I'm not sure how it will help LIRs with their planning. How many LIRs know now (or soon) what their IPv4 needs will be once IANA runout is reached? Will they share that data? Will it be truthful? If I was an LIR, I'd be tempted to inflate my post runout needs in the hope of getting an extra chunk of the then scarce and valuable IPv space. Partly that could be justified by conservative engineering. OTOH it could be for baser motives: like getting extra space which can be traded. Even if accurate run-rate data was available, it would inevitably be a snap shot and inherently out of date. And it would undoubtedly influence LIR behaviour. Which would have an impact on run-rates. My guess is this would promote depletion of the remaining v4 space, but not necessarily in a fair way.
On 25 Aug 2009, at 10:54, <michael.dillon@bt.com> wrote:
But they will also file an application with RIPE which will be included in the list of LIR applications that RIPE publishes before holding the general meeting which will decide how much address space to give out.
I'm confused. Which general meeting are you talking about? AFAIK address policy for the RIPE region is decided on this mailing list. RIPE NCC holds general meetings for its members, the LIRs. These vote on the activity plan, decide membership fees and elect the board. Those meetings don't currently vote on RIPE policies other than indirectly through how those policies are reflected in the activity plan.
Hi, ...
This is important, because if the period of time is short enough, we could ask all LIRs to tell RIPE what their IP address requirements are month by month. Then RIPE can see how much the inventory is oversubscribed, and allocate the entire inventory at one time, dividing it up so that everyone runs out at the same time.
Why do this? So that we help ISPs who are providing IPv6 Internet access to get market penetration for their services by creating yet another media event. A scheme like a) allocate one fixed block size, or b) starve everyone equally, will result in everyone running out at different times. This makes it harder to get the attention of the market and sell IPv6 services in sufficient volume.
Two remarks on this: {this is more a formal one] (1) in a previous poll from Sander, we'd a large majority of comments against bundling IPv4 use with IPv6 (deployment). This looks like getting in through the backdoor. (2) changing run-rates will render your approach useless. And it is very likely, that run-rates will change at the end of life cycle. Regards, Andreas -- -- Andreas Schachtner afs Holding GmbH communication technologies & solutions http://afs-com.de/ Geschaeftsfuehrer Andreas Schachtner HRB 15448, Amtsgericht Dortmund
(2) changing run-rates will render your approach useless. And it is very likely, that run-rates will change at the end of life cycle.
That is why I would like to see a decision based on run-rates in the future, when those run-rates are known to everyone. In the meantime RIPE can regularly publish run-rates so that when the final /8 comes to RIPE, we have a standard of comparison. --Michael Dillon
On 25 Aug 2009, at 15:37, <michael.dillon@bt.com> wrote:
That is why I would like to see a decision based on run-rates in the future, when those run-rates are known to everyone.
EH? You said earlier that no-one has a crystal ball. So predictions of future run-rates are just that: predictions. A policy based on those predictions therefore makes no sense. We might as well be developing policies based on the number of unicorns each LIR has. Or says they plan to have when the last /8 leaves IANA. Anyway, let's get back to the original poster's point. What use is a policy developed today based on we *think* future run-rates will be. What's the point of that when the actual run rates at the point when this policy took effect would almost certainly be different from those predictions? What is there to be gained from such a policy? What would such a policy achieve that the current policy doesn't?
On 24 Aug 2009, at 21:04, Sander Steffann wrote:
Most people preferred option b: All requests are downscaled by a certain factor Some people preferred option a: Everyone gets one (and only one) fixed size block Because most people preferred option b, let's discuss some of the details to see if we can make that work. If we are going to downscale address space requests, how should we do that? Some issues:
Slightly rephrasing Sander's questions .. - Do we want a maximum allocation size ? Maybe, although certainly not to the levels discussed in recent threads, e.g. /26. I still think that PA should be highly aggregatable for it to be fit for purpose. If we have typical PA allocations of /26, which by and large will be unroutable, we make the last /8 broadly useless. If we do that, we effectively make the v4 dry period start one /8 earlier. Does this matter ? Well, if our work makes the last /8 useless, it moves the sky a thousand feet closer to the earth. If we don't do this work, then the sky is STILL FALLING. - Do I think the minimum allocation size should fall ? Maybe, but if everyone decides to be a 'good citizen' and ask for a / 22 rather than /21, how much extra time would we buy ? 3 or 4 months ? Perhaps a smaller minimum allocation size for the last /8 pushes the sky back a few hundred feet, but it sure looks like it's getting closer.. - Do I think companies should be limited to one PA allocation from the last /8 ? Probably not, because we will make a lot of business for lawyers trying to define what 'one company' is. If a company has an arm in Switzerland, one in the UK, one in France, then does spending money on three LIR memberships earn 3x PA ? What about if an e-commerce organisation, an ISP, and a hosting company have the same ultimate parent company, must only one of those organisations receive addresses ? Can I bypass this by requesting PI ? If so, all of my end users will just have to obtain PI through my LIR and we have the same amount of addresses in use, but an extra route in the routing table to carry - the net result is a worse situation, but the same addresses in use. Does that sky look any closer to you.. ? - Should we make an exception for people who say downscaling is not possible, e.g. https server farm. Hmm, whats this blue thing surrounding and crushing me, argh ! - What are our motives ? Are we building a policy that is designed to placate the regulators and governments at the time of the last /8 ? Because, if so, have we not done enough v6 promotion ? If our motivation is the extend the life of v4, then this is playing into the hands of Big NAT vendors. We can do much harm whilst trying to do good in the construction of intervention policies. The only fix is to deploy v6, so policies which are designed to extend the life of v4 will muddy the pro-v6 message that we want to send to operators. Andy Davidson
On 21 Sep 2009, at 17:35, Andy Davidson wrote:
Slightly rephrasing Sander's questions ..
Sorry, I missed another question which I would like to add. If we design a policy which is somehow more 'fair' than the policies which we assign with today, what is the rationale for leaving it until the last /8 before putting it into action ? Thanks Andy
- Do we want a maximum allocation size ?
Yes, based on the applicant's run-rate. In other words the maximum is not an arbitrary fixed amount of IP space, but an arbitrary fixed time period that is used, with the run-rate, to calculate the allocation size. The end result is that everybody's last allocation runs out at roughly the same time.
If we have typical PA allocations of /26, which by and large will be unroutable, we make the last /8 broadly useless. If we do that, we effectively make the v4 dry period start one /8 earlier.
Any policy change is going to make the v4 scarcity period start earlier so the best we can do is to make the shape of that scarcity period less harsh. This is why I keep talking about an attempt to make everyone's free space run out at roughly the same time. I believe that this will mimimize the negative impact even though it would result in a certain amount of routing table consumption for very long prefixes.
Does this matter ? Well, if our work makes the last /8 useless, it moves the sky a thousand feet closer to the earth. If we don't do this work, then the sky is STILL FALLING.
The sky is falling regardless of our actions. And if RIPE hands out /26 blocks that end up being unroutable, the unroutability is the ISP's fault, not RIPE's. In other words, if LIRs vote for a policy change that results in /26 allocations, one would expect that those LIRs would follow through by changing their routing filters.
- Do I think the minimum allocation size should fall ?
Maybe, but if everyone decides to be a 'good citizen' and ask for a / 22 rather than /21, how much extra time would we buy ? 3 or 4 months ?
Perhaps a smaller minimum allocation size for the last /8 pushes the sky back a few hundred feet, but it sure looks like it's getting closer..
If there is a good reason to simply reduce allocation sizes then there is no good reason why we should wait until the final /8 to make that reduction.
- Do I think companies should be limited to one PA allocation from the last /8 ?
Probably not, because we will make a lot of business for lawyers trying to define what 'one company' is. If a company has an arm in Switzerland, one in the UK, one in France, then does spending money on three LIR memberships earn 3x PA ?
All modern multinational companies, and many larger domestic companies are actually formed as a collection of many corporations. Sometimes this is simply a result of the way mergers and acquisitions are done, and sometimes it is done for tax reasons. These component corporate entities do not necessarily use the mother company's brand name in their corporate name, so RIPE may not even know that two LIRs are related. I think that we will do better by focusing on the demand, and make rules for applicants who ask for address space. Separately, RIPE might want to work on the issues of merging LIRs.
We can do much harm whilst trying to do good in the construction of intervention policies. The only fix is to deploy v6, so policies which are designed to extend the life of v4 will muddy the pro-v6 message that we want to send to operators.
It is still reasonable to change the IPv4 policy so that everybody suffers equally as we use up the last drops of IPv4. --Michael Dillon
participants (6)
-
Andreas Schachtner -
Andy Davidson -
Gert Doering -
Jim Reid -
michael.dillon＠bt.com -
Sander Steffann