<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>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.</p>
<p>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. </p>
<p>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.</p>
<p>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. </p>
<p>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. <br>
</p>
<div class="moz-cite-prefix">On 23/09/2023 11:28 pm, Sebastian
Moeller wrote:<br>
</div>
<blockquote type="cite" cite="mid:7EB4E450-D3D9-4159-8870-BA3EA97E47EA@gmx.de">
Hi Ulrich,<br>
<br>
<br>
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?<br>
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). <br>
<br>
Regards<br>
Sebastian<br>
<br>
<br>
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.<br>
<br>
*) 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.<br>
<br>
<br>
> On Sep 23, 2023, at 12:53, Ulrich Speidel via Starlink
<a class="moz-txt-link-rfc2396E" href="mailto:starlink@lists.bufferbloat.net"><starlink@lists.bufferbloat.net></a> wrote:<br>
> <br>
> On 23/09/2023 4:22 pm, Noel Butler via Starlink wrote:<br>
>> IPv6 is only 4% of traffic that hits my Mail Servers,
it's less than 1% on my Web servers.<br>
>> 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.<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> -- <br>
> <br>
>
****************************************************************<br>
> Dr. Ulrich Speidel<br>
> <br>
> School of Computer Science<br>
> <br>
> Room 303S.594 (City Campus)<br>
> <br>
> The University of Auckland<br>
> <a class="moz-txt-link-abbreviated" href="mailto:u.speidel@auckland.ac.nz">u.speidel@auckland.ac.nz</a><br>
> <a href="http://www.cs.auckland.ac.nz/~ulrich" moz-do-not-send="true">http://www.cs.auckland.ac.nz/~ulrich/</a><br>
>
****************************************************************<br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> Starlink mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:Starlink@lists.bufferbloat.net">Starlink@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/starlink" moz-do-not-send="true">https://lists.bufferbloat.net/listinfo/starlink</a><br>
</blockquote>
<pre class="moz-signature" cols="72">--
****************************************************************
Dr. Ulrich Speidel
School of Computer Science
Room 303S.594 (City Campus)
The University of Auckland
<a class="moz-txt-link-abbreviated" href="mailto:u.speidel@auckland.ac.nz">u.speidel@auckland.ac.nz</a>
<a class="moz-txt-link-freetext" href="http://www.cs.auckland.ac.nz/~ulrich/">http://www.cs.auckland.ac.nz/~ulrich/</a>
****************************************************************
</pre>
</body>
</html>