Geoff Huston

The idea that there are already devices out there designed for a new protocol was considered an advantage of the TUBA protocol to replace IPv4 before v6 was chosen: "The reviewers generally felt that the most important thing that TUBA has offers is that it is based on CLNP and there is significant deployment of CLNP-capable routers throughout the Internet." [0] [0] https://www.potaroo.net/ietf/idref/draft-ipng-recommendation/#page-17 Of course these days nobody remembers either TUBA or CNLP...

It's worth pointing out, in terms of LE being "wildly more successful", that this represents a single organisation, with a security critical role on the web, approaching a monopoly. That's actually a worse situation than if 100% of hosts on the internet supported (different but compatible implementations of) IPv6. Here is a chart showing the trend for LE marketshare (under the IdenTrust root): https://w3techs.com/technologies/history_overview/ssl_certificate I really support LE's mission, and celebrate their success, but would feel more comfortable if a separate organisation tried replicating what they had done, running the same service but with distinct personnel and assets. For reference, here is another chart showing the run down of the remaining IPv4 supply: http://www.potaroo.net/tools/ipv4/plotend.png

ARIN hasn't reached zero yet: http://www.potaroo.net/tools/ipv4/ But if you're going to start an ISP, you'd best do it in the next few months. Europe and Asia are already screwed.

My favourite IPv4 infographic is this one: http://www.potaroo.net/tools/ipv4/index.html

This kind of thing seems innocent, but it really isn't. Another comment put it as "25.x.x.x is not advertised globally, not announced with BGP, so they're using it as private IP space. This works because you will never connect to a 25.x.x.x IP. It's just NAT." That sounds fine but you run into trouble when the owner suddenly starts using the space or it’s reallocated. This has happened quite a lot in the last decade as IP space was ever more in demand and thus ever more scarce. An example is the use of 1.0.0.0/8 - allocated to APNIC in 2010 - there is a detailed analysis of the "unintentional" traffic this network was receiving when first used https://www.potaroo.net/studies/1slash8/1slash8.html - over 165 megabits in 2010. Among various lazy configs and people using the range as it was convenient I recall there was some default popular Cisco recommended config that used it. Though I can’t find a link right now. Similar problems also happened in the 2007-2010 timeframe as a lot of people used to have static “Bogon filter” firewalls that dropped traffic from unallocated IP ranges (not those marked as 'never to be used', just those not allocated yet). As more and more ranges were allocated the people receiving them had all sorts of connectivity problems to random networks because of these old out of date static filters - in my experience as a hosting provider the most common offender was banks hilariously. In practice these filters provided relatively little security and…

I share your pain, bro :) Although, two corrections: 1) prices are, in my experience, lower than what you quoted: around 10-12 $/IP, depending on the subnet size. 2) RIPE is indeed encouraging the marketplace model: it is seen as a mechanism to move resources to LIRs that need them the most, with the side effect of increasing IP efficiency. Also, to note: 4) Since some time, there is a policy proposal [1] to allow intra-RIR transfers to/from RIPE. I'm not aware on whether there is such a proposal within ARIN, which currently allows only transfers to/from APNIC (not very useful if you're american... addresses in APNIC ended a long time ago!). 5) RIPE currently operates in a "emergency policy" that allows a /22 to new registrants and a /24 to new members. ARIN will follows the same policy as soon as they remain with a single /8 left (probably around May-June 2014). 6) I always like to give a link to the very informative exhaustion graph of Geoff Huston [3] :) [1] http://www.ripe.net/ripe/policies/proposals/2012-03 [2] https://www.arin.net/resources/request/transfers_8_4.html [3] http://www.potaroo.net/tools/ipv4/index.html

"market based allocation" - this means further deaggregation of the existing prefixes. Which translates into eventual serious capital expenditures for the carriers to hold the large tables. Worldwide. In addition to the money required to pay for carrier grade translators. Though my employer produces them (amongst other stuff) - I do not think that architecturally they are a good thing. All this money will need to come from somewhere. As the profit from a "prefix sold" goes into one pocket, but the expenditures are spread around the world, it means this profit would not come from IP addresses. It will come from the subscribers' monthly payments and quotas. Translating: bye bye unmetered access on the cheap. Not so long ago in .be the ISPs were charging after you go over 10Gb on the DSL line. About squeezing out the /8s from the current owner: that would help but not for long. It's like getting the additional credit line from the bank on the credit card. For some info on the exhaustion and the models used you can take a look here: http://www.potaroo.net/tools/ipv4/ Of course, NATs are "convenient", so I would not necessarily exclude that some will decide to go with the scenario you describe - cascaded NATs.

