Re: RIPE our of IPv4

[Large Hadron Collider]

that would be a throwback, if my MTA supported full-length bangpaths.

On 19-12-04 01 h 56, Aled Morris via NANOG wrote:

On Tue, 3 Dec 2019 at 14:43, Randy Bush mailto:ra...@psg.com>> wrote:

> Why does a new organisation need to have any global IPv4
addresses of
> their own at all?

if all folk saying such things would make their in- and out-bound mail
servers v6-only, it would reduce confusion in this area.

randy


...!6to4mx!m2xenix!randy

Aled

Re: RIPE our of IPv4

[Aled Morris via NANOG]

On Tue, 3 Dec 2019 at 14:43, Randy Bush  wrote:

> > Why does a new organisation need to have any global IPv4 addresses of
> > their own at all?
>
> if all folk saying such things would make their in- and out-bound mail
> servers v6-only, it would reduce confusion in this area.
>
> randy
>

...!6to4mx!m2xenix!randy

Aled

Re: RIPE our of IPv4

[Fernando Gont]

On 3/12/19 17:47, Mark Andrews wrote:
> 
> 
>> On 4 Dec 2019, at 02:04, Fernando Gont  wrote:
>>
>> On 3/12/19 00:12, Mark Andrews wrote:
>>>
>>>
 On 3 Dec 2019, at 13:31, Valdis Klētnieks  wrote:

 On Mon, 02 Dec 2019 11:04:24 -0800, Fred Baker said:

>> I believe that Dmitry's point is that we will still require IPv4 
>> addresses for new
>> organizations deploying dual-stack
>
> I think I understood what you meant, but not what you said.

> If someone is dual stack, they are IPv6-capable and IPv4-capable.

 And they're going to need v4 addresses to be v4-capable, aren't there?

 A new corporation that's trying to spin up dual-stack is going to need 2
 address allocations, a v4 and a v6.
>>>
>>> Why does a new organisation need to have any global IPv4 addresses of their 
>>> own
>>> at all?  In most cases they don’t.  It’s only inertia that is causing 
>>> people to
>>> want to have their own global IPv4 addresses.
>>>
>>> We have IPv4 as a service which gives on demand shared IPv4 addresses.  
>>> Millions
>>> of people reach the IPv4 Internet every day using IPv4AAS.
>>> CDNs are dual stack and provide the IPv4 presence on the net.  These days 
>>> these
>>> are shared addresses.
>>> VPNs run over IPv6 and they can in turn run over IPv6 in IPv4 tunnels when
>>> the remote doesn’t support native IPv6.  Its just another level on 
>>> encapsulation.
>>> Email is often out sourced so you don’t need your own IPv4 addresses for 
>>> that.
>>> Then there is in the cloud for other services, again you don’t need your 
>>> own IPv4
>>> addresses.
>>
>> Wwll, yeah.. you don't need IPv4 addresses if you are going to be using
>> somebody else's networks and services. Not that you should, though…
> 
> Why not use someone else’s IPv4 addresses?  Really.  What is wrong with using
> someone else’s IPv4 addresses if it achieves the need?  As far as I can tell
> nothing.

Security? Privacy?

It may or may not be a concern for you. But there are implications in
doing so.



> Just because enterprises that established themselves in a  IPv4-only world did
> it one way.  It doesn’t mean that enterprises establishing themselves in a 
> IPv4 /
> IPv6 world need to follow that model.

As long as you do analyze the implications and trade-offs...


-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Re: RIPE our of IPv4

[Brandon Martin]

On 12/3/19 10:04 AM, Fernando Gont wrote:

Wwll, yeah.. you don't need IPv4 addresses if you are going to be using
somebody else's networks and services. Not that you should, though


OTOH, many many organizations, especially outside of service providers, 
in fact DO such a thing.  I'd suspect your average mid-size business 
these days really in fact does not "need" any IPv4 addresses to conduct 
their ordinary and even many extraordinary operations.


As long as you can make IPv4 HTTP/HTTPS destinations work to handle the 
long tail of non-IPv6 web destinations out there, I bet most people 
wouldn't even notice, and the only reason the IT folks would notice 
would be during testing/troubleshooting or the fact that their machine 
suspiciously has no RFC1918 nor public IPv4 address configured on it.


Most organizations do indeed outsource most of their IT functions in one 
way or another, and it's pretty easy these days to pick outsourcing 
partners for most common business needs that are indeed natively 
IPv6-enabled.  The remainder probably run over HTTP/HTTPS, anyway, and 
are easily translatable at the service provider level.


I'd certainly not (yet) say that that's a recommended configuration, but 
I suspect it would often work.  I certainly have IPv6-only testbeds. 
There's a few groaners usually, but a surprisingly large amount of stuff 
"just works".

--
Brandon Martin

Re: RIPE our of IPv4

[Fred Baker]

> On Dec 3, 2019, at 3:22 PM, Valdis Klētnieks  wrote:
> 
> On Tue, 03 Dec 2019 14:58:59 -0800, FREDERICK BAKER said:
> 
>> I think he is saying that companies like Reliance JIO have started with a /22
>> of IPv4 and a /32 (or more) of IPv6,
> 
> As I said - you need IPv4 space to dual-stack. How does Reliance do this
> without any v4 address space?

They have a very small amount, and do CGN, the same as anyone else. If that's 
what you took away from the APNIC measurements, you missed the story, though.

Re: RIPE our of IPv4

[Valdis Klētnieks]

On Tue, 03 Dec 2019 14:58:59 -0800, FREDERICK BAKER said:

> I think he is saying that companies like Reliance JIO have started with a /22
> of IPv4 and a /32 (or more) of IPv6,

As I said - you need IPv4 space to dual-stack. How does Reliance do this
without any v4 address space?


pgpZzt54PJqbb.pgp
Description: PGP signature

Re: RIPE our of IPv4

[Mark Andrews]

> On 4 Dec 2019, at 09:51, Valdis Klētnieks  wrote:
> 
> On Wed, 04 Dec 2019 07:47:25 +1100, Mark Andrews said:
> 
>> Why not use someone else’s IPv4 addresses?  Really.  What is wrong with using
>> someone else’s IPv4 addresses if it achieves the need?  As far as I can tell
>> nothing.
> 
> Other than the fact that a /24 is being advertised out of one AS and it's 
> part of
> some other AS's /14 and looks suspiciously like a hijack?  And we currently 
> don't
> deal well with identifying and preventing true hijacks and mess up false 
> positives
> a lot of the time?

I’m curious if you actually read the example of use of another’s IPv4 address 
before
starting talking about hijacking addresses?

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: RIPE our of IPv4

[Valdis Klētnieks]

On Wed, 04 Dec 2019 07:47:25 +1100, Mark Andrews said:

> Why not use someone else’s IPv4 addresses?  Really.  What is wrong with 
> using
> someone else’s IPv4 addresses if it achieves the need?  As far as I can tell
> nothing.

Other than the fact that a /24 is being advertised out of one AS and it's part 
of
some other AS's /14 and looks suspiciously like a hijack?  And we currently 
don't
deal well with identifying and preventing true hijacks and mess up false 
positives
a lot of the time?



pgpUBGTodN9bJ.pgp
Description: PGP signature

Re: RIPE our of IPv4

[Mark Andrews]

> On 4 Dec 2019, at 02:04, Fernando Gont  wrote:
> 
> On 3/12/19 00:12, Mark Andrews wrote:
>> 
>> 
>>> On 3 Dec 2019, at 13:31, Valdis Klētnieks  wrote:
>>> 
>>> On Mon, 02 Dec 2019 11:04:24 -0800, Fred Baker said:
>>> 
> I believe that Dmitry's point is that we will still require IPv4 
> addresses for new
> organizations deploying dual-stack
 
 I think I understood what you meant, but not what you said.
>>> 
 If someone is dual stack, they are IPv6-capable and IPv4-capable.
>>> 
>>> And they're going to need v4 addresses to be v4-capable, aren't there?
>>> 
>>> A new corporation that's trying to spin up dual-stack is going to need 2
>>> address allocations, a v4 and a v6.
>> 
>> Why does a new organisation need to have any global IPv4 addresses of their 
>> own
>> at all?  In most cases they don’t.  It’s only inertia that is causing people 
>> to
>> want to have their own global IPv4 addresses.
>> 
>> We have IPv4 as a service which gives on demand shared IPv4 addresses.  
>> Millions
>> of people reach the IPv4 Internet every day using IPv4AAS.
>> CDNs are dual stack and provide the IPv4 presence on the net.  These days 
>> these
>> are shared addresses.
>> VPNs run over IPv6 and they can in turn run over IPv6 in IPv4 tunnels when
>> the remote doesn’t support native IPv6.  Its just another level on 
>> encapsulation.
>> Email is often out sourced so you don’t need your own IPv4 addresses for 
>> that.
>> Then there is in the cloud for other services, again you don’t need your own 
>> IPv4
>> addresses.
> 
> Wwll, yeah.. you don't need IPv4 addresses if you are going to be using
> somebody else's networks and services. Not that you should, though…

Why not use someone else’s IPv4 addresses?  Really.  What is wrong with using
someone else’s IPv4 addresses if it achieves the need?  As far as I can tell
nothing.

Just because enterprises that established themselves in a  IPv4-only world did
it one way.  It doesn’t mean that enterprises establishing themselves in a IPv4 
/
IPv6 world need to follow that model.

Mark

> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fg...@si6networks.com
> PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: RIPE our of IPv4

[Valdis Klētnieks]

On Tue, 03 Dec 2019 14:12:27 +1100, Mark Andrews said:

> Email is often out sourced so you don’t need your own IPv4 addresses for 
> that.
> Then there is in the cloud for other services, again you don’t need your 
> own IPv4
> addresses.

Are you seriously trying to say "If you're a new company, there's no plausible
reason for you to need your own IPv4 addresses, because there's no reason for
you to have your own mail servers or web servers"?

Because if it *were* true that people don't need v4 addresses so they can 
dual-stack,
we wouldn't have a healthy market buying and selling v4 address space.



pgpI6UkYlltNv.pgp
Description: PGP signature

Re: RIPE our of IPv4

[Fernando Gont]

On 3/12/19 00:12, Mark Andrews wrote:
> 
> 
>> On 3 Dec 2019, at 13:31, Valdis Klētnieks  wrote:
>>
>> On Mon, 02 Dec 2019 11:04:24 -0800, Fred Baker said:
>>
 I believe that Dmitry's point is that we will still require IPv4 addresses 
 for new
 organizations deploying dual-stack
>>>
>>> I think I understood what you meant, but not what you said.
>>
>>> If someone is dual stack, they are IPv6-capable and IPv4-capable.
>>
>> And they're going to need v4 addresses to be v4-capable, aren't there?
>>
>> A new corporation that's trying to spin up dual-stack is going to need 2
>> address allocations, a v4 and a v6.
> 
> Why does a new organisation need to have any global IPv4 addresses of their 
> own
> at all?  In most cases they don’t.  It’s only inertia that is causing people 
> to
> want to have their own global IPv4 addresses.
> 
> We have IPv4 as a service which gives on demand shared IPv4 addresses.  
> Millions
> of people reach the IPv4 Internet every day using IPv4AAS.
> CDNs are dual stack and provide the IPv4 presence on the net.  These days 
> these
> are shared addresses.
> VPNs run over IPv6 and they can in turn run over IPv6 in IPv4 tunnels when
> the remote doesn’t support native IPv6.  Its just another level on 
> encapsulation.
> Email is often out sourced so you don’t need your own IPv4 addresses for that.
> Then there is in the cloud for other services, again you don’t need your own 
> IPv4
> addresses.

Wwll, yeah.. you don't need IPv4 addresses if you are going to be using
somebody else's networks and services. Not that you should, though

-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Re: RIPE our of IPv4

[Randy Bush]

> Why does a new organisation need to have any global IPv4 addresses of
> their own at all?

if all folk saying such things would make their in- and out-bound mail
servers v6-only, it would reduce confusion in this area.

randy

Re: RIPE our of IPv4

[Mark Andrews]

> On 3 Dec 2019, at 13:31, Valdis Klētnieks  wrote:
> 
> On Mon, 02 Dec 2019 11:04:24 -0800, Fred Baker said:
> 
>>> I believe that Dmitry's point is that we will still require IPv4 addresses 
>>> for new
>>> organizations deploying dual-stack
>> 
>> I think I understood what you meant, but not what you said.
> 
>> If someone is dual stack, they are IPv6-capable and IPv4-capable.
> 
> And they're going to need v4 addresses to be v4-capable, aren't there?
> 
> A new corporation that's trying to spin up dual-stack is going to need 2
> address allocations, a v4 and a v6.

Why does a new organisation need to have any global IPv4 addresses of their own
at all?  In most cases they don’t.  It’s only inertia that is causing people to
want to have their own global IPv4 addresses.

We have IPv4 as a service which gives on demand shared IPv4 addresses.  Millions
of people reach the IPv4 Internet every day using IPv4AAS.
CDNs are dual stack and provide the IPv4 presence on the net.  These days these
are shared addresses.
VPNs run over IPv6 and they can in turn run over IPv6 in IPv4 tunnels when
the remote doesn’t support native IPv6.  Its just another level on 
encapsulation.
Email is often out sourced so you don’t need your own IPv4 addresses for that.
Then there is in the cloud for other services, again you don’t need your own 
IPv4
addresses.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: RIPE our of IPv4

[Valdis Klētnieks]

On Mon, 02 Dec 2019 11:04:24 -0800, Fred Baker said:

> > I believe that Dmitry's point is that we will still require IPv4 addresses 
> > for new
> > organizations deploying dual-stack
>
> I think I understood what you meant, but not what you said.

> If someone is dual stack, they are IPv6-capable and IPv4-capable.

And they're going to need v4 addresses to be v4-capable, aren't there?

A new corporation that's trying to spin up dual-stack is going to need 2
address allocations, a v4 and a v6.


pgpcySEVj1r_i.pgp
Description: PGP signature

Re: RIPE our of IPv4

[Owen DeLong]

> On Dec 1, 2019, at 18:05 , Brandon Martin  wrote:
> 
> On 12/1/19 8:56 PM, Mark Andrews wrote:
>> End Users
>> End users receive IP addresses for use in their internal networks only, and 
>> not for distribution to external users of their Internet services.
> 
> I guess it's possible that these networks would be considered end users, but 
> I get the impression that they would probably be classified as ISPs, and then 
> the fee would indeed be $500/yr for 2X-Small.  A bit ridiculous for 
> IPv6-only, but still probably approaching noise in the budget for a service 
> provider who has a legacy allocation unless they have remained tiny somehow 
> (in which case, sell off some of that IP space you have and pay your $500/yr 
> for the next decade or so).
> 
> FWIW, if you need it, you should also be immediately eligible for a /24 for 
> IPv6 deployment and transition tech at no additional cost since your legacy 
> space wouldn't be considered by ARIN unless you specifically brought it under 
> their purview AFAIK.  Even if you don't need the space, per se, there are 
> often times where it's useful to have a disjoint /24 e.g. for traffic 
> engineering, anycast, DNS servers, etc.  All depends on how much legacy space 
> you have, I guess.  I'm also somewhat hopeful that, as those allocations all 
> come from a known block, the various content networks will recognize them as 
> being likely to house the inevitable (eventually) CGN sources, but I won't 
> hold my breath.

I would like to clarify that the idea of Legacy “Space” i somewhat fallacious. 
In reality there are only legacy registrations. Once the registration is 
brought under an RSA (or LRSA) either by the original holder, or through the 
transfer process, the resulting registration loses its “Legacy” status. In the 
case of LRSA, there are some additional rights afforded to the original holder, 
but in the event of a subsequent transfer, that space would move to a standard 
RSA.

ARIN will consider all space held by an organization, whether legacy or 
otherwise in computing need. However, to the best of my knowledge, need under a 
section 4.10 request is computed independent of other IPv4 holdings. As such, I 
believe that the first /24 issued to an organization under section 4.10 would 
not consider their existing IPv4 holdings. Subsequent 4.10 requests are 
evaluated based on the utilization of the previous 4.10 space for its intended 
purpose.

> I guess you also get to vote in ARIN elections and comment on policy matters 
> as a member, if that matters to you.

Membership is not required to comment on policy matters. Anyone with an email 
address may comment on policy matters simply by subscribing to and 
participating in the ARIN public policy mailing list.

Membership is required to vote in ARIN elections for the Advisory Council and 
the Board of Trustees.

Owen

Re: RIPE our of IPv4

[Owen DeLong]

That’s a one-time fee for end-users (and it can be as low as $250 unless you 
need a /40 or more).

If you’re an ISP, then yes, it’s $500 per year if you need a /40 or more (or as 
little as $250 if you can
get buy on less than a /40).

Owen


> On Dec 1, 2019, at 17:23 , Matthew Kaufman  wrote:
> 
> I get $500, not $150, when I read the price list.
> 
> On Sun, Dec 1, 2019 at 4:06 PM Owen DeLong  > wrote:
> You’re saying that there are two networks that are of sufficient 
> complexity/size/whatever to require PA addressing, yet lack the resources for 
> $150/year in registration fees?
> 
> I suppose it’s not impossible, but I’m wondering how they afford the other 
> expenses associated with maintaining such a network.
> 
> Owen
> 
> 
>> On Nov 30, 2019, at 09:00 , Matthew Kaufman > > wrote:
>> 
>> I administer two networks that use legacy IPv4 blocks (one also uses an 
>> allocation from the 44 net)
>> 
>> Both could have IPv6 if it was free, but neither organization has the funds 
>> to waste on a paid IPv6 allocation.
>> 
>> We should have given every legacy block matching free IPv6 space, because 
>> early adopters are still sometimes early adopters. 
>> 
>> But you’re right, what could have been supported on a volunteer basis is now 
>> a profit center. Especially for IPv6, which is once-and-done if sized 
>> properly.
>> 
>> Matthew Kaufman
>> 
>> On Tue, Nov 26, 2019 at 2:29 PM > > wrote:
>> 
>> If the commitment really was to spread IPv6 far and wide IPv6 blocks
>> would be handed out for free, one per qualified customer (e.g., if you
>> have an IPv4 allocation you get one IPv6 block free), or perhaps some
>> trivial administrative fee like $10 per year.
>> 
>> But the RIRs can't live on that.
>> 
>> We have put them under the management of a group of five organizations
>> which are very dependent on the income from block allocations and no
>> doubt were hoping IPv6 allocations would be a boon since there will be
>> very little if any income growth from future IPv4 block allocations.
>> 
>> Worse, once acquired an IPv6 block has so many billions of addresses
>> very few if any would ever need another allocation so it would hardly
>> act as a loss leader.
>> 
>> I realize many still would not deploy IPv6 for various reasons such as
>> their equipment doesn't support it or they don't have the in-house
>> expertise to support it, etc tho I can't think of much other etc, a
>> few points of resistance do come up.
>> 
>> -- 
>> -Barry Shein
>> 
>> Software Tool & Die| b...@theworld.com 
>>  | http://www.TheWorld.com 
>> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
>> The World: Since 1989  | A Public Information Utility | *oo*
> 

