[AusNOG] IPv4
Bevan Slattery
Bevan.Slattery at nextdc.com
Tue Mar 5 08:31:14 EST 2013
Sorry (2) is meant to say "(2) an initial $1 per IPv4 PER ANNUM"
[b]
On 5/03/13 7:28 AM, "Bevan Slattery" <Bevan.Slattery at nextdc.com> wrote:
>It is easy - if the RIR's only have the courage. Just an idea.
>
>Modify the "membership" criteria so that:
>
>(1) $1,000 base membership (or whatever number)
>(2) + an initial US$1 (or similar number) per IPv4 address "IPv4
>membership" cost per allocated IPv4 address (only fair that those that
>BENEFIT from a finite resource all equally share a cost for same)
>(3) Notice goes out in the next 60 days (provides notice that change is
>coming)
>(4) First invoice for IPv4 space goes out based upon your allocation used
>as at 31/12/2013 and its anniversary each year after (provides time to
>modify behaviour and reallocate network)
>(4) 90 day "embargo period" for those wishing re-assign space between 1
>October and 31 December - (meaning if you want to reduce your space you
>can hand it back to the RIR during that period - but if you want to sell
>it if you must do it earlier in the year to provide other people the
>opportunity to get it registered to them for the new year)
>
>It's a finite resource and we all need an incentive to change. If you
>can't be bothered to go through the pain to move/double stack and
>reallocate then that's fine - you will be paying for the privilege and
>that money goes towards IPv6 marketing/development strategies.
>
>With this type of structure in place we would all be incentivised to move
>to IPv6 equally which is the what is needed. If we don't then there will
>be many, many organisations in the developed internet world which have
>their IPv4 fill and can't be bothered going down the path to the (initial)
>detriment of those that only have IPv6.
>
>A soft landing and an economical reason for people to audit themselves.
>It's call allocation MANAGEMENT.
>
>And if as everyone (including the RIR's) say they all knew this was coming
>10 years ago (and we did) then this should have been implement 10 years
>ago and we simply wouldn't be in the position we are today.
>
>[b]
>
>[b]
>
>
>
>
>
>
>On 5/03/13 7:02 AM, "Mark Andrews" <marka at isc.org> wrote:
>
>>
>>In message <002601ce18a8$81df23e0$859d6ba0$@rb.net.au>, "Rod Veith"
>>writes:
>>>
>>> Mark Andrews questions, my answers:
>>>
>>>
>>>
>>> Q1: I'm curious, how would you have allocated address over the last 10
>>> years?
>>>
>>> A: Not sure I could have done better with allocations. What could have
>>>been
>>> done better is a 'use it or lose it' clause in the conditions applying
>>>to
>>> not only new allocations but all historical allocations.
>>
>>So you can't actually point out anywhere that the RIRs have mismanaged
>>the allocations. IPv4 addresses were always going to run out. That
>>the addresses have run out is not evidence of mismangement.
>>
>>As for a 'use it or lose it' being added to the conditions almost
>>all applicants did use it. All I can see with a 'use it or lose
>>it' policy is that RIR's would have been spending vast amounts of
>>money doing mostly useless audits which as far as I can tell is the
>>only way to enforce a 'use it or lose it' policy. There were rules
>>to recover addresses when companies failed and they weren't in use
>>otherwise they were transfered.
>>
>>As for retroactively applying new rules to legacy allocations I
>>suspect that it would have been squashed at the first court case.
>>Note any additional applications for addresses required that the
>>applicants demonstrate that they were using their existing address
>>by the new guide lines. Lots of legacy address holders were being
>>held to exactly the same conditions as the rest of the address
>>holders due to this. Also for APNIC and RIPE there are very few
>>legacy allocation. The vast majority of those where inherited by
>>ARIN.
>>
>>> Q2: Please list actual resources that APNIC, ARIN or RIPE could
>>>recover.
>>>
>>> A: Specious question used to mask a case for doing nothing. Please ask
>>> better questions that contribute in a meaningful way this good
>>>discussion.
>>
>>You claim that there is vast amounts of unused addresses out there
>>to be reclaimed. I've got no doubt that there are some addresses.
>>I doubt that there are vast amounts or that it would be worth
>>spending the money required to firstly uncover them and secondly
>>to get them returned.
>>
>>Yes it is a pain to not have the addresses you need to expand. I
>>suspect that you would have better results with a public awareness
>>campain asking why Optus and Telstra are abusing their dominate
>>market position by not offering IPv6 to residential customers. If
>>Telstra Wholesale can deliver IPv6 them Telstra Retail can as well.
>>
>>IPv6 is place where ISP's need to take the lead to keep the Australian
>>economy compeditive.
>>
>>> Q3: Is there really? Not globally announced does not mean that they
>>>are
>>> mis-managed.
>>>
>>> A: Partially agreed. The fact some people have legitimate uses is no
>>>excuse
>>> to do nothing.
>>>
>>>
>>>
>>> Q4: Again what used addresses?
>>>
>>> A: See answer to Q2.
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Mark Andrews [mailto:marka at isc.org]
>>> Sent: Monday, 4 March 2013 5:01 PM
>>> To: Rod Veith
>>> Cc: 'AusNOG at lists.ausnog.net'
>>> Subject: Re: [AusNOG] IPv4
>>>
>>>
>>>
>>>
>>>
>>> In message < <mailto:011c01ce188c$c91f1ab0$5b5d5010$@rb.net.au>
>>> 011c01ce188c$c91f1ab0$5b5d5010$@rb.net.au>, "Rod Veith" writes:
>>>
>>> >
>>>
>>> > "Was v4 allocations screwed? I don't know. We didn't know what was
>>>
>>> > going to happen 20 years ago... It is easy to look back in
>>>hindsight."
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > V4 allocations ARE screwed using hindsight. There is one camp saying
>>>
>>> > get over it, use V6 and forget the screwed V4 allocations. And the
>>>
>>> > other camp says why not try to fix the problem.
>>>
>>>
>>>
>>> I'm curious, how would you have allocated address over the last 10
>>>years?
>>> As far as I can tell the RIR's all have allocated address on the basis
>>>of
>>> need. They didn't hide the fact that IPv4 address were in limited
>>>supply.
>>> They did all they could to promote IPv6 which unlike IPv4 has enough
>>> addresses for everyone on the planet.
>>>
>>>
>>>
>>> > It is typical human behaviour to sit on resources even if they are
>>>not
>>>
>>> > being used because 'one just never knows if they might be needed in
>>>10
>>>
>>> > years' time or worth something. Just because many people and
>>>
>>> > businesses do this doesn't make it right, just as sitting back and
>>>
>>> > letting past mistakes continue is not right.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I think it is wrong of APNIC to NOT take a more proactive role in
>>>
>>> > recovering
>>>
>>> > V4 allocations that were obvious mistakes in the past, just as other
>>>
>>> > "resource allocators" around the world should be doing the same
>>>thing.
>>>
>>> > Just because people with allocations are going to scream "you can't
>>>
>>> > take away something I might use one day etc etc" doesn't mean the
>>>
>>> > attempt shouldn't be made.
>>>
>>>
>>>
>>> Please list actual resources that APNIC, ARIN or RIPE could recover.
>>>
>>> > "IPv4 is dead. People need to get over it and move to IPv6..."
>>>
>>> >
>>>
>>> >
>>>
>>> > No, IPv4 is not dead. Why should people get over it when quite
>>>clearly
>>>
>>> > there is a resource not being properly managed. People have every
>>>
>>> > right to complain about mismanagement of an important resource.
>>>Agreed
>>>
>>> > though that people need to move to IPv6 as they can. Problem is that
>>>
>>> > many of the organisations with the technical knowledge and resources
>>>
>>> > to move to IPv4 have already tied up most of the IPv4 space and don't
>>>yet
>>> care, after all,
>>>
>>> > that's a problem for the next CIO to fix.
>>>
>>>
>>>
>>> Is there really? Not globally announced does not mean that they are
>>> mis-managed.
>>>
>>>
>>>
>>> > APNIC needs to grow some balls on this issue and take the lead on
>>>
>>> > preserving a scarce resource and re-allocate unused space. If they
>>>are
>>>
>>> > not willing to behave properly, maybe the resource deserves to be
>>>
>>> > given to the ITU to manage.
>>>
>>>
>>>
>>> Again what usused addresses?
>>>
>>>
>>>
>>> Mark
>>>
>>> --
>>>
>>> Mark Andrews, ISC
>>>
>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>
>>> PHONE: +61 2 9871 4742 INTERNET:
>>><mailto:marka at isc.org>
>>> marka at isc.org
>>>
>>>
>>> ------=_NextPart_000_0027_01CE1904.B55170A0
>>> Content-Type: text/html;
>>> charset="us-ascii"
>>> Content-Transfer-Encoding: quoted-printable
>>>
>>> <html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
>>> xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
>>> xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
>>> xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
>>> xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META =
>>> HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
>>> charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14
>>>=
>>> (filtered medium)"><style><!--
>>> /* Font Definitions */
>>> @font-face
>>> {font-family:Calibri;
>>> panose-1:2 15 5 2 2 2 4 3 2 4;}
>>> /* Style Definitions */
>>> p.MsoNormal, li.MsoNormal, div.MsoNormal
>>> {margin:0cm;
>>> margin-bottom:.0001pt;
>>> font-size:11.0pt;
>>> font-family:"Calibri","sans-serif";
>>> mso-fareast-language:EN-US;}
>>> a:link, span.MsoHyperlink
>>> {mso-style-priority:99;
>>> color:blue;
>>> text-decoration:underline;}
>>> a:visited, span.MsoHyperlinkFollowed
>>> {mso-style-priority:99;
>>> color:purple;
>>> text-decoration:underline;}
>>> p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
>>> {mso-style-priority:99;
>>> mso-style-link:"Plain Text Char";
>>> margin:0cm;
>>> margin-bottom:.0001pt;
>>> font-size:11.0pt;
>>> font-family:"Calibri","sans-serif";}
>>> span.PlainTextChar
>>> {mso-style-name:"Plain Text Char";
>>> mso-style-priority:99;
>>> mso-style-link:"Plain Text";
>>> font-family:"Calibri","sans-serif";
>>> mso-fareast-language:EN-AU;}
>>> .MsoChpDefault
>>> {mso-style-type:export-only;
>>> font-family:"Calibri","sans-serif";
>>> mso-fareast-language:EN-US;}
>>> @page WordSection1
>>> {size:612.0pt 792.0pt;
>>> margin:72.0pt 72.0pt 72.0pt 72.0pt;}
>>> div.WordSection1
>>> {page:WordSection1;}
>>> --></style><!--[if gte mso 9]><xml>
>>> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
>>> </xml><![endif]--><!--[if gte mso 9]><xml>
>>> <o:shapelayout v:ext=3D"edit">
>>> <o:idmap v:ext=3D"edit" data=3D"1" />
>>> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-AU link=3Dblue
>>>=
>>> vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoPlainText><span
>>>=
>>> lang=3DEN-US>Mark Andrews questions, my
>>>answers:<o:p></o:p></span></p><p =
>>> class=3DMsoPlainText><i><o:p> </o:p></i></p><p =
>>> class=3DMsoPlainText><i>Q1: I'm curious, how would you have allocated =
>>> address over the last 10 years? <o:p></o:p></i></p><p =
>>> class=3DMsoPlainText>A: Not sure I could have done better with =
>>> allocations. What could have been done better is a ‘use it or
>>>lose =
>>> it’ clause in the conditions applying to not only new allocations
>>>=
>>> but all historical allocations.<o:p></o:p></p><p =
>>> class=3DMsoPlainText><o:p> </o:p></p><p
>>>class=3DMsoPlainText><i>Q2: =
>>> Please list actual resources that APNIC, ARIN or RIPE could =
>>> recover.<o:p></o:p></i></p><p class=3DMsoPlainText>A: Specious question
>>>=
>>> used to mask a case for doing nothing. Please ask better questions that
>>>=
>>> contribute in a meaningful way this good discussion.<o:p></o:p></p><p =
>>> class=3DMsoPlainText><o:p> </o:p></p><p
>>>class=3DMsoPlainText><i>Q3: =
>>> Is there really? Not globally announced does not mean that they =
>>> are mis-managed.<o:p></o:p></i></p><p class=3DMsoPlainText>A: Partially
>>>=
>>> agreed. The fact some people have legitimate uses is no excuse to do =
>>> nothing. <o:p></o:p></p><p =
>>> class=3DMsoPlainText><o:p> </o:p></p><p
>>>class=3DMsoPlainText><i>Q4: =
>>> Again what used addresses?<o:p></o:p></i></p><p class=3DMsoPlainText>A:
>>>=
>>> See answer to Q2. <o:p></o:p></p><p =
>>> class=3DMsoPlainText><o:p> </o:p></p><p =
>>> class=3DMsoPlainText><o:p> </o:p></p><p class=3DMsoPlainText><span
>>>=
>>> lang=3DEN-US>-----Original Message-----<br>From: Mark Andrews =
>>> [mailto:marka at isc.org] <br>Sent: Monday, 4 March 2013 5:01 PM<br>To:
>>>Rod =
>>> Veith<br>Cc: 'AusNOG at lists.ausnog.net'<br>Subject: Re: [AusNOG] =
>>> IPv4</span></p><p class=3DMsoPlainText><o:p> </o:p></p><p =
>>> class=3DMsoPlainText><o:p> </o:p></p><p class=3DMsoPlainText>In =
>>> message <<a =
>>> href=3D"mailto:011c01ce188c$c91f1ab0$5b5d5010$@rb.net.au"><span =
>>>
>>>style=3D'color:windowtext;text-decoration:none'>011c01ce188c$c91f1ab0$5b
>>>5
>>>=
>>> d5010$@rb.net.au</span></a>>, "Rod Veith" =
>>> writes:<o:p></o:p></p><p class=3DMsoPlainText>> <o:p></o:p></p><p =
>>> class=3DMsoPlainText>> "Was v4 allocations screwed? I don't =
>>> know. We didn't know what was <o:p></o:p></p><p =
>>> class=3DMsoPlainText>> going to happen 20 years ago... It is easy to
>>>=
>>> look back in hindsight."<o:p></o:p></p><p
>>>class=3DMsoPlainText>> =
>>> <o:p></o:p></p><p class=3DMsoPlainText>> <o:p></o:p></p><p =
>>> class=3DMsoPlainText>> <o:p></o:p></p><p class=3DMsoPlainText>>
>>>V4 =
>>> allocations ARE screwed using hindsight. There is one camp saying =
>>> <o:p></o:p></p><p class=3DMsoPlainText>> get over it, use V6 and =
>>> forget the screwed V4 allocations. And the <o:p></o:p></p><p =
>>> class=3DMsoPlainText>> other camp says why not try to fix the =
>>> problem.<o:p></o:p></p><p class=3DMsoPlainText><o:p> </o:p></p><p
>>>=
>>> class=3DMsoPlainText>I'm curious, how would you have allocated address
>>>=
>>> over the last 10 years? As far as I can tell the RIR's all have =
>>> allocated address on the basis of need. They didn't hide the fact
>>>=
>>> that IPv4 address were in limited supply. They did all they could
>>>=
>>> to promote IPv6 which unlike IPv4 has enough addresses for everyone on
>>>=
>>> the planet.<o:p></o:p></p><p =
>>> class=3DMsoPlainText><o:p> </o:p></p><p class=3DMsoPlainText>>
>>>=
>>> It is typical human behaviour to sit on resources even if they are not
>>>=
>>> <o:p></o:p></p><p class=3DMsoPlainText>> being used because 'one
>>>just =
>>> never knows if they might be needed in 10 <o:p></o:p></p><p =
>>> class=3DMsoPlainText>> years' time or worth something. Just =
>>> because many people and <o:p></o:p></p><p class=3DMsoPlainText>> =
>>> businesses do this doesn't make it right, just as sitting back and =
>>> <o:p></o:p></p><p class=3DMsoPlainText>> letting past mistakes =
>>> continue is not right.<o:p></o:p></p><p class=3DMsoPlainText>> =
>>> <o:p></o:p></p><p class=3DMsoPlainText>> <o:p></o:p></p><p =
>>> class=3DMsoPlainText>> <o:p></o:p></p><p class=3DMsoPlainText>> I
>>>=
>>> think it is wrong of APNIC to NOT take a more proactive role in =
>>> <o:p></o:p></p><p class=3DMsoPlainText>> recovering<o:p></o:p></p><p
>>>=
>>> class=3DMsoPlainText>> V4 allocations that were obvious mistakes in
>>>=
>>> the past, just as other <o:p></o:p></p><p class=3DMsoPlainText>> =
>>> "resource allocators" around the world should be doing the =
>>> same thing. <o:p></o:p></p><p class=3DMsoPlainText>> Just because =
>>> people with allocations are going to scream "you can't =
>>> <o:p></o:p></p><p class=3DMsoPlainText>> take away something I might
>>>=
>>> use one day etc etc" doesn't mean the <o:p></o:p></p><p =
>>> class=3DMsoPlainText>> attempt shouldn't be made.<o:p></o:p></p><p =
>>> class=3DMsoPlainText><o:p> </o:p></p><p
>>>class=3DMsoPlainText>Please =
>>> list actual resources that APNIC, ARIN or RIPE could =
>>> recover.<o:p></o:p></p><p class=3DMsoPlainText> <o:p></o:p></p><p =
>>> class=3DMsoPlainText>> "IPv4 is dead. People need to get
>>>=
>>> over it and move to IPv6..."<o:p></o:p></p><p =
>>> class=3DMsoPlainText>> <o:p></o:p></p><p =
>>> class=3DMsoPlainText>><o:p> </o:p></p><p =
>>> class=3DMsoPlainText>> No, IPv4 is not dead. Why should people get =
>>> over it when quite clearly <o:p></o:p></p><p class=3DMsoPlainText>>
>>>=
>>> there is a resource not being properly managed. People have every =
>>> <o:p></o:p></p><p class=3DMsoPlainText>> right to complain about =
>>> mismanagement of an important resource. Agreed <o:p></o:p></p><p =
>>> class=3DMsoPlainText>> though that people need to move to IPv6 as =
>>> they can. Problem is that <o:p></o:p></p><p class=3DMsoPlainText>> =
>>> many of the organisations with the technical knowledge and resources =
>>> <o:p></o:p></p><p class=3DMsoPlainText>> to move to IPv4 have
>>>already =
>>> tied up most of the IPv4 space and don't yet care, after =
>>> all,<o:p></o:p></p><p class=3DMsoPlainText>> that's a problem for
>>>the =
>>> next CIO to fix. <o:p></o:p></p><p =
>>> class=3DMsoPlainText><o:p> </o:p></p><p class=3DMsoPlainText>Is =
>>> there really? Not globally announced does not mean that they are
>>>=
>>> mis-managed.<o:p></o:p></p><p =
>>> class=3DMsoPlainText><o:p> </o:p></p><p class=3DMsoPlainText>>
>>>=
>>> APNIC needs to grow some balls on this issue and take the lead on =
>>> <o:p></o:p></p><p class=3DMsoPlainText>> preserving a scarce
>>>resource =
>>> and re-allocate unused space. If they are <o:p></o:p></p><p =
>>> class=3DMsoPlainText>> not willing to behave properly, maybe the =
>>> resource deserves to be <o:p></o:p></p><p class=3DMsoPlainText>> =
>>> given to the ITU to manage.<o:p></o:p></p><p =
>>> class=3DMsoPlainText><o:p> </o:p></p><p class=3DMsoPlainText>Again
>>>=
>>> what usused addresses?<o:p></o:p></p><p =
>>> class=3DMsoPlainText><o:p> </o:p></p><p =
>>> class=3DMsoPlainText>Mark<o:p></o:p></p><p =
>>> class=3DMsoPlainText>--<o:p></o:p></p><p class=3DMsoPlainText>Mark =
>>> Andrews, ISC<o:p></o:p></p><p class=3DMsoPlainText>1 Seymour St.,
>>>Dundas =
>>> Valley, NSW 2117, Australia<o:p></o:p></p><p
>>>class=3DMsoPlainText>PHONE: =
>>> +61 2 9871 =
>>>
>>>4742 &n
>>>b
>>>=
>>> sp; INTERNET: <a =
>>> href=3D"mailto:marka at isc.org"><span =
>>>
>>>style=3D'color:windowtext;text-decoration:none'>marka at isc.org</span></a>
>>><
>>>=
>>> o:p></o:p></p></div></body></html>
>>> ------=_NextPart_000_0027_01CE1904.B55170A0--
>>>
>>>
>>>
>>> --===============5110076315026223362==
>>> Content-Type: text/plain; charset="us-ascii"
>>> MIME-Version: 1.0
>>> Content-Transfer-Encoding: 7bit
>>> Content-Disposition: inline
>>>
>>> _______________________________________________
>>> AusNOG mailing list
>>> AusNOG at lists.ausnog.net
>>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>>
>>> --===============5110076315026223362==--
>>>
>>>
>>--
>>Mark Andrews, ISC
>>1 Seymour St., Dundas Valley, NSW 2117, Australia
>>PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
>>_______________________________________________
>>AusNOG mailing list
>>AusNOG at lists.ausnog.net
>>http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
>
>The information contained in this email and any attachments may be
>confidential. This email and any attachments are also subject to
>copyright. No part of them may be reproduced, adapted or transmitted
>without the written permission of the copyright owner. If you are not the
>intended recipient, any use, interference with, disclosure or copying of
>this information is unauthorised and prohibited. If you have received
>this email in error, please immediately advise the sender by return email
>and delete the message from your system. All email communications to and
>from NEXTDC Limited are recorded for the purposes of archival and storage.
>_______________________________________________
>AusNOG mailing list
>AusNOG at lists.ausnog.net
>http://lists.ausnog.net/mailman/listinfo/ausnog
The information contained in this email and any attachments may be confidential. This email and any attachments are also subject to copyright. No part of them may be reproduced, adapted or transmitted without the written permission of the copyright owner. If you are not the intended recipient, any use, interference with, disclosure or copying of this information is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the message from your system. All email communications to and from NEXTDC Limited are recorded for the purposes of archival and storage.
More information about the AusNOG
mailing list