If you look at the older article linked (https://www.potaroo.net/ispcol/2022-03/revocation.html), it's very similar and uses the same tick/cross, so I don't think it's AI generated.

e.g. https://www.potaroo.net/studies/103-slash8/103-slash8.pdf and https://conference.apnic.net/news-archives/2010/network-1/assets/Traff…

Roughly 40% of the Internet is IPv6. That's not taken over, and disappointing for a 30 year old standard, but it's not nothing. https://www.potaroo.net/ispcol/2024-10/ipv6-transition.html I've been using IPv6 via Starlink for months now and it was a big ho-hum when I deployed it. It just works.

Previously: • https://news.ycombinator.com/item?id=41893200 – https://www.potaroo.net/ispcol/2024-10/ipv6-transition.html – The IPv6 Transition – (224 points / 416 comments)

The rabbit hole on people gradually pulling up stakes on DNSSEC goes deeper than that; I'd say the canary in the coal mine is probably Geoff Huston switching from "of course we're going to DNSSEC everything" to "are we going to DNSSEC anything?": https://www.potaroo.net/ispcol/2023-02/dnssec.html (Geoff Huston is an Internet infrastructure giant.) But really it all just boils down to the fact that the DNS zones that matter --- the ones at the busy end of the fat tail of lookups --- just aren't signed, despite 25 years of work on the standard. IPv6 is gradually mainstreaming; in countries where registrars auto-sign zones, DNSSEC is growing too, but very notably in countries where people have a choice, DNSSEC deployment is stubbornly stuck in the low single digit percentages, and the zones that are getting signed are disproportionately not in the top 10,000 of the Tranco list.

If you’ve read them before, surely you can bring some counter-arguments which are not a simple ad hominem? If you insist on dismissing arguments outright from persons whom you do not consider authoritative, consider Geoff Huston, a person you referred to before: <https://www.potaroo.net/ispcol/2023-02/dnssec.html>.

So you think improving security is about a "knee-jerk anti-innovation sentiment"? To better understand why these regulations are pushed forward throughout the world, read for instance Huston's elegant piece: https://www.potaroo.net/ispcol/2021-02/iot.html

When you look at the same graph for IPv4, its pretty obvious that graph isn't showing data that supports the conclusions you're drawing from it: https://www.potaroo.net/ispcol/2022-01/addrfig2.png

Here you go: https://www.potaroo.net/ispcol/2022-02/ipv6-fig4.png also: https://www.potaroo.net/ispcol/2022-02/ipv6-fig5.png You can answer the rest of your own questions. I am not your personal Google.

afaik 1st-gen bbr is somewhat unfair to other cc-algos to the point that it will starve them. use it if you want to be 'that guy' (or google :) update: slide 27 and onwards https://www.potaroo.net/presentations/2018-05-10-bbr.pdf

The problem is the number of updates / changes that happen all the time in BGP, and having each router cryptographically validate each one / sign every update it sends.... it doesn’t scale well. The BGPSEC theory is there but not sure if we can make a workable system. https://www.potaroo.net/ispcol/2011-07/bgpsec.pdf

> Are we actually running out of addresses We ran out a long time ago: IANA Unallocated Address Pool Exhaustion: 03-Feb-2011 Projected RIR Address Pool Exhaustion Dates: RIR Projected Exhaustion Date Remaining Addr in RIR Pool (/8s) APNIC: 19-Apr-2011 (actual) 0.1946 RIPE NCC: 14-Sep-2012 (actual) 0.1289 LACNIC: 10-Jun-2014 (actual) 0.0351 ARIN: 24 Sep-2015 (actual) 0.0002 AFRINIC: 08-Feb-2020 0.2940 http://www.potaroo.net/tools/ipv4/index.html

For anyone interested, this a pretty good write up on "Bogons": http://www.potaroo.net/ispcol/2004-04/2004-04-isp.htm

DHCP already has support for providing an NTP server IP; there has been at least one proposal[1] to also provide a DHCP option specifying the "rough current time", so that devices have at least _something_ to start with. As for trust, you're already going to be trusting DHCP to give you an IP address, you could also trust it for this (with some safeguard in place to catch known-wrong values). This kindof reinforces how having an 'IoT Gateway' would be a good idea: The gateway can provide DHCP, and rough time, and (S)NTP, and DNS, and can also act as a proxy to the outside. [1]: http://www.potaroo.net/ietf/idref/draft-ogud-dhc-udp-time-option/

Came here to say this. Learning BNF ( https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form ) and knowing how to go to the roots have helped me more than once in my career (started as tester, moved to security engineer, then net engineer, then CISSP, then ISSO, then HIPPA SPO -- now senior sec engineer at top10 UNI) Here is a good site to see what obsoletes and is superseded by what. https://www.potaroo.net/ietf/html/rfcindex.html

APNIC used that terminology in their analysis paper of 1.0.0.0/8, "1.0.0.0/8 has been assigned by IANA to APNIC on the 19th January 2010" [1]. To do this analysis, wouldn't they have had to advertise a route back in 2010? [1] http://www.potaroo.net/studies/1slash8/1slash8.html

Houston has run a study on the traffic being directed towards 1/8 before. http://www.potaroo.net/studies/1slash8/1slash8.html

I don't think this should be downvoted. Serious Internet People have been discussing this exact topic recently: https://blog.apnic.net/2016/10/28/the-death-of-transit/ http://www.potaroo.net/presentations/2017-05-25-death-of-transit.pdf When 90% of traffic goes through CDNs, it will be easier for ISPs to "accidentally" deliberately congest the remaining 10% without too many people noticing. https://ag.ny.gov/sites/default/files/summons_and_complaint.pdf

1/8 was reserved for a long time and various entities improperly used it as a private address. It was eventually given to APNIC for assignment use but a few ultra-commonly-used ranges and addresses like 1.1.1/24 and 1.2.3/something were never assigned because they get so much noise traffic and would break so many things. It's improper for anything to use these unassigned in-theory-globally-routable addresses but there are no real hosts there and lots of local networks use them for random internal purposes. At least one commercial Wi-Fi hotspot uses 1.1.1.1 as a captive portal address. Here's an incredibly detailed report on the situation on the 1-network: http://www.potaroo.net/studies/1slash8/1slash8.html

Not that I know of now. Here's the original RFC that became the RFC which got .onion recognized http://www.potaroo.net/ietf/idref/draft-grothoff-iesg-special-use-p2p-… They were trying to get .gns, .zkey, .onion, .exit, .i2p and .bit recognized.

IPSec admitted and reacted to this too late, but they were going to handle it by giving the policy choices to the application through socket options. See IPSec Channel Bindings RFC (RFC5660) and unfinished specs at http://www.potaroo.net/ietf/html/ids-wg-btns.html for where this work was heading.

http://www.potaroo.net/ispcol/2015-11/v6perf.html I was talking about qualitative measurement like this Quote : These measurements show that in a large set of 1:1 individual comparisons where the IPv4 and IPv6 paths between the same two dual stack endpoints are compared, the two protocols, as measured by the TCP SYN round trip time, are roughly equivalent. The measurements are within 10ms of each other 60% of the time. While the connection performance is roughly equivalent once the connection is established, the probability of establishing the connection is not the same. The current connection failure rate for IPv4 connections was seen to be some 0.2% of all connection attempts, while the equivalent connection failure rate for unicast IPv6 is nine times higher, at 1.8% of all connection attempts.

"signed with DNSSEC" is an ambiguous statement. You need to take into account that, while nameservers may enable DNSSEC, resolvers may: (a) validate (include the AD bit) but strip the RRSIGs (i.e. regular DNSSEC resolver) (b) omit the AD bit but include the RRSIGs (i.e. you have to validate yourself) (c) omit the AD bit and omit the RRSIGs (i.e. regular non-DNSSEC resolver) (d) validate (i.e. include the AD bit) and include the RRSIGs (i.e. alleluia!) My own study [0] (using the Atlas network [1]) found 30% of resolvers doing (a), and 65% doing (b), including some overlap. There are people way more qualified than me doing this kind of stuff, namely APNIC's Geoff Huston, see [2] for instance. [0] https://www.os3.nl/_media/2013-2014/courses/rp2/p14_report.pdf [1] https://atlas.ripe.net [2] http://www.potaroo.net/presentations/2014-06-03-dns-measurements.pdf