Re: RIPE our of IPv4

[Willy Manga]

Hi,

On 02/12/2019 16:00, nanog-requ...@nanog.org wrote:
> From: Mark Tinka 
> [...]
> On 1/Dec/19 02:54, Brandon Martin wrote:
> 
>> How slim are your margins to have been around long enough to have a legacy 
>> IPv4 block but not be able to afford the ARIN fees to get a comparable/very 
>> usable (/48 to /52 for each IPv4) amount of IPv6?  And if you don't need a 
>> "comparable" amount of IPv6, presumably you aren't using all your legacy 
>> IPv4 and can sell off part of its presumably huge allocation to get some 
>> funds.
> 
> AFRINIC offered IPv6 /32's for free for every member that paid for their
> IPv4.
> 
> Not sure if they still do, but my annual bill does mention that amount
> of IPv6 space we have.


still accurate.
https://afrinic.net/membership/cost#resource , section
3.1-"For existing members".
It is said "No additional fees as a result of the issued IPv6 prefix
will apply."


Section 3.2. new IPv6-only members get discounts over 3 years

-- 
Willy Manga
@ongolaboy
https://ongola.blogspot.com/



signature.asc
Description: OpenPGP digital signature

Re: RIPE our of IPv4

[Justin Streiner]

On Sat, Nov 30, 2019 at 7:58 PM Brandon Martin 
wrote:

> Does Verizon still own/manage ANY of their Fios territories?  I thought it
> was all sold off to Frontier at this point.  It certainly all is, along
> with all their legacy LEC territories not having FTTx and having some form
> of DSL, around here.  The latter DSL offerings are usually pretty
> hilarious.  It's mostly run out of the CO or existing RTUs from the POTS
> era.  I can't imagine they have a ton of subscribers outside of areas with
> literally no other wireline options, and I'm guessing a lot of that
> infrastructure hasn't been touched in a decade-plus.
>
> Is Frontier-managed Fios included in those numbers regardless, or are they
> separate like I'd expect them to be?
>

I don't think those numbers include wireline territories that were
transferred from Verizon to Frontier, but in my area (western
Pennsylvania), Fios service is provided by Verizon.

Verizon hasn't updated their IPv6 resource site since at least 2012.  It
still includes a subtle but significant typo. A /56 does not give you "56
LANs"

Requests for updates from front-line customer service go into a black hole,
as do sidebar questions to our Verizon account team at $dayjob.

jms

Re: RIPE our of IPv4

[bzs]

This is that reasoning that because this particular shiny bauble is
laying right here on the table then that's the whole picture.

More likely if some of them decided to sell that IPv4 block they'd
catch up on the rent or cut deductibles on the health care plan or or
get rid of some of that 100mb ethernet or something.

IPv6 would be way, way down on that list.

That's how small businesses run.

On November 30, 2019 at 19:54 lists.na...@monmotha.net (Brandon Martin) wrote:
 > On 11/30/19 4:48 PM, Matthew Kaufman wrote:
 > > See previous message about legacy IPv4 holders without budget for IPv6 
 > > blocks 
 > 
 > How slim are your margins to have been around long enough to have a legacy 
 > IPv4 block but not be able to afford the ARIN fees to get a comparable/very 
 > usable (/48 to /52 for each IPv4) amount of IPv6?  And if you don't need a 
 > "comparable" amount of IPv6, presumably you aren't using all your legacy 
 > IPv4 and can sell off part of its presumably huge allocation to get some 
 > funds.
 > -- 
 > Brandon Martin

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: RIPE our of IPv4

[Brandon Martin]

On 12/1/19 8:56 PM, Mark Andrews wrote:

End Users
End users receive IP addresses for use in their internal networks only, and not 
for distribution to external users of their Internet services.


I guess it's possible that these networks would be considered end users, 
but I get the impression that they would probably be classified as ISPs, 
and then the fee would indeed be $500/yr for 2X-Small.  A bit ridiculous 
for IPv6-only, but still probably approaching noise in the budget for a 
service provider who has a legacy allocation unless they have remained 
tiny somehow (in which case, sell off some of that IP space you have and 
pay your $500/yr for the next decade or so).


FWIW, if you need it, you should also be immediately eligible for a /24 
for IPv6 deployment and transition tech at no additional cost since your 
legacy space wouldn't be considered by ARIN unless you specifically 
brought it under their purview AFAIK.  Even if you don't need the space, 
per se, there are often times where it's useful to have a disjoint /24 
e.g. for traffic engineering, anycast, DNS servers, etc.  All depends on 
how much legacy space you have, I guess.  I'm also somewhat hopeful 
that, as those allocations all come from a known block, the various 
content networks will recognize them as being likely to house the 
inevitable (eventually) CGN sources, but I won't hold my breath.


I guess you also get to vote in ARIN elections and comment on policy 
matters as a member, if that matters to you.


--
Brandon Martin

Re: RIPE our of IPv4

[Mark Andrews]

End Users
End users receive IP addresses for use in their internal networks only, and not 
for distribution to external users of their Internet services.

End Users with Registration Services Plan
End users may opt to pay for ARIN registration services on the same schedule as 
ISPs detailed above by subscribing to a Registration Services Plan. End users 
who do so receive additional services, including ARIN Membership and the 
ability to report reassignment information and/or provide utilization data via 
the Shared Whois Project (SWIP). Organizations that choose to convert to the 
Registration Services Plan will be evaluated as an ISP from a policy 
perspective when requesting future Internet number resources from ARIN. The 
applicable annual Registration Services Plan will be invoiced annually based on 
the organization resources in the ARIN registry.

End Users Paying Per Resource
End-user customers who do not have a Registration Services Plan pay fees per 
number resource, as specified below:

IPv4 / IPv6 Number Resources

Initial

An organization will be assessed an initial fee for each new IPv4, IPv6, or 
experimental address assignment based on the service category approved for them 
by Registration Services. After an assignment has been approved, ARIN will 
invoice for payment. Payment and the executed Registration Services Agreement 
(RSA)  must be received before resources are issued.

Annual

An organization’s annual fee is due each year at the end of their anniversary 
month (the month of their initial assignment). Annual maintenance fees are $150 
USD for each IPv4 address block, $150 USD for each IPv6 address block, and $150 
USD for each ASN assigned to the organization.

Note: ARIN Membership is also available to end-user customers who pay fees on a 
per resource basis.

https://www.arin.net/resources/fees/fee_schedule/#ipv4-ipv6-number-resources


> On 2 Dec 2019, at 12:23, Matthew Kaufman  wrote:
> 
> I get $500, not $150, when I read the price list.
> 
> On Sun, Dec 1, 2019 at 4:06 PM Owen DeLong  wrote:
> You’re saying that there are two networks that are of sufficient 
> complexity/size/whatever to require PA addressing, yet lack the resources for 
> $150/year in registration fees?
> 
> I suppose it’s not impossible, but I’m wondering how they afford the other 
> expenses associated with maintaining such a network.
> 
> Owen
> 
> 
>> On Nov 30, 2019, at 09:00 , Matthew Kaufman  wrote:
>> 
>> I administer two networks that use legacy IPv4 blocks (one also uses an 
>> allocation from the 44 net)
>> 
>> Both could have IPv6 if it was free, but neither organization has the funds 
>> to waste on a paid IPv6 allocation.
>> 
>> We should have given every legacy block matching free IPv6 space, because 
>> early adopters are still sometimes early adopters. 
>> 
>> But you’re right, what could have been supported on a volunteer basis is now 
>> a profit center. Especially for IPv6, which is once-and-done if sized 
>> properly.
>> 
>> Matthew Kaufman
>> 
>> On Tue, Nov 26, 2019 at 2:29 PM  wrote:
>> 
>> If the commitment really was to spread IPv6 far and wide IPv6 blocks
>> would be handed out for free, one per qualified customer (e.g., if you
>> have an IPv4 allocation you get one IPv6 block free), or perhaps some
>> trivial administrative fee like $10 per year.
>> 
>> But the RIRs can't live on that.
>> 
>> We have put them under the management of a group of five organizations
>> which are very dependent on the income from block allocations and no
>> doubt were hoping IPv6 allocations would be a boon since there will be
>> very little if any income growth from future IPv4 block allocations.
>> 
>> Worse, once acquired an IPv6 block has so many billions of addresses
>> very few if any would ever need another allocation so it would hardly
>> act as a loss leader.
>> 
>> I realize many still would not deploy IPv6 for various reasons such as
>> their equipment doesn't support it or they don't have the in-house
>> expertise to support it, etc tho I can't think of much other etc, a
>> few points of resistance do come up.
>> 
>> -- 
>> -Barry Shein
>> 
>> Software Tool & Die| b...@theworld.com | 
>> http://www.TheWorld.com
>> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
>> The World: Since 1989  | A Public Information Utility | *oo*
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: RIPE our of IPv4

[Matthew Kaufman]

I get $500, not $150, when I read the price list.

On Sun, Dec 1, 2019 at 4:06 PM Owen DeLong  wrote:

> You’re saying that there are two networks that are of sufficient
> complexity/size/whatever to require PA addressing, yet lack the resources
> for $150/year in registration fees?
>
> I suppose it’s not impossible, but I’m wondering how they afford the other
> expenses associated with maintaining such a network.
>
> Owen
>
>
> On Nov 30, 2019, at 09:00 , Matthew Kaufman  wrote:
>
> I administer two networks that use legacy IPv4 blocks (one also uses an
> allocation from the 44 net)
>
> Both could have IPv6 if it was free, but neither organization has the
> funds to waste on a paid IPv6 allocation.
>
> We should have given every legacy block matching free IPv6 space, because
> early adopters are still sometimes early adopters.
>
> But you’re right, what could have been supported on a volunteer basis is
> now a profit center. Especially for IPv6, which is once-and-done if sized
> properly.
>
> Matthew Kaufman
>
> On Tue, Nov 26, 2019 at 2:29 PM  wrote:
>
>>
>> If the commitment really was to spread IPv6 far and wide IPv6 blocks
>> would be handed out for free, one per qualified customer (e.g., if you
>> have an IPv4 allocation you get one IPv6 block free), or perhaps some
>> trivial administrative fee like $10 per year.
>>
>> But the RIRs can't live on that.
>>
>> We have put them under the management of a group of five organizations
>> which are very dependent on the income from block allocations and no
>> doubt were hoping IPv6 allocations would be a boon since there will be
>> very little if any income growth from future IPv4 block allocations.
>>
>> Worse, once acquired an IPv6 block has so many billions of addresses
>> very few if any would ever need another allocation so it would hardly
>> act as a loss leader.
>>
>> I realize many still would not deploy IPv6 for various reasons such as
>> their equipment doesn't support it or they don't have the in-house
>> expertise to support it, etc tho I can't think of much other etc, a
>> few points of resistance do come up.
>>
>> --
>> -Barry Shein
>>
>> Software Tool & Die| b...@theworld.com |
>> http://www.TheWorld.com 
>> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
>> The World: Since 1989  | A Public Information Utility | *oo*
>>
>
>

Re: RIPE our of IPv4

[Owen DeLong]

You’re saying that there are two networks that are of sufficient 
complexity/size/whatever to require PA addressing, yet lack the resources for 
$150/year in registration fees?

I suppose it’s not impossible, but I’m wondering how they afford the other 
expenses associated with maintaining such a network.

Owen


> On Nov 30, 2019, at 09:00 , Matthew Kaufman  wrote:
> 
> I administer two networks that use legacy IPv4 blocks (one also uses an 
> allocation from the 44 net)
> 
> Both could have IPv6 if it was free, but neither organization has the funds 
> to waste on a paid IPv6 allocation.
> 
> We should have given every legacy block matching free IPv6 space, because 
> early adopters are still sometimes early adopters. 
> 
> But you’re right, what could have been supported on a volunteer basis is now 
> a profit center. Especially for IPv6, which is once-and-done if sized 
> properly.
> 
> Matthew Kaufman
> 
> On Tue, Nov 26, 2019 at 2:29 PM  > wrote:
> 
> If the commitment really was to spread IPv6 far and wide IPv6 blocks
> would be handed out for free, one per qualified customer (e.g., if you
> have an IPv4 allocation you get one IPv6 block free), or perhaps some
> trivial administrative fee like $10 per year.
> 
> But the RIRs can't live on that.
> 
> We have put them under the management of a group of five organizations
> which are very dependent on the income from block allocations and no
> doubt were hoping IPv6 allocations would be a boon since there will be
> very little if any income growth from future IPv4 block allocations.
> 
> Worse, once acquired an IPv6 block has so many billions of addresses
> very few if any would ever need another allocation so it would hardly
> act as a loss leader.
> 
> I realize many still would not deploy IPv6 for various reasons such as
> their equipment doesn't support it or they don't have the in-house
> expertise to support it, etc tho I can't think of much other etc, a
> few points of resistance do come up.
> 
> -- 
> -Barry Shein
> 
> Software Tool & Die| b...@theworld.com | 
> http://www.TheWorld.com 
> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*

Re: RIPE our of IPv4

[Mark Tinka]

On 1/Dec/19 02:54, Brandon Martin wrote:

> How slim are your margins to have been around long enough to have a legacy 
> IPv4 block but not be able to afford the ARIN fees to get a comparable/very 
> usable (/48 to /52 for each IPv4) amount of IPv6?  And if you don't need a 
> "comparable" amount of IPv6, presumably you aren't using all your legacy IPv4 
> and can sell off part of its presumably huge allocation to get some funds.

AFRINIC offered IPv6 /32's for free for every member that paid for their
IPv4.

Not sure if they still do, but my annual bill does mention that amount
of IPv6 space we have.

Mark.

Re: RIPE our of IPv4

[Mark Tinka]

On 30/Nov/19 18:45, Ca By wrote:

>
>
> Sadly, ipv6 is creating a bifurcation of the internet.  Scale shops
> have v6, and non-scale shops don’t. The big players are pulling away,
> and that makes things bleak for the folks just trying to tread water
> in ipv4.

Well, China have scale, but perhaps Google's data sets aren't reliable
in that region.

Mark.

Re: RIPE our of IPv4

[Simon Leinen]

Matthew Kaufman writes:
> This is a great example (but just one of many) of how server software
> development works:

Small addition/correction to this example
(which I find interesting and also sad):

> Kubernetes initial release June 2014. Developed by Google engineers.
[...]
> Full support including CoreDNS support in 1.13, December 2018.

Support for dual-stack pods[1]: alpha in 1.16, October 2019.
-- 
Simon.
[1] https://kubernetes.io/docs/concepts/services-networking/dual-stack/

Re: RIPE our of IPv4

[Jared Mauch]

I'm still surprised that for $42/mo you can't afford IPv6. If you already have 
a legacy allocation most cases you can get v6 for "free". 

I get low budget stuff, but honestly it doesn't have to be you it could be one 
upstream that gives you a /48 to get you started. 

Sent from my iCar

> On Dec 1, 2019, at 1:10 AM, Matthew Kaufman  wrote:
> 
> 
> 
> 
>> On Sat, Nov 30, 2019 at 5:55 PM Valdis Klētnieks  
>> wrote:
>> On Sat, 30 Nov 2019 13:47:36 -0800, Matthew Kaufman said:
>> 
>> > User apps prefer IPv6, Netflix stops, users complain
>> 
>> And fallback to IPv4 fails to happen, why, exactly?
> 
> Because of the layer at which failure happens. You get connected successfully 
> to a Netflix that tells you that reaching it via tunnels is prohibited by 
> their terms of service.
> 

Re: RIPE our of IPv4

[Matthew Kaufman]

On Sat, Nov 30, 2019 at 5:55 PM Valdis Klētnieks 
wrote:

> On Sat, 30 Nov 2019 13:47:36 -0800, Matthew Kaufman said:
>
> > User apps prefer IPv6, Netflix stops, users complain
>
> And fallback to IPv4 fails to happen, why, exactly?
>
Because of the layer at which failure happens. You get connected
successfully to a Netflix that tells you that reaching it via tunnels is
prohibited by their terms of service.

Re: RIPE our of IPv4

[Brandon Martin]

On 11/30/19 8:55 PM, Valdis Klētnieks wrote:
>> User apps prefer IPv6, Netflix stops, users complain
> And fallback to IPv4 fails to happen, why, exactly?

Inability to signal application-level failure on IPv6 and that fallback to IPv4 
would succeed.

Netflix definitely exhibits this.  I've also noticed that a lot of 
Cloudflare-hosted apps/sites block AS6939 outright which mostly only affects 
IPv6 as they don't actually originate much end-user-facing IPv4 space.  The 
result is an HTTP/403 which most browsers do not interpret as a response that 
could be remedied by "happy eyeballs" type behavior.  Whether banning an entire 
ASN like that in precisely a situation where this kind of thing is likely to 
occur is a good practice or not is left as an exercise to the reader.
-- 
Brandon Martin

Re: RIPE our of IPv4

[Valdis Klētnieks]

On Sat, 30 Nov 2019 13:47:36 -0800, Matthew Kaufman said:

> User apps prefer IPv6, Netflix stops, users complain

And fallback to IPv4 fails to happen, why, exactly?


pgphoWWsRXmVA.pgp
Description: PGP signature

Re: RIPE our of IPv4

[Matthew Kaufman]

On Sat, Nov 30, 2019 at 4:57 PM Brandon Martin 
wrote:

