[HN Gopher] Reclaiming IPv4 Class E's 240.0.0.0/4
___________________________________________________________________
Reclaiming IPv4 Class E's 240.0.0.0/4
Author : todsacerdoti
Score : 111 points
Date : 2024-05-27 14:28 UTC (8 hours ago)
(HTM) web link (blog.benjojo.co.uk)
(TXT) w3m dump (blog.benjojo.co.uk)
| Latty wrote:
| I'd really just rather get IPv6 working everywhere and not have
| to deal with NAT. Some more addresses just drags out the problem
| by reducing incentives to switch, it doesn't solve anything,
| which is roughly where the article seems to land:
|
| > If we are going to start using address space that might not
| work for all users, it would be wise to pick the address space
| that we already have a considerable head start on getting
| accepted: IPv6.
| gmuslera wrote:
| This. It will break a lot of existing applications, devices,
| firewalls, and have conflicts with companies that are somewhat
| already using them in a public or private environments. And if
| we want to do it anyway despite all the trouble, it will only
| push forward the problem a few months or years.
|
| In the other hand, IPv6 is already used by nearly half of
| internet, and probably most installed infrastructure supports
| it. And it have a lot of advantages over IPv4, starting with
| not having to use NAT.
| TheLoafOfBread wrote:
| If IPv6 would be created with a little bit more care for
| backward compatibility, it could have been years since last
| server stopped using IPv4. The whole IPv6 fiasco is self
| inflicted.
| loeg wrote:
| Yes, yes, but at this point those mistakes have been
| litigated sufficiently and complaining about them doesn't
| help solve any of the remaining problems.
| bbarnett wrote:
| Sure it does. We can just move to ipv8, 5 octlets instead
| of 4. We can give 2.x.x.x.x to 10. to earth, maybe 100 to
| 110 for moon, mars, etc.
|
| 1.x.x.x.x will be for legacy stuff. If anything is trying
| to route to only 4 octlets, routers add a 1. in front of
| it. Bam, legacy solved.
|
| edit: I realised people don't see the big picture here.
|
| Step 1) We collectively engineer and deploy ipv8, along
| with RFCs explaining how future expansion works
|
| 2) We put all sorts of preparatory work, conversation into
| the eventual expansion into 6 octlets, from 5. We'll need
| that once we colonize multiple systems.
|
| 3) The RFC will state that "new planetary systems get space
| on 5th oclet, 1.200.x.x.x.x to 1.250.x.x.x.x.
|
| 4) As systems grow to need more than an ipv4 range, we
| transition them to their own 6th oclet. It's easy for them,
| because they can retain legacy 5th octlet headers.
|
| 5) We then collectively freeze our brains, so that in the
| future, once interplanetary, faster than light
| communication exists, we are thawed to deal with the 5 to 6
| oclet transition!
|
| And we all become immortal.
|
| But _no_ , that's _fine_ , think small, stay non-immortal
| with your ipv6 Flanders!
| ynik wrote:
| > If anything is trying to route to only 4 octlets,
| routers add a 1. in front of it. Bam, legacy solved.
|
| Only for unidirectional UDP.
|
| How do you think the other side would be able to respond
| if it's unaware of the 5th octlet? Basically every
| protocol in existence requires two-way communication and
| there's no backward compatible way of providing that.
| bbarnett wrote:
| I covered that. Edge routers transition 1.x.x.x.x to
| x.x.x.x as a default, and x.x.x.x to 1.x.x.x.x. This is
| an interim change, so that ipv4 can communicate to ipv4
| forever. Legacy systems can be supported on ipv4 only,
| relegating them (just as they are now!) to not having
| access to that new address space.
| growse wrote:
| You realise that this idea of "embedding a smaller, old
| address space inside a newer bigger one" has existed in
| IPv6 for a pretty long time now?
| bbarnett wrote:
| A car and a motorcycle both travel on roads, but they are
| still not the same. - Henry Perkins
| humanfromearth9 wrote:
| 1.x.x.x.x -> why not 0.x.x.x.x to represent x.x.x.x ?
| itchyouch wrote:
| The dotted quad notation is just a human readable
| notation. You can't just add another octet willy nilly.
| That's exactly what ipv6 did. They added an extra 12
| octets, but used hex notation (0-F) to shorten the number
| of characters for human readability.
|
| Internally, an IP is just a 32bit number. Adding another
| octet is adding another 8bits to the number. IPv6 merely
| expands that number to a 128bit number.
|
| If you do the math of say converting 8.8.8.8 to 8 _256^3
| + 8_ 256^2 + 8 _256^1 + 8_ 256^0 and ping the resulting
| number, it will work.
| bbarnett wrote:
| Yes, but this is to aid in a proper transition. All old
| ipv4 addresses will route fine, using this method.
| eqvinox wrote:
| Is this genuine or sarcasm? I can't tell.
| rcxdude wrote:
| What kind of backward compatibility are you imagining? If you
| say "with ipv4 addresses", how are you imagining that would
| work?
| TheLoafOfBread wrote:
| Keep the structure and services around IP protocol (DNS,
| DHCP, NAT), just with more bits for address. Do not try to
| reinvent the wheel and add unnecessary breaking bell and
| whistles which nobody asked for.
| jcranmer wrote:
| All of these things already exist for IPv6, although I
| don't know how much DHCPv6 is deployed in practice.
| baq wrote:
| It should be deployed everywhere where IPv6 is deployed
| and there's an IT department if only for logging/audit.
| kccqzy wrote:
| Stateful DHCPv6 does not get deployed because IPv6
| purists at Google refuse to implement them on Android.
| And I in fact agree with them.
|
| And DHCPv6 isn't needed for logging/audit: the router
| always has an association of MAC addresses and IPv6
| addresses even if hosts assign their own addresses with
| SLAAC.
| fanf2 wrote:
| Regrettably little, mainly because Lorenzo Colitti who is
| in charge of the Google Android network stack refuses to
| support it.
| dmm wrote:
| His justification for not supported stateful dhcpv6 is
| completely reasonable and I wish more platforms had come
| to the same conclusions.
| justsomehnguy wrote:
| > just with more bits for address
|
| And by having a just more bits for the address - be
| incompatible with IPv4.
|
| DNS is _IP_ ^W address protocol agnostic, by the way. If
| you really need you can run it on IPX/SPX.
|
| DHCP is just a lack of the autoconfiguration in IPv4. No
| thanks. Nor APIPA, nor DHCP with _the same 192.168.0.1
| /24 everywhere_ solve that properly like in v6. Sure
| there were some nuances in the begging (like the
| inability to provide the DNS servers addresses at the
| beginning) but they were solved _15 years ago_.
| kemotep wrote:
| Yeah any "solution" to backwards compatibility I have
| heard involves updating the address scheme. And to get
| that to work you need to update your networking
| equipment, software, and start redesigning your network
| to accommodate the new address scheme and guess what,
| that's an IPV6 migration.
| tsimionescu wrote:
| If you only had to update the software for a new IP
| version and a longer address, and maybe even a bit of
| cleanup in the headers, adoption could have been much
| quicker.
|
| As it is, virtually everything about networking is
| different in the IPv6 world. That has significantly
| complicated adoption for everyone, arguably needlessly.
| And not everyone who says they support IPv6 even actually
| supports everything that the designers expect (e.g. lots
| of ISPs give you a /64 or even a /128 for your whole
| network).
|
| Also, plenty of software that interacts with networking
| will sometimes be subtly broken if running on an IPv6
| host, because of assumptions like one IP per interface.
| justsomehnguy wrote:
| > If you only had to update the software for a new IP
| version and a longer address
|
| By 2005 all the major 'software' (read: general purpose
| network operating systems) had the software for IPv6
| already.
|
| If your _application_ is hardcoded to use IPv4 addresses
| then you need to rewrite it anyway and no amount of IPv5
| would change that.
|
| More so, if the software just didn't bother with
| hardcoding and just used the OS primitives for it's
| network activity (read: sockets and OS provided name
| resolution) then you don't even need to update it, it
| would just work.
|
| But the most important part here is what were (and I can
| bet my pumpkin latte - still are) incapable of anything
| of not IPv4 - because it's _the hardware_ , which routed,
| NATed, checksummed all that traffic.
|
| You just couldn't slap your IPv5 there by exactly the
| same reason you couldn't slap IPv6 there - you needed to
| replace the hardware.
|
| > As it is, virtually everything about networking is
| different in the IPv6 world
|
| Sorry, but no.
|
| The basics, ie _the networking_ , is exactly the same.
| Yes, there are some nuances, like using link-local
| addresses for the gateways, which absolutely, totally,
| makes sense after a 15 minute reading. But overall it's
| just another technology, not harder then everything else
| out there, _including IPv4 itself_.
|
| > That has significantly complicated adoption for
| everyone, arguably needlessly
|
| _sigh_ At this point I need to conclude what the network
| guys are... just dumb. Like, come on, I needed to learn
| _every year_ from the time I touched my first 286. Every
| year there is something new and you need to learn it[0].
| Sometimes to abandon and forget it after a couple of
| years.[1] IPv6 is not a rocket-neuroscience, just another
| set of RFC 's and guides. If anything, IPSec with it's
| idiosyncrasies is way, way more convoluted both to learn
| _and implement_.[2]
|
| > And not everyone who says they support IPv6 even
| actually supports everything that the designers expect
|
| Now you argue what with 'IPv5' this wouldn't happen.
|
| > Also, plenty of software that interacts with networking
| will sometimes be subtly broken if running on an IPv6
| host, because of assumptions like one IP per interface.
|
| I wrote about it - it's the problem of the software. I
| had multiple IPv4 addresses on the same interface many,
| many times. If that software breaks with multiple IPv6
| addresses on the one interface then it would break the
| same with mulltiple addresses of IPv4 and 'IPv5'.
|
| PS I have a small fleet of PowerConnect 5500 and 8000
| switches. They are old, so old 5500 has SSH bolted onto a
| _Telnet_ server. Yet they did already support IPv6 by
| 2010. It 's already passed more years since the release
| of 8000 (2010 - 2024) than between IPv6 IETF proposal and
| release of 8000 (1998 - 2010).
|
| Slow adoption has nothing to do with IPv6 itself, and no
| IPv5 or whatever would made it faster.
|
| [0] if anything it's slower now
|
| [1] MS Exchange for example. Do you know X.400? I do not,
| anymore. But for some years I needed to know and I
| learned it.
|
| [2] Take this from someone who did and does both.
| icedchai wrote:
| Can you describe how you'd make it more backwards compatible?
| I often see comments like this, yet nobody can work around
| the fact that you're limited by 32-bit source and destination
| headers in V4.
| jedberg wrote:
| It's pretty simple. If IPv6 headers were split into two
| parts, where the first part was the same as IPv4, and the
| second part had the rest of the bits, so you had say 8
| octets instead of 4. The rest of the header would look like
| data to an IPv4 router.
|
| So your IPv6 address would be 1.2.3.4.5.6.7.8. The header
| would have 5.6.7.8 as the IPv4 destination. When it got
| there, that router would unpack the rest of it and send it
| off to 1.2.3.4.5.6.7.8. If that host had to talk to an IPv4
| host, it would just use the IPv4 headers.
|
| Then IPv6 traffic could pass over IPv4 networks without any
| changes. The only constraint would be that each IPv6
| network would have to have an IPv4 "gateway" address.
|
| Old IPv4 hosts wouldn't be able to talk to IPv6 endpoints,
| but at least this way the user could upgrade their own
| stack without having to wait for their ISP, and every
| network in between, to also upgrade.
|
| It's pretty much carrier grade NAT but from client to
| client without ISP support being necessary, which is the
| biggest bottleneck right now.
| andrewshadura wrote:
| This has been proposed many times already, and it
| actually wouldn't work.
| jedberg wrote:
| Why not?
| ianburrell wrote:
| Because the IPv4 host can't talk to new protocol hosts.
| IPv4 hosts can only do 32-bit addresses and don't know
| about the wrapping. If they did, they would be new
| protocol hosts.
|
| I had idea of putting the internal address for NAT in
| options so could be addresses directly. But too many
| boxes would need to be changed, and lots of unchanged
| boxes remove options. Plus, all the IPv4 applications
| wouldn't know what to do with stack of addresses. It
| would devolve to NAT.
| jedberg wrote:
| Of course they can't. But the point is that if a client
| _wants_ to interact with IPv6, they only have to upgrade
| themselves, and not wait for everything in between to get
| upgraded. And the service can serve on their IPv4 gateway
| and then pass the traffic back to other hosts to server
| IPv4 clients.
| jcranmer wrote:
| > So your IPv6 address would be 1.2.3.4.5.6.7.8. The
| header would have 5.6.7.8 as the IPv4 destination. When
| it got there, that router would unpack the rest of it and
| send it off to 1.2.3.4.5.6.7.8. If that host had to talk
| to an IPv4 host, it would just use the IPv4 headers.
|
| How does the IPv4 person craft the reply back to the not-
| IPv4 source?
| jedberg wrote:
| They don't. They still have to upgrade. But at least the
| service owner has options to run the services on their
| gateway and then pass the traffic back to the hosts
| behind on their internal IPv6 network.
|
| And more importantly it means that if a client _wants_ to
| interact with IPv6, they only have to upgrade their
| client, and not wait for everyone in between to upgrade
| too.
| jcranmer wrote:
| In other words, your proposal establishes only not-
| IPv4<->not-IPv4 communication over an IPv4 tunnel, which
| is something actual IPv6 has had for decades?
|
| (There's also the interesting question of how not-IPv4
| addresses are supposed to get their not-IPv4 addresses if
| the entity they get their IP addresses from doesn't
| support not-IPv4.)
| jedberg wrote:
| No, it establishes a path for piecemeal upgrades to the
| infrastructure that is cross compatible with IPv4.
| jcranmer wrote:
| I'm not seeing it... can you clearly explain specifically
| what scenarios your not-IPv4 deployment strategy enables
| that doesn't exist with IPv6 today?
|
| (If you're going to say "not-IPv4 local network with IPv4
| ISP", then clearly explain how the not-IPv4 local network
| is supposed to get its not-IPv4 address, and why that is
| materially different from existing IPv6 tunnel options.)
| icedchai wrote:
| One problem with this approach is it doesn't really
| expand the address space for _new_ address assignments.
| We 're still stuck within the 32-bit IPv4 space for the
| "outer" routing. This seems worse than simply tunneling
| IPv6 for users with ISPs that don't support it yet.
| throw0101d wrote:
| > _Then IPv6 traffic could pass over IPv4 networks
| without any changes. The only constraint would be that
| each IPv6 network would have to have an IPv4 "gateway"
| address._
|
| So:
|
| * https://en.wikipedia.org/wiki/Teredo_tunneling
|
| * https://en.wikipedia.org/wiki/6in4
|
| * https://en.wikipedia.org/wiki/ISATAP
|
| You can sign up for an IPv6 connection, without any IPv6
| support from your ISP, via Hurricane Electric's tunnel
| service:
|
| *
| https://wiki.archlinux.org/title/IPv6_tunnel_broker_setup
|
| * https://docs.netgate.com/pfsense/en/latest/recipes/ipv6
| -tunn...
|
| It's been around for at least a decade:
|
| * https://www.internetsociety.org/blog/2014/01/weekend-
| project...
|
| Any 'expanded IPv4 address' solution will (have) face the
| same problems that IPv6 has faced, and the solutions will
| end up being the same: having to slowly upgrade the
| network stack (hosts, routers, firewalls, ASICs), changes
| in networking system calls and associated _structs_
| (because the number of bits), gateways and transitions
| mechanisms, expansion of related protocols (DNS A records
| are only 32-bits, so a new record type needs to be
| supports (e.g., AAAA for IPv6, AAAAAA for your new
| proposal)).
|
| If you want to argue that we should have (say) kept ARP
| instead of moving NDP, sure.
|
| But anything to do with expanded addressing would be the
| exact situation: code upgrades and transition mechanisms.
| lloeki wrote:
| > It's been around for at least a decade
|
| I just logged into tunnelbroker.net to check: my HE
| account has been registered November 22, 2010 11:30:00
| UTC. Today it's unused because IPv6 is basically always
| available in France.
|
| That's not even the first time I tried IPv6 things, part
| of it being I had some access to RENATER via my
| engineering school, right when they kicked off IPv6
| around 2002.
|
| The past 10 years of IPv6 have been largely uneventful
| for me: _it just works_.
| akira2501 wrote:
| > The only constraint would be that each IPv6 network
| would have to have an IPv4 "gateway" address.
|
| In your scheme, any IPv4 address is automatically
| expanded into an IPv6 gateway address, since there is no
| other way to map that partial addresses together. So, for
| every /32 of space you want to add, you have to get
| another IPv4 and use it as a gateway.
|
| It's also going to be a massive amount of fun doing
| "second level CIDR" on those gateways.
|
| You've just turned CGNAT inside out to no real benefit.
| JackSlateur wrote:
| Pretty simple indeed Will it rewrite all my hardware,
| without it nothing will work ?
|
| No You'd need a full rewrite at the parser level
|
| As everybody said : ipv4 cannot be made compatible with
| larger addr space
| chadsix wrote:
| We do backwards and forwards compatibility between v4 and
| v6 using NAT64+DNS64 between IPv6 -> IPv4[1] and a reverse
| proxy (delorean) for IPv4 -> IPv6 [2]. To ensure
| reachability to IPv4 endpoints without a domain, we use
| visibleip.com [3].
|
| For our users, it doesn't matter if it's IPv4 or IPv6 -
| they can reach it, and it can reach them.
|
| [1] https://blog.ipv6.rs/ipv4-activated-via-nat64/
|
| [2] https://github.com/ipv6rslimited/delorean
|
| [3] https://github.com/ipv6rslimited/legacydns
| tsimionescu wrote:
| If they didn't completely rethink how IPs are associated
| with hosts, with the whole SLAAC and privacy address and
| etc crazyness that even ended up making ifconfig
| deprecated, perhaps adoption could have been much quicker.
|
| IPv6 didn't only impact networking devices, it affected
| end-user applications that interact with the network in
| many ways, and this is a big part of the slow adoption.
| ajsnigrutin wrote:
| We had two choices back then..
|
| 1) make everything the same, the good and the bad, just
| extend the address space, and replace all the networking
| stacks in all the gear everywhere.
|
| 2) if we're already replacing everything, make stuff
| better
|
| We chose #2, with varying degrees of what is "better".
| quectophoton wrote:
| And for the record, a backwards-compatible-ish way was
| proposed in 1993
| (https://datatracker.ietf.org/doc/html/rfc1475), by using
| an option in the IPv4 packet header.
|
| AFAIU it was "just" defining an option type; the IPv4
| packet header itself didn't even need to be changed.
|
| 1993 was more than 30 years ago.
|
| So people who wanted to keep it backwards-compatible with
| IPv4 already had a chance.
| throw0101b wrote:
| From SS8.3: Each TCP/IP v7 system,
| whether host or router, must be able to recognize
| adjacent systems in the topology that are (only) v4, and
| call the appropriate conversion routine just before
| sending the datagram.
|
| [...] On networks where ARP is not
| normally used, the method is to assume that a
| remote system is v7. If an IPv7 datagram is received
| from it, the assumption is confirmed. If, after
| a short time, no IPv7 datagram is received, a v7
| ICMP echo is sent. If a reply is received (in
| either version) the assumption is confirmed.
| If no reply is recieved, the remote system is assumed not
| to understand IPv7, and datagrams are converted
| to IPv4 just before transmitting them.
|
| So basically very close to what's done now in the
| IPv4-IPv6 world with Happy Eyeballs (do a DNS lookup, and
| try both A and AAAA responses, and see who answers
| first):
|
| * https://en.wikipedia.org/wiki/Happy_Eyeballs
|
| And let's not forget about all the function and system
| calls that need to be updated (SS2.4) because various
| _structs_ are of a fixed sized: There
| is a non-trivial amount of software that assumes that an
| "int" is the same size and shape as an IP
| address, and does things like "ipaddr = *(int
| *)ptr". This usage has always been incorrect, but
| does occur with disturbing frequency. As IPv7 8 byte
| addresses appear in the application layers, this
| software will find those addresses unreachable;
| this is preferable to interacting with a random
| host.
|
| Just like with IPv6, the IPv7 described in RFC 1475 would
| have needed libraries and data structures to be created.
| Also DNS A records were fixed sizes, and so a new record
| type would have needed to be created for IPv7 (like AAAA
| was for IPv6).
|
| IPv7 would have had the exact same issues that IPv6 had
| with rollout.
|
| There is no "just" when trying to expand a fixed-size
| data structure across the entire planet.
| ninkendo wrote:
| It's interesting because much of the "better" has eroded
| away in the current IPv6 landscape:
|
| - "You don't need NAT": well, you still need a stable
| address space for your LAN that survives your ISP
| randomly changing your prefix (which has happened to me
| at least a half dozen times over the past year), and the
| best option for that is ULA, which erodes many of the
| benefits of "no NAT" because my IP's are not routable.
|
| - "No DHCP", well you can't reliably know the IP address
| of anything on your network without it: SLAAC with EUI-64
| was supposed to make addresses stable and derived from
| your MAC address, but oops, that's a privacy nightmare,
| so we end up randomly generating them (and rotating
| them!) IMO this is more complicated than DHCP, not less.
| Oh and DHCP lets you assign dynamic DNS names to every
| lease you hand out, and you lose that too with SLAAC. You
| can do mDNS but that doesn't help with public hosts that
| you want to access from the internet, you're left with
| static IPs there, and god help you if you get re-prefixed
| (see point #1) because now your static IP won't route
| because your ISP changed the prefix.
|
| I'm really rooting for ipv6, trust me, but it feels like
| all the greenfield rearchitecting they did ultimately
| doesn't seem much better than the IPv4 equivalent
| standards. NAT is here to stay, unfortunately, and so is
| DHCP.
| alerighi wrote:
| You could have just extended the IPv4 header in such a way
| that the routers in between you and the server didn't need
| to understand the extended protocol, and could continue to
| route IPv4 packets as-is, since they only see the upper 32
| bit of the address. Then network inside LAN and the server
| need of course to understand IPv4-extended (let's call it
| IPv5) packets, but still you only need to update the
| endpoint devices, and not the core of the network (fare
| easy, since that evolves more quickly!). You could also
| implemented a mechanism "similar" to NAT, where the router
| did for outgoing traffic compose the extended "IPv5" packet
| by combining the local IPv4 and the external IPv4, and did
| the opposite operation for incoming packets. That way
| really only the router needed to be updated, and not
| individual devices in your house. Thus being backward
| compatible in both ways.
|
| Also adopting IPv6 these days would require to maintain
| still IPv4, this means that for example firewall rules must
| be made both for IPv4 and IPv6, something that adds a lot
| of work to IT technicians (and they thus disable the
| protocol that if you disable the internet still works, that
| is IPv6). Extending IPv4 would mean that the same firewall
| rules can apply, just considering again the upper 32 bits
| of the address.
|
| Finally IPv6 is in general more complex, it has some
| obscure things like SLAAC or the fact that an interface can
| have multiple IPs, that not all IPs are routable, etc, even
| simply the notation for IPv6 addresses that is not even
| consistent among software (in some software you have to put
| it between [] to disambiguate with port numbers, in some
| other not), DHCPv6 implementations that are still these
| days quite broken, etc. Compared to IPv4 is quite a
| complication...
|
| I'm the opinion that we are slow to adopt IPv6 since it's
| too different from IPv4, and requires maintaining a network
| with two protocols, since everyone completes the
| migrations, this is unlikely to succeed in the next years
| (for example in my country, Italy, most ISP, even the most
| important one, don't even bother to provide you an IPv6
| address! I think that because it does increment the
| problems and thus the requests to handle in the customer
| service, thus they decided that you just get IPv4 that
| works reliably).
| quectophoton wrote:
| > You could have just extended the IPv4 header
|
| Sounds like IPv7, from year 1993:
| https://datatracker.ietf.org/doc/html/rfc1475
|
| > I'm the opinion that we are slow to adopt IPv6 since
| it's too different from IPv4
|
| Doubt, seeing how IPv7 appeared around the same time as
| IPv6 (RFC1883, from year 1995) and we still don't see
| IPv7 anywhere.
|
| To be fair, IPv7 seems to have been deprecated in 2012
| (RFC6814). It had almost 20 years to catch up but,
| quoting the RFC, "IPv7 was never widely deployed".
| Macha wrote:
| Earlier IP migrations were done when the internet was run by
| universities and government bodies who felt the need to
| migrate to a newer standard because there was a newer
| standard.
|
| IPv6 took longer because the internet is now run by companies
| that need to see a return on investment, and as long as IPv4
| was working fine for their customers, didn't see a benefit to
| it. It's why IPv6 adoption only started taking off when the
| answer to "Our projected customer growth this year is
| 200,000, can we have 200,000 more IPv4 addresses please?"
| became "No".
| api wrote:
| It was created by people who were used to the Internet being
| an ultra high trust relatively close knit community of
| universities, research, government, and industry. Upgrades
| across the net had happened before just fine. This one should
| be no problem.
|
| This was around 1996, which is when the vertical growth phase
| took off. Too late.
| tonetegeatinst wrote:
| This. IPV4 is a mess.....and its extremely frustrating just how
| unsupported ipv6 is.
|
| IPV6 is one of those things where if isp,'s just switched over
| to it, I'd have so less nightmares caused by cgnat and that
| bullshit like how expensive static IP's are.
|
| Many its because I'm not working at a ISP or a teir 1 backbone
| but forcing the transition to ipv6 seems like overall it would
| be less of a clusterfuck than our current ipv4 stuff. I know
| their is stuff going to break, anytime changes are made at this
| scale it often has some hickups....but dear god I really hate
| how static IP's are so expensive, and how expensive a small IP
| block is. Also IPV6 is just an excuse to get fiber
| everywhere.....I hate how slow many services are.
| mike_d wrote:
| People hail CGNAT and IPv6 as the savior but don't realize
| you still need v4 addresses to make it work.
|
| CGNAT at scale functions by assigning a range of ports on a
| shared v4 address to a downstream customer. You can normally
| get between a 1:8 and 1:32 "compression ratio."
|
| We still need to free up additional IPv4 to keep the internet
| growing. Don't let the "just switch to v6" crowd fool you,
| both solutions need to addressed in parallel.
| viraptor wrote:
| That's a really confusing comment. Cgnat is almost
| universally criticised. IPv6 doesn't need ipv4 addresses.
| Cgnat and IPv6 are not related.
| mardifoufs wrote:
| Maybe they meant NAT64? Not sure though
| api wrote:
| I am absolutely convinced that the main thing holding V6 back
| is not even that it's a full shift rather than an incremental
| upgrade. It's that the addresses are too long to easily
| remember or type and the text representation is unwieldy and
| aesthetically ugly.
|
| Anyone who has ever done net stuff for a living knows that you
| type or copy paste addresses _constantly_. Whenever I say this
| to V6 evangelists they say "we'll use DNS" which is "tell me
| you've never been a net admin without telling me."
|
| I'd love for V6 to get traction but I think something needs to
| be done about the usability issues before it will happen.
|
| Even little details like the fact that in no terminal does
| double clicking on a V6 address properly select it is a huge
| problem. Yeah you might be able to change that but that custom
| config won't be there on the next machine, etc.
|
| Even seemingly simple usability problems are death to adoption.
| jauer wrote:
| I'm a NetEng for a large (>1M servers, >100 POPs) network
| that is IPv6-only internally.
|
| It's not hard to remember IPv6 addresses for DNS servers
| assuming your addressing plan reserved the right subnets for
| anycasted services.
|
| Remembering IP addresses stops being a thing pretty quickly.
| If anything the challenge shifts to remembering airport
| codes.
|
| If you are typing them by hand that often even in IPv4
| networks I'd be worried about typos and insufficient
| automation.
|
| I think it's more that small and medium organizations just
| don't have any incentive to change (and plenty of incentive
| to not take the risk of change) leading to the numbers we see
| at https://ipv6-in-real.life/
| michaelt wrote:
| _> If you are typing them by hand that often even in IPv4
| networks I 'd be worried about typos and insufficient
| automation._
|
| Automation is all very well _once the network link is up
| and working so you can reach the automation_
|
| But the reality is you put someone who knows what they're
| doing in front of a machine where the network connection
| isn't working, the first things they're going to be doing
| is ifconfig and ping 8.8.8.8 - which they'll be doing from
| memory, because you can't google anything when your network
| connection isn't working.
|
| The fact that IPv6 will deprecate both ifconfig and 8.8.8.8
| to me seems emblematic of why the adoption has been going
| so badly.
| JackSlateur wrote:
| ifconfig is deprecated for years, and this has nothing to
| do with ipv4 nor ipv6 Checkout iproute2 and its
| impressive feature list
| oofabz wrote:
| 2600:: is shorter than 8.8.8.8 and iproute2 is much more
| pleasant to use than ifconfig.
| vaylian wrote:
| github.com reachable via IPv6 when?
| eqvinox wrote:
| When you set up NAT64...
|
| ... :-( ... _goes to cry in a corner_
| mikl wrote:
| The absurd lengths this industry goes to, only to avoid the
| switch to IPv6. Wish the FCC would step in with a mandate or
| something, it's just long overdue.
| xacky wrote:
| Networking software and routers without ipv6 should be
| considered a security issue at this point and should have CVEs
| assigned against them. It's amazing how we deprecated
| unencrypted http across the internet but still use the
| equivalent for ip addresses.
| john01dav wrote:
| Ipv4 is deeply flawed and needs to be replaced, but how is it
| insecure? CVEs are specifically for security issues.
| lagniappe wrote:
| This is NOT how the CVE system is used.
| DaSHacka wrote:
| > It's amazing how we deprecated unencrypted http across the
| internet but still use the equivalent for ip addresses.
|
| This makes no sense, http is flawed because its unencrypted
| and allows MITMing information.
|
| IPv4 is flawed merely because it doesn't have enough
| addresses.
|
| How are these two comparable? Your proposed "solution" is
| overkill and is completely ridiculous.
| itchyouch wrote:
| It's not a logical argument, but if we only take the part
| about the transition to https, the difference was that
| https and http coexisted with mostly full compatibility to
| go between the 2 for its whole life. And it lives at layer
| 4.
|
| A more cogent argument is that IPv4 and IPv6 have not fully
| coexisted like http/https, where you can pull the ipv4 rug
| out and every packet has an ipv6 path like http to https
| did.
|
| Also more profoundly, https conversion had the benefit of
| every operator being able to transition on their own time
| frame. And people can still opt to use http if they so
| choose. IP not having that luxury is a profound problem.
| fullspectrumdev wrote:
| Ah yes, more abuse of the CVE system. Real Linux foundation
| vibes off this.
| tsimionescu wrote:
| IPv4 is _exactly_ as secure as IPv6.
| umanwizard wrote:
| The industry _is_ switching to IPv6, just slowly. Google 's
| report of the fraction of users accessing its services on IPv6
| steadily rises by a few percent a year. Right now it's at about
| 45%, so it'll be the majority in about two years.
| john01dav wrote:
| Such a mandate would still be useful. Even of 80% of users
| can view things on ipv6, very few people will sacrafice the
| 20%.
|
| I'd like to see rules that force ipv6 support, and then to
| prevent idiot network admins from disabling ipv6 locally
| because they're too lazy to learn how it works, make some
| websites v6 only. Start with essential government websites
| and move on to laws forcing more and more private websites to
| be v6 only to force people to maintain its functionality in
| their networks.
|
| See: https://konecipv4.cz/en/
|
| The market has been given its chance to move for DECADES and
| we're not NEARLY at the approximately 100% deployment that we
| need. It's time that we fix this mess.
| jcranmer wrote:
| Here's Google's graph:
| https://www.google.com/intl/en/ipv6/statistics.html
|
| Adoption rate is currently increasing roughly linearly at a
| rate of about 5 percentage points every 12-18 months. Also
| note that there is a clear weekday/weekend pattern, with
| weekdays about 3-4 percentage points lower than weekends.
| rnhmjoj wrote:
| I wonder what happened in March.
| rvnx wrote:
| It means 100% adoption will be in 2040 using linear
| regression model.
| mike_d wrote:
| IPv6 "adoption" is happening at roughly the same rate as
| the move to handheld devices becoming the primary browsing
| platform. The weekday split you see is people being on
| their work computers during the day and personal
| tablets/phones on weekends.
|
| Very little progress has actually been made to move the
| bulk of stuff using v4 addresses over to v6. AWS v6 only
| instances have only been around for 20 months or so?
| ehPReth wrote:
| my ISP has no plans for it.. and even escalating it to the
| highest levels the best answer was something like they're
| focused on upgrading physical infrastructure and aren't
| bothering with IPv6 at this time (despite me casually asking
| for 10+ years)
| photonbeam wrote:
| We need the FCC to say its a requirement for 2028 or some
| such year
| tsimionescu wrote:
| You do realize that the FCC doesn't have jurisdiction
| over pretty big parts of the Internet?
| mikl wrote:
| Sure, but what happens in the U.S. part of the Internet
| tends to set the tone for the rest. A U.S. mandate would
| do a lot to swing things in the right direction, and many
| other countries would likely follow along and pass
| similar mandates.
| mikl wrote:
| Yeah, problem is that we're competing with ~99.99% for IPv4.
| So until IPv6 gets in that ballpark, most Internet servers
| (HTTP and friends) will still need to IPv4 addresses. And as
| long as that is true, many companies won't bother and their
| service will be IPv4 only. Meaning ISPs must continue to
| offer IPv4 connectivity to their customers.
|
| A true chicken and egg problem.
|
| At this rate, we'll be struggling with IP-shortages, CGNAT
| and other fun things for decades to come. And it's all so
| unnecessary.
| myself248 wrote:
| Just drop all ipv4 traffic for one minute at noon UTC every
| day. Next month, extend it to two minutes. The stragglers will
| switch.
| mike_d wrote:
| This is how you end up with a nationwide ban on IPv6. When
| traffic lights start flashing red, flow control valves in the
| water distribution system fail safe closed, and ATMs don't
| work people will quickly discover the correlation with your
| silly plan.
| binwiederhier wrote:
| Great article, thank you for enlightening us.
|
| > While there are somewhat ongoing efforts to see 0.0.0.0/8,
| 127.0.0.0/8 become routable unicast space
|
| I am curious about this statement. How can 127/8 ever become
| internet routable? It is after all used for the local host. Or am
| I misunderstanding something here?
| greyface- wrote:
| Most deployments only use 127.0.0.1/32. Some niche cases use
| 127.0.0.0/24. Vanishingly few use more than that. Keep the /24
| reserved for local use, and repurpose the rest for global
| unicast.
| benjojo12 wrote:
| systemd's resolved commonly uses 127.0.0.53, Given the
| deployment of systemd I would not really call that a niche
| cases in terms of volume, but I do agree in general that
| 127.0.0.0/24 would in theory be enough. However the whole
| discussion on repurposing 127.0.0.0/8 is mostly academic as
| it will be basically impossible to use reliably
| greyface- wrote:
| My plot to pretend systemd doesn't exist has been foiled
| once again!
|
| Agreed that it would be impractical to actually use these.
| Maybe for linknets?
| itchyouch wrote:
| Give it to someone like Google and I'm sure every corporate
| ceo will demand that Google.com loads from their
| infrastructure.
| loeg wrote:
| MacOS gives the loopback 127.0/8: inet
| 127.0.0.1 netmask 0xff000000
|
| As does Linux (Fedora): inet 127.0.0.1
| netmask 255.0.0.0
| greyface- wrote:
| The whole /8 is "on-net" for the loopback interface, but
| that doesn't mean it's usable to applications. On macOS, I
| can't ping or bind to 127.0.0.2, for example. Linux's
| behavior of allowing the whole /8 to be used, even when
| only a single address is assigned, is a bit of an oddity
| here.
| akira2501 wrote:
| > I can't ping or bind to 127.0.0.2, for example.
|
| You can as soon as you define it as an alias.
|
| > Linux's behavior of allowing the whole /8 to be used,
| even when only a single address is assigned, is a bit of
| an oddity here.
|
| Per the RFC: "127.0.0.0/8 - This block is assigned for
| use as the Internet host loopback address. A datagram
| sent by a higher level protocol to an address anywhere
| within this block should loop back inside the host."
| greyface- wrote:
| Yes, exactly. If I connect a physical loopback adapter to
| a network interface, I can't just ping any on-net address
| and expect a response. I need to add it as an explicit
| interface address/alias first. Just because the packet
| loops back on the interface doesn't mean that it will
| then be treated as if it were addressed to the host.
|
| Linux special-cases 127/8 on the virtual loopback
| interface and will treat all looped-back packets as if
| they were addressed to the host, even when the
| destination isn't explicitly configured as an alias. This
| behavior is not required by the quote from RFC3330.
| hinkley wrote:
| Docker desktop also uses 127.0.0.11 for dns
| toast0 wrote:
| I've used 127.0.0.0/16 for real work[1]. Keeping a /16 is not
| much cost and helps out a few more niche cases. Although, I
| guess if it wasn't available, I could have used a /16 in
| private space that didn't overlap with my existing network.
|
| [1] I needed a lot of localhost connections to run a TLS
| terminator separate from the underlying service which didn't
| support unix sockets. Using the 127.0.X.0 bits in addressing
| was very helpful for diversity in the hash used for kernel
| socket tables, otherwise most slots had few sockets and some
| slots had way too many and perf was bad. Configuring multiple
| loopback interfaces using more address space was a lot more
| tractable than changing the kernel hashing behavior, adding
| unix socket support to the underlying service, or adding good
| TLS to the underlying service. Although probably since then
| all three things have happened.
| themoonisachees wrote:
| I think the intent comes from the fact that most people never
| use any other address that 127.0.0.1 (yes, I know about docker
| DNS). It sort of comes across as if you were "wasting" a large
| block of adresses on functions that are seldom used. In reality
| though, this isn't a solution and we should really just go
| forwards with ipv6.
| zie wrote:
| Where there is a will, there is a way. Off the top of my head,
| most localhosts stay within 127.0.0.X/24, so one could slowly
| peel off the top parts of the /8 until we start encroaching too
| closely on the /24 most people tend to stick to.
|
| Sometimes you see 127.0.1.X/24. I've even seen 127.1.X.X
| around, but I've never seen 127.254.X.X around. I'm sure
| someone somewhere did it just for grins and giggles or
| something though.
| bewaretheirs wrote:
| The same way that 240/4 can become internet routable: a global
| effort to change defaults and push code and configuration
| changes everywhere over the next two decades.
|
| It isn't all in use on most machines. Many hosts only use
| 127.0.0.1/32 and do not use the rest of the space; changing the
| default netmask on the loopback interface from /8 to something
| like /24 would be one step of the transition.
|
| Like 240/8 it's probably not worth the effort.
| obscurette wrote:
| The current proposal is to reduce loopback subnet size from /8
| to /16 - https://github.com/schoen/unicast-
| extensions/blob/master/127...
|
| I think that it's the most problematic proposal from all these
| - unlike 240/4 etc every ip stack on earth has hardcoded
| knowledge about 127/8 for sure and it will took at least
| decades to deprecate all these. And I also have seen addresses
| other than 127.0.0.x used in wild. As far as I understood, some
| orchestration systems use generated 127.x.x.x addresses to
| avoid conflicts between applications. Linux makes it very easy
| - you just bind an application to 127.45.2.189 for example and
| it just works. There is no need to add it to the interface or
| something.
| phildenhoff wrote:
| If an organization ever had the technical control over their
| network to make 240.0.0.0/4 usable, why would they not use IPv6
| instead?
| bell-cot wrote:
| An org with that level of technical control might well be an
| extremely security-conscious org. And "No IPv6 Anywhere, Ever"
| would make it somewhat easier to keep things secure.
| phildenhoff wrote:
| Ah, for the companies with high technical control, but no
| technical competence! Of course :)
| bell-cot wrote:
| If your #1 goal is to keep the stuff you manage secure,
| then keeping that stuff as simple as practical is a pretty
| obvious strategy.
|
| If your #1 goal is to keep your 133t bragging rights, then
| there are no such things as unnecessary nor excessive
| complexities.
| zokier wrote:
| A brick is very simple and very secure. Some might say
| practically unhackable.
| DaSHacka wrote:
| It would presume its significantly easier to implement routing
| for a few more blocks of IPv4 addresses than switch the entire
| underlying infrastructure to IPv6, which requires different
| infrastructure than IPv4 to work properly (like dealing with
| SLAAC/DHCPv6 addresses, ICMP, and AAAA addresses)
| omoikane wrote:
| They might have to interact with a lot of devices that only
| support IPv4, and will never upgrade. These include a lot of
| industrial PLCs and various embedded devices.
|
| 10.0.0.0/8 might seem like a lot of addresses, but certain
| large companies have enough fans and chillers and miscellaneous
| things that can fill that space, and it takes a lot of effort
| to reorganize their network to better allocate those addresses.
| helf wrote:
| Sadly I'm in that position. I have hundreds of PLCs and
| legacy controllers on my network that are IPv4 only and will
| never be replaced. At least not in a reasonable time frame.
| I'm talking 20+ year life expectancies.
| michaelt wrote:
| _> 10.0.0.0 /8 might seem like a lot of addresses, but
| certain large companies have enough fans and chillers and
| miscellaneous things that can fill that space_
|
| Do these large companies _really_ have 16,777,216 fans and
| chillers? That would be enough for each of Wal-Mart 's 10,586
| stores to have 1500 IPs each.
|
| Or do they just have legacy allocation mistakes?
| omoikane wrote:
| > Do these large companies really have 16,777,216 fans and
| chillers?
|
| Some of those might be regular servers or networking gear
| that are required to have IPv4 addresses for one reason or
| another. For example, they might need to interact with fans
| and chillers.
|
| > legacy allocation mistakes
|
| Requiring the same globally unique prefix for devices that
| share locations or functions would eat up allocations
| faster than the number devices would grow. But there are
| definitely good reasons for allocating addresses that way,
| just as there are probably good reasons why the number of
| ports on a switch isn't always a power of 2.
| Symbiote wrote:
| If they will never upgrade then they can't use 240/4 either.
| loeg wrote:
| > Since the internet was at the start not obviously going to be
| used, the minimum allocation size for an address block was a /8
| at the start, later on we got "classful" allocations where a /16
| would be assigned instead (this is why you often see /16s
| assigned to universities or institutions of similar ages),
|
| Classful allocation had /8s, /16s, and /24s depending on the
| numeric prefix (0-127 were /8, 128-191 were /16, and 192-223 were
| /24).
|
| https://en.wikipedia.org/wiki/Classful_network#Classful_addr...
| jcalvinowens wrote:
| Ugh, this is RFC1918 all over again, but worse.
|
| IPv6 has none of these problems by design: use it.
| benjojo12 wrote:
| (blog post author here)
|
| No in fact, it is _so much worse_! I do agree we should use
| IPv6, The ending of the blog post says as such :)
|
| > If we are going to start using address space that might not
| work for all users, it would be wise to pick the address space
| that we already have a considerable head start on getting
| accepted: IPv6.
| jcalvinowens wrote:
| I'm yelling at the people doing this shit, not you :)
|
| Somehow it is getting more and more common. I stayed at a
| hotel last year that used 1.0.0.0/24 on its LAN (yes, '1' not
| '10', I couldn't believe it at first).
| schoen wrote:
| Hi everybody,
|
| I'm not connected with this presentation (other than having
| talked to Ben about it prior to his giving it, and I guess
| supplying some of the information on software that accepts 240/4)
| but I am one of the people working on the project that he
| describes/criticizes.
|
| Here is our current proposal.
|
| https://www.ietf.org/archive/id/draft-schoen-intarea-unicast...
|
| People have been reacting to this with different forms of "just
| do IPv6" for many years. I guess we need an official statement
| about that somewhere. [Edit: other than these quick thoughts
| below...!]
|
| I personally think IPv6 is great (I was excited about it in the
| late 1990s when it was standardized, and gave some talks to
| promote it, and am happy to see it getting deployed and happy to
| find myself using it sometimes). I hope people will keep working
| on it and networks and services will keep adopting it.
|
| However, people's need for IPv4 address space depends enormously
| on _other people 's_ behavior. IPv6 addresses are not a good
| substitute for IPv4 addresses when you're providing a public
| service, if many of your _users_ don 't have IPv6. A high
| fraction of demand for IPv4 address resources appears to come
| from organizations and networks that _already_ support IPv6,
| because they need dual-stack support for compatibility with
| _other people_.
|
| Even though IPv6 adoption has been happening, it's easy to
| imagine that it's "almost done" where that really doesn't seem to
| be the case. (This is complicated by having very different
| statistics in different countries: some countries are now almost
| all IPv6 traffic, while others have almost no IPv6 -- so people
| in different parts of the world often have rather different
| intuitions about it.) We still see enormous economic demand for
| IPv4 address space and projections that IPv6 adoption _to a point
| where IPv4 would somehow no longer be useful or important_ is
| likely still decades away. If that 's correct1, we can still get
| a benefit from making 240/4 usable because that process can be
| substantially complete during a time when IPv4 is still extremely
| important.
|
| One thing that Ben (and one of the questioners at the end) argued
| in his presentation is that even if the adoption of IPv6 is
| unreliable or erratic, it might be _more_ reliable than useful
| adoption of 240 /4. (This was kind of phrased in the converse
| direction.) I'll have to think about models of that issue.
|
| Edit: We have been sad when seeing how proposals to make 240/4
| usable were made in 2008, but not adopted at IETF. Among things
| that people said in 2008 was that IPv6 would make this irrelevant
| quickly. That turned out not to be right, but we lost years of
| opportunity to make 240/4 more useful in the meantime, where
| billions of devices shipped in the interim could easily have
| supported it by default. So, we still have the opportunity not to
| have the same sense of regret in 2035.
|
| 1 I'm also aware that there are other projections here; I
| recently interviewed a prominent Internet greybeard figure who
| theorized that Internet infrastructure growth as a whole has
| slowed so much that IPv4 demand may be satisfied in the future
| out of gradual conversion of residential ISPs to using primarily
| carrier-grade NAT for IPv4, and then selling off their number
| resources. In this account, IPv4 will remain important on the
| Internet for a long time, but economic demand for addresses will
| decline because most users won't have native IPv4 at home or on
| their mobile devices (the latter already the case in many
| networks). The economic demand for IPv4 resources is something
| that has made reclaiming 240/4 appear worthwhile, so in this
| model it would become less exciting, even without having IPv4 "go
| away".
| chadsix wrote:
| Just wanted to chime in and say thank you Seth for all of the
| work you did to create LetsEncrypt.
|
| You've made the internet safer for all of us.
|
| I believe that IPv6 [1] is without a doubt coming in the
| future. Even with carrier grade NAT'ing and the likes, there
| are too many major providers who have already switched to
| single stack IPv6 natively.
|
| That said, I agree that 240/4 is necessary to assist with the
| transition. Due to the fact that most network operators aren't
| even dealing with /24's, it becomes increasingly hard to
| facilitate bridges between the legacy IP and IPv6 so more IPv4
| space is always appreciated (until the day we don't need to
| bridge at all).
|
| [1] I may have a bias due to affiliation with https://IPv6.rs
| akira2501 wrote:
| > depends enormously on other people's behavior.
|
| The disappointment is there seems to be no difference between
| "needing a single open port" and "needing and entire IP
| address" due to overzealous egress firewall rules that everyone
| thought was good engineering practice 20 years ago.
| the8472 wrote:
| I wish it were just some old boxen from 20 years ago.
| $employer STILL does port-based firewalling and thinks it's
| great policy. Just getting SSH to github requires requesting
| an exemption.
|
| edit: spelling
| frutiger wrote:
| > some old boxens
|
| Aside: in this vernacular, plural of ox is oxen; plural of
| box is boxen. "boxens" is never appropriate.
| schoen wrote:
| I want to say something else about IPv6 adoption! (Apart from
| how you can't necessarily unilaterally stop using IPv4, even if
| you can unilaterally start using IPv6.)
|
| There is a great level of IPv6 awareness and enthusiasm in sort
| of technically elite spaces. Like at Ben's talk at RIPE that
| we're talking about, the audience was kind of laughing together
| at the non-IPv6 outgroup.
|
| Meanwhile, I keep helping people use Let's Encrypt over on the
| Let's Encrypt forum. One of the most common reasons that people
| are failing to get their certificates is ... misconfigured IPv6
| on their servers or in their DNS! And people in that situation
| often (1) didn't think of that as a possibility, (2) didn't
| notice (!!), (3) didn't necessarily care about it. Even worse,
| when people are told something like "your certificate issuance
| isn't working because your AAAA record is pointing at your old
| hosting provider rather than your current hosting provider"
| their usual response is to _delete the AAAA record_ rather than
| updating it.
|
| Other forum members may also advocate this as a solution. "Oh,
| just delete your AAAA record, you don't need it."
|
| I'm not making this up, I've seen these things happen about 100
| times on the Let's Encrypt forum.
|
| Now, these are primarily sites in the long tail of Internet
| popularity, the proverbial Joe's Lamp Store rather than Gmail
| or Facebook or something. But the level of IPv6 awareness and
| interest among small-scale site operators and people doing
| small-scale IT stuff is very weak. And I've also seen that a
| surprisingly high fraction of web sites are IPv4-only rather
| than dual-stack.
|
| I'm working on 240/4 usability, but I certainly _don 't_ want
| people to delete their AAAA records. I want them to know what
| an AAAA record is, and want to have their AAAA records be
| correct.
|
| But there's quite a gap, in a way, between the elite and the
| non-elite tech spaces on this.
| beefnugs wrote:
| wait... what about ip6 and lets encrypt? I thought I had it
| working with no ip6 anything or AAAA records??
| saghm wrote:
| It sounded like they were saying that people had badly
| configured IPv6 and/or AAAA records that prevented stuff
| from working; the fact that you don't technically need it
| is why the "solution" of deleting AAAA records would make
| sense in this context. If my understanding is correct, then
| part of the problem of IPv6 adoption is people not really
| understanding what it is or why it might be useful, instead
| seeing it as a nuisance that they should avoid. Crucially,
| they're not exactly _wrong_ with this viewpoint because
| IPv6 doesn't really provide any benefits at the individual
| adoption level; the benefits are only realized if others
| adopt it as well, and that's not likely to be a convincing
| argument to someone having a concrete, immediate issue with
| their servers that they can address (pun intended) by not
| supporting IPv6.
| schoen wrote:
| Yes, exactly.
|
| If you do have AAAA records, Let's Encrypt (not unlike
| other software and services!) will _prefer_ the AAAA
| records when doing domain validation for your domain. So
| if you have a correct A record and an incorrect AAAA
| record, your domain validation process will fail. You can
| then "fix" this by deleting the AAAA record, but it
| isn't a fix in the larger scheme of things, but indeed it
| makes plenty of users happy right away.
| redox99 wrote:
| I intentionally disable IPv6. It provides no advantage
| whatsoever (every user will be able to connect via IPv6) and
| it adds complexity and security risks, because you need
| separate firewall rules, dns records, etc for each stack.
|
| In addition, rate limiting with IPv6 is much harder (because
| IPs aren't scarce), so you risk DoS or other kind of abuse.
| viraptor wrote:
| A similar issue is documentation. I wish more companies
| defaulted to IPv6-and-also-IPv4 examples rather than other
| way around. Or at least make them same importance rather than
| ignore/hide the v6 part.
| tjoff wrote:
| > _I 'm also aware that there are other projections here; I
| recently interviewed a prominent Internet greybeard figure who
| theorized that Internet infrastructure growth as a whole has
| slowed so much that IPv4 demand may be satisfied in the future
| out of gradual conversion of residential ISPs to using
| primarily carrier-grade NAT for IPv4, and then selling off
| their number resources._
|
| That is one projection, but it is also a very bleak view of the
| future. One that we should actively fight at any opportunity
| and at almost any cost. It will centralize the internet further
| and squash many attempts for alternative communications.
| derefr wrote:
| > It will centralize the internet further and squash many
| attempts for alternative communications.
|
| Would it? It seems to me that a future where 1. every home
| land-line Internet connection is CGNATed; but 2. every
| _cellular_ Internet connection is a public IPv6 prefix (as is
| already mostly the case today!); is actually a promising one.
| _Provided_ , that is, that residential ISPs also get off
| their collective asses and provide the promised "hosted edge
| compute" capabilities they've been tinkering with for the
| last 10 years.
|
| Since the Internet's inception, people on residential
| connections have been stuck in a broken mindset of "your home
| PC _can_ act as a monolithic Internet peer -- but only an
| unreliable one, that can 't receive messages when it's shut
| off and is prone to being DDoSed -- so you probably shouldn't
| actually _use_ it as a server /p2p node, for anything other
| than, say, VoIP, or hosting an ephemeral multiplayer FPS game
| session. And you can _tinker_ with a development web-server
| on your home network -- but if you want to actually _host_
| anything, you should go pay a cloud provider. "
|
| Whereas, in a world with no well-Internet-connected home PCs
| providing the _illusion of the possibility_ of hosting a home
| server, only instead:
|
| 1. home PCs -- which can compute well, but _can 't_ be a
| network-ingress, and also might go down (often for laptops,
| less often for desktops, but both far more often than a real
| server would);
|
| 2. smartphones -- which _can_ network-ingress, but can 't
| spend long periods computing (without burning all your
| battery life), and which will go down / out of wireless range
| _extremely_ often; and
|
| 3. both commercial, and more importantly _ISP-residential_ ,
| edge-compute clusters -- which would give tiny compute slices
| per workload, but ones with full network-ingress, and would
| _never_ go down;
|
| ...then it 'd be clear to all the people who had been
| thinking until that point that they could get away with p2p
| on home PCs using STUN/TURN-based protocols, that they would
| have to _do something else_ ; that operating systems (esp.
| mobile ones) and their client-server/p2p applications would
| have to evolve to become inherently edge-hybrid; that
| applications would need to evolve frameworks to embed
| persistent network-ingress "edge components" that could be
| shipped automatically and implicitly to the active network's
| associated edge deploy environment as part of the
| application's runtime; etc.
|
| If you can't picture that: think about a web server backend
| that automatically deploys/updates an associated Cloudflare
| Worker whenever it boots up; and which then expects to be
| talked to through that Cloudflare Worker proxying requests to
| it; and where that Worker can also buffer requests, store
| data into its edge key-value store, etc.
|
| But instead of a web server backend, it's the Minecraft app
| on your phone; and instead of Cloudflare, it's your
| residential ISP; and instead of the edge worker making a
| forward connection to your phone, your phone holds open an
| ngrok-like reverse connection to the edge worker to receive
| requests.
|
| (Oh, and one other point of necessary evolution: that the
| "server component" of any p2p app would also be a mobile
| workload -- not shiftable to the edge itself, but rather
| _through_ the persistent edge workload _to_ any [similarly
| reverse-connected, not always online] "compute host nodes"
| owned by the same user/organization. Such that you could buy
| a little NUC/NAS-like box to shove under your TV at home,
| whose marketed purpose would be compute+storage offload for
| the workloads launched on your phone; or such that your
| office could have some server racks for free auto-offload of
| "server components" of apps running on any employee machine
| -- reversing the usual "cloud app with local client"
| relationship into "local app with slaved cloud workload."
| Where, in either case, the relevant workloads are still
| _canonically_ on your phone /PC, so if the "compute offload"
| has to be drained for an update, the workloads just
| temporarily migrate back to your phone/PC.)
|
| From my perspective, this would actually be a much _better_
| Internet _in practice_ than the one we have today.
| Individuals would be far more able to host persistent,
| accessible services on a whim, without investment into local
| infra _or_ being beholden to a commercial provider with a
| ToU. Individuals would be paying their ISPs for edge hosting,
| yes (if they don 't have a server with a public IP to run an
| "edge layer" on themselves); but --
|
| * those would be small fixed costs (as apps' network-ingress
| components would be small fixed workloads);
|
| * and would likely be sold as free value-adds of data plans
| (just like web hosting, email, and access to locally-mirrored
| NNTP groups used to be sold as value-adds of residential
| Internet plans);
|
| * and such workloads would only be smarter versions of the
| "dumb pipe" the residential ISP was already providing, not
| backends in-and-of themselves; and so wouldn't be subject to
| a VPS-host-like "you can't host X/Y/Z on our servers" type
| ToU, because users are not _hosting_ anything per se;
|
| * and as such edge workloads live on a very high-level
| abstraction layer, an edge-hosting ISP would be empowered to
| do all sorts of things to defend such workloads from DDoS
| attacks (e.g. putting the known-protocol workload behind a
| layer-7 WAF), that it can't do for individual customers'
| single-homed single-IP single-port, arbitrary-protocol home
| PC server processes.
| caf wrote:
| I don't see this ever happening.
|
| As you say, residential ISPs _used to_ provide additional
| services to their customers like web hosting, email, NNTP,
| shell access, time synch, IRC, mirrors of popular archives.
| They don 't anymore - frequently, not even email. ISPs have
| clearly shown that they're not interested in being much
| more than the fastest dumb pipe around, because that's what
| their customers want, and I don't see that trend reversing.
| derefr wrote:
| To be clear, residential ISPs already _do_ provide edge-
| compute hosting... _for corporations_.
|
| When Netflix and others put CDNs "at the edge", they
| aren't doing that by building their own DC inside your
| city; nor by renting space in a random colo facility.
| Rather, they partner with each of the local regional
| ISPs, to put their CDN inside the ISP's "edge hosting DC"
| -- a facility that almost all ISPs own (if not
| necessarily manage) at least one of in every city,
| precisely for the purpose of enabling such agreements.
|
| So, unlike most Over-The-Top data services (which ISPs
| have long since lost the _competency_ for), this one is
| something ISPs _are_ actively doing. They 're just not
| selling it B2C; their edge data-centers are currently a
| pure B2B play for them. But ISPs do _know_ how to sell
| things B2C -- so this would just be a question of them
| _feeling enabled by product re-packaging_ to give this
| product line over to their B2C sales and marketing
| departments as something to charge their customers for.
|
| "Re-packaging" this B2B colo into something they can sell
| to customers, would in turn just require the mobile OS
| vendors to step up and write code to make doing so an ops
| question rather than an R&D question -- just as they did
| for visual voicemail, wi-fi calling, eSIM deployment, and
| so on. Essentially, Apple and Google would just need to
| provide their own server racks to ISPs, which host
| workload hypervisors for offload of workloads from
| "their" devices -- in such a way that offload wouldn't be
| something customers would be paying Apple or Google a
| subscription fee for, but rather, as with Visual
| Voicemail, something where usage records from this system
| could feed into the ISP's usage-accounting systems, to be
| reduced into billing items by arbitrary ISP data-plan
| business rules.
|
| (And _hopefully_ -- but I 'm not holding my breath --
| this would be done using open protocols and with FOSS-
| replicable software, such that eventually the ISPs could
| stop relying on Apple and Google to provide this only for
| specific devices, and instead could ask for their 3GPP
| hardware-integration vendor of choice to provide this as
| part of their 6/7/8G head-end system, in such a way that
| any device leased an IP by said head-end could make use
| of it.)
| overstay8930 wrote:
| You'll never get serious discussions about this unless you talk
| about how this IP block will be distributed if it became
| unicast space. Otherwise this is no different than the other 10
| times this has been proposed.
|
| The main issue has always been the logistics of defining a
| brand new allocation policy that won't run out of IPs in 6
| months, because otherwise nobody is going to bother spending a
| bunch of money to support an address block which will most
| likely not even work anyways.
| ericvanular wrote:
| Supposed "developer-first" companies like Stripe & Github not
| enabling IPv6 access to their APIs is preventing progress
| jiggawatts wrote:
| Not to mention public cloud providers dragging their feet on
| implementing basic IPv6 functionality as if it was some sort of
| obscure feature instead of... _the Internet protocol_ for the
| last two decades.
| inopinatus wrote:
| To this day I maintain that a large part of IPv4 space wastage is
| due to the HTTP WG's longtime avoidance of adopting SRV or SRV-
| like DNS records or even the DNS itself as normative for
| HTTP/HTTPS, instead allowing the HTTP RFCs to just vaguely
| suggest that DNS might be one way to resolve the IP address of
| origin servers, whilst in practice squatting on the A (address)
| record like they owned it (and worse, all the apex records).
| Consequently inspiring a vast chorus of LIRs applying for /19
| allocations over the years "for SSL hosting" and continuing to do
| so long past the introduction of SNI (RFC 3546). Saw this
| behaviour firsthand as a European LIR operator with friends at
| RIPE. Is it cracked down on now? Yes. Are there whole swathes of
| IPv4 space that remain unassigned or entirely unannounced? Yes.
| Does every large-scale DNS hosting service have some hackish way
| to workaround the prohibition of CNAME records at the zone apex?
| They sure do, and HTTP is why.
|
| Paul Vixie saw it coming, the very first example in the original
| SRV proposal (RFC 2052, _1996_ ) is resolution of HTTP. Alas that
| this example was omitted in later editions. The new SVCB/HTTPS
| RRs (RFC 9460, _2024_ ) are literally decades overdue.
| BeefySwain wrote:
| I am trying to parse what this means, can someone ELI5?
| inopinatus wrote:
| _TLDR_
|
| For years a combination of gaps in policy, disjointed
| standards development, hoarding behaviour, and administrative
| laxity, led to substantial wastage of IPv4 address space that
| persists to this day, in part because multiple independent
| website tenants sharing an IP address was (and often still
| is) difficult.
|
| _Glossary_
|
| DNS: Domain Name System, how computers discover (or _resolve_
| ) each other's numeric IP addresses from symbolic
| hierarchical names.
|
| HTTP WG: HTTP Working Group, the standards committee(s)
| responsible for defining the application-layer protocols by
| which a web browser talks to a web server. Under the auspices
| of the IETF.
|
| IETF: Internet Engineering Task Force, the standards
| organization for the Internet. Most famous for being the
| entity that publishes TCP/IP and the cherries on top.
|
| LIR: Local Internet Registry, an entity that applies to be
| the holder of block-allocated IP address space. Typically
| ISPs and hosting companies that assign it for their use or
| onward customer use.
|
| RIPE: The European peak body, a Regional Internet Registry
| (RIR), responsible for (amongst many other things) allocating
| IP space to the LIRs, ultimately under license from the
| global steward IANA. Sibling of ARIN, LACNIC, AFRINIC, APNIC
| (North & South America, Africa, Asia-Pacific respectively).
|
| SNI: Server Name Identification. Before SNI was introduced to
| SSL/TLS, the only way to tell which HTTPS origin was being
| requested, was by server IP address.
|
| SRV: A specific type of record in the DNS that allows lookup
| of a service (e.g. IMAP mail, XMPP messaging, LDAP
| directories) for a given domain name, to return a set of
| hostname(s) that actually provide that service, and the ports
| on which it is available. This enables multi-tenant services
| on shared IP addresses and thereby conserves IP space.
|
| /19 network prefix: A large chunk of IPv4 address space,
| corresponding to 8192 unique IPv4 addresses. Refers to the
| first 19 bits of the block of (32 bit) IPv4 addresses being
| allocated. Back in the 90s a /19 was a common granularity of
| allocation from RIR to LIR and could be granted with a low
| bar to justification. Mathematically, 2^(32-19) = 8192.
|
| Address record: A specific type of record in the DNS that
| maps a hostname to an IP address. Technically referred to as
| an "A record" for IPv4 addresses, or an "AAAA" record for
| IPv6 addresses which are literally 4x the binary length.
|
| Allocation, Assignment, and Announcement: IP address space is
| _allocated_ in blocks by RIRs to LIRs, who then _assign_
| smaller parcels of it to specific purposes such as retail
| hosting and internet access, and _announce_ it at internet
| exchanges and to their peers for actual traffic exchange.
| Very often, the quantity of assignment failed to justify a
| large allocation, leaving space unassigned i.e. unused, and
| in some cases unannounced, but still hoarded, with incentives
| for hoarding becoming perversely stronger as the addresses
| ran out and the policy screws started to tighten
| ca.2005-2011.
|
| Apex: in "example.com" it is the "example.com" rather than
| "www.example.com". For marketing purposes, almost every
| entity wants their zone apex to be directly reachable as a
| website, which means placing an address record at the apex.
| This excludes using the apex address record for any other
| service but HTTP, which I have personally always regarded as
| pretty damn rude. Since alias records (a.k.a CNAME records)
| aren't permitted at the apex, it also makes DNS management
| harder when you have frequent changes to make, as in the
| highly dynamic world of cloud-based services, or even just
| want to point your website at a third party hosting service
| without having to edit your zones whenever their IP addresses
| change.
|
| Normative: A formal declaration in one technical standard
| (e.g. SMTP) that it depends in whole or in part on another
| standard (e.g. DNS) for full specification. It is unusual for
| a TCP/IP-based IETF protocol standard to omit DNS as
| normative or otherwise specify how they use the DNS for
| discovery, but HTTP has always been super vague about it.
|
| Origin: Fancy word for your actual website. Or in the
| presence of complications like reverse proxies/load
| balancers/CDNs etc, the front of your service stack from the
| point of view of a web browser.
| metadat wrote:
| Thanks for this. It seems the parent comment put maximum
| acronyms with zero information for people who are on the
| same wavelength / plane of existence.
| inopinatus wrote:
| guilty as charged
| matt-p wrote:
| That it was historically "more difficult" to have more than
| one website per IP address particularly if it was using SSL
| because doing that needed amendments/extensions to DNS and
| other specs.
|
| We now have it, but still need to use a hack to cname an apex
| e.g set Google.com to bah-bahs-tenant100.s3.amazon.com.
| Adhering to the spec we need to set google.com to an ip
| address e.g 8.8.4.4
| bonzini wrote:
| Right now if you want to retrieve http://www.example.com, you
| have to ask DNS for the IP address of www.example.com. HTTP
| can multiplex multiple sites on a single IP address so you
| can make DNS answer with a "CNAME", i.e. let it give another
| hostname which could be from Cloudflare and will actually do
| the serving. However http://example.com cannot use CNAME
| because it is an apex record (historical limitation that's
| hard to lift and is worked around in many different ways by
| providers). And this caused many websites to occupy an IP
| address unnecessarily.
|
| Likewise for HTTPS, though in that case multiplexing arrived
| only maybe 10-15 years ago instead of 25.
|
| A proposed Internet "standard" suggested that instead you
| would do a different kind of query, not a query for the IP
| address but one for a "server". It's a kind of query that is
| very underused on the Internet but it's related to how you
| find printers on a local network for example. In that case
| you would do this kind of query (called SRV) for http.tcp.
| example.com and that would always be able to return another
| hostname, thus getting rid of the issue with apex domains.
___________________________________________________________________
(page generated 2024-05-27 23:00 UTC)