People who buy IPv4 address blocks can most certainly afford them - the
big buyers are large ISPs and CSPs that offer IPv4 as a service.
Pressure points that make migration to v6 attractive can vary, and don't
always meet the eye. Networks that are heavily NATed are inherently more
complex to manage, and forensics becomes a nightmare.
My personal pressure point: I have an unfortunately not-so-little
service role here in which I get to deal with a certain subset of
students who think that outsourcing each and every assessment in their
degree is the thing to do. It's not-so-little because there aren't so
few of them, sadly. So we decided some time ago that we'd pull some of
our core courses into invigilated labs for tests and exams, using
systems such as CodeRunner for assessment. We also log client IPs at the
CodeRunner end in order to detect clients not coming from the lab (or
rather, we do now, after discovering that you need to get the load
balancer to propagate the actual client IP to see more than one
meaningless address). And we do find - not a test or exam goes by
without some folk being observed having questions answered from IP
addresses outside the lab.
So what does this have to do with IPv4? Well, I never get to catch
anyone for collusion because of IPv4. One reason for this is that even
if they did collude (and from what I've seen to date, it wouldn't
surprise me in the slightest), the lab sits behind a NAT (many computers
hosting no services), and the CodeRunner instance sits outside. All
students in the lab are seen coming from the same address. So imagine
Alice sitting a test for herself and Bob answering questions 1 to 4 for
both of them, while Bob takes care of 5 to 8. No way we can detect this
- even packet capture inside the lab won't help up because user IDs are
hidden behind HTTPS. IPv6 would do away with the problem altogether -
we'd see Alice's machine answering 1 to 4 for both her and Bob, and
Bob's machine answering 5 to 8 for both of them.
We also get issues when we see two students who we suspect to be
"connected" coming in from the same CGNAT IP address in non-lab
assessments. This could be coincidence, an external helper, or just
people being flatmates, but IPv4 makes us more myopic here than we need
to be.
On 23/09/2023 11:28 pm, Sebastian Moeller wrote:
Hi Ulrich,
nice tangential discussion. I guess what we might expect is some
"Kipp-Punkt"/tipping-point at which acquiring new IPv4 becomes cost
prohibitive enough so new deployments go IPv6 only, at which point the
existing IPv4 offers might devaluate pretty quickly... Now, if IPv6
would have been made more like IPv4 this would be considerably easier
(I am thinking DHPCv6 and Android devices here, and I am only speaking
of ease of deployment; I accept there are valid reasons for a
SLAAC-only position like Android's). The US$1 million (or better 3.5
Million) question is when this tipping-point will be?
Tangent: German ISPs tend to charge ~5EUR/month extra for static
public IPv4 addresses so over a typical 24 month contract period can
easily tolerate a cost of 5*24 = 120 EUR for an IPv4 address (that
will afterwards still be in the ISP's property). They typically
provision either full DualStack (from the incumbent sitting on a large
pile of IPv4s) or ds-lite and for a few unfortunate one's CG-NAT-IPv4
only. But even the IPv6 addresses/prefixes are typically dynamically
assigned with relative short renewal periods (like 24 hours).
Regards
Sebastian
P.S.: My personal gripes with IPv6 are much smaller, I mostly miss
stuff like ICMP timestamps in ICMPv6 and the IP timestamp option in
IPv6*, or the fact that privacy extensions (as well intended as they
are) make it harder for novice users to actually use their IPv6
globally routable addresses to make services available.
*) I think I understand the limitations of both ICMP and IP timestamps
compared to the more elaborate alternatives that have been RFC'd as
alternatives and that apparently convinced team IPv6 to not carry
these things over from IPv4, but boy, no amount of higher temporal
precision makes up for the point that many deployed servers today
happily respond tp ICMP/IP timestamp requests, ubiquity in itself is a
major asset.
> On Sep 23, 2023, at 12:53, Ulrich Speidel via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
> On 23/09/2023 4:22 pm, Noel Butler via Starlink wrote:
>> IPv6 is only 4% of traffic that hits my Mail Servers, it's less
than 1% on my Web servers.
>> Just like TCP, it wont be going anywhere, not quietly, and if it
were to, likely be long after I'm gone, QUIC seems an interesting
project, and I guess only the decades ahead of us will tell of it
becomes a raging success.
>
> Now what that tells me is that you and those that use your mail /
web servers are within networks that are either in networks that are
old and have legacy IPv4 allocations, or that are new, desparate, and
rich. And Geoff, if you asked him, would tell you that this is
perfectly fine by him - as long as you're happy with it. In fact, I
can recall a presentation of his not too long ago (APNIC54, AINTEC22?)
where he said pretty much exactly that he didn't foresee a rapid
demise of IPv4.
>
> But if you look at the Internet as a whole - and Geoff does, in a
very ingenious way, I might add - then we notice that the percentage
of IPv6 out there has been growing steadily. IPv6 is now what about
half of Internet users use. Maybe not the folk that visit your
services, but Internet users nonetheless. So you're in the process of
being outnumbered. But that's perhaps of academic interest only, for
now, at least.
>
> What's a bit more pertinent in some respects is a point that Vint
brought up, and this is that if you want a new IPv4 address these
days, you will generally need to buy it from someone who has an
allocation. Or lease it - which is a little controversial, but not a
debate I'm wanting to enter here. Let's stay with the buying price tag
for a moment.
>
> I came home from APNIC54 last year with the insight that my
employer's /16 IPv4 allocation was worth around US$3.5 million. Since
we've had the /16 for ages, I started wondering whether this was even
on our asset list. I was pretty sure that it ought to be. Turns out it
wasn't - when every $100 monitor in our place is. So I started asking
questions and am told that there was a hastily arranged meeting
between IT and Finance.
>
> The upshot is that we now have a $3.5m asset on our books that may
appreciate or depreciate, and people who are responsible for managing
it. In fact, I dug a bit further and found a total of around NZ$100m
worth of IPv4 addresses in NZ's public sector, including a /16 held by
a government department that wasn't part of any AS. NZ's auditor
general's office told me that they expected public sector agencies to
list IPv4 holdings on their balance sheets.
>
> Why is this important? Because otherwise, there is nothing that
stops an individual with access to your RIR account from transferring
your IPv4 holdings to whichever party they so desire. If the addresses
are not on your asset list, then there's nothing that documents that
you own the value that is inherent in them and thus nothing to sue
anyone for. One imagines this as the ultimate stunt that a disgruntled
sysadmin might pull off before they leave your employ.
>
> But let's get back to that newly-found asset that we now have to
manage. Your next CGNAT now becomes an investment in making that
newly-found asset a little less tradable. A bit like putting a shiny
new building right onto the only access way to your back sections
you've just been told you can actually develop.
>
> Of course, this only applies to folk who sit on larger address
blocks - for a /24, it won't make much of a difference on the balance
sheet.
>
> --
>
> ****************************************************************
> Dr. Ulrich Speidel
>
> School of Computer Science
>
> Room 303S.594 (City Campus)
>
> The University of Auckland
> u.spei...@auckland.ac.nz
> http://www.cs.auckland.ac.nz/~ulrich/
<http://www.cs.auckland.ac.nz/~ulrich>
> ****************************************************************
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
<https://lists.bufferbloat.net/listinfo/starlink>
--
****************************************************************
Dr. Ulrich Speidel
School of Computer Science
Room 303S.594 (City Campus)
The University of Auckland
u.spei...@auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