> On 11/30/19 4:48 PM, Matthew Kaufman wrote:
> > See previous message about legacy IPv4 holders without budget for IPv6
> blocks
>
> How slim are your margins to have been around long enough to have a legacy
> IPv4 block but not be able to afford the ARIN fees to get a comparable/very
> usable (/48 to /52 for each IPv4) amount of IPv6?  And if you don't need a
> "comparable" amount of IPv6, presumably you aren't using all your legacy
> IPv4 and can sell off part of its presumably huge allocation to get some
> funds.
> --
>

Nonprofit that acts as an ISP with a budget of a few thousand a year,
smallest allocation to an ISP would be $500/yr in fees, a substantial
fraction of budget.

>
>

Re: RIPE our of IPv4

[Brandon Martin]

On 11/30/19 12:18 PM, Justin Streiner wrote:
> Verizon is an interesting case.  While IPv6 penetration on the wireless side 
> is very high, the same is not true on the Fios/DSL side.  IPv6 deployment 
> there is nearly nonexistent.
> I've heard rumblings that some early Fios users will need to have their ONTs 
> replaced to be able to get v6, regardless if the router itself supports it.  
> I don't know if this is true, because I've never been able to get a 
> straight/authoritative answer from Verizon.

Does Verizon still own/manage ANY of their Fios territories?  I thought it was 
all sold off to Frontier at this point.  It certainly all is, along with all 
their legacy LEC territories not having FTTx and having some form of DSL, 
around here.  The latter DSL offerings are usually pretty hilarious.  It's 
mostly run out of the CO or existing RTUs from the POTS era.  I can't imagine 
they have a ton of subscribers outside of areas with literally no other 
wireline options, and I'm guessing a lot of that infrastructure hasn't been 
touched in a decade-plus.

Is Frontier-managed Fios included in those numbers regardless, or are they 
separate like I'd expect them to be?
-- 
Brandon Martin

Re: RIPE our of IPv4

[Brandon Martin]

On 11/30/19 4:48 PM, Matthew Kaufman wrote:
> See previous message about legacy IPv4 holders without budget for IPv6 blocks 

How slim are your margins to have been around long enough to have a legacy IPv4 
block but not be able to afford the ARIN fees to get a comparable/very usable 
(/48 to /52 for each IPv4) amount of IPv6?  And if you don't need a 
"comparable" amount of IPv6, presumably you aren't using all your legacy IPv4 
and can sell off part of its presumably huge allocation to get some funds.
-- 
Brandon Martin

Re: RIPE our of IPv4

[Matthew Kaufman]

Sorry, thought this was the Tunnels part of the thread.

Kubernetes Container networking only supported one address per pod until
well *after* V6-only clusters were in alpha, so dual-stack want an option.

Point is, plenty of popular server-side infrastructure was designed
IPv4-first as late as 2014. This is just one example of many.

Matthew Kaufman


On Sat, Nov 30, 2019 at 1:29 PM Mark Andrews  wrote:

> And how did that stop you deploying IPv6?  It’s not like you were turning
> off IPv4.
> --
> Mark Andrews
>
> On 1 Dec 2019, at 04:03, Matthew Kaufman  wrote:
>
> 
> This is a great example (but just one of many) of how server software
> development works:
>
> IANA IPv4 runout January 2011.
>
> Kubernetes initial release June 2014. Developed by Google engineers.
>
> ARIN IPv4 runout September 2015.
>
> Support for IPv6-only Kubernetes clusters alphas in 1.9, December 2017.
>
> Full support including CoreDNS support in 1.13, December 2018.
>
> Too bad nobody had warned them about IPv4 exhaustion before they started!
>
> On Mon, Nov 25, 2019 at 8:02 AM Andy Ringsmuth  wrote:
>
>>
>>
>> > On Nov 25, 2019, at 8:56 AM, Dmitry Sherman 
>> wrote:
>> >
>> > Just received a mail that RIPE is out of IPv4:
>> >
>> > Dear colleagues,
>> >
>> > Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4
>> allocation from the last remaining addresses in our available pool. We have
>> now run out of IPv4 addresses.
>>
>> Does this mean we are finally ripe for widespread IPv6 adoption?
>>
>> (Admit it, someone had to say it!)
>>
>> 
>> Andy Ringsmuth
>> 5609 Harding Drive
>> 
>> Lincoln, NE 68521
>> 
>> -5831
>> (402) 304-0083
>> a...@andyring.com
>
>

Re: RIPE our of IPv4

[Matthew Kaufman]

See previous message about legacy IPv4 holders without budget for IPv6
blocks

On Sat, Nov 30, 2019 at 12:15 PM Filip Hruska  wrote:

> You can announce your own IPv6 subnets through TunnelBroker.
>
> Filip
>
>
> On 30 November 2019 8:37:33 pm GMT+01:00, Matthew Kaufman <
> matt...@matthew.at> wrote:
>>
>>
>>
>> On Sat, Nov 30, 2019 at 9:21 AM Justin Streiner 
>> wrote:
>>
>>>
>>>
>>> While a tunnel from HE works perfectly well, it would be nice to have
>>> native v6 from VZ.
>>>
>>
>> Worked perfectly well. Until Netflix blocked all known tunnel providers.
>> Then my users demanded I turn IPv6 off... so I did. Won’t come back until
>> both my up streams properly support it.
>>
>> Matthew Kaufman
>>
>>>
>>>
> --
> Sent from my mobile device. Please excuse my brevity.
>

Re: RIPE our of IPv4

[Matthew Kaufman]

User apps prefer IPv6, Netflix stops, users complain

On Sat, Nov 30, 2019 at 1:29 PM Mark Andrews  wrote:

> And how did that stop you deploying IPv6?  It’s not like you were turning
> off IPv4.
> --
> Mark Andrews
>
> On 1 Dec 2019, at 04:03, Matthew Kaufman  wrote:
>
> 
> This is a great example (but just one of many) of how server software
> development works:
>
> IANA IPv4 runout January 2011.
>
> Kubernetes initial release June 2014. Developed by Google engineers.
>
> ARIN IPv4 runout September 2015.
>
> Support for IPv6-only Kubernetes clusters alphas in 1.9, December 2017.
>
> Full support including CoreDNS support in 1.13, December 2018.
>
> Too bad nobody had warned them about IPv4 exhaustion before they started!
>
> On Mon, Nov 25, 2019 at 8:02 AM Andy Ringsmuth  wrote:
>
>>
>>
>> > On Nov 25, 2019, at 8:56 AM, Dmitry Sherman 
>> wrote:
>> >
>> > Just received a mail that RIPE is out of IPv4:
>> >
>> > Dear colleagues,
>> >
>> > Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4
>> allocation from the last remaining addresses in our available pool. We have
>> now run out of IPv4 addresses.
>>
>> Does this mean we are finally ripe for widespread IPv6 adoption?
>>
>> (Admit it, someone had to say it!)
>>
>> 
>> Andy Ringsmuth
>> 5609 Harding Drive
>> 
>> Lincoln, NE 68521
>> 
>> -5831
>> (402) 304-0083
>> a...@andyring.com
>
>

Re: RIPE our of IPv4

[Mark Andrews]

And how did that stop you deploying IPv6?  It’s not like you were turning off 
IPv4. 
-- 
Mark Andrews

> On 1 Dec 2019, at 04:03, Matthew Kaufman  wrote:
> 
> 
> This is a great example (but just one of many) of how server software 
> development works:
> 
> IANA IPv4 runout January 2011.
> 
> Kubernetes initial release June 2014. Developed by Google engineers.
> 
> ARIN IPv4 runout September 2015.
> 
> Support for IPv6-only Kubernetes clusters alphas in 1.9, December 2017.
> 
> Full support including CoreDNS support in 1.13, December 2018.
> 
> Too bad nobody had warned them about IPv4 exhaustion before they started!
> 
>> On Mon, Nov 25, 2019 at 8:02 AM Andy Ringsmuth  wrote:
>> 
>> 
>> > On Nov 25, 2019, at 8:56 AM, Dmitry Sherman  wrote:
>> > 
>> > Just received a mail that RIPE is out of IPv4:
>> > 
>> > Dear colleagues,
>> > 
>> > Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 
>> > allocation from the last remaining addresses in our available pool. We 
>> > have now run out of IPv4 addresses.
>> 
>> Does this mean we are finally ripe for widespread IPv6 adoption?
>> 
>> (Admit it, someone had to say it!)
>> 
>> 
>> Andy Ringsmuth
>> 5609 Harding Drive
>> Lincoln, NE 68521-5831
>> (402) 304-0083
>> a...@andyring.com

Re: RIPE our of IPv4

[Filip Hruska]

You can announce your own IPv6 subnets through TunnelBroker.

Filip

On 30 November 2019 8:37:33 pm GMT+01:00, Matthew Kaufman  
wrote:
>On Sat, Nov 30, 2019 at 9:21 AM Justin Streiner 
>wrote:
>
>>
>>
>> While a tunnel from HE works perfectly well, it would be nice to have
>> native v6 from VZ.
>>
>
>Worked perfectly well. Until Netflix blocked all known tunnel
>providers.
>Then my users demanded I turn IPv6 off... so I did. Won’t come back
>until
>both my up streams properly support it.
>
>Matthew Kaufman
>
>>
>>

-- 
Sent from my mobile device. Please excuse my brevity.

Re: RIPE our of IPv4

[Matthew Kaufman]

On Sat, Nov 30, 2019 at 9:21 AM Justin Streiner  wrote:

>
>
> While a tunnel from HE works perfectly well, it would be nice to have
> native v6 from VZ.
>

Worked perfectly well. Until Netflix blocked all known tunnel providers.
Then my users demanded I turn IPv6 off... so I did. Won’t come back until
both my up streams properly support it.

Matthew Kaufman

>
>

Re: RIPE our of IPv4

[Justin Streiner]

On Sat, Nov 30, 2019 at 11:46 AM Ca By  wrote:

>
> That said, google see nearly 40% of their traffic on  ipv6 in the usa ,
> growth trend looks strong
>
> https://www.google.com/intl/en/ipv6/statistics.html
>
> And
>
> Comcast (71%), Charter (52%), VZ (85%),  ATT (60 and 78%) , and T-Mobile
> (95%) have the majority of their subs on ipv6
>
> https://www.worldipv6launch.org/measurements/
>

Verizon is an interesting case.  While IPv6 penetration on the wireless
side is very high, the same is not true on the Fios/DSL side.  IPv6
deployment there is nearly nonexistent.
I've heard rumblings that some early Fios users will need to have their
ONTs replaced to be able to get v6, regardless if the router itself
supports it.  I don't know if this is true, because I've never been able to
get a straight/authoritative answer from Verizon.

While a tunnel from HE works perfectly well, it would be nice to have
native v6 from VZ.

jms


> Sadly, ipv6 is creating a bifurcation of the internet.  Scale shops have
> v6, and non-scale shops don’t. The big players are pulling away, and that
> makes things bleak for the folks just trying to tread water in ipv4.
>
>
>>
>> Frankly, I'm surprised anti-IPv6 people still have employment.
>>
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>>
>> Midwest-IX
>> http://www.midwest-ix.com
>>
>>
>> -Brian
>>
>>
>> ------
>> *From: *"Brian Knight" 
>> *To: *"Mark Andrews" 
>> *Cc: *"nanog" 
>> *Sent: *Friday, November 29, 2019 10:29:17 AM
>> *Subject: *Re: RIPE our of IPv4
>>
>>
>> > On Nov 27, 2019, at 4:04 PM, Mark Andrews  wrote:
>> >
>> > 
>> >
>> >> On 28 Nov 2019, at 06:08, Brian Knight  wrote:
>> >>
>> >>> On 2019-11-26 17:11, Ca By wrote:
>> >>> On Tue, Nov 26, 2019 at 12:15 AM Sabri Berisha > >
>> >>> wrote:
>> >>>> - On Nov 26, 2019, at 1:36 AM, Doug Barton do...@dougbarton.us
>> wrote:
>> >>
>> >> [snip]
>> >>>> there is no ROI at this point. In this kind of environment there
>> needs to
>> >>>> be a strong case to invest the capex to support IPv6.
>> >>>> IPv6 must be supported on the CxO level in order to be deployed.
>> >>>> Thanks,
>> >>>> Sabri, (Badum tsss) MBA
>> >>> I seewell let me translate it you MBA-eese for you:
>> >>> FANG deployed ipv6 nearly 10 years ago. Since deploying ipv6, the
>> cohort
>> >>> experienced 300% CAGR. Also, everything is mobile, and all mobile
>> providers
>> >>> in the usa offer ipv6 by default in most cases. Latency! Scale! As
>> your
>> >>> company launches its digital transformation iot 2020 virtualization
>> >>> container initiatives, ipv6 will be an integral part of staying
>> relevant on
>> >>> the blockchain.  Also, FANG did it nearly 10 years ago.  Big content
>> and
>> >>> big eyeballs are on ipv6, ipv4 is a winnowing longtail of irrelevance
>> and
>> >>> iot botnets.
>> >>
>> >> None of which matters a damn to almost all of my business eyeball
>> customers.  They can still get from our network to 100% of all Internet
>> content & services via IPv4 in 2019.
>> >
>> > No you can’t.  You can’t reach the machine I’m typing on via IPv4 and
>> it is ON THE INTERNET.  It is directly reachable via IPv6.  Selling
>> Internet connectivity without IPv6 should be considered fraud these days.
>> Don’t
>> > you believe in “Truth in Advertising”?
>>
>> I had meant to write “They can still get from our network to 100% of all
>> Internet content and services that matter to them [our customers] via
>> IPv4...”
>>
>> 0% of my IPv4-only customers have opened tickets saying they cannot reach
>> some service that is only IPv6 accessible. So if they do care about IPv6
>> connectivity, they haven’t communicated that to us.
>>
>> > Mark Andrews, ISC
>> > 1 Seymour St., Dundas Valley, NSW
>> <https://www.google.com/maps/search/1+Seymour+St.,+Dundas+Valley,+NSW?entry=gmail=g>
>> 2117, Australia
>> > PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>> >
>>
>> Thanks,
>>
>> -Brian
>>
>>

Re: RIPE our of IPv4

[Matthew Kaufman]

This is a great example (but just one of many) of how server software
development works:

IANA IPv4 runout January 2011.

Kubernetes initial release June 2014. Developed by Google engineers.

ARIN IPv4 runout September 2015.

Support for IPv6-only Kubernetes clusters alphas in 1.9, December 2017.

Full support including CoreDNS support in 1.13, December 2018.

Too bad nobody had warned them about IPv4 exhaustion before they started!

On Mon, Nov 25, 2019 at 8:02 AM Andy Ringsmuth  wrote:

>
>
> > On Nov 25, 2019, at 8:56 AM, Dmitry Sherman 
> wrote:
> >
> > Just received a mail that RIPE is out of IPv4:
> >
> > Dear colleagues,
> >
> > Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4
> allocation from the last remaining addresses in our available pool. We have
> now run out of IPv4 addresses.
>
> Does this mean we are finally ripe for widespread IPv6 adoption?
>
> (Admit it, someone had to say it!)
>
> 
> Andy Ringsmuth
> 5609 Harding Drive
> Lincoln, NE 68521-5831
> (402) 304-0083
> a...@andyring.com

Re: RIPE our of IPv4

[Matthew Kaufman]

I administer two networks that use legacy IPv4 blocks (one also uses an
allocation from the 44 net)

Both could have IPv6 if it was free, but neither organization has the funds
to waste on a paid IPv6 allocation.

We should have given every legacy block matching free IPv6 space, because
early adopters are still sometimes early adopters.

But you’re right, what could have been supported on a volunteer basis is
now a profit center. Especially for IPv6, which is once-and-done if sized
properly.

Matthew Kaufman

On Tue, Nov 26, 2019 at 2:29 PM  wrote:

>
> If the commitment really was to spread IPv6 far and wide IPv6 blocks
> would be handed out for free, one per qualified customer (e.g., if you
> have an IPv4 allocation you get one IPv6 block free), or perhaps some
> trivial administrative fee like $10 per year.
>
> But the RIRs can't live on that.
>
> We have put them under the management of a group of five organizations
> which are very dependent on the income from block allocations and no
> doubt were hoping IPv6 allocations would be a boon since there will be
> very little if any income growth from future IPv4 block allocations.
>
> Worse, once acquired an IPv6 block has so many billions of addresses
> very few if any would ever need another allocation so it would hardly
> act as a loss leader.
>
> I realize many still would not deploy IPv6 for various reasons such as
> their equipment doesn't support it or they don't have the in-house
> expertise to support it, etc tho I can't think of much other etc, a
> few points of resistance do come up.
>
> --
> -Barry Shein
>
> Software Tool & Die| b...@theworld.com |
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*
>

Re: RIPE our of IPv4

[Ca By]

On Sat, Nov 30, 2019 at 8:06 AM Brian Knight  wrote:

>
> On Nov 29, 2019, at 5:28 PM, Mike Hammett  wrote:
>
> 
> "So if they do care about IPv6 connectivity, they haven’t communicated
> that to us."
>
> Nor will they, but that doesn't mean IPv6 isn't important.
>
>
> Personally, I don’t disagree. We engineers do what we can to support IPv6:
> We build it into our tooling and switch it on in our gear. Our network is
> dual stack v4/v6 and has been for quite a while. But with other tools we
> don’t control, and particularly in terms of business process, we have a
> ways to go, and it’s not a priority.
>
> I want IPv6 to succeed, really.  But the global end game picture looks
> more and more bleak to me.
>

I can see how your situation is bleak

That said, google see nearly 40% of their traffic on  ipv6 in the usa ,
growth trend looks strong

https://www.google.com/intl/en/ipv6/statistics.html

And

Comcast (71%), Charter (52%), VZ (85%),  ATT (60 and 78%) , and T-Mobile
(95%) have the majority of their subs on ipv6

https://www.worldipv6launch.org/measurements/


Sadly, ipv6 is creating a bifurcation of the internet.  Scale shops have
v6, and non-scale shops don’t. The big players are pulling away, and that
makes things bleak for the folks just trying to tread water in ipv4.


>
> Frankly, I'm surprised anti-IPv6 people still have employment.
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
>
> -Brian
>
>
> --
> *From: *"Brian Knight" 
> *To: *"Mark Andrews" 
> *Cc: *"nanog" 
> *Sent: *Friday, November 29, 2019 10:29:17 AM
> *Subject: *Re: RIPE our of IPv4
>
>
> > On Nov 27, 2019, at 4:04 PM, Mark Andrews  wrote:
> >
> > 
> >
> >> On 28 Nov 2019, at 06:08, Brian Knight  wrote:
> >>
> >>> On 2019-11-26 17:11, Ca By wrote:
> >>> On Tue, Nov 26, 2019 at 12:15 AM Sabri Berisha 
> >>> wrote:
> >>>> - On Nov 26, 2019, at 1:36 AM, Doug Barton do...@dougbarton.us
> wrote:
> >>
> >> [snip]
> >>>> there is no ROI at this point. In this kind of environment there
> needs to
> >>>> be a strong case to invest the capex to support IPv6.
> >>>> IPv6 must be supported on the CxO level in order to be deployed.
> >>>> Thanks,
> >>>> Sabri, (Badum tsss) MBA
> >>> I seewell let me translate it you MBA-eese for you:
> >>> FANG deployed ipv6 nearly 10 years ago. Since deploying ipv6, the
> cohort
> >>> experienced 300% CAGR. Also, everything is mobile, and all mobile
> providers
> >>> in the usa offer ipv6 by default in most cases. Latency! Scale! As your
> >>> company launches its digital transformation iot 2020 virtualization
> >>> container initiatives, ipv6 will be an integral part of staying
> relevant on
> >>> the blockchain.  Also, FANG did it nearly 10 years ago.  Big content
> and
> >>> big eyeballs are on ipv6, ipv4 is a winnowing longtail of irrelevance
> and
> >>> iot botnets.
> >>
> >> None of which matters a damn to almost all of my business eyeball
> customers.  They can still get from our network to 100% of all Internet
> content & services via IPv4 in 2019.
> >
> > No you can’t.  You can’t reach the machine I’m typing on via IPv4 and it
> is ON THE INTERNET.  It is directly reachable via IPv6.  Selling Internet
> connectivity without IPv6 should be considered fraud these days.  Don’t
> > you believe in “Truth in Advertising”?
>
> I had meant to write “They can still get from our network to 100% of all
> Internet content and services that matter to them [our customers] via
> IPv4...”
>
> 0% of my IPv4-only customers have opened tickets saying they cannot reach
> some service that is only IPv6 accessible. So if they do care about IPv6
> connectivity, they haven’t communicated that to us.
>
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW
> <https://www.google.com/maps/search/1+Seymour+St.,+Dundas+Valley,+NSW?entry=gmail=g>
> 2117, Australia
> > PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> >
>
> Thanks,
>
> -Brian
>
>

Re: RIPE our of IPv4

[Brian Knight]

>> On Nov 29, 2019, at 5:28 PM, Mike Hammett  wrote:
> 
> "So if they do care about IPv6 connectivity, they haven’t communicated that 
> to us."
> 
> Nor will they, but that doesn't mean IPv6 isn't important.

Personally, I don’t disagree. We engineers do what we can to support IPv6: We 
build it into our tooling and switch it on in our gear. Our network is dual 
stack v4/v6 and has been for quite a while. But with other tools we don’t 
control, and particularly in terms of business process, we have a ways to go, 
and it’s not a priority.

I want IPv6 to succeed, really.  But the global end game picture looks more and 
more bleak to me.

> 
> Frankly, I'm surprised anti-IPv6 people still have employment.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
> 
> Midwest-IX
> http://www.midwest-ix.com

-Brian

> 
> From: "Brian Knight" 
> To: "Mark Andrews" 
> Cc: "nanog" 
> Sent: Friday, November 29, 2019 10:29:17 AM
> Subject: Re: RIPE our of IPv4 
> 
> 
> > On Nov 27, 2019, at 4:04 PM, Mark Andrews  wrote:
> > 
> > 
> > 
> >> On 28 Nov 2019, at 06:08, Brian Knight  wrote:
> >> 
> >>> On 2019-11-26 17:11, Ca By wrote:
> >>> On Tue, Nov 26, 2019 at 12:15 AM Sabri Berisha 
> >>> wrote:
> >>>> - On Nov 26, 2019, at 1:36 AM, Doug Barton do...@dougbarton.us wrote:
> >> 
> >> [snip]
> >>>> there is no ROI at this point. In this kind of environment there needs to
> >>>> be a strong case to invest the capex to support IPv6.
> >>>> IPv6 must be supported on the CxO level in order to be deployed.
> >>>> Thanks,
> >>>> Sabri, (Badum tsss) MBA
> >>> I seewell let me translate it you MBA-eese for you:
> >>> FANG deployed ipv6 nearly 10 years ago. Since deploying ipv6, the cohort
> >>> experienced 300% CAGR. Also, everything is mobile, and all mobile 
> >>> providers
> >>> in the usa offer ipv6 by default in most cases. Latency! Scale! As your
> >>> company launches its digital transformation iot 2020 virtualization
> >>> container initiatives, ipv6 will be an integral part of staying relevant 
> >>> on
> >>> the blockchain.  Also, FANG did it nearly 10 years ago.  Big content and
> >>> big eyeballs are on ipv6, ipv4 is a winnowing longtail of irrelevance and
> >>> iot botnets.
> >> 
> >> None of which matters a damn to almost all of my business eyeball 
> >> customers.  They can still get from our network to 100% of all Internet 
> >> content & services via IPv4 in 2019.
> > 
> > No you can’t.  You can’t reach the machine I’m typing on via IPv4 and it is 
> > ON THE INTERNET.  It is directly reachable via IPv6.  Selling Internet 
> > connectivity without IPv6 should be considered fraud these days.  Don’t
> > you believe in “Truth in Advertising”?
> 
> I had meant to write “They can still get from our network to 100% of all 
> Internet content and services that matter to them [our customers] via IPv4...”
> 
> 0% of my IPv4-only customers have opened tickets saying they cannot reach 
> some service that is only IPv6 accessible. So if they do care about IPv6 
> connectivity, they haven’t communicated that to us.
> 
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> > 
> 
> Thanks,
> 
> -Brian

Re: RIPE our of IPv4

[Valdis Klētnieks]

On Fri, 29 Nov 2019 23:26:04 -0500, Brandon Martin said:

> definitely the lagging factor, here.  I suspect it's at least partially
> because high-ratio NAT44 has been the norm for enterprise deployments
> for some time, and, among those who might otherwise be willing to
> support first-class dual stack, many enterprise IT folks lack the
> education to recognize the nuance between public addressing and
> unfiltered public reachability of a given host.  I suspect many of them
> are already using IPv6 for LAN traffic without even realizing it given
> Windows' penchant for doing so since Vista.

Judging how long it took to (mostly) stamp out CLASSA/B/C nonsense,
we're in for at least a decade of IPv6 firewalls that block all ICMP, plus
whatever common IPv6 misconfigurations and misconceptions are
out there (I was deploying this stuff literally last century, so I admit
not knowing what people are screwing up currently).



pgpwdX4RrpNns.pgp
Description: PGP signature

Re: RIPE our of IPv4

[Brandon Martin]

On 11/29/19 11:29 AM, Brian Knight wrote:

0% of my IPv4-only customers have opened tickets saying they cannot reach some 
service that is only IPv6 accessible. So if they do care about IPv6 
connectivity, they haven’t communicated that to us.


I help admin a very small (<1k subs, but growing) municipal ISP.  We 
have had a couple requests from residential subscribers for IPv6 which 
is not yet enabled due to lack of support for a nice, but not strictly 
required, feature from one vendor in our stack (and they have opened a 
feature request and promised support in the next release - we'll see if 
they deliver).  If a SP with <1k subs has ANY registered interest, I'd 
say a non-trivial SP is going to have some even if it's not being 
communicated.


Certainly, to me, if I have a choice of service providers, and one 
offers native IPv6 (or even well-supported 6rd) while the other offers 
no IPv6 and has no plans or is even downright IPv6-hostile (e.g. mucking 
with protocol 41), that's certainly going to factor into my decision. 
This is a pre-sales issue which, on standard consumer services, is 
unlikely to ever be communicated to the provider.  However, I'll admit 
that I'm not a normal customer.


Interestingly, albeit somewhat unsurprisingly, interest from enterprises 
on DIA services (where the aforementioned feature is irrelevant) has 
been not just nonexistent but outright hostile.  Every one of them has 
asked to have it explicitly disabled when prompted.  Enterprise is 
definitely the lagging factor, here.  I suspect it's at least partially 
because high-ratio NAT44 has been the norm for enterprise deployments 
for some time, and, among those who might otherwise be willing to 
support first-class dual stack, many enterprise IT folks lack the 
education to recognize the nuance between public addressing and 
unfiltered public reachability of a given host.  I suspect many of them 
are already using IPv6 for LAN traffic without even realizing it given 
Windows' penchant for doing so since Vista.


--
Brandon Martin

Re: RIPE our of IPv4

[Mike Hammett]

"So if they do care about IPv6 connectivity, they haven’t communicated that to 
us." 


Nor will they, but that doesn't mean IPv6 isn't important. 


Frankly, I'm surprised anti-IPv6 people still have employment. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Brian Knight"  
To: "Mark Andrews"  
Cc: "nanog"  
Sent: Friday, November 29, 2019 10:29:17 AM 
Subject: Re: RIPE our of IPv4 


> On Nov 27, 2019, at 4:04 PM, Mark Andrews  wrote: 
> 
> 
> 
>> On 28 Nov 2019, at 06:08, Brian Knight  wrote: 
>> 
>>> On 2019-11-26 17:11, Ca By wrote: 
>>> On Tue, Nov 26, 2019 at 12:15 AM Sabri Berisha  
>>> wrote: 
>>>> - On Nov 26, 2019, at 1:36 AM, Doug Barton do...@dougbarton.us wrote: 
>> 
>> [snip] 
>>>> there is no ROI at this point. In this kind of environment there needs to 
>>>> be a strong case to invest the capex to support IPv6. 
>>>> IPv6 must be supported on the CxO level in order to be deployed. 
>>>> Thanks, 
>>>> Sabri, (Badum tsss) MBA 
>>> I seewell let me translate it you MBA-eese for you: 
>>> FANG deployed ipv6 nearly 10 years ago. Since deploying ipv6, the cohort 
>>> experienced 300% CAGR. Also, everything is mobile, and all mobile providers 
>>> in the usa offer ipv6 by default in most cases. Latency! Scale! As your 
>>> company launches its digital transformation iot 2020 virtualization 
>>> container initiatives, ipv6 will be an integral part of staying relevant on 
>>> the blockchain. Also, FANG did it nearly 10 years ago. Big content and 
>>> big eyeballs are on ipv6, ipv4 is a winnowing longtail of irrelevance and 
>>> iot botnets. 
>> 
>> None of which matters a damn to almost all of my business eyeball customers. 
>> They can still get from our network to 100% of all Internet content & 
>> services via IPv4 in 2019. 
> 
> No you can’t. You can’t reach the machine I’m typing on via IPv4 and it is ON 
> THE INTERNET. It is directly reachable via IPv6. Selling Internet 
> connectivity without IPv6 should be considered fraud these days. Don’t 
> you believe in “Truth in Advertising”? 

I had meant to write “They can still get from our network to 100% of all 
Internet content and services that matter to them [our customers] via IPv4...” 

0% of my IPv4-only customers have opened tickets saying they cannot reach some 
service that is only IPv6 accessible. So if they do care about IPv6 
connectivity, they haven’t communicated that to us. 

> Mark Andrews, ISC 
> 1 Seymour St., Dundas Valley, NSW 2117, Australia 
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org 
> 

Thanks, 

-Brian 

Re: RIPE our of IPv4

[Brian Knight]

> On Nov 27, 2019, at 4:04 PM, Mark Andrews  wrote:
> 
> 
> 
>> On 28 Nov 2019, at 06:08, Brian Knight  wrote:
>> 
>>> On 2019-11-26 17:11, Ca By wrote:
>>> On Tue, Nov 26, 2019 at 12:15 AM Sabri Berisha 
>>> wrote:
 - On Nov 26, 2019, at 1:36 AM, Doug Barton do...@dougbarton.us wrote:
>> 
>> [snip]
 there is no ROI at this point. In this kind of environment there needs to
 be a strong case to invest the capex to support IPv6.
 IPv6 must be supported on the CxO level in order to be deployed.
 Thanks,
 Sabri, (Badum tsss) MBA
>>> I seewell let me translate it you MBA-eese for you:
>>> FANG deployed ipv6 nearly 10 years ago. Since deploying ipv6, the cohort
>>> experienced 300% CAGR. Also, everything is mobile, and all mobile providers
>>> in the usa offer ipv6 by default in most cases. Latency! Scale! As your
>>> company launches its digital transformation iot 2020 virtualization
>>> container initiatives, ipv6 will be an integral part of staying relevant on
>>> the blockchain.  Also, FANG did it nearly 10 years ago.  Big content and
>>> big eyeballs are on ipv6, ipv4 is a winnowing longtail of irrelevance and
>>> iot botnets.
>> 
>> None of which matters a damn to almost all of my business eyeball customers. 
>>  They can still get from our network to 100% of all Internet content & 
>> services via IPv4 in 2019.
> 
> No you can’t.  You can’t reach the machine I’m typing on via IPv4 and it is 
> ON THE INTERNET.  It is directly reachable via IPv6.  Selling Internet 
> connectivity without IPv6 should be considered fraud these days.  Don’t
> you believe in “Truth in Advertising”?

I had meant to write “They can still get from our network to 100% of all 
Internet content and services that matter to them [our customers] via IPv4...”

0% of my IPv4-only customers have opened tickets saying they cannot reach some 
service that is only IPv6 accessible. So if they do care about IPv6 
connectivity, they haven’t communicated that to us.

> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 

Thanks,

-Brian

Re: RIPE our of IPv4

[Sabri Berisha]

- On Nov 27, 2019, at 8:03 PM, Doug Barton do...@dougbarton.us wrote:

> I don't understand how you're using "teams" here. For the most part you
> turn it on, and end-user systems pick up the RA and do the right thing.
> If you want something fancier, you can do that with DHCP, static
> addressing, etc. In other words, this works the exact same way that IPv4
> does.

Different teams support different parts of the business. Also, most large 
enterprises today have been through multiple acquisitions, with different 
systems that are somehow merged into each other. Those that know how it works 
have left a long time ago, and those that don't won't touch it. 

>> - Modifying old (ancient) internal code;
> 
> What code? IPv4 isn't going away on the inside, so what needs to be
> modified? If you're talking monitoring software, etc., if you're still
> using software that doesn't understand IPv6, you're way overdue for an
> upgrade already.

There can be many things that need to be modified. And I'm not saying an 
upgrade is not long overdue, I'm saying it must make sense on the business side 
before the engineering side gets the go ahead to spend time and resources (and 
thus, cash) on it.

>> - Modifying old (ancient) database structures (think 16 character fields for 
>> IP
>> addresses);
> 
> Either see above, or much more likely you'd be adding a field, not
> modifying the existing one.

Yeah, maybe yes, maybe no. That will be part of a feasibility/cost study.
 
>> - Upgrading/replacing load balancers and other legacy crap that only support
>> IPv4 (yeah, they still exist);
> 
> If we're talking about an enterprise that is seriously still using stuff
> this old, it's more likely than not that IPv6 is the least of their
> worries. And I'm not being flippant or disrespectful here. For at least
> the last 10 years or so, and definitely in the last 5, all of the
> enterprise level network gear sold has had support for IPv6. 

Let me give you one example: old APC remotely accessible powerstrips. Plenty in 
use today. IPv4 only.


>> Execs have bonus targets. IPv6 is not yet important enough to become part of
>> that bonus target: there is no ROI at this point.
> 
> That depends heavily on what enterprise you're talking about.
> 
> The point I'm trying to make is that there IS an ROI here.

You are preaching to the choir here. I have made those points many times. 
However, the ROI is in the distant future, and won't be easily measurable. So 
execs just don't prioritize; they are motivated by their own targets for the 
year so they get their bonuses. And let's be honest: can you blame them?

Again, I'm not saying there is no need to implement it, I'm saying that the 
reality is that large businesses have not prioritized it enough because it is 
difficult to measure the need and ROI. And that's a problem I have, 
unfortunately, witnessed firsthand over the course of my career at different 
employers.

Thanks,

Sabri

Re: RIPE our of IPv4

[Owen DeLong]

That’s absurd…

Yes, you have to support both for now. However, you really only need IPv4 
addresses on each front-end box and you only need that until the proportion of 
eyeball users that lack IPv6 capabilities is small enough to be considered no 
longer worth the cost of support.

I doubt seriously that the quantity of eyeball users you would consider cost 
effective to support is one. Case in point: Do your servers still support 
non-SNI compliant browsers? Do you limit your pages to compatibility with IE 
version 10?

Owen

> On Nov 25, 2019, at 11:50 , Dmitry Sherman  wrote:
> 
> Because we can’t only use ipv6 on the boxes, each box with ipv6 must have 
> IPv4 until the last eyeball broadband user will have ipv6 support.
> 
> Best regards,
> Dmitry Sherman
> Interhost Networks
> www.interhost.co.il
> dmi...@interhost.net
> Mob: 054-3181182
> Sent from Steve's creature 
> 
> 
>> On 25 Nov 2019, at 21:47, Mark Andrews  wrote:
>> 
>>  It requires both sides to move to IPv6.  Why should the cost of 
>> maintaining working networks be borne alone by the eyeball networks?   That 
>> is what is mostly happening today with CGN.
>> 
>> Every server that offers services to the public should be making them 
>> available over IPv6.   Most of the CDNs support both transports. Why are you 
>> scared to tick the box for IPv6?  HTTPS doesn’t care which transport is 
>> used. 
>> 
>> -- 
>> Mark Andrews
>> 
>>> On 26 Nov 2019, at 03:53, Dmitry Sherman  wrote:
>>> 
>>>  I believe it’s Eyeball network’s matter to free IPv4 blocks and move to 
>>> v6.
>>> 
>>> 
>>> Best regards,
>>> Dmitry Sherman
>>> 
>>> 
>>> 
 On 25 Nov 2019, at 18:08, Billy Crook  wrote:
 
 
 Huh.  I guess we get to go home early today then?  And look into that 
 whole "Aye Pee Vee Sicks" thing next week aye boss?
 
 On Mon, Nov 25, 2019 at 8:58 AM Dmitry Sherman >>> > wrote:
 Just received a mail that RIPE is out of IPv4:
 
 Dear colleagues,
 
 Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 
 allocation from the last remaining addresses in our available pool. We 
 have now run out of IPv4 addresses.
 
 
 Best regards,
 Dmitry Sherman
 Interhost Networks
 www.interhost.co.il 
 dmi...@interhost.net 
 Mob: 054-3181182
 Sent from Steve's creature 
 

Re: RIPE our of IPv4

[Doug Barton]

On 11/26/19 12:13 AM, Sabri Berisha wrote:

- On Nov 26, 2019, at 1:36 AM, Doug Barton do...@dougbarton.us wrote:


I get that some people still don't like it, but the answer is IPv6. Or,
folks can keep playing NAT games, etc. But one wonders at what point
rolling out IPv6 costs less than all the fun you get with [CG]NAT.


When the MBAs start realizing the risk of not deploying it.

I have some inside knowledge about the IPv6 efforts of a large eyeball network. 


For what it's worth, I have extensive experience in both eyeball and 
content networks.



In that particular case, the cost of deploying IPv6 internally is not simply 
configuring it on the network gear;


We're rehashing old ground here. Perhaps you weren't on the list the 
last N times this has come up. My short answer, I didn't say it would be 
easy, I said it is less expensive than the alternatives over time.



that has already been done. The cost of fully supporting IPv6 includes (but is 
probably not limited to):

- Support for deploying IPv6 across more than 20 different teams;


I don't understand how you're using "teams" here. For the most part you 
turn it on, and end-user systems pick up the RA and do the right thing. 
If you want something fancier, you can do that with DHCP, static 
addressing, etc. In other words, this works the exact same way that IPv4 
does.



- Modifying old (ancient) internal code;


What code? IPv4 isn't going away on the inside, so what needs to be 
modified? If you're talking monitoring software, etc., if you're still 
using software that doesn't understand IPv6, you're way overdue for an 
upgrade already.



- Modifying old (ancient) database structures (think 16 character fields for IP 
addresses);


Either see above, or much more likely you'd be adding a field, not 
modifying the existing one.



- Upgrading/replacing load balancers and other legacy crap that only support 
IPv4 (yeah, they still exist);


If we're talking about an enterprise that is seriously still using stuff 
this old, it's more likely than not that IPv6 is the least of their 
worries. And I'm not being flippant or disrespectful here. For at least 
the last 10 years or so, and definitely in the last 5, all of the 
enterprise level network gear sold has had support for IPv6. So again, 
way overdue for an update, but if this is all you have available, then 
you likely have bigger fish to fry. (And feel free to save the 
obligatory, "My favorite network widget that I use in my 100% 
enterprise-class network does not support IPv6." Yes, I realize that 
there are exceptions, but they are the exceptions, not the rule.)



- Modifying the countless home-grown tools that automate firewalls etc;


Yes, this is actually a legitimate point.


- Auditing the PCI infrastructure to ensure it is still compliant after 
deploying IPv6;


Also legit, where it applies, although you also have the option of not 
deploying on the network with the PCI data. For internal-only things, 
it's great to have IPv6, and will become increasingly important as time 
goes on, but it's not required.


Execs have bonus targets. IPv6 is not yet important enough to become part of that bonus target: there is no ROI at this point. 


That depends heavily on what enterprise you're talking about.

The point I'm trying to make is that there IS an ROI here. For content 
providers it's the ability to create a stable network architecture 
across all of your sites, and connect directly to the many eyeballs that 
are already on IPv6 (cell networks, many ISPs, etc.). There is also the 
much harder to define ROI for future-proofing the network, but that's 
part of the master class.  :)


For eyeball networks the same stable network architecture argument 
applies. The immediate ROI is harder to define, but similar, in the 
sense that connect directly to the many content networks that have 
already deployed IPv6 and future-proofing are both relevant.


Much harder for the eyeball networks to quantify are the savings related 
to NOT having to do [CG]NAT, etc. To create that slide you need an exec 
who truly understands the (rising over time) costs of twiddling around 
with the NATs, as well as the realistic costs involved in rolling out 
IPv6 balanced by the long term support. Then you also need an executive 
team and board that can understand those slides when they see them.


But it's not all in vain. I'm on Spectrum here at home, and I have 
native IPv6 that "just worked" from the moment I plugged my router into 
my cable modem.


So there are a non-trivial number of both eyeball and content networks 
that already get it. The value proposition obviously does exist, we just 
need more people in the right places with the right knowledge and 
experience to make it happen.


Doug

Re: RIPE our of IPv4

[Baldur Norddahl]

IPv6 significantly offloads the CGN servers. If you are not yet using CGN
you probably won't care, but sooner or later you will.

Thanks to the content providers that make this possible by offering enough
content by volume available on the IPv6 internet.

Regards

Baldur

Re: RIPE our of IPv4

[Brian Knight]

>> On Nov 27, 2019, at 2:54 PM, Brandon Butterworth  
>> wrote:
>> 
>> On Wed Nov 27, 2019 at 01:08:04PM -0600, Brian Knight wrote:
>> None of which matters a damn to almost all of my business eyeball
>> customers.  They can still get from our network to 100% of all Internet
>> content & services via IPv4 in 2019.  I regularly vet deals for our
>> sales team, and out of the hundreds of deals we sold this year, I can
>> count on one hand the number of deals where customers wanted IPv6.  We
>> sold them IPv6 access, but we didn't put it on our own network, because
>> we face the same internal challenges Sabri mentioned.  (SD-WAN, OTOH,
>> was far more popular
> 
> A few year later customer wakes up:
> 
> "wait you sold us all those toys we didn't need but didn't include
> the basic transport capabilites everyone apparently has been saying
> for over a decade are required minimum?"
> 
> "and now you want us to pay you to rebuild it again and trust that
> you got the basics right this time?"
> 
> If you're an internet professional you are a negligent one if by
> now you are not ensuring all you build quietly includes IPv6, no
> customer should need to know to ask for it. It's not like it
> needs different kit.

Possibly some customers may react this way, but I’m thinking many more would 
ask “what does it take to enable it?”  Most are reasonable and show good faith, 
even if an equipment swap is needed.  And if the demand for IPv6 is there, the 
providers will get the work prioritized.

>> As an aside, I would guess that it's the corporate eyeball customers
>> with servers, not resi/mobile behind CGNAT, that will bear the brunt of
>> the IPv4 cost first.  But what enterprise wants to tell its non-IPv6
>> customers "your Internet needs to be upgraded, come back to us when
>> you're done?"  That doesn't bode well for the short-term future.
> 
> "all that multi natted into same address space VPN firewall 
> complicated knitting we never got right wasn't needed if you'd
> told us to use IPv6?"

IPv6 doesn’t help anyone get access to their IPv4-only customers.  (Too bad 
that it doesn’t.)

My point was that, if eyeball networks start charging a premium for IPv4, their 
likely first customers to be charged are business customers not behind CGNAT.  
Those that don’t wish to pay the IPv4 premium would have to force *their* 
customers to go IPv6. That would be a much more difficult conversation than 
simply paying the premium.  So out of all the forces at work, which gives way 
first?

> 
> brandon

Thanks,

-Brian

RE: RIPE our of IPv4

[Michel Py]

>> Brian Knight wrote :
>> None of which matters a damn to almost all of my business eyeball customers. 
>>  They can still get from our network to 100% of all Internet content & 
>> services via IPv4 in 2019.

> Mark Andrews wrote :
> No you can’t.  You can’t reach the machine I’m typing on via IPv4 and it is 
> ON THE INTERNET.

Why should I care ? it contains zero content of value to me. It's on a subset 
of the Internet that contains zero content that interests me.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

Re: RIPE our of IPv4

[Mark Andrews]

> On 28 Nov 2019, at 06:08, Brian Knight  wrote:
> 
> On 2019-11-26 17:11, Ca By wrote:
>> On Tue, Nov 26, 2019 at 12:15 AM Sabri Berisha 
>> wrote:
>>> - On Nov 26, 2019, at 1:36 AM, Doug Barton do...@dougbarton.us wrote:
> 
> [snip]
>>> there is no ROI at this point. In this kind of environment there needs to
>>> be a strong case to invest the capex to support IPv6.
>>> IPv6 must be supported on the CxO level in order to be deployed.
>>> Thanks,
>>> Sabri, (Badum tsss) MBA
>> I seewell let me translate it you MBA-eese for you:
>> FANG deployed ipv6 nearly 10 years ago. Since deploying ipv6, the cohort
>> experienced 300% CAGR. Also, everything is mobile, and all mobile providers
>> in the usa offer ipv6 by default in most cases. Latency! Scale! As your
>> company launches its digital transformation iot 2020 virtualization
>> container initiatives, ipv6 will be an integral part of staying relevant on
>> the blockchain.  Also, FANG did it nearly 10 years ago.  Big content and
>> big eyeballs are on ipv6, ipv4 is a winnowing longtail of irrelevance and
>> iot botnets.
> 
> None of which matters a damn to almost all of my business eyeball customers.  
> They can still get from our network to 100% of all Internet content & 
> services via IPv4 in 2019.

No you can’t.  You can’t reach the machine I’m typing on via IPv4 and it is ON 
THE INTERNET.  It is directly reachable via IPv6.  Selling Internet 
connectivity without IPv6 should be considered fraud these days.  Don’t
you believe in “Truth in Advertising”?

>  I regularly vet deals for our sales team, and out of the hundreds of deals 
> we sold this year, I can count on one hand the number of deals where 
> customers wanted IPv6.  We sold them IPv6 access, but we didn't put it on our 
> own network, because we face the same internal challenges Sabri mentioned.  
> (SD-WAN, OTOH, was far more popular.  I'll give you three guesses why.  Hint 
> - it's not because tunnel technology is awesome and allows us to scale our 
> networks further and everyone is doing it.)

> Though their participation has been key in making IPv6 more useful for 
> eyeballs, content hasn't driven adoption.  The only thing eyeballs care about 
> is getting to 100% of what they need and want at minimal cost.  Until eyeball 
> networks start charging eyeballs for IPv4, IPv4 will linger.  The day 
> eyeballs start bitching on forums, opening tickets, complaining on Twitter, 
> etc. because they have only IPv6 is when IPv4 will start to lose relevance.
> 
> As an aside, I would guess that it's the corporate eyeball customers with 
> servers, not resi/mobile behind CGNAT, that will bear the brunt of the IPv4 
> cost first.  But what enterprise wants to tell its non-IPv6 customers "your 
> Internet needs to be upgraded, come back to us when you're done?"  That 
> doesn't bode well for the short-term future.
> 
> -Brian

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: RIPE our of IPv4

[Scott Weeks]

--- sur...@mauigateway.com wrote:
From: "Scott Weeks" 

No, it's just that (at least in my case at several different
companies) we're so focused by management on getting the sale
done by augmenting the existing network there is not enough 
time to devote to **planning an entire network from the 
ground up**, then working your plan.  The other way (just 
start configuring stuff) is replete with troubles.

BTW, I have been the IPv6 loudmouth every time, but I don't 
get any traction at all in any of the companies I've worked 
for.  Eyes gloss over and someone quickly changes the 
conversation.  Then we talk about sizing subnets and stuff...
-


BTW, what Mark Andrews said about 6rd fixes (I'm assuming 
a relatively low level of network architecturing work is 
necessary to get it done) what I am saying, but it feels 
so dirty.  I would like to go straight to dual stack.

scott

RE: RIPE our of IPv4

[Michel Py]

> Brian Knight wrote :
> None of which matters a damn to almost all of my business eyeball customers.  
> They
> can still get from our network to 100% of all Internet content & services via 
> IPv4 in 2019.

And will for the foreseable future. I am not one of your customers, but I like 
your realistic views. I vote with my wallet and buy my transit from the ISP who 
understands my needs.

>  I regularly vet deals for our sales team, and out of the hundreds of deals 
> we sold this year,
> I can count on one hand the number of deals where customers wanted IPv6.

Won't change any time soon. For the vast majority of business eyballs and 
entreprises, IPv6 is not even on the agenda.

> But what enterprise wants to tell its non-IPv6 customers "your Internet needs 
> to be upgraded,
> come back to us when you're done?"  That doesn't bode well for the short-term 
> future.

None of my customers has IPv6. None of my suppliers has IPv6. Nobody wants The 
business / enterprise ecosystem is and will remain of a size large enough to 
keep the IPv4 services for the foreseeable future.
Facebook going IPv6-only ? that would be a blessing. That is not what we pay 
employees to do at the office.

As Sabri would have said, why should I look like an idiot and go to the board 
and the investors for money to invest in something that has zero ROI ?
I was on the 6bone. I heard the IPv6 FUD for 20 years.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

Re: RIPE our of IPv4

[Scott Weeks]

--- bran...@rd.bbc.co.uk wrote:
From: Brandon Butterworth 

If you're an internet professional you are a negligent one if by
now you are not ensuring all you build quietly includes IPv6, no
customer should need to know to ask for it. It's not like it
needs different kit.
-


No, it's just that (at least in my case at several different
companies) we're so focused by management on getting the sale
done by augmenting the existing network there is not enough 
time to devote to **planning an entire network from the 
ground up**, then working your plan.  The other way (just 
start configuring stuff) is replete with troubles.

BTW, I have been the IPv6 loudmouth every time, but I don't 
get any traction at all in any of the companies I've worked 
for.  Eyes gloss over and someone quickly changes the 
conversation.  Then we talk about sizing subnets and stuff...

scott

Re: RIPE our of IPv4

[Brandon Butterworth]

On Wed Nov 27, 2019 at 01:08:04PM -0600, Brian Knight wrote:
> None of which matters a damn to almost all of my business eyeball 
> customers.  They can still get from our network to 100% of all Internet 
> content & services via IPv4 in 2019.  I regularly vet deals for our 
> sales team, and out of the hundreds of deals we sold this year, I can 
> count on one hand the number of deals where customers wanted IPv6.  We 
> sold them IPv6 access, but we didn't put it on our own network, because 
> we face the same internal challenges Sabri mentioned.  (SD-WAN, OTOH, 
> was far more popular

A few year later customer wakes up:

"wait you sold us all those toys we didn't need but didn't include
the basic transport capabilites everyone apparently has been saying
for over a decade are required minimum?"

"and now you want us to pay you to rebuild it again and trust that
you got the basics right this time?"

If you're an internet professional you are a negligent one if by
now you are not ensuring all you build quietly includes IPv6, no
customer should need to know to ask for it. It's not like it
needs different kit.

> As an aside, I would guess that it's the corporate eyeball customers 
> with servers, not resi/mobile behind CGNAT, that will bear the brunt of 
> the IPv4 cost first.  But what enterprise wants to tell its non-IPv6 
> customers "your Internet needs to be upgraded, come back to us when 
> you're done?"  That doesn't bode well for the short-term future.

"all that multi natted into same address space VPN firewall 
complicated knitting we never got right wasn't needed if you'd
told us to use IPv6?"

brandon

Re: RIPE our of IPv4

[Sabri Berisha]

- On Nov 26, 2019, at 4:16 PM, Ca By cb.li...@gmail.com wrote:

> Sabri volunteered the information that they are an MBA at a large eyeball
> network with 20 teams...

You drew the wrong conclusions. I wrote: "I have some inside knowledge about 
the IPv6 efforts of a large eyeball network". I also have similar knowledge of 
a large worldwide e-commerce enterprise, with similar challenges. 

I've been a JNCIE since 2007 and have worked for 3 different network gear 
vendors in a technical capacity. The MBA (which I earned this year) just helps 
understand the business side of things. I can recommend it to anyone, even if 
you have no aspirations for management roles. 

Thanks,

Sabri,

Re: RIPE our of IPv4

[Brian Knight]

On 2019-11-26 17:11, Ca By wrote:

On Tue, Nov 26, 2019 at 12:15 AM Sabri Berisha 
wrote:

- On Nov 26, 2019, at 1:36 AM, Doug Barton do...@dougbarton.us 
wrote:




[snip]
there is no ROI at this point. In this kind of environment there needs 
to

be a strong case to invest the capex to support IPv6.

IPv6 must be supported on the CxO level in order to be deployed.

Thanks,

Sabri, (Badum tsss) MBA



I seewell let me translate it you MBA-eese for you:

FANG deployed ipv6 nearly 10 years ago. Since deploying ipv6, the 
cohort
experienced 300% CAGR. Also, everything is mobile, and all mobile 
providers

in the usa offer ipv6 by default in most cases. Latency! Scale! As your
company launches its digital transformation iot 2020 virtualization
container initiatives, ipv6 will be an integral part of staying 
relevant on
the blockchain.  Also, FANG did it nearly 10 years ago.  Big content 
and
big eyeballs are on ipv6, ipv4 is a winnowing longtail of irrelevance 
and

iot botnets.


None of which matters a damn to almost all of my business eyeball 
customers.  They can still get from our network to 100% of all Internet 
content & services via IPv4 in 2019.  I regularly vet deals for our 
sales team, and out of the hundreds of deals we sold this year, I can 
count on one hand the number of deals where customers wanted IPv6.  We 
sold them IPv6 access, but we didn't put it on our own network, because 
we face the same internal challenges Sabri mentioned.  (SD-WAN, OTOH, 
was far more popular.  I'll give you three guesses why.  Hint - it's not 
because tunnel technology is awesome and allows us to scale our networks 
further and everyone is doing it.)


Though their participation has been key in making IPv6 more useful for 
eyeballs, content hasn't driven adoption.  The only thing eyeballs care 
about is getting to 100% of what they need and want at minimal cost.  
Until eyeball networks start charging eyeballs for IPv4, IPv4 will 
linger.  The day eyeballs start bitching on forums, opening tickets, 
complaining on Twitter, etc. because they have only IPv6 is when IPv4 
will start to lose relevance.


As an aside, I would guess that it's the corporate eyeball customers 
with servers, not resi/mobile behind CGNAT, that will bear the brunt of 
the IPv4 cost first.  But what enterprise wants to tell its non-IPv6 
customers "your Internet needs to be upgraded, come back to us when 
you're done?"  That doesn't bode well for the short-term future.


-Brian

Re: RIPE our of IPv4

[Mike Hammett]

Telcos looking at the short term is why telcos have largely turned into 
dumpster fires in the last 20 years. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Scott Weeks"  
To: nanog@nanog.org 
Sent: Tuesday, November 26, 2019 6:40:11 PM 
Subject: Re: RIPE our of IPv4 



--- cb.li...@gmail.com wrote: 
From: Ca By  

If your business is dysfunctional, that is a different 
issue from ipv6 being dysfunctional. 
- 


I was just expressing the problems eyeball networks are 
having getting this done. Shittons of stuff is out there 
in the CPE that mobile and DC networks do not have to deal 
with. The suits are looking at the short term cost/risk. 

scott 

Re: RIPE our of IPv4

[Christian]

Speaking as being a trifle self-entitled?


On 27/11/2019 00:35, Scott Weeks wrote:


--- c...@firsthand.net wrote:
From: Christian 

Sounds like your company is about to go offline. So I will
say bye bye for now just in case it happens faster than you
expected.
-


Speaking of flippant...  No the ILEC has been here since the
1800s.  I don't think it's going anywhere fast.

scott

Re: RIPE our of IPv4

[Mark Milhollan]

On Tuesday 2019-11-26 00:13, Sabri Berisha wrote:

Don't get me wrong, I'm not advocating against IPv6 deployment; on the 
contrary. But it is not that simple in the real corporate world. Execs 
have bonus targets. IPv6 is not yet important enough to become part of 
that bonus target: there is no ROI at this point.


Though eyeballs need to change, so does content.  And eyeballs will 
invest if the content were to demand it.  So, perhaps Google will give 
IPv6 hosted content the same tiny boost they gave HTTPS content.



/mark

Re: RIPE our of IPv4

[Mark Andrews]

> On 27 Nov 2019, at 11:40, Scott Weeks  wrote:
> 
> 
> 
> --- cb.li...@gmail.com wrote:
> From: Ca By 
> 
> If your business is dysfunctional, that is a different 
> issue from ipv6 being dysfunctional.
> -
> 
> 
> I was just expressing the problems eyeball networks are 
> having getting this done.  Shittons of stuff is out there 
> in the CPE that mobile and DC networks do not have to deal 
> with.  The suits are looking at the short term cost/risk.
> 
> scott

Eyeball networks can still deliver IPv6 even if most of their
gear isn’t IPv6 ready.  6rd [1] allows you to give every customer
a /48 over a IPv4 access network.  You just need to record the
6rd DHCPv4 Option being returned over time so you can map from
IPv6 address to the IPv4 address your customer was using.

You bill on the IPv4 packets.

This is 10+ years old at this stage and quite frankly just works.
Yes, you need a few BRs and a IPv6 path from them to the rest of
the world.  Lots of ISP’s deliver IPv6 to their customers today
using 6rd.

Lots of CPE routers support 6rd already and if the CPE router doesn’t
there is no harm so no foul.  If you are supplying CPE devices just
replace ones that don’t support 6rd with ones that support 6rd (and
native IPv6) as they break.  If a customer requests a new CPE router
post it to them.  If you aren’t supplying CPE devices just tell your
customers that 6rd is supported.

6rd works with 50 year replacement time frames.

This is really no different to what HE has been doing for the last
20 years, it just moves the encapsulation / decapsulation closer to
the customer.

Mark

[1] https://tools.ietf.org/html/rfc5969
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: RIPE our of IPv4

[Scott Weeks]

--- cb.li...@gmail.com wrote:
From: Ca By 

If your business is dysfunctional, that is a different 
issue from ipv6 being dysfunctional.
-


I was just expressing the problems eyeball networks are 
having getting this done.  Shittons of stuff is out there 
in the CPE that mobile and DC networks do not have to deal 
with.  The suits are looking at the short term cost/risk.

scott

Re: RIPE our of IPv4

[Scott Weeks]

--- c...@firsthand.net wrote:
From: Christian 

Sounds like your company is about to go offline. So I will 
say bye bye for now just in case it happens faster than you 
expected.
-


Speaking of flippant...  No the ILEC has been here since the 
1800s.  I don't think it's going anywhere fast.

scott

Re: RIPE our of IPv4

[Christian]

Sounds like your company is about to go offline. So I will say bye bye 
for now just in case it happens faster than you expected.


C

On 26/11/2019 23:46, Scott Weeks wrote:


Top posting...

-
:: But it is not that simple in the real corporate world.
:: Execs have bonus targets.

Why would an exec care?  Ipv6 is just normal work like ipv4.
-

No, you have to make purchases and have folks across the
company do work to get everything going.  Refocusing folks
work on deploying IPv6 to *everything* (rather than, say,
getting that shiny new Nokia 7750 deployed so we can sell
more services) costs money.  Ancient boxen are out here
and don't support aye pee vee six well or at all.  Getting
ones that do costs money.  Training lower level folks takes
them away from their current work and costs money.  Etc.

::> - Modifying old (ancient) internal code;
:: Ancient in 2019 means what? Is this code not in security
:: compliance ?

I recently started back with a company after being gone nine
years.  My code was still running and no one in neteng had
the knowledge of how to do anything with it much less to try
to write in IPv6 sections.  To take an SA and look into the
networking code I wrote takes them away from things they
need to do to sell services.  That costs money.

What Sabri wrote hit home here.  Folks are not looking into
it and will wait until forced to do so.  Then said companies
will be behind the ball in a big way, but that it what it is
here and in the other companies I worked for.

A lot of this read to me as flippant.  You don't seem to be
willing to listen to those of us out here on the raggedy
edges. I've said what Sabri said at least a few times on this
list.

scott





--- cb.li...@gmail.com wrote:

From: Ca By 
To: Sabri Berisha 
Cc: nanog 
Subject: Re: RIPE our of IPv4
Date: Tue, 26 Nov 2019 15:11:40 -0800

On Tue, Nov 26, 2019 at 12:15 AM Sabri Berisha 
wrote:


- On Nov 26, 2019, at 1:36 AM, Doug Barton do...@dougbarton.us wrote:


I get that some people still don't like it, but the answer is IPv6. Or,
folks can keep playing NAT games, etc. But one wonders at what point
rolling out IPv6 costs less than all the fun you get with [CG]NAT.

When the MBAs start realizing the risk of not deploying it.


Hey, i have an mba. That and $5 will get me cup of coffee.



I have some inside knowledge about the IPv6 efforts of a large eyeball
network.


Me too.

In that particular case, the cost of deploying IPv6 internally is not

simply configuring it on the network gear; that has already been done. The
cost of fully supporting IPv6 includes (but is probably not limited to):

- Support for deploying IPv6 across more than 20 different teams;


Wow.  I support 80M mobile subscribers, 90% of which are ipv6-only.  I
think 20 people in the company can spell ipv6, but somehow you need 20
teams how many teams speak ipv4 ?



- Modifying old (ancient) internal code;


Ancient in 2019 means what? Is this code not in security compliance ?



- Modifying old (ancient) database structures (think 16 character fields
for IP addresses);


Hash 128 bits into 240/4 is how i heard Google handled it early on



- Upgrading/replacing load balancers and other legacy crap that only
support IPv4 (yeah, they still exist);


Again, with all the CVEs, this code is always moving in the real world.



- Modifying the countless home-grown tools that automate firewalls etc;


Home grown means it can be fixed instead of replaced.



- Auditing the PCI infrastructure to ensure it is still compliant after
deploying IPv6;


Ah, so you are keeping up with compliance / cve and are upgrading at
regular intervals?




If it was as simple as upgrading a few IP stacks here and there, it would
be a non-issue.


Usually is just a few edge stacks to start and scale the edge



Don't get me wrong, I'm not advocating against IPv6 deployment; on the
contrary. But it is not that simple in the real corporate world. Execs have
bonus targets.


Why would an exec care?  Ipv6 is just normal work like ipv4.

IPv6 is not yet important enough to become part of that bonus target:


The bonus target was normal business continuity planning... in 2008.  Sorry
you missed that one.  Here you go, just put 1 in 2009 to make it 2019 so
you dont look so bad

https://www.arin.net/vault/knowledge/about_resources/ceo_letter.pdf


there is no ROI at this point. In this kind of environment there needs to

be a strong case to invest the capex to support IPv6.

IPv6 must be supported on the CxO level in order to be deployed.

Thanks,

Sabri, (Badum tsss) MBA


I seewell let me translate it you MBA-eese for you:

FANG deployed ipv6 nearly 10 years ago. Since deploying ipv6, the cohort
experienced 300% CAGR. Also, everything is mobile, and all mobile providers
in the usa offer ipv6 by default in most cases. Latency! Scale! As your
company launches its digital transformation iot 2020 virtualizat

RE: RIPE our of IPv4

[Michel Py]

> Scott Weeks wrote :
> A lot of this read to me as flippant.  You don't seem to be willing to listen 
> to those of us out here on the raggedy edges.

And there are lots of us.

> I've said what Sabri said at least a few times on this  list.

+1

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

Re: RIPE our of IPv4

[Mark Andrews]

> On 27 Nov 2019, at 10:58, Sabri Berisha  wrote:
> 
> - On Nov 26, 2019, at 7:59 AM, Willy Manga mangawi...@gmail.com wrote:
> 
> Hi,
> 
>> I would have said the very very minimum could be to invest in a
>> dual-stack 'proxy' for public-facing services; internal or external
>> solution, you have the choice.
>> 
>> And why even do that ? Because the other side is not only on IPv4.
> 
> Using a dual-stack proxy is not always an option. Source IP information may 
> be needed on the app level for risk analysis, OFAC compliance, and copyright 
> purposes. For example, Paypal will definitely use IP address information in 
> its fraud risk analysis.

And existing proxies don’t already pass through the connecting IP address?  
There are even header fields that are dedicated for this purpose [1].

Most web sites could be dual stacked today with zero issues.  Web site analytic 
tools already deal with IPv6 and have for years.

> That said, there are of course ways to do that while using a proxy. However, 
> that will now require some for of development. Dev time better used to 
> properly implement v6.

And the difference in time between reading the address from X-Forwarded-For: vs 
directly is negligible. 

> Unfortunately, I've been part of way to many discussions where the only thing 
> a beancounter wants to know is: what is the short term effect of not doing it?
> 
> Short term exec bonuses, short term decisions.
> 
> Thanks,
> 
> Sabri


[1] https://en.wikipedia.org/wiki/X-Forwarded-For
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: RIPE our of IPv4

[Ca By]

On Tue, Nov 26, 2019 at 3:47 PM Scott Weeks  wrote:

>
>
> Top posting...
>
> -
> :: But it is not that simple in the real corporate world.
> :: Execs have bonus targets.
>
> Why would an exec care?  Ipv6 is just normal work like ipv4.
> -
>
> No, you have to make purchases and have folks across the
> company do work to get everything going.  Refocusing folks
> work on deploying IPv6 to *everything* (rather than, say,
> getting that shiny new Nokia 7750 deployed so we can sell
> more services) costs money.  Ancient boxen are out here
> and don't support aye pee vee six well or at all.  Getting
> ones that do costs money.  Training lower level folks takes
> them away from their current work and costs money.  Etc.
>

This is known as “too hungry to eat” or something similar about failing to
help yourself

https://www.google.com/amp/s/amp.businessinsider.com/marc-andreessen-advice-to-startups-raise-prices-2016-6



> ::> - Modifying old (ancient) internal code;
> :: Ancient in 2019 means what? Is this code not in security
> :: compliance ?
>
> I recently started back with a company after being gone nine
> years.  My code was still running and no one in neteng had
> the knowledge of how to do anything with it much less to try
> to write in IPv6 sections.  To take an SA and look into the
> networking code I wrote takes them away from things they
> need to do to sell services.  That costs money.
>
> What Sabri wrote hit home here.  Folks are not looking into
> it and will wait until forced to do so.  Then said companies
> will be behind the ball in a big way, but that it what it is
> here and in the other companies I worked for.
>

We agree, neglecting ipv6 is a bad business decision


> A lot of this read to me as flippant.  You don't seem to be
> willing to listen to those of us out here on the raggedy
> edges. I've said what Sabri said at least a few times on this
> list.
>

Sabri volunteered the information that they are an MBA at a large eyeball
network with 20 teams... , not the “raggedy edge”, they said something
about executive bonus alignment being the key problem

That said, speaking of not being listened too, this artifact is useful as
it squarely raises the business risk in no uncertain terms.

https://www.arin.net/vault/knowledge/about_resources/ceo_letter.pdf

Business risk is mitigated or accepted ... for the last 10 years.  Folks /
orgs make decisions and deal with the consequence.

My reality is that, at scale, ipv4 is winnowing longtail. The majority of
real bits/s and dollars are in ipv6. Ymmv. But i reject vehemently the
notion that v6 vanity project with no obvious business case / roi (Another
misstatement by Sabri).

If your business is dysfunctional, that is a different issue from ipv6
being dysfunctional.


> scott
>
>
>
>
>
> --- cb.li...@gmail.com wrote:
>
> From: Ca By 
> To: Sabri Berisha 
> Cc: nanog 
> Subject: Re: RIPE our of IPv4
> Date: Tue, 26 Nov 2019 15:11:40 -0800
>
> On Tue, Nov 26, 2019 at 12:15 AM Sabri Berisha 
> wrote:
>
> > - On Nov 26, 2019, at 1:36 AM, Doug Barton do...@dougbarton.us
> wrote:
> >
> > > I get that some people still don't like it, but the answer is IPv6. Or,
> > > folks can keep playing NAT games, etc. But one wonders at what point
> > > rolling out IPv6 costs less than all the fun you get with [CG]NAT.
> >
> > When the MBAs start realizing the risk of not deploying it.
> >
>
> Hey, i have an mba. That and $5 will get me cup of coffee.
>
>
> > I have some inside knowledge about the IPv6 efforts of a large eyeball
> > network.
>
>
> Me too.
>
> In that particular case, the cost of deploying IPv6 internally is not
> > simply configuring it on the network gear; that has already been done.
> The
> > cost of fully supporting IPv6 includes (but is probably not limited to):
> >
> > - Support for deploying IPv6 across more than 20 different teams;
>
>
> Wow.  I support 80M mobile subscribers, 90% of which are ipv6-only.  I
> think 20 people in the company can spell ipv6, but somehow you need 20
> teams how many teams speak ipv4 ?
>
>
> > - Modifying old (ancient) internal code;
>
>
> Ancient in 2019 means what? Is this code not in security compliance ?
>
>
> > - Modifying old (ancient) database structures (think 16 character fields
> > for IP addresses);
>
>
> Hash 128 bits into 240/4 is how i heard Google handled it early on
>
>
> > - Upgrading/replacing load balancers and other legacy crap that only
> > support IPv4 (yeah, they still exist);
>
>
> Again, with all the CVEs, this code is always 

Re: RIPE our of IPv4

[Sabri Berisha]

- On Nov 26, 2019, at 7:59 AM, Willy Manga mangawi...@gmail.com wrote:

Hi,

> I would have said the very very minimum could be to invest in a
> dual-stack 'proxy' for public-facing services; internal or external
> solution, you have the choice.
> 
> And why even do that ? Because the other side is not only on IPv4.

Using a dual-stack proxy is not always an option. Source IP information may be 
needed on the app level for risk analysis, OFAC compliance, and copyright 
purposes. For example, Paypal will definitely use IP address information in its 
fraud risk analysis.

That said, there are of course ways to do that while using a proxy. However, 
that will now require some for of development. Dev time better used to properly 
implement v6.

Unfortunately, I've been part of way to many discussions where the only thing a 
beancounter wants to know is: what is the short term effect of not doing it?

Short term exec bonuses, short term decisions.

Thanks,

Sabri

Re: RIPE our of IPv4

[Matt Palmer]

On Tue, Nov 26, 2019 at 05:26:44PM -0500, b...@theworld.com wrote:
> If the commitment really was to spread IPv6 far and wide IPv6 blocks
> would be handed out for free, one per qualified customer (e.g., if you
> have an IPv4 allocation you get one IPv6 block free), or perhaps some
> trivial administrative fee like $10 per year.

It has been some time since I had to deal with RIRs directly, but my
understanding was that if you had an IPv4 allocation, you got a reasonably
sized chunk of IPv6 alongside for free.  Not even an extra $10/year.  FREE!

Looking at ARIN's fee schedule
(https://www.arin.net/resources/fees/fee_schedule/), it does seem like that
is still the case:

> For organizations holding both ARIN-issued IPv4 and IPv6 allocations, the
> fee is based on the larger of the two service categories.

So you only need to pay extra for your IPv6 numbers if you've got a lot more
of them than you've got IPv4.  The only situation in which I could imagine
that happening is if you were a (very) late-start eyeball network that had a
tiny IPv4 allocation (and a *lot* of CGNAT), but were planning on handing
out IPv6 /48s to every customer.

- Matt

Re: RIPE our of IPv4

[Scott Weeks]

Top posting...

-
:: But it is not that simple in the real corporate world. 
:: Execs have bonus targets.

Why would an exec care?  Ipv6 is just normal work like ipv4.
-

No, you have to make purchases and have folks across the 
company do work to get everything going.  Refocusing folks 
work on deploying IPv6 to *everything* (rather than, say, 
getting that shiny new Nokia 7750 deployed so we can sell 
more services) costs money.  Ancient boxen are out here 
and don't support aye pee vee six well or at all.  Getting 
ones that do costs money.  Training lower level folks takes 
them away from their current work and costs money.  Etc.

::> - Modifying old (ancient) internal code;
:: Ancient in 2019 means what? Is this code not in security 
:: compliance ?

I recently started back with a company after being gone nine 
years.  My code was still running and no one in neteng had 
the knowledge of how to do anything with it much less to try 
to write in IPv6 sections.  To take an SA and look into the 
networking code I wrote takes them away from things they
need to do to sell services.  That costs money.

What Sabri wrote hit home here.  Folks are not looking into 
it and will wait until forced to do so.  Then said companies 
will be behind the ball in a big way, but that it what it is 
here and in the other companies I worked for.

A lot of this read to me as flippant.  You don't seem to be 
willing to listen to those of us out here on the raggedy 
edges. I've said what Sabri said at least a few times on this 
list.

scott





--- cb.li...@gmail.com wrote:

From: Ca By 
To: Sabri Berisha 
Cc: nanog 
Subject: Re: RIPE our of IPv4
Date: Tue, 26 Nov 2019 15:11:40 -0800

On Tue, Nov 26, 2019 at 12:15 AM Sabri Berisha 
wrote:

> - On Nov 26, 2019, at 1:36 AM, Doug Barton do...@dougbarton.us wrote:
>
> > I get that some people still don't like it, but the answer is IPv6. Or,
> > folks can keep playing NAT games, etc. But one wonders at what point
> > rolling out IPv6 costs less than all the fun you get with [CG]NAT.
>
> When the MBAs start realizing the risk of not deploying it.
>

Hey, i have an mba. That and $5 will get me cup of coffee.


> I have some inside knowledge about the IPv6 efforts of a large eyeball
> network.


Me too.

In that particular case, the cost of deploying IPv6 internally is not
> simply configuring it on the network gear; that has already been done. The
> cost of fully supporting IPv6 includes (but is probably not limited to):
>
> - Support for deploying IPv6 across more than 20 different teams;


Wow.  I support 80M mobile subscribers, 90% of which are ipv6-only.  I
think 20 people in the company can spell ipv6, but somehow you need 20
teams how many teams speak ipv4 ?


> - Modifying old (ancient) internal code;


Ancient in 2019 means what? Is this code not in security compliance ?


> - Modifying old (ancient) database structures (think 16 character fields
> for IP addresses);


Hash 128 bits into 240/4 is how i heard Google handled it early on


> - Upgrading/replacing load balancers and other legacy crap that only
> support IPv4 (yeah, they still exist);


Again, with all the CVEs, this code is always moving in the real world.


> - Modifying the countless home-grown tools that automate firewalls etc;


Home grown means it can be fixed instead of replaced.


> - Auditing the PCI infrastructure to ensure it is still compliant after
> deploying IPv6;
>

Ah, so you are keeping up with compliance / cve and are upgrading at
regular intervals?



> If it was as simple as upgrading a few IP stacks here and there, it would
> be a non-issue.
>

Usually is just a few edge stacks to start and scale the edge


> Don't get me wrong, I'm not advocating against IPv6 deployment; on the
> contrary. But it is not that simple in the real corporate world. Execs have
> bonus targets.


Why would an exec care?  Ipv6 is just normal work like ipv4.

IPv6 is not yet important enough to become part of that bonus target:


The bonus target was normal business continuity planning... in 2008.  Sorry
you missed that one.  Here you go, just put 1 in 2009 to make it 2019 so
you dont look so bad

https://www.arin.net/vault/knowledge/about_resources/ceo_letter.pdf


there is no ROI at this point. In this kind of environment there needs to
> be a strong case to invest the capex to support IPv6.
>
> IPv6 must be supported on the CxO level in order to be deployed.
>
> Thanks,
>
> Sabri, (Badum tsss) MBA


I seewell let me translate it you MBA-eese for you:

FANG deployed ipv6 nearly 10 years ago. Since deploying ipv6, the cohort
experienced 300% CAGR. Also, everything is mobile, and all mobile providers
in the usa offer ipv6 by default in most cases. Latency! Scale! As your
company launches its digital transformation iot 202

Re: RIPE our of IPv4

[Ca By]

On Tue, Nov 26, 2019 at 12:15 AM Sabri Berisha 
wrote:

> - On Nov 26, 2019, at 1:36 AM, Doug Barton do...@dougbarton.us wrote:
>
> > I get that some people still don't like it, but the answer is IPv6. Or,
> > folks can keep playing NAT games, etc. But one wonders at what point
> > rolling out IPv6 costs less than all the fun you get with [CG]NAT.
>
> When the MBAs start realizing the risk of not deploying it.
>

Hey, i have an mba. That and $5 will get me cup of coffee.


> I have some inside knowledge about the IPv6 efforts of a large eyeball
> network.


Me too.

In that particular case, the cost of deploying IPv6 internally is not
> simply configuring it on the network gear; that has already been done. The
> cost of fully supporting IPv6 includes (but is probably not limited to):
>
> - Support for deploying IPv6 across more than 20 different teams;


Wow.  I support 80M mobile subscribers, 90% of which are ipv6-only.  I
think 20 people in the company can spell ipv6, but somehow you need 20
teams how many teams speak ipv4 ?


> - Modifying old (ancient) internal code;


Ancient in 2019 means what? Is this code not in security compliance ?


> - Modifying old (ancient) database structures (think 16 character fields
> for IP addresses);


Hash 128 bits into 240/4 is how i heard Google handled it early on


> - Upgrading/replacing load balancers and other legacy crap that only
> support IPv4 (yeah, they still exist);


Again, with all the CVEs, this code is always moving in the real world.


> - Modifying the countless home-grown tools that automate firewalls etc;


Home grown means it can be fixed instead of replaced.


> - Auditing the PCI infrastructure to ensure it is still compliant after
> deploying IPv6;
>

Ah, so you are keeping up with compliance / cve and are upgrading at
regular intervals?



> If it was as simple as upgrading a few IP stacks here and there, it would
> be a non-issue.
>

Usually is just a few edge stacks to start and scale the edge


> Don't get me wrong, I'm not advocating against IPv6 deployment; on the
> contrary. But it is not that simple in the real corporate world. Execs have
> bonus targets.


Why would an exec care?  Ipv6 is just normal work like ipv4.

IPv6 is not yet important enough to become part of that bonus target:


The bonus target was normal business continuity planning... in 2008.  Sorry
you missed that one.  Here you go, just put 1 in 2009 to make it 2019 so
you dont look so bad

https://www.arin.net/vault/knowledge/about_resources/ceo_letter.pdf


there is no ROI at this point. In this kind of environment there needs to
> be a strong case to invest the capex to support IPv6.
>
> IPv6 must be supported on the CxO level in order to be deployed.
>
> Thanks,
>
> Sabri, (Badum tsss) MBA


I seewell let me translate it you MBA-eese for you:

FANG deployed ipv6 nearly 10 years ago. Since deploying ipv6, the cohort
experienced 300% CAGR. Also, everything is mobile, and all mobile providers
in the usa offer ipv6 by default in most cases. Latency! Scale! As your
company launches its digital transformation iot 2020 virtualization
container initiatives, ipv6 will be an integral part of staying relevant on
the blockchain.  Also, FANG did it nearly 10 years ago.  Big content and
big eyeballs are on ipv6, ipv4 is a winnowing longtail of irrelevance and
iot botnets.


>

Re: RIPE our of IPv4

[bzs]

If the commitment really was to spread IPv6 far and wide IPv6 blocks
would be handed out for free, one per qualified customer (e.g., if you
have an IPv4 allocation you get one IPv6 block free), or perhaps some
trivial administrative fee like $10 per year.

But the RIRs can't live on that.

We have put them under the management of a group of five organizations
which are very dependent on the income from block allocations and no
doubt were hoping IPv6 allocations would be a boon since there will be
very little if any income growth from future IPv4 block allocations.

Worse, once acquired an IPv6 block has so many billions of addresses
very few if any would ever need another allocation so it would hardly
act as a loss leader.

I realize many still would not deploy IPv6 for various reasons such as
their equipment doesn't support it or they don't have the in-house
expertise to support it, etc tho I can't think of much other etc, a
few points of resistance do come up.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: RIPE our of IPv4

[Willy Manga]

Hello,

On 26/11/2019 16:00, nanog-requ...@nanog.org wrote:
> Date: Tue, 26 Nov 2019 00:13:48 -0800 (PST)
> From: Sabri Berisha 
> To: Doug Barton 
> Cc: nanog 
> Subject: Re: RIPE our of IPv4
> Message-ID:
>   <1383247942.183700.1574756028904.javamail.zim...@cluecentral.net>
> Content-Type: text/plain; charset=utf-8
> 
> - On Nov 26, 2019, at 1:36 AM, Doug Barton do...@dougbarton.us wrote:
> 
>> I get that some people still don't like it, but the answer is IPv6. Or,
>> folks can keep playing NAT games, etc. But one wonders at what point
>> rolling out IPv6 costs less than all the fun you get with [CG]NAT.
> When the MBAs start realizing the risk of not deploying it.
> 
> I have some inside knowledge about the IPv6 efforts of a large eyeball 
> network. In that particular case, the cost of deploying IPv6 internally is 
> not simply configuring it on the network gear; that has already been done. 
> The cost of fully supporting IPv6 includes (but is probably not limited to):
> 
> - Support for deploying IPv6 across more than 20 different teams;
> - Modifying old (ancient) internal code;
> - Modifying old (ancient) database structures (think 16 character fields for 
> IP addresses);
> - Upgrading/replacing load balancers and other legacy crap that only support 
> IPv4 (yeah, they still exist);
> - Modifying the countless home-grown tools that automate firewalls etc;
> - Auditing the PCI infrastructure to ensure it is still compliant after 
> deploying IPv6;
> 
> If it was as simple as upgrading a few IP stacks here and there, it would be 
> a non-issue.

No matter how complex is your network (and your teams), from my humble
point of view, there is always something you can do regarding IPv6. The
key is not to solve one million problems on one day. The key is to go
gradually, one small block after another one.
You can even keep all your internal network on v4 (forever if that is
your intent ) and use IPv6 on specific portions of your network.


> Don't get me wrong, I'm not advocating against IPv6 deployment; on the 
> contrary. But it is not that simple in the real corporate world. Execs have 
> bonus targets. IPv6 is not yet important enough to become part of that bonus 
> target: there is no ROI at this point. In this kind of environment there 
> needs to be a strong case to invest the capex to support IPv6.
> 
> IPv6 must be supported on the CxO level in order to be deployed. 


I would have said the very very minimum could be to invest in a
dual-stack 'proxy' for public-facing services; internal or external
solution, you have the choice.

And why even do that ? Because the other side is not only on IPv4.


-- 
Willy Manga
@ongolaboy
https://ongola.blogspot.com/



signature.asc
Description: OpenPGP digital signature

Re: RIPE our of IPv4

[Sabri Berisha]

- On Nov 26, 2019, at 1:36 AM, Doug Barton do...@dougbarton.us wrote:

> I get that some people still don't like it, but the answer is IPv6. Or,
> folks can keep playing NAT games, etc. But one wonders at what point
> rolling out IPv6 costs less than all the fun you get with [CG]NAT.

When the MBAs start realizing the risk of not deploying it.

I have some inside knowledge about the IPv6 efforts of a large eyeball network. 
In that particular case, the cost of deploying IPv6 internally is not simply 
configuring it on the network gear; that has already been done. The cost of 
fully supporting IPv6 includes (but is probably not limited to):

- Support for deploying IPv6 across more than 20 different teams;
- Modifying old (ancient) internal code;
- Modifying old (ancient) database structures (think 16 character fields for IP 
addresses);
- Upgrading/replacing load balancers and other legacy crap that only support 
IPv4 (yeah, they still exist);
- Modifying the countless home-grown tools that automate firewalls etc;
- Auditing the PCI infrastructure to ensure it is still compliant after 
deploying IPv6;

If it was as simple as upgrading a few IP stacks here and there, it would be a 
non-issue.

Don't get me wrong, I'm not advocating against IPv6 deployment; on the 
contrary. But it is not that simple in the real corporate world. Execs have 
bonus targets. IPv6 is not yet important enough to become part of that bonus 
target: there is no ROI at this point. In this kind of environment there needs 
to be a strong case to invest the capex to support IPv6.

IPv6 must be supported on the CxO level in order to be deployed. 

Thanks,

Sabri, (Badum tsss) MBA

Re: RIPE our of IPv4

[Doug Barton]

On 2019-11-25 20:26, Brandon Martin wrote:

On 11/26/19 4:36 AM, Doug Barton wrote:
I get that some people still don't like it, but the answer is IPv6. 
Or, folks can keep playing NAT games, etc. But one wonders at what 
point 
rolling out IPv6 costs less than all the fun you get with [CG]NAT.


If it weren't for the ongoing need to continue to support IPv4
reachability (i.e. if we'd flag-day'd several years ago), I think the
(admittedly non-scientific) answer to that question is that we have
already passed it.

However, in the face of continuing need for IPv4 reachability, I'm
less sure.  I think that the incremental cost to deploy and support
IPv6 is probably no more than the incremental savings of CGNAT
headaches for service providers caused by offloading what traffic you
can to native IPv6.  Those savings from not just from capacity savings
(which can be extreme to totally trivial depending on your size) but
also support for having 3rd party services properly treat an SP
customer as an individual customer rather than the results of multiple
SP customers being lumped onto a small CGNAT target pool.

That is, even if you are 100% committed to needing to run a functional
CGNAT as a service provider and deal with everything that entails, I
think it's probably STILL in your short-term economic best interest to
deploy IPv6 simply due to the reduction in scope of "everything that
entails".


I think this is spot on. The only thing I'd add is that the costs to 
deploy IPv6 will remain fairly constant or perhaps go down some over 
time as economies of scale continue to grow, whereas the costs for 
continuing to prop up IPv4 will only increase.


Doug

Re: RIPE our of IPv4

[Brandon Martin]

On 11/26/19 4:36 AM, Doug Barton wrote:
I get that some people still don't like it, but the answer is IPv6. Or, 
folks can keep playing NAT games, etc. But one wonders at what point 
rolling out IPv6 costs less than all the fun you get with [CG]NAT.


If it weren't for the ongoing need to continue to support IPv4 
reachability (i.e. if we'd flag-day'd several years ago), I think the 
(admittedly non-scientific) answer to that question is that we have 
already passed it.


However, in the face of continuing need for IPv4 reachability, I'm less 
sure.  I think that the incremental cost to deploy and support IPv6 is 
probably no more than the incremental savings of CGNAT headaches for 
service providers caused by offloading what traffic you can to native 
IPv6.  Those savings from not just from capacity savings (which can be 
extreme to totally trivial depending on your size) but also support for 
having 3rd party services properly treat an SP customer as an individual 
customer rather than the results of multiple SP customers being lumped 
onto a small CGNAT target pool.


That is, even if you are 100% committed to needing to run a functional 
CGNAT as a service provider and deal with everything that entails, I 
think it's probably STILL in your short-term economic best interest to 
deploy IPv6 simply due to the reduction in scope of "everything that 
entails".

--
Brandon Martin

Re: RIPE our of IPv4

[Doug Barton]

On 2019-11-25 1:47 PM, Valdis Klētnieks wrote:

On Tue, 26 Nov 2019 06:46:52 +1100, Mark Andrews said:

On 26 Nov 2019, at 03:53, Dmitry Sherman  wrote:

 I believe it’s Eyeball network’s matter to free IPv4 blocks and move to 
v6.



It requires both sides to move to IPv6.  Why should the cost of maintaining
working networks be borne alone by the eyeball networks?   That is what is
mostly happening today with CGN.


I believe that Dmitry's point is that we will still require IPv4 addresses for 
new
organizations deploying dual-stack


Right, which is why we started warning folks about this issue 10+ years 
ago, when IPv4 was still plentiful and cheap.


But even content networks have NAT options, and while most of them are 
not pretty, the options become more limited every day that passes.


I get that some people still don't like it, but the answer is IPv6. Or, 
folks can keep playing NAT games, etc. But one wonders at what point 
rolling out IPv6 costs less than all the fun you get with [CG]NAT.


Doug

Re: RIPE our of IPv4

[Mike Hammett]

Most eyeball networks (by organization count) don't have a /16 in the first 
place, much less one to give. 


Obviously something like 90% of the population is in the top 10 providers and 
the rest of the population is in the other several thousand providers. 


(Numbers are out of thin air, but illustrate the point.) 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Valdis Klētnieks"  
To: "Mark Andrews"  
Cc: "Aaron C. de Bruyn" , "NANOG mailing list" 
 
Sent: Monday, November 25, 2019 3:47:37 PM 
Subject: Re: RIPE our of IPv4 

On Tue, 26 Nov 2019 06:46:52 +1100, Mark Andrews said: 
> > On 26 Nov 2019, at 03:53, Dmitry Sherman  wrote: 
> > 
> > ��� I believe it���s Eyeball network���s matter to free IPv4 blocks and 
> > move to v6. 

> It requires both sides to move to IPv6. Why should the cost of maintaining 
> working networks be borne alone by the eyeball networks? That is what is 
> mostly happening today with CGN. 

I believe that Dmitry's point is that we will still require IPv4 addresses for 
new 
organizations deploying dual-stack, and eyeball networks can more easily 
move a /16 or even bigger to mostly IPv6 and a small CGNAT address space 
than content providers can free up IPv4 addresses during the time that dual 
stack is still needed. 

Re: RIPE our of IPv4

[Valdis Klētnieks]

On Tue, 26 Nov 2019 06:46:52 +1100, Mark Andrews said:
> > On 26 Nov 2019, at 03:53, Dmitry Sherman  wrote:
> >
> >  I believe it’s Eyeball network’s matter to free IPv4 blocks and 
> > move to v6.

> It requires both sides to move to IPv6.  Why should the cost of maintaining
> working networks be borne alone by the eyeball networks?   That is what is
> mostly happening today with CGN.

I believe that Dmitry's point is that we will still require IPv4 addresses for 
new
organizations deploying dual-stack, and eyeball networks can more easily
move a /16 or even bigger to mostly IPv6 and a small CGNAT address space
than content providers can free up IPv4 addresses during the time that dual
stack is still needed.


pgpJWJYbH090t.pgp
Description: PGP signature

Re: RIPE our of IPv4

[Doug Barton]

The two things feed each other. Big content networks have had IPv6 for 
years now, and the mobile phone networks are primarily, if not 
exclusively IPv6 on the inside.


Adding IPv6 now helps push the cycle forward, whether you are an 
eyeball, content, or other network.


Doug


On 11/25/19 11:50 AM, Dmitry Sherman wrote:
Because we can’t only use ipv6 on the boxes, each box with ipv6 must 
have IPv4 until the last eyeball broadband user will have ipv6 support.


Best regards,
Dmitry Sherman
Interhost Networks
www.interhost.co.il
dmi...@interhost.net
Mob: 054-3181182
Sent from Steve's creature


On 25 Nov 2019, at 21:47, Mark Andrews  wrote:

 It requires both sides to move to IPv6.  Why should the cost of 
maintaining working networks be borne alone by the eyeball networks?   
That is what is mostly happening today with CGN.


Every server that offers services to the public should be making them 
available over IPv6.   Most of the CDNs support both transports. Why 
are you scared to tick the box for IPv6?  HTTPS doesn’t care which 
transport is used.


--
Mark Andrews


On 26 Nov 2019, at 03:53, Dmitry Sherman  wrote:

 I believe it’s Eyeball network’s matter to free IPv4 blocks and 
move to v6.



Best regards,
Dmitry Sherman



On 25 Nov 2019, at 18:08, Billy Crook  wrote:


Huh.  I guess we get to go home early today then?  And look into 
that whole "Aye Pee Vee Sicks" thing next week aye boss?


On Mon, Nov 25, 2019 at 8:58 AM Dmitry Sherman > wrote:


Just received a mail that RIPE is out of IPv4:

Dear colleagues,

Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22
IPv4 allocation from the last remaining addresses in our
available pool. We have now run out of IPv4 addresses.


Best regards,
Dmitry Sherman
Interhost Networks
www.interhost.co.il 
dmi...@interhost.net 
Mob: 054-3181182
Sent from Steve's creature

Re: RIPE our of IPv4

[Dmitry Sherman]

Because we can’t only use ipv6 on the boxes, each box with ipv6 must have IPv4 
until the last eyeball broadband user will have ipv6 support.

Best regards,
Dmitry Sherman
Interhost Networks
www.interhost.co.il
dmi...@interhost.net
Mob: 054-3181182
Sent from Steve's creature
[X]

On 25 Nov 2019, at 21:47, Mark Andrews  wrote:

 It requires both sides to move to IPv6.  Why should the cost of maintaining 
working networks be borne alone by the eyeball networks?   That is what is 
mostly happening today with CGN.

Every server that offers services to the public should be making them available 
over IPv6.   Most of the CDNs support both transports. Why are you scared to 
tick the box for IPv6?  HTTPS doesn’t care which transport is used.

--
Mark Andrews

On 26 Nov 2019, at 03:53, Dmitry Sherman  wrote:

 I believe it’s Eyeball network’s matter to free IPv4 blocks and move to v6.


Best regards,
Dmitry Sherman

[X]

On 25 Nov 2019, at 18:08, Billy Crook  wrote:


Huh.  I guess we get to go home early today then?  And look into that whole 
"Aye Pee Vee Sicks" thing next week aye boss?

On Mon, Nov 25, 2019 at 8:58 AM Dmitry Sherman 
mailto:dmi...@interhost.net>> wrote:
Just received a mail that RIPE is out of IPv4:

Dear colleagues,

Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 
allocation from the last remaining addresses in our available pool. We have now 
run out of IPv4 addresses.


Best regards,
Dmitry Sherman
Interhost Networks
www.interhost.co.il
dmi...@interhost.net
Mob: 054-3181182
Sent from Steve's creature
[X]

Re: RIPE our of IPv4

[Mark Andrews]

It requires both sides to move to IPv6.  Why should the cost of maintaining 
working networks be borne alone by the eyeball networks?   That is what is 
mostly happening today with CGN.

Every server that offers services to the public should be making them available 
over IPv6.   Most of the CDNs support both transports. Why are you scared to 
tick the box for IPv6?  HTTPS doesn’t care which transport is used. 

-- 
Mark Andrews

> On 26 Nov 2019, at 03:53, Dmitry Sherman  wrote:
> 
>  I believe it’s Eyeball network’s matter to free IPv4 blocks and move to v6.
> 
> 
> Best regards,
> Dmitry Sherman
> 
> 
> 
>>> On 25 Nov 2019, at 18:08, Billy Crook  wrote:
>>> 
>> 
>> Huh.  I guess we get to go home early today then?  And look into that whole 
>> "Aye Pee Vee Sicks" thing next week aye boss?
>> 
>>> On Mon, Nov 25, 2019 at 8:58 AM Dmitry Sherman  wrote:
>>> Just received a mail that RIPE is out of IPv4:
>>> 
>>> Dear colleagues,
>>> 
>>> Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 
>>> allocation from the last remaining addresses in our available pool. We have 
>>> now run out of IPv4 addresses.
>>> 
>>> 
>>> Best regards,
>>> Dmitry Sherman
>>> Interhost Networks
>>> www.interhost.co.il
>>> dmi...@interhost.net
>>> Mob: 054-3181182
>>> Sent from Steve's creature 

Re: RIPE our of IPv4

[Mark Andrews]

But IPv4 is ripe.  You have just become accustomed to the stench of NAT that 
you don’t realise it. 

-- 
Mark Andrews

> On 26 Nov 2019, at 05:31, Jeff Shultz  wrote:
> 
> Hard to say that something that is in full implementation and use is dead.
> 
>> On Mon, Nov 25, 2019 at 9:21 AM Owen DeLong  wrote:
>> 
>> RIPE isn’t dead… Just IPv4.
>> 
>> Owen
>> 
>> 
>>>> On Nov 25, 2019, at 08:03 , Ryland Kremeier  
>>>> wrote:
>>> 
>>> RIP RIPE
>>> 
>>> 
>>> -Original Message-
>>> From: NANOG  On Behalf Of Andy Ringsmuth
>>> Sent: Monday, November 25, 2019 9:58 AM
>>> To: NANOG mailing list 
>>> Subject: Re: RIPE our of IPv4
>>> 
>>> 
>>> 
>>>> On Nov 25, 2019, at 8:56 AM, Dmitry Sherman  wrote:
>>>> 
>>>> Just received a mail that RIPE is out of IPv4:
>>>> 
>>>> Dear colleagues,
>>>> 
>>>> Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 
>>>> allocation from the last remaining addresses in our available pool. We 
>>>> have now run out of IPv4 addresses.
>>> 
>>> Does this mean we are finally ripe for widespread IPv6 adoption?
>>> 
>>> (Admit it, someone had to say it!)
>>> 
>>> 
>>> Andy Ringsmuth
>>> 5609 Harding Drive
>>> Lincoln, NE 68521-5831
>>> (402) 304-0083
>>> a...@andyring.com
>> 
> 
> 
> -- 
> Jeff Shultz
> 
> -- 
> Like us on Social Media for News, Promotions, and other information!!
> 
>
> <https://www.facebook.com/SCTCWEB/>  
> <https://www.instagram.com/sctc_503/>  
> <https://www.yelp.com/biz/sctc-stayton-3>  
> <https://www.youtube.com/c/sctcvideos>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _ This message 
> contains confidential information and is intended only for the individual 
> named. If you are not the named addressee you should not disseminate, 
> distribute or copy this e-mail. Please notify the sender immediately by 
> e-mail if you have received this e-mail by mistake and delete this e-mail 
> from your system. E-mail transmission cannot be guaranteed to be secure or 
> error-free as information could be intercepted, corrupted, lost, destroyed, 
> arrive late or incomplete, or contain viruses. The sender therefore does 
> not accept liability for any errors or omissions in the contents of this 
> message, which arise as a result of e-mail transmission. _
> 

Re: RIPE our of IPv4

[Scott Weeks]

> RIPE isn’t dead… Just IPv4.



--- jeffshu...@sctcweb.com wrote:
From: Jeff Shultz 

Hard to say that something that is in full implementation 
and use is dead.
---


Ok...  In the process of dying a slow, painful, agonizing, 
brutal, sickening, won't-just-up-and-friggin-die-already 
death.  Does that work? :)

scott

RE: RIPE our of IPv4

[Nicholas Warren]

I think the context was referring to RIPE's v4 space being dead.

> 
> Hard to say that something that is in full implementation and use is dead.
> 
> >
> > RIPE isn’t dead… Just IPv4.
> >
> > Owen
> >
> > >
> > > RIP RIPE
> > >>
> > >> Just received a mail that RIPE is out of IPv4:

Re: RIPE our of IPv4

[Jeff Shultz]

Hard to say that something that is in full implementation and use is dead.

On Mon, Nov 25, 2019 at 9:21 AM Owen DeLong  wrote:
>
> RIPE isn’t dead… Just IPv4.
>
> Owen
>
>
> > On Nov 25, 2019, at 08:03 , Ryland Kremeier  
> > wrote:
> >
> > RIP RIPE
> >
> >
> > -Original Message-
> > From: NANOG  On Behalf Of Andy Ringsmuth
> > Sent: Monday, November 25, 2019 9:58 AM
> > To: NANOG mailing list 
> > Subject: Re: RIPE our of IPv4
> >
> >
> >
> >> On Nov 25, 2019, at 8:56 AM, Dmitry Sherman  wrote:
> >>
> >> Just received a mail that RIPE is out of IPv4:
> >>
> >> Dear colleagues,
> >>
> >> Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 
> >> allocation from the last remaining addresses in our available pool. We 
> >> have now run out of IPv4 addresses.
> >
> > Does this mean we are finally ripe for widespread IPv6 adoption?
> >
> > (Admit it, someone had to say it!)
> >
> > 
> > Andy Ringsmuth
> > 5609 Harding Drive
> > Lincoln, NE 68521-5831
> > (402) 304-0083
> > a...@andyring.com
>


-- 
Jeff Shultz

-- 
Like us on Social Media for News, Promotions, and other information!!

   
<https://www.facebook.com/SCTCWEB/>      
<https://www.instagram.com/sctc_503/>      
<https://www.yelp.com/biz/sctc-stayton-3>      
<https://www.youtube.com/c/sctcvideos>













_ This message 
contains confidential information and is intended only for the individual 
named. If you are not the named addressee you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately by 
e-mail if you have received this e-mail by mistake and delete this e-mail 
from your system. E-mail transmission cannot be guaranteed to be secure or 
error-free as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses. The sender therefore does 
not accept liability for any errors or omissions in the contents of this 
message, which arise as a result of e-mail transmission. _

RE: RIPE our of IPv4

[Ryland Kremeier]

RIP RIPE('s IPV4)*


-Original Message-
From: Owen DeLong  
Sent: Monday, November 25, 2019 11:19 AM
To: Ryland Kremeier 
Cc: Andy Ringsmuth ; NANOG mailing list 
Subject: Re: RIPE our of IPv4 

RIPE isn’t dead… Just IPv4.

Owen


> On Nov 25, 2019, at 08:03 , Ryland Kremeier  
> wrote:
> 
> RIP RIPE
> 
> 
> -Original Message-
> From: NANOG  On Behalf Of Andy Ringsmuth
> Sent: Monday, November 25, 2019 9:58 AM
> To: NANOG mailing list 
> Subject: Re: RIPE our of IPv4 
> 
> 
> 
>> On Nov 25, 2019, at 8:56 AM, Dmitry Sherman  wrote:
>> 
>> Just received a mail that RIPE is out of IPv4:
>> 
>> Dear colleagues,
>> 
>> Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 
>> allocation from the last remaining addresses in our available pool. We have 
>> now run out of IPv4 addresses.
> 
> Does this mean we are finally ripe for widespread IPv6 adoption?
> 
> (Admit it, someone had to say it!)
> 
> 
> Andy Ringsmuth
> 5609 Harding Drive
> Lincoln, NE 68521-5831
> (402) 304-0083
> a...@andyring.com

Re: RIPE our of IPv4

[Owen DeLong]

RIPE isn’t dead… Just IPv4.

Owen


> On Nov 25, 2019, at 08:03 , Ryland Kremeier  
> wrote:
> 
> RIP RIPE
> 
> 
> -Original Message-
> From: NANOG  On Behalf Of Andy Ringsmuth
> Sent: Monday, November 25, 2019 9:58 AM
> To: NANOG mailing list 
> Subject: Re: RIPE our of IPv4 
> 
> 
> 
>> On Nov 25, 2019, at 8:56 AM, Dmitry Sherman  wrote:
>> 
>> Just received a mail that RIPE is out of IPv4:
>> 
>> Dear colleagues,
>> 
>> Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 
>> allocation from the last remaining addresses in our available pool. We have 
>> now run out of IPv4 addresses.
> 
> Does this mean we are finally ripe for widespread IPv6 adoption?
> 
> (Admit it, someone had to say it!)
> 
> 
> Andy Ringsmuth
> 5609 Harding Drive
> Lincoln, NE 68521-5831
> (402) 304-0083
> a...@andyring.com

Re: RIPE our of IPv4

[Dmitry Sherman]

I believe it’s Eyeball network’s matter to free IPv4 blocks and move to v6.


Best regards,
Dmitry Sherman

[X]

On 25 Nov 2019, at 18:08, Billy Crook  wrote:


Huh.  I guess we get to go home early today then?  And look into that whole 
"Aye Pee Vee Sicks" thing next week aye boss?

On Mon, Nov 25, 2019 at 8:58 AM Dmitry Sherman 
mailto:dmi...@interhost.net>> wrote:
Just received a mail that RIPE is out of IPv4:

Dear colleagues,

Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 
allocation from the last remaining addresses in our available pool. We have now 
run out of IPv4 addresses.


Best regards,
Dmitry Sherman
Interhost Networks
www.interhost.co.il
dmi...@interhost.net
Mob: 054-3181182
Sent from Steve's creature
[X]

Re: RIPE our of IPv4

[Tei]

Thanks

I am lurking on this mail list. Sometimes is hard to decipher whats
goin on. Always interesting. You guys are awesome.

On Mon, 25 Nov 2019 at 16:57, Donald Eastlake  wrote:
>
> I think it is less historic than when IANA ran out of blocks to
> delegate to the regional registries.
> https://en.wikipedia.org/wiki/IPv4_address_exhaustion
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e...@gmail.com
>
> On Mon, Nov 25, 2019 at 10:34 AM Tei  wrote:
> >
> > Nice!
> >
> > Is this what I think it is?a historical moment for the internet
> > for the story books?
> >
> > On Mon, 25 Nov 2019 at 15:59, Dmitry Sherman  wrote:
> > >
> > > Just received a mail that RIPE is out of IPv4:
> > >
> > > Dear colleagues,
> > >
> > > Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 
> > > allocation from the last remaining addresses in our available pool. We 
> > > have now run out of IPv4 addresses.
> > >
> > >
> > > Best regards,
> > > Dmitry Sherman
> > > Interhost Networks
> > > www.interhost.co.il
> > > dmi...@interhost.net
> > > Mob: 054-3181182
> > > Sent from Steve's creature
> >
> >
> >
> > --
> > --
> > ℱin del ℳensaje.



-- 
--
ℱin del ℳensaje.

Re: RIPE our of IPv4

[Billy Crook]

Huh.  I guess we get to go home early today then?  And look into that whole
"Aye Pee Vee Sicks" thing next week aye boss?

On Mon, Nov 25, 2019 at 8:58 AM Dmitry Sherman  wrote:

> Just received a mail that RIPE is out of IPv4:
>
> Dear colleagues,
>
> Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4
> allocation from the last remaining addresses in our available pool. We have
> now run out of IPv4 addresses.
>
>
> Best regards,
> Dmitry Sherman
> Interhost Networks
> www.interhost.co.il
> dmi...@interhost.net
> Mob: 054-3181182
> Sent from Steve's creature
>

RE: RIPE our of IPv4

[Ryland Kremeier]

RIP RIPE


-Original Message-
From: NANOG  On Behalf Of Andy Ringsmuth
Sent: Monday, November 25, 2019 9:58 AM
To: NANOG mailing list 
Subject: Re: RIPE our of IPv4 



> On Nov 25, 2019, at 8:56 AM, Dmitry Sherman  wrote:
> 
> Just received a mail that RIPE is out of IPv4:
> 
> Dear colleagues,
> 
> Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 
> allocation from the last remaining addresses in our available pool. We have 
> now run out of IPv4 addresses.

Does this mean we are finally ripe for widespread IPv6 adoption?

(Admit it, someone had to say it!)


Andy Ringsmuth
5609 Harding Drive
Lincoln, NE 68521-5831
(402) 304-0083
a...@andyring.com

Re: RIPE our of IPv4

[Andy Ringsmuth]

> On Nov 25, 2019, at 8:56 AM, Dmitry Sherman  wrote:
> 
> Just received a mail that RIPE is out of IPv4:
> 
> Dear colleagues,
> 
> Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 
> allocation from the last remaining addresses in our available pool. We have 
> now run out of IPv4 addresses.

Does this mean we are finally ripe for widespread IPv6 adoption?

(Admit it, someone had to say it!)


Andy Ringsmuth
5609 Harding Drive
Lincoln, NE 68521-5831
(402) 304-0083
a...@andyring.com

Re: RIPE our of IPv4

[Donald Eastlake]

I think it is less historic than when IANA ran out of blocks to
delegate to the regional registries.
https://en.wikipedia.org/wiki/IPv4_address_exhaustion

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Mon, Nov 25, 2019 at 10:34 AM Tei  wrote:
>
> Nice!
>
> Is this what I think it is?a historical moment for the internet
> for the story books?
>
> On Mon, 25 Nov 2019 at 15:59, Dmitry Sherman  wrote:
> >
> > Just received a mail that RIPE is out of IPv4:
> >
> > Dear colleagues,
> >
> > Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 
> > allocation from the last remaining addresses in our available pool. We have 
> > now run out of IPv4 addresses.
> >
> >
> > Best regards,
> > Dmitry Sherman
> > Interhost Networks
> > www.interhost.co.il
> > dmi...@interhost.net
> > Mob: 054-3181182
> > Sent from Steve's creature
>
>
>
> --
> --
> ℱin del ℳensaje.

Re: RIPE our of IPv4

[Tei]

Nice!

Is this what I think it is?a historical moment for the internet
for the story books?

On Mon, 25 Nov 2019 at 15:59, Dmitry Sherman  wrote:
>
> Just received a mail that RIPE is out of IPv4:
>
> Dear colleagues,
>
> Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 
> allocation from the last remaining addresses in our available pool. We have 
> now run out of IPv4 addresses.
>
>
> Best regards,
> Dmitry Sherman
> Interhost Networks
> www.interhost.co.il
> dmi...@interhost.net
> Mob: 054-3181182
> Sent from Steve's creature



-- 
--
ℱin del ℳensaje.