[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 : 237 points
Date : 2024-05-27 14:28 UTC (1 days 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.
| ta1243 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.
|
| If that's _all_ IPv6 did that would have been one thing.
| ipv6 changed tons of things, from arp to nat, dhcp to
| dns.
| p_l wrote:
| And all of them had to change because guess what, they
| had hardcoded v4 assumptions including "4 octets"
| 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.
| bigstrat2003 wrote:
| > Stateful DHCPv6 does not get deployed because IPv6
| purists at Google refuse to implement them on Android.
|
| Which is absolutely ridiculous. Google should not be
| trying to dictate to their customers how to run
| infrastructure. If someone wants to use stateful DHCPv6
| for their Android devices, that is their right and Google
| has no business standing in their way.
| jandrese wrote:
| IPv6 DHCP isn't the same as IPv4 DHCP though. It doesn't
| work very well for logging and audits. It's more for
| assigning prefixs to routers.
| 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.
| tsimionescu wrote:
| > 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.
|
| This is only true if you use DNS for every network
| request. That has never been realistic for any home
| network.
|
| > _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.
|
| This attitude is part of why many people _love_ IPv6
| evangelism.
|
| > If anything, IPSec with it's idiosyncrasies is way, way
| more convoluted both to learn and implement.
|
| "Easier than IPSec" is not exactly a ringing endorsement.
|
| And note that IPv6 doesn't replace any of this. You still
| need to know the IPv4 way, and the IPv6 way, and IPSec in
| both flavors etc.
|
| Sure, it's not neuroscience, but it is needlessly more
| work, and most people like to not fuss with more work if
| they can avoid it. Especially when it's entirely
| duplicated, since, again, you can't drop IPv4 support,
| you still need to do CGNAT and all that, _and then_ add
| IPv6 management on top.
| JackSlateur wrote:
| He is right, tho : many network guys are .. just dumb.
|
| And I know what I am talking about: I am one of them :)
|
| People who fails to adapt because "it is new" has no
| place in IT. The only skill required to work in IT is a
| great ability to adapt.
| tsimionescu wrote:
| But that's just it: it's not failing to adapt. It's
| avoiding doing too much extra work.
|
| If IPv6 were a simple replacement for all things IPv4,
| and you simply had to learn IPv6 instead of IPv4, no one
| would complain.
|
| But you need to learn IPv6 _in addition_ to IPv4, in
| almost all areas of networking. The complexity adds up,
| it isn 't replaced.
| JackSlateur wrote:
| Well, yes, just like I learned k8s but still know
| iproute2 and I still use tcpdump and curl despite knowing
| how to debug http requests using the web console
|
| And I still manage ipsec tunnels and NAT and I still have
| to know things about OSPF, even tho I learned BGP more
| than 10 years ago
|
| In the real world, you cannot simply replace things in
| the blink of a eye. This is not possible unless you are
| working in your own, fully-managed environment, never
| talking to other people (which is a good but scarse
| position)
| hot_gril wrote:
| Updating the addressing scheme wasn't necessary. If I
| have 1.2.3.4 and I want to flip on ipv6, I should still
| be reachable at 1.2.3.4, just using the ipv6 header
| instead of v4. The hardware/software support is already
| there too.
| 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_.
| simoncion wrote:
| > The past 10 years of IPv6 have been largely uneventful
| for me: _it just works_.
|
| Yeah, ditto. Except that it has been more like twenty
| than ten for me.
|
| From my he.net tunnel, to (several years later) my
| Comcast-provided native IPv6 service, to IPv6 on my
| phone, to IPv6 with my local ISP (once I switched off of
| Comcast/NBCUniversal) it has been so very, very boring
| and reliable for so many years.
| Control8894 wrote:
| I didn't have IPv6 available from the sole (land-based)
| ISP who offered service at my last house, Altice USA
| (Suddenlink/Optimum).
|
| I moved away about 13 months ago.
|
| (Worse yet their modem/router did RAs or whatever but
| there was no connectivity out)
|
| The past 10 years of IPv6 have been largely uneventful
| for me: _it just doesn 't work_.
| throw0101d wrote:
| > _The past 10 years of IPv6 have been largely uneventful
| for me:_ it just doesn 't work.*
|
| IPv6 worked "too well" for me: a while ago I was web
| surfing I had all those little Facebook icons show up
| that were served from their web site, probably dropping
| cookies on my system. I didn't want that so I put FB's
| domain in my _hosts(5)_ file so that it go to "0.0.0.0":
| the little icons went away.
|
| Then suddenly they appeared. And I checked _hosts_ to
| make sure things were still there, and I did web browser
| debugging to see if things changed in the HTML.
|
| And then I remembered that my ISP had activated IPv6, and
| so the icons were coming from FB's IPv6 address. Once I
| added "::1" for FB in my _hosts_ file the icons
| disappeared again.
| 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
| Hikikomori wrote:
| Where you gonna put the bits for the extended address?
| 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.
| theamk wrote:
| No they would not. Linux is IPv6 compatible since 1996.
| Apache since 2002. Python since 2004.
|
| The C programs and network protocols have been
| implemented for 20+ years.. so why isn't everyone
| switched yet?
|
| Because IPv6 refused to be IPv4-with-extensions and
| instead decided to be completely incompatible - so all
| the admin scripts, all the best practices, all the
| configuration needs to be rewritten. Instead of fixing a
| single apache codebase, one needs to fix millions of
| adhoc network configurations.
|
| IPv7 on the other side, had absolutely different
| philosophy: The objective of conversion
| is to be able to upgrade systems, both hosts and
| routers, in whatever order desired by their owners.
| Organizations must be able to upgrade any given system
| without reconfiguration or modification of any
| other; and IPv4 hosts must be able to
| interoperate essentially forever. (IPv4 routers will
| probably be effectively eliminated at some point, except
| where they exist in their own remote or isolated
| corners.)
|
| this would get things converted much faster.
| throw0101b wrote:
| > _No they would not. Linux is IPv6 compatible since
| 1996. Apache since 2002. Python since 2004._
|
| Okay: so given that _gethostbyname(3)_ only dealt with
| _struct hostent_ with type of AF_INET:
|
| * https://pubs.opengroup.org/onlinepubs/000095399/functio
| ns/ge...
|
| * https://www.akkadia.org/drepper/userapi-ipv6.html
|
| Those had to be rewritten to support AF_INET6 and use use
| that new address type. See also changing all _socket(2)_
| calls.
|
| * https://datatracker.ietf.org/doc/html/rfc3493
|
| * https://datatracker.ietf.org/doc/html/rfc4038
|
| Regardless of what was chosen to be IPng, there would
| have been a whole bunch of rewriting necessary. If "IPv7"
| (TP/IX) was chosen as IPng (instead of SIPP(-16) becoming
| "IPv6") then we would have to add "AF_INET7" everywhere.
| And the supporting infrastructure (e.g., new DNS record
| types) would also have needed to be done for AF_INET7,
| just like it had to be done for AF_INET6.
|
| > _The C programs and network protocols have been
| implemented for 20+ years.. so why isn 't everyone
| switched yet?_
|
| Because most programs are written in Western,
| industrialized countries. And those countries have plenty
| of IPv4 address to go around since they got to the
| Internet first. And so there is no (perceived) shortage
| for the people writing and and running the largest
| Internet services they feel no pressing need to. ("
| _Address shortage? What address shortage?_ ")
|
| IPv6 has not taken off not because it's "bad" or "worse"
| than IPv4, or because IPv4 is "better" than IPv6: it has
| not taken off because of inertia: IPv4 works well enough
| and its short-coming (e.g., NAT) are known quantities
| with known workarounds.
|
| Meanwhile those folks that weren't fortunate enough to
| around for the early IPv4 address land grab are
| struggling with shortages:
|
| * https://community.roku.com/t5/Features-settings-
| updates/It-s...
|
| * https://news.ycombinator.com/item?id=35047624
|
| > _IPv7 on the other side, had absolutely different
| philosophy:_
|
| _All_ IPng had the same criteria, _including_ gradual
| upgrades ( "Technical Criteria for Choosing IP The Next
| Generation (IPng)" SS 5.5 Transition):
| We believe that it is not possible to have a "flag-day"
| form of transition in which all hosts and
| routers must change over at once. The size,
| complexity, and distributed administration of the
| Internet make such a cutover impossible.
| Rather, IPng will need to co-exist with IPv4 for some
| period of time. There are a number of ways to
| achieve this co-existence such as requiring
| hosts to support two stacks, converting between
| protocols, or using backward compatible extensions to
| IPv4. Each scheme has its strengths and
| weaknesses, which have to be weighed.
| Furthermore, we note that, in all probability, there will
| be IPv4 hosts on the Internet effectively
| forever. IPng must provide mechanisms to
| allow these hosts to communicate, even after IPng
| has become the dominant network layer protocol in the
| Internet.
|
| *
| https://datatracker.ietf.org/doc/html/rfc1726#section-5.5
|
| The authors of RFC 1475 _themselves_ 'abandoned' /
| changed TP/IX and put forward CATNIP:
|
| * https://datatracker.ietf.org/doc/html/rfc1707
|
| You are putting forward an idea (RFC 1475: TP/IX) which
| the authors themselves did not put forward for
| evaluation.
| theamk wrote:
| I am not sure why you keep mentioning gethostbyname(3),
| socket calls, and so on. As I said, this has been fixed -
| python's IPv6 support back in 2004 (20+ years ago!) had
| it all figured out and implemented. Bind 9.2 (released
| 2001) had AAAA support. You cannot explain difficulties
| in IPv6 adoption by need to rewrite in 2024.
|
| And yes, maybe IPv7 in particular is not the best
| solution, but it's hard to imagine how it could be worse
| than IPv6.. 20 years since support has been added to all
| core software and it's _still_ not adopted by end users?
|
| I think the problem with IPv6 is a decision to redo all
| the management methodology. Your RFC 1726 illustrates it
| well: there is only one brief mention of backward
| compatibility in 5.5, listed as "optional" feature, and
| whole sections about changing the protocol in
| incompatible way, including 5.8 which starts with:
| People complain that IP is hard to manage. We cannot
| plug and play. We must fix that problem.
|
| They fixed it indeed! Today, for home networks, IPv6 is
| even harder to manage than IPv4 was, just try to keep
| your small office LAN functioning while handling ISP
| address changes. Certainly possible, but nowhere close to
| "plug device in and it gets stable IPv4 address which is
| unlikely to ever change".
| throw0101b wrote:
| > _You cannot explain difficulties in IPv6 adoption by
| need to rewrite in 2024._
|
| The difficulties encountered with IPv6 would have been
| the same even if another proposal would have been chosen
| for IPng because the exact same thing would have needed
| to be done: new address type for syscalls, new data
| structures, new surrounding infrastructure.
|
| When your original standards do not allow for address
| length changes/flexibility, you have to write a new
| standard with the new address size, and there's no way to
| stuff >32 bits of data (addresses) into a 32-bit field.
| IPng would always have been a breaking change, regardless
| of proposed candidate chosen.
|
| And if you're not going to have a flag day (a la NCP-IP
| changeover), then you'll need transition mechanisms with
| tunnels for sparse dispersal between IPng islands in a
| sea of IPv4.
|
| > _And yes, maybe IPv7 in particular is not the best
| solution, but it 's hard to imagine how it could be worse
| than IPv6.. 20 years since support has been added to all
| core software and it's _still_ not adopted by end users?_
|
| All the proposals for IPng needed to have the same things
| done. "Technical Criteria for Choosing IP The Next
| Generation (IPng)":
|
| * https://datatracker.ietf.org/doc/html/rfc1726
|
| New packet type/header, new API options, new records and
| data structures for DNS, transition mechanisms
| (tunnelling). All this needs to be rolled out to hosts,
| routers, firewalls, ASICs, _etc_.
|
| All the while IPv4 would continued to be used, so what
| incentive would business and IT departments have had to
| move to TUBA or TP/IX-CATNIP? ( _" Our (IPv4) network
| works, why do we need IPv7?"_)
|
| > _Today, for home networks, IPv6 is even harder to
| manage than IPv4 was, just try to keep your small office
| LAN functioning while handling ISP address changes._
|
| Before recently moving ISPs (to go from DSL to GPON) I
| had IPv6 for several years on the old one and all my
| hosts (cabled, Wifi), phones, printers, _etc_ , had IPv6
| addresses given out by RA by my Asus, and I had no
| issues.
|
| In fact IPv6 worked "too well" for me at one point: a
| while ago I was web surfing I had all those little
| Facebook icons show up that were served from their web
| site, probably dropping cookies on my system. I didn't
| want that so I put FB's domain in my hosts(5) file so
| that it go to "0.0.0.0": the little icons went away.
|
| Then suddenly they appeared. And I checked hosts to make
| sure things were still there, and I did web browser
| debugging to see if things changed in the HTML.
|
| And then I remembered that my ISP had activated IPv6, and
| so the icons were coming from FB's IPv6 address. Once I
| added "::1" for FB in my hosts file the icons disappeared
| again.
|
| The IPX/SPX and DECnet folks managed to learn IPv4, so
| I'm not sure why the IPv4 folks have such a hard time
| with IPv6. IPv6 is no more difficult a Layer 3 protocol
| than IPv4.
| p_l wrote:
| Because even in 2000-2004, when people starting more
| seriously talking about adding IPv6 support, BSD Sockets
| stupid legacy of having every user deal with gory details
| of used protocol made people write new software using
| gethostbyname(3) and connect()/listen() calls that used
| hand-written IPv4 parsers and artisanal sockaddr structs.
|
| And there's a lot of software that never got corrected,
| that explodes when it reads an address that isn't IPv4
| even if uses a more modern API.
|
| Meanwhile IPv4 was supposed to be sunsetted in 1990, had
| been actively pushed to be migrated off in 1990-1995, but
| the cost of updating software that used the popular BSD
| Sockets API, introduction of NAT to remove major pain
| point, and certain major client (read: government and
| military) giving waivers on upgrading deadlines to
| vendors[1] meant that nothing really moved.
|
| And everytime people try to push things forward, some big
| chunk of infrastructure becomes a blocker - like cloud
| providers[2] - or we get inundated with "why in 1995 they
| didn't decide to go with something backwards
| compatible?". Newsflash - it was impossible for BSD
| Sockets software to be forward-compatible. If your
| software was build with XTI or similar interface (like
| Plan9's dial(), which is present in Go), you got IPv6,
| IPv7, and IPv9 support back in 1996, along with X.25 and
| who knows what else. In fact, IPv9 aka TUBA was actually
| implemented in network hardware around 1992 - the
| original RFC pointed to experiments using nearly
| unmodified Sun and Cisco hardware.
|
| [1] US government finally learnt though, and if you're
| selling to them you now have to support v6 or wrap your
| product in a black-box that will handle v6. No deferrals
| for products/vendors.
|
| [2] I'd argue AWS, GCP and Azure had significantly
| hampered global IPv6 migration
| 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.
| simoncion wrote:
| > ...the best option for that is ULA...
|
| I have both globally-routable and ULA addresses assigned
| to the hosts on my LAN. The ULA addresses are in my local
| DNS, and I update global DNS whenever the site's global
| prefix changes. Aside from the fact that the global
| prefix changes way too frequently (like once a quarter)
| it works great for me.
|
| > ...so we end up randomly generating them (and rotating
| them!)...
|
| Yeah, I turn this shit off whenever I have the power to.
| This was a fucking stupid-ass thing to have on by
| default. Hella buncha ways you can be tracked that give
| zero shits about what your IP address is. (This is one
| time when I wish the Net Heads would have consulted with
| the Web Heads and learned about how trackers actually
| work.)
|
| > NAT is here to stay, unfortunately, and so is DHCP.
|
| Nothing wrong with doing DHCPv6 and SLAAC, or just
| DHCPv6. My network just uses SLAAC, but folks who need
| more features than that provides have another tool they
| can deploy. This is a good thing.
|
| And you __can__ use NAT if you choose to, but if you're
| being assigned a publicly-routable prefix, there's no
| real reason to. Set up your border firewall to deny
| inbound unsolicited traffic, and set up uPNP (or similar)
| to hole-punch and you end up with the same security
| guarantees.
| ninkendo wrote:
| I think you're making my point for me quite nicely...
|
| Originally it was "IPv6 is great, you don't need dhcp",
| but then it became "well you may need DHCP anyway so
| here's DHCPv6", and then that becomes necessary often
| enough that you can't really point to that as a benefit
| of IPv6 any more.
|
| You don't need NAT but you need a _lot_ of the systems
| complexity that NAT requires, because you have to manage
| two sets of addresses in various configurations. Split
| DNS, etc.
|
| You're fine if you own the address range and it isn't
| provided to you dynamically with DHCP-PD, but that isn't
| the case with basically 100% of residential deployments.
| You need to multihome to even apply as a RIR to get your
| own prefix.
| ninkendo wrote:
| Thinking aloud: there needs to be a rethinking of how
| prefixes work in the next ::/3 we allocate for global
| unicast: it should be possible for individuals to get
| their own /48 for basically the same price as a domain
| name today. Hell, they could make cash as people rush to
| buy the memorable ones. Make personal route announcement
| a basic part of ISP service as defined by the FCC. We'd
| have a fighting chance of actually having a decentralized
| internet again. But I'm basically wishing for a pony at
| this point.
| icedchai wrote:
| You can basically do this today. There are RIPE LIRs that
| will allocate you a /48 pretty cheaply. There are
| tunneling services that will route it to you.
| sgjohnson wrote:
| It's not actually expensive or difficult for an
| individual to get an ASN and IPv6 space.
|
| https://lagrange.cloud/products/lir PS15 one-off for an
| ASN and PS7/y for a /48.
|
| Then you just need to find someone to give you a BGP
| session. https://bgp.services
| ninkendo wrote:
| I can't get any of that to my house. Comcast doesn't
| support BGP advertising a custom /48, and I can't even
| get one in the first place unless I'm dual-homed. The
| product you linked to has no details but it seems like
| you can get a /48 _for their services_ , ie. if they're
| hosting my machines, they'll give me a /48. That doesn't
| help me.
| icedchai wrote:
| It helps you if you set up a tunnel back to your
| location. I have a /48 tunneled back to my home network
| over wireguard. There are several RIPE LIRs that will
| guide you through this, even if you're in the US. (You'll
| need a VPS in the EU to satisfy the contractual
| requirements. Your other VPSes can be closer to you.)
| lmz wrote:
| That 7PS /48 is a PA assignment, you can't take it home
| with you. https://en.m.wikipedia.org/wiki/Provider-
| aggregatable_addres...
| icedchai wrote:
| You can. I have some PA address space, assigned by an
| LIR, that I announce out of my own AS. All "PA" means is
| it comes out of their parent block and, if you stop
| paying, they'll probably want it back.
| sgjohnson wrote:
| Exactly. I have a PA /32 of IPv6 that I can sub-allocate
| and announce however I want. Or even lease to other
| people. It's my space, as long as I'm paying my LIR for
| it.
| sgjohnson wrote:
| You can do whatever you want with that PA assignment. PA
| means that it's the provider's address space, not yours.
| You can announce it wherever you want though.
|
| The Wikipedia explanation is flat-out wrong.
| simoncion wrote:
| > I think you're making my point for me quite nicely
|
| Sorry, what's your point? That having both address
| autoconfiguration _and_ DHCP is too complex? If so, that
| 's has been the standardized state of the art in IPv4
| since 2005 with RFC 3927, and has been non-standard
| actual practice with Windows and Mac since like 1998.
|
| > ...you need a _lot_ of the systems complexity that NAT
| requires...
|
| No, all you need is a router that can do IPv6. It doesn't
| even have to have a firewall, which is absolutely
| mandatory for consumer-grade border-router NAT.
|
| > ...Split DNS...
|
| I don't run that. My DNS answers local queries for LAN
| hostnames it knows about and forwards global queries
| upstream. Just like nearly every consumer edge-router DNS
| server.
|
| > ...DHCP-PD...
|
| Yep. My ISP runs that on the WAN side of the router. I
| just do RAs on the LAN side of the router.
| tsimionescu wrote:
| > Sorry, what's your point? That having both address
| autoconfiguration and DHCP is too complex? If so, that's
| has been the standardized state of the art in IPv4 since
| 2005 with RFC 3927, and has been non-standard actual
| practice with Windows and Mac since like 1998.
|
| I don't think I've ever seen two computers communicate
| over a 169.254 address. Also, OS network stacks normally
| don't even try to get a link-local IPv4 address if they
| can get to a DHCP server or have a static address
| assigned. The RFC even recommends not using the link-
| local address if any other address is available. It's
| quite different from the way IPv6 works (as usual).
| simoncion wrote:
| > I don't think I've ever seen two computers communicate
| over a 169.254 address.
|
| I have. Used to do it often in the dorms when the uni's
| DHCP server was on the fritz. Zeroconf/Avahi wasn't
| really a thing, so we'd use Network Neighborhood to get
| people's IP addresses to browse files or play on servers
| they were hosting or whatever. I have also (as the RFC
| envisions) done it when connected to ad-hoc WiFi
| networks, and also while directly connecting two Windows
| PCs. In those scenarios, I asked my peer what their IP
| address was, rather than bothering with going to Network
| Neighborhood.
|
| > Also, OS network stacks normally don't even try to get
| a link-local IPv4 address if they can get to a DHCP
| server or have a static address assigned.
|
| Correct. From the second paragraph of the Abstract of RFC
| 3927: [0]
|
| > IPv4 Link-Local addresses are not suitable for
| communication with devices not directly connected to the
| same physical (or logical) link, and are only used where
| stable, routable addresses are not available (such as on
| ad hoc or isolated networks).
|
| > The RFC even recommends not using the link-local
| address if any other address is available. It's quite
| different from the way IPv6 works (as usual).
|
| No, it's also recommended when using IPv6 to not use
| link-local addresses if any other address is available.
| (Both because those addresses are only link-local, and
| because one usually needs to put an outbound interface
| specifier on the address when you go to contact another
| host, which is pretty obnoxious.) It just happens that
| IPv6's address autoconfiguration has been upgraded to be
| useful for globally-routable addressing, too.
|
| So, yeah, a usual mode of both IPv4 and IPv6 networks is
| to have autoconfigured addresses, as well as DHCP-
| assigned addresses. It just so happens that most of the
| time IPv4 addresses are not autoconfigured, and most of
| the time IPv6 addresses are not assigned by DHCP.
|
| That's equivalent complexity.
|
| [0] <https://www.rfc-editor.org/rfc/rfc3927>
| tsimionescu wrote:
| > No, it's also recommended when using IPv6 to not use
| link-local addresses if any other address is available.
| (Both because those addresses are only link-local, and
| because one usually needs to put an outbound interface
| specifier on the address when you go to contact another
| host, which is pretty obnoxious.) It just happens that
| IPv6's address autoconfiguration has been upgraded to be
| useful for globally-routable addressing, too.
|
| With what seems to be the recommended IPv6 setup at least
| for client machines, the Link-local address is the only
| stable identifier of that machine, as the actual
| reputable address changes all the time. So, the machine
| has both a link-local and a routable IPv6 at the same
| time, and both are going to be used. This is still
| different from IPv4, where link-local addresses are,
| again, an obscure feature that almost no one uses.
| simoncion wrote:
| > With what seems to be the recommended IPv6 setup at
| least for client machines, the Link-local address is the
| only stable identifier of that machine...
|
| What? ULA space _is_ the IPv6 equivalent of RFC 1918
| space. If you want a prefix you know will not change,
| then you go generate you a /48 and use that on your
| internal network(s).
|
| Why on earth would people expect ISPs that have a "We
| won't give you a guaranteed-static IPv4 address." policy
| to have a "We will give you a guaranteed-static IPv6
| prefix" policy? Thinking that way is madness.
|
| Perhaps you're confused because you're looking at
| guidance for client machines, when you should be looking
| at guidance for customer edge routers? Check out RFC
| 7084, and in particular section 3 and its subsections,
| and section 4.3 and its subsections. [0]
|
| > ...as the actual reputable address changes all the time
|
| Are you talking about IPv6 address randomization? (AKA
| "privacy" addresses?) IF you are, then know that it's
|
| a) Controlled by the operator of the computer, rather
| than the operator of the network it's connected to.
|
| b) Optional, and SHOULD be able to be turned off by the
| computer operator.
|
| c) RECOMMENDED that a stable address be generated for the
| machine, in addition to the random ones.
|
| Thing c) is in part to deal with "But what if I want to
| put a AAAA into the local DNS?" problem, and in part to
| give expected-to-be-long-lived connections an address
| that the system knows will hang around for at least as
| long as the interface is up.
|
| After all, unless you want to tear down the connections
| associated with it, you can't remove an address from an
| interface until those connections have closed. More
| addresses allocated to a host means more multicast groups
| joined for that host, which eats up resources on the
| local networking infrastructure... so (if you're using
| "privacy" addresses) you really, really wanna steer
| ephemeral connections to addresses that are temporary,
| and long-lived ones to ones that are not.
|
| [0] <https://datatracker.ietf.org/doc/html/rfc7084>
| ninkendo wrote:
| > Sorry, what's your point? That having both address
| autoconfiguration and DHCP is too complex?
|
| My point is very simple: you can't say "IPv6 is simpler
| because there's no DHCP" if there's DHCP. It's pretty
| obvious right?
| dagenix wrote:
| ULAs aren't the same as a NAT setup. You can assign all
| of your local devices stable ULAs _and_ also reputable
| addresses that randomly change. If you do that, there is
| no need for NAT.
| ninkendo wrote:
| Right, I picked the word "eroded" because it's not like
| the benefit is completely gone, but it's not what was
| originally envisioned.
|
| I do ULA+global unicast too, but it would be _far_
| simpler if I actually had a reliable stable prefix and
| could just use that. I put my ULA addresses in local DNS
| (because that's why I need ULA, I need to not worry about
| rewriting my zone file whenever my cable modem reboots),
| but that means I have to do split horizon DNS. I wish I
| didn't have to. (Yes I do mDNS too but I need real DNS
| for lots of use cases.)
| simoncion wrote:
| > Right, I picked the word "eroded" because it's not like
| the benefit is completely gone, but it's not what was
| originally envisioned.
|
| You also said
|
| > NAT is here to stay
|
| Which, uh, it sure sounds like you're not using IPv6 NAT.
| In fact, it looks like aside from probably being confused
| about what "split horizon DNS" is [0] your setup is
| exactly like mine. Address autoconfig for both a
| annoyingly-frequently-changing global prefix, and a
| constant ULA prefix with DNS entries for the ULA
| addresses.
|
| [0] Does your DNS server serve LAN _and_ WAN clients? If
| it doesn't, and it only serves LAN clients, you're almost
| certainly confused.
| simiones wrote:
| They pretty clearly talk about public hosts, so it seems
| quite likely that they are in fact doing split-horizon
| DNS (i.e. machine1.site.com will be resolved to an ULA
| address if the query is coming from the same subnet, or
| to the public address otherwise).
| simoncion wrote:
| IF homie is serving public-facing DNS for the site with
| the same server that's serving local DNS, then yeah,
| sure, split-horizon DNS is probably the thing that you'd
| do. But:
|
| > They pretty clearly talk about public hosts
|
| Thing is, I ALSO have public hosts on my LAN. And they're
| in both the public DNS and in the DNS on my LAN. But
| public DNS is not served from my local DNS, so I don't
| have a split-horizon setup.
|
| The mere act of maintaining (in two entirely unrelated
| DNS servers) records for the same resource but with
| different data doesn't make a split-horizon setup. If it
| did, then I could reasonably claim "I'm running a split-
| horizon setup for mit.com!" just by adding an A record
| for "mit.com" to my local DNS server, despite being
| neither connected to any MIT internal networks, nor in a
| position to serve any data to MIT's Internet clients.
| ninkendo wrote:
| "homie" here.
|
| I do DNS such that the same hostname, which I control,
| resolves to the ULA address if asking locally, but the
| public address if asking from an external machine. But
| it's not literally the same server, I use DNSimple for my
| public DNS and unbound on my local DNS. You can split
| hairs about whether split horizon means "the same DNS
| server serving both views" or not, but that's a
| needlessly pedantic snipe. But to cut off this argument:
| Sure, you're right. You score one internet point, I used
| the word "split horizon" incorrectly. You're very smart.
| ninkendo wrote:
| > You also said
|
| > > NAT is here to stay
|
| It's not generally good form to cherry-pick things I said
| from other threads and put them out of context. "NAT is
| here to stay" can for the purposes of this discussion
| mean "Thinking about global vs local addresses is here to
| stay", even if it's not NAT per se that is happening (ie.
| if you're using a ULA + global unicast, like I do.)
|
| > you're almost certainly confused
|
| I'm not confused. I do split horizon DNS. I serve WAN and
| LAN clients (not currently from the same DNS server,
| although that's what I'd prefer to do. The same hostnames
| are currently configured in different DNS systems
| depending on who's asking, hence "split horizon".)
|
| To be clear, here's my setup. It's not unique or
| interesting compared to any other "home lab" setup:
|
| - I have multiple machines that I want to be able to
| access by DNS name externally.
|
| - I also want to be able to use those same DNS names for
| local configuration, to keep things sane.
|
| To do this, I have two options:
|
| 1) Use the publicly-routable global unicast addresses in
| my DNS, and make a system to keep them updated in a
| reprefix
|
| 2) Use a ULA prefix for local DNS, and the global unicast
| equivalent addresses for public DNS, and make a system to
| update _only the public DNS_ when I get reprefixed
|
| I chose option (2) because I want to mitigate the damage
| that happens when my ISP reprefixes me. (It's happened 6
| times over the past year, it's not uncommon.)
|
| When I get reprefixed, any local traffic that's using DNS
| to lookup the address keeps working as usual, because the
| ULA address doesn't change. I have to worry about
| reconfiguring _public_ DNS, but that 's the lesser of two
| evils IMO:
|
| Because if I picked option (1), I'd have to reconfigure
| public DNS _and_ my local traffic would all be disrupted
| while the reprefix happened: My hosts would all be trying
| to communicate with one another via their old prefixes,
| and failing until DNS reconfigures.
|
| And this is all not to mention that I have to do the
| exact same reconfiguration dance with my firewall config:
| When I get reprefixed, my pf.conf is now referencing
| invalid IP's. I disable-by-default so it's not a security
| issue, but it's something that I had to solve with
| automation (in my case, by templatizing my pf.conf and
| writing dhcpcd hooks that reconfigure it when the prefix
| changes. It wasn't trivial.)
|
| Now, to get back to my original argument: IPv6's
| simplicity benefits "erode" when you consider that
| worrying about internal vs external addresses is still
| something you have to deal with in the real world, at
| least in residential deployments where you don't own your
| own prefix. Granted: These issues are inherent to any
| system where your ISP is dynamically assigning you IP's,
| but it's important to understand: Yes you can have real
| endpoints for all of your hosts simultaneously without
| dealing with NAT, but you still have complexity to deal
| with to make this work, due to it being the real world.
| dmm wrote:
| > you still need a stable address space for your LAN that
| survives your ISP randomly changing your prefix
|
| The randomly changing prefix is really annoying. There's
| no reason for your ISP to do this other than to try and
| upsell you on expensive commercial services.
| convolvatron wrote:
| This was done so that networks could actually be
| renumbered to increase aggregation and routing efficacy.
| In todays work once you give out a number you cant take
| it back, and that leads to fragmentation (i.e. the swamp)
| simoncion wrote:
| > In todays work once you give out a number you cant take
| it back
|
| This isn't true. If it were, then home ISPs would never
| renumber client networks.
|
| You're probably thinking about the larger allocations
| handed to folks who have ASNs, rather than the small
| allocations handed small ISP customer sites... and even
| then, those can _totally_ be reclaimed.
| Control8894 wrote:
| I think there's an extra, important, oft-missed part
| implicit in your scenarios:
|
| 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. ... but don't make
| anyone learn anything new
|
| 2) if we're already replacing everything, make stuff
| better ... and make everyone learn everything all over
| again
| sidewndr46 wrote:
| I'd argue they chose a 3rd option: make it 'better' but
| be sure that the transition can never actually happen.
| jandrese wrote:
| That would still require you to have two stacks and two
| firewall configurations and all of the other things that
| prevent IPv6 from being turned on. The only thing you
| save is by not doing SLAAC and sticking with IPv4-like
| DHCP you can more easily control things like assigned
| hostnames, but that's pretty low on the totem pole for
| blocking issues with IPv6.
| tsimionescu wrote:
| SLAAC was just an example, but even here you're
| downplaying. SLAAC adds a lot of extra complexity:
| _every_ host now has multiple IP addresses, which was a
| rarity in IPv4 land, especially for client machines in a
| LAN; and exactly which IP _should_ be used to identify a
| host is now highly dependent on details of the network
| config that are hard to guess (is it using privacy
| extensions? Will this IP expire daily, or is it more
| stable?). Plus the dependence on ISPs assigning more than
| a /64, otherwise SLAAC is broken.
|
| And there are also other things - more dependence on
| ICMP, the concept that your LAN IPs are determined by
| your ISP (unless you _also_ assign ULAs in addition to
| all the other IPs), and probably others I 'm forgetting.
| p_l wrote:
| The host side issues were pretty much all related to BSD
| Sockets being shittiest, but cheapest, network stack on
| the block.
|
| For many years it embedded the idea that every
| application had to handle exact details of each protocol
| it wanted to support through its exposure of gory details
| in sockaddr struct and requiring that as input to
| connect() and listen() calls.
|
| All the SLAAC, privacy address, etc? That's just an
| emanation of people cargo-culting some practices that
| were workable with IPv4 but only by making the network
| suck.
|
| And ifconfig got deprecated because it didn't fit linux
| networking API anymore, and nobody wanted to maintain it
| instead of writing something that fit well - which was
| iproute2.
| 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".
| throw0101d wrote:
| > _Sounds like IPv7, from year
| 1993:https://datatracker.ietf.org/doc/html/rfc1475_
|
| The author(s) of IPv7 (TP/IX) 'abandoned' / altered it to
| CATNIP:
|
| * https://datatracker.ietf.org/doc/html/rfc1707
|
| This was put up for consideration for IPng, and compared
| with TUBA and SIPP:
|
| * https://datatracker.ietf.org/doc/html/rfc1752
|
| The general idea of SIPP(-16) was chosen (and tweaked) to
| be IPng, now called IPv6.
|
| The criteria needed for IPng candidates were:
|
| * https://datatracker.ietf.org/doc/html/rfc1726
| dboreham wrote:
| There was a proposal called TUBA (TCP/UDP with Bigger
| Addresses). It was voted down in favor of IPng.
| throw0101b wrote:
| > _There was a proposal called TUBA (TCP /UDP with Bigger
| Addresses). It was voted down in favor of IPng._
|
| "IPng" was the _general thing_ that would come after
| IPv4, and not a _specific_ proposal.
|
| The specific proposal that was chosen (over TUBA (aka
| ISO's CLNP), as well as CATNIP) was Simple Internet
| Protocol Plus (SIPP):
|
| * https://datatracker.ietf.org/doc/html/rfc1752
| hot_gril wrote:
| The issue is really forwards compatibility. Every ipv4
| address should've been kept valid in all ipv6 networks.
|
| Step 1 would've been to leave all the routing, DNS, NAT,
| DHCP etc as-is and just get people's devices speaking ipv6.
| And we would've already been there years ago. Once that's
| done, DNS and DHCP can be updated, then people can start
| using the extended address space by splitting up their
| blocks. So if you previously had 1.2.3.4, you now also have
| 1.2.3.4.1 etc.
|
| It's actually not too late to do this with the existing v6
| header.
| mprovost wrote:
| It's not the case that there were no alternative designs at
| the time that v6 was proposed. RFC 1385 described a
| backwards compatible Extended Internet Protocol which used
| IP Option headers to stuff in extra addressing space.
|
| https://datatracker.ietf.org/doc/html/rfc1385
| p_l wrote:
| Still deals with the mess that was BSD Sockets preventing
| forward compatibility.
| 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.
| dboreham wrote:
| This was deliberate: the idea was that IPng wouldn't get
| adopted, or even traction in the IETF, if it didn't provide
| additional functionality/fix perceived problems beyond just
| address space exhaustion. Remember also that NAT wasn't
| really a thing at that time. It might have existed but wasn't
| widely used like happened subsequently.
|
| Source: was there.
| JoshTriplett wrote:
| I can certainly understand that perspective. But from
| _today 's_ perspective, it seems like IPv6 adoption was
| _slowed_ by ideological arguments like "people should use
| SLAAC, not DHCP". By all means introduce a new means of
| obtaining addresses, but let it live or (preferably) die on
| its own merits, rather than attaching it and a dozen other
| albatrosses around IPv6's neck. If IPv6 had started from
| day one by saying "just add an IPv6 block to your DHCP
| server and let any client that understands IPv6 get an IPv6
| address", that would have been an easier sell.
| 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
| mike_d wrote:
| IPv6 depends on IPv4 addressing if you have downstream
| devices that need to reach the entire internet. If you go
| to ARIN they have an explicit policy of allocating IPv4
| blocks to facilitate IPv6 deployment.
|
| CGNAT is a term that broadly used to refer to carrier-
| scale solutions to deal with issues with number
| exhaustion and dual-stack deployments. What most people
| think "CGNAT" is, is actually NAT44.
| https://nfware.com/blog/why-cgnat
| jacob019 wrote:
| Mobile providers have IPv6 only networks and use NAT64 with
| CGNAT and DNS64 to permit access to the legacy internet. No
| incoming IPv4 ports. CGNAT can serve way more than 32
| customers per IP, and they are pooled.
| tgsovlerkhgsel wrote:
| The problem is that you _have_ to have working IPv4 in some
| form, because enough major sites (e.g. Twitter, Wordpress,
| Github, Pintrest, Vimeo, bit.ly, TikTok, Tumblr, the New York
| Times, but also mozilla.org and Archive.org) don 't support
| IPv6. [1]
|
| Likewise, some Linux mirrors don't support it. If I decide to
| try an IPv6-only server, and the first thing I see after "apt
| update" is network errors, I'm not very motivated to use IPv6
| in the future.
|
| Then add some problems where having IPv6 enabled randomly
| breaks things for one reason or another. I can either debug
| it forever, or turn the "internet is broken" switch (labeled
| "Enable IPv6") to "off" and get on with my day. That means
| more people that support IPv4 but not IPv6 (to be fair, this
| one seems to have gotten a _lot_ better).
|
| But ultimately, until some major, hard-to-avoid site says
| "we'll only be on IPv6", there is little reason for most to
| use it, and many reasons not to. That's why the transition
| takes forever.
|
| [1] http://www.delong.com/ipv6_alexa500.html
| crote wrote:
| It's a bit of a chicken-and-egg problem. Major sites don't
| deploy IPv6 because "everyone has IPv4", and people don't
| roll out IPv6-only servers because they still want to be
| able to reach IPv4-only hosts.
|
| Amazon has hopefully started a change in this mentality by
| charging money for _every_ IPv4 address used. This creates
| a real financial incentive to deploy IPv6-only servers,
| which in turn means that critical services like Github and
| Linux mirrors are slowly forced to provide IPv6.
| sambazi wrote:
| afaik there was a serious lack of v6 support within aws
| services. has the financial incentive reached this far or
| do they just want to charge you more?
| M2Ys4U wrote:
| >afaik there was a serious lack of v6 support within aws
| services.
|
| There still is, even though they've started charging for
| v4!
| jacob019 wrote:
| NAT64 is a thing, combined with CGNAT it offers a way for
| IPv6 only clients to acess the legacy internet. Mobile
| prividers are doing this, ISPs can as well. It would
| incentivize IPv4 only sites to upgrade, to avoid the CGNAT.
| 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.
| p_l wrote:
| ifconfig got deprecated because it didn't match how
| networking worked in the kernel.
|
| If you're using ifconfig _on linux_ [1] for the last 10
| years, I'm going to negatively look on your claimed
| expertise
|
| As for point-to-point links, that's what simple link-
| local addresses are, _added in ipv6_. And why IP-IP is
| superior to OSPF, both because it doesn 't hardcode
| address sizes and because it runs on Layer 2.
|
| [1] ifconfig on other systems might be the right command
| vaylian wrote:
| github.com reachable via IPv6 when?
| eqvinox wrote:
| When you set up NAT64...
|
| ... :-( ... _goes to cry in a corner_
| ta1243 wrote:
| I'd rather deal with NAT than have multiple IPv6 address ranges
| on my network, even if I could stop using ipv4
| 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.
| simoncion wrote:
| > ...https conversion had the benefit of every operator
| being able to transition on their own time frame. ... IP
| not having that luxury is a profound problem.
|
| This I don't get. I expect that Google will be _far_ more
| likely to make it extremely difficult (or perhaps
| impossible) to use Chrome to visit non-TLS-wrapped HTTP
| sites on the Internet in the next five years than the
| operators of the various networks that make up the
| Internet are to just shut off IPv4 on their network.
|
| I expect IPv4 will not be shut off within the lifetime of
| anyone posting on this forum today... and why would it
| be? Once just about everyone has well-functioning IPv6
| access, release a recommendation to ISPs that unless a
| customer has an even vaguely-reasonable need for a
| globally-routable IPv4 address, that ISPs substantially
| reduce their IPv4 usage by providing IPv4 service to
| their customers through some CGNAT.
|
| This would ensure that the few remaining hosts with
| IPv4-only service will remain reachable, that any
| customers who can bother to write a letter to their ISP
| asking for a globally-routable IPv4 address can get one,
| and a ton of IPv4 space gets opened up for whatever we
| might need to do with it in the future... just in case.
| 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.
| xacky wrote:
| So surprised that hacker news is stuck in ipv4 land. Even if
| you disagree with the method, I do not consider a device not
| capable of IPv6 to be using the real internet anymore. It's
| the same with the housing market where people would rather
| speculate on IPV4 houses instead of building plentiful IPv6
| apartments.
| 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.
| umanwizard wrote:
| Probably their data collection was just broken for
| whatever reason.
| 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?
| umanwizard wrote:
| FWIW the weekday numbers are increasing too, they just
| lag the weekend ones a bit.
|
| I don't know how to quantify "very little progress", but
| my home ISP (Verizon FiOS in NYC) got IPv6 relatively
| recently (maybe a year or two ago).
|
| Anyway, don't most people connect to WiFi while using
| their handheld devices at home anyway?
| simoncion wrote:
| > AWS v6 only instances have only been around for 20
| months or so?
|
| a) According to [0], AWS has provided IPv6 addressing to
| EC2 instances since 2016.
|
| > IPv6 support for Amazon Elastic Compute Cloud (Amazon
| EC2) has been available along with IPv6 support for
| several other services since 2016.
|
| Refer to the 2016 blog post at [1], which says (among
| other things)
|
| > By default, every IPv6 address is public and internet-
| routable. For customers requiring a private subnet on
| their IPv6-enabled VPCs, we are introducing a new
| resource within the VPC called the Egress-only Internet
| Gateway, which can be setup to allow one-way access to
| Internet resources.
|
| b) I don't get the "This migration only counts if we can
| support only IPv6 and shut off IPv4" obsession. I see no
| reason to shut off IPv4 within our lifetimes. I expect
| the distant future will be providing end-users with a
| globally-routable IPv6 prefix and a CGNATted-to-hell-and-
| back IPv4 address for reaching out to those sites that
| may still be using v4 only.
|
| [0] <https://aws.amazon.com/blogs/publicsector/aws-
| enables-us-fed...>
|
| [1] <https://aws.amazon.com/about-aws/whats-
| new/2016/12/announcin...>
| mike_d wrote:
| > a) According to [0], AWS has provided IPv6 addressing
| to EC2 instances since 2016.
|
| Yes, but that isn't what we are talking about. 2022 is
| when they added native IPv6 support, prior to that it was
| just a fancy NAT like translation.
| simoncion wrote:
| > 2022 is when they added native IPv6 support, prior to
| that it was just a fancy NAT like translation.
|
| Are you _sure_ about that? The relevant docs from 2019
| (the Wayback Machine doesn 't have anything earlier) sure
| make it seem like you're getting globally-reachable IPv6
| addresses:
|
| From [0]:
|
| > To complete this exercise, do the following: ...
|
| > * Launch an Amazon EC2 instance into your subnet, and
| associate an IPv6 address with your instance during
| launch. An IPv6 address is globally unique, and allows
| your instance to communicate with the Internet.
|
| Yes, the last bit of that doesn't automatically mean that
| your instance is globally-reachable. Read on.
|
| From [1]:
|
| > IPv6 addresses are globally unique, and therefore
| reachable over the Internet. You can control whether
| instances are reachable via their IPv6 addresses by
| controlling the routing for your subnet, or by using
| security group and network ACL rules. For more
| information, see Security.
|
| From the "Inbound" table of the "Recommended Rules for
| Scenario 1" section of [2]:
|
| > | 170 | IPv6 address range of your home network | TCP |
| 22 | ALLOW | Allows inbound SSH traffic from your home
| network (over the Internet gateway). |
|
| Am I missing some part of the docs where they talk about
| how there was some fancy NAT-like translation box that
| made it so that these weren't globally-reachable IP
| addresses? Was AWS just lying in their docs?
|
| [0] <https://web.archive.org/web/20190131164146/https://d
| ocs.aws....>
|
| [1] <https://web.archive.org/web/20190801182729/https://d
| ocs.aws....>
|
| [2] <https://web.archive.org/web/20191021190354/https://d
| ocs.aws....>
| kbolino wrote:
| IPv6 is still second-class for a lot of AWS's other
| services, so unless you treat AWS as just an overpriced
| VPS/colo it's not going to work all the way through.
| 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.
| photonbeam wrote:
| Even if its just "all US residential services have ipv6
| by 2028" fixes a lot of the chicken and egg
| 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.
| kmeisthax wrote:
| American here, I've had IPv6 on literally every device I've had
| for almost a decade now. Every mobile provider has been v6
| since LTE. Comcast migrated to v6 over a decade ago because
| they exhausted 10.0.0.0/8 in their control plane network (they
| have a lot of cable modems). And I'm on Google Fiber now which
| is all v6.
|
| There's probably a few other ISPs that need a good kick to the
| groin in the US, but the general feeling I get here is that the
| real stragglers in v6 deployment are other countries. Indeed,
| looking at Google's IPv6 map[0] it's all countries in Africa
| and the Middle East that have the worst v6 adoption. It's
| places where there isn't enough demand for addressing to make
| CGNAT unviable and IPv6 necessary.
|
| [0]
| https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
| marcthe12 wrote:
| USA is has to much legacy interim to do this. I think India has
| the best leverage having being one the highest IPv6 adoption
| and shear number of internet users, so it easier get all main
| blockers of IPv6 only internet usuable.
| kbolino wrote:
| The government should start by rolling out IPv6 for its own
| stuff before telling others what to do. I say this because they
| need to learn how to do it too/first.
| 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.
| tgsovlerkhgsel wrote:
| Except someone like Google would likely also want their
| site to work, and thus I expect them to be unwilling to
| use such a problematic IP.
|
| If any big site (or even better, many big sites together)
| _were_ willing to go that far, a much better measure
| would be announcing that they 'll go IPv6-only on the
| next IPv6 day. Just for that day. And then again the next
| year, but for a week. Then for a month the year after.
| Then permanently. That would give ISPs the kick in the
| butt to fix it, because nobody wants their hotline to
| field a day full of "my Internet doesn't work" calls,
| only to then _have_ to fix it anyways because otherwise
| it 'll be a week next time.
| 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.
| RKearney wrote:
| > On macOS, I can't ping or bind to 127.0.0.2
| uname -a Darwin LT-JT6692XPXJ 23.5.0 Darwin
| Kernel Version 23.5.0: Wed May 1 20:12:58 PDT 2024;
| root:xnu-10063.121.3~5/RELEASE_ARM64_T6000 arm64
| ~ ifconfig lo0 lo0:
| flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
| options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
| inet 127.0.0.1 netmask 0xff000000 inet6 ::1
| prefixlen 128 inet6 fe80::1%lo0 prefixlen 64
| scopeid 0x1 nd6 options=201<PERFORMNUD,DAD>
| ~ ping -c 1 127.0.0.2 PING 127.0.0.2
| (127.0.0.2): 56 data bytes --- 127.0.0.2
| ping statistics --- 1 packets transmitted, 0
| packets received, 100.0% packet loss ~
| 11s sudo ifconfig lo0 add 127.0.0.2
| Password: ~ ping -c 1 127.0.0.2
| PING 127.0.0.2 (127.0.0.2): 56 data bytes 64
| bytes from 127.0.0.2: icmp_seq=0 ttl=64 time=0.824 ms
| --- 127.0.0.2 ping statistics --- 1 packets
| transmitted, 1 packets received, 0.0% packet loss
| round-trip min/avg/max/stddev = 0.824/0.824/0.824/nan ms
| ~ ifconfig lo0 lo0:
| flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
| options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
| inet 127.0.0.1 netmask 0xff000000 inet6 ::1
| prefixlen 128 inet6 fe80::1%lo0 prefixlen 64
| scopeid 0x1 inet 127.0.0.2 netmask 0xff000000
| nd6 options=201<PERFORMNUD,DAD> ~
| 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.
| nick238 wrote:
| What's the use for multiple local loopback IPs? I'm not a
| networking guy, just backend dev, so 99.99% of my 127.0...
| use is running applications locally.
|
| For your TLS thing, is it whatever application you were
| using expected to use a whole swath of TCP ports at
| whatever IP address, so expected separate IPs?
|
| Feels like dedicating some range of addresses to "private
| use" would have been useful, then if you needed a bunch of
| local loopbacks, could configure it so, or if your local
| network wants some magic, tada.
| 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.
| bell-cot wrote:
| True. But if you need a secure network for the factory's
| SCADA equipment - a brick is just not a practical
| substitute.
| 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.
| Control8894 wrote:
| Sometimes they might have been able to allocate it more
| compactly - but how do you predict exactly what your needs
| will be in 20 years?
|
| Other times they might not have been able to allocate it
| more compactly - are you really going to go make routes for
| a /25 _and_ a /26 _and_ a /27 when you need 200 IPs, just
| to save a single /27 over giving it the whole /24?
|
| There can also be reasons to structure it more sparsely
| than required for UX, namely to give a more hierarchical
| structure - maybe by region and store, or similar.
|
| tl;dr it's not necessarily a mistake that your allocations
| mean you use more space than strictly necessary
| Symbiote wrote:
| If they will never upgrade then they can't use 240/4 either.
| sambazi wrote:
| amazon is using class-e internally for some years now; i guess
| it's profitable
| 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).
| ale42 wrote:
| This was very common in the past. People abused 1.0.0.0/24
| because it was unused. There was even one of the big ISPs
| in Italy assigning such addresses for their customers for
| CGNAT...
| sambazi wrote:
| does this fit in the greater 'enshittification' theme?
|
| subpar replacements w/o real alternatives
| 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.
| akira2501 wrote:
| DNS SRV. So much promise. Ultimately just became "I know
| where exchange is!"
| mschuster91 wrote:
| > $employer STILL does port-based firewalling and thinks
| it's great policy.
|
| And they're not wrong either, it by definition disables not
| just a whole class of (admittedly outdated) communication
| channels for malware (such as IRC), but also other stuff
| you don't want to happen on your network either:
| bittorrent, people running online games during work...
| dewey wrote:
| Isn't it trivial to run these on another port?
| p_l wrote:
| It is
| 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.
| pests wrote:
| I think you mean every user will connect via IPv4.
|
| Users aren't getting single IPv6 addresses though. Most
| assign a /48 which is at least a bit better.
| redox99 wrote:
| Yes, I meant IPv4.
|
| And rate limiting is very uncertain. If I limit per /56,
| users that have an entire /48 can outright bypass the
| rate limit. If I limit per /48, maybe I'll erroneously
| limit thousands of users whose ISP has all of them on the
| same /48.
| pests wrote:
| Don't you have those same issues with banning/rate
| limiting IV46 though?
| ta1243 wrote:
| The difference between a /48 (like my residential
| handoff) and a /64 (like some people get) is the same as
| a difference between blocking a single /32 ipv4 address
| and blocking an entire /16 - which is a very large
| allocation
|
| If you wanted to block me, you'd have to block the whole
| /48. If you blocked a /48, you could be blocking 64,000
| people.
| pests wrote:
| I meant IPv4 - one IP might represent thousands of users.
|
| Looks like crote brought the issue up in a sibling
| thread.
| crote wrote:
| But the exact same issue exists with IPv4 due to CGNAT? A
| single IPv4 address could be used by a single user, or
| their ISP could be sharing that same single IP with many
| thousands of users.
| Control8894 wrote:
| My employer also disables it (choice made above me). And I
| get it. It really is duplicating lots of work for
| absolutely no benefit (to the organizations doing the
| work).
|
| It's a shame that you're getting downvoted. I'm sure a lot
| of those people are shouting at their screen "well just
| learn it" but even if you're familiar enough with all the
| stuff it changes (RA, NDP, heck the lack of NAT), it's
| still a ton of work to get it properly set up and worse yet
| to maintain.
| crote wrote:
| The whole duplication doesn't have to be as bad as it
| might seem at first glance.
|
| Large companies (and even ISPs) seem to be going for
| "IPv6-mostly" rollouts. Basically, everything is done
| primarily using IPv6, with fallbacks to IPv4 only when
| strictly necessary. This means IPv4 traffic gets
| converted to IPv6 at the client, forwarded over an
| IPv6-only network, and turned into "native" IPv4 for the
| internet at an edge NAT64 gateway. Legacy IPv4-only
| devices (printers and such) get an isolated vlan with its
| own gateway, and will of course be replaced with
| IPv6-capable alternatives as soon as it's appropriate.
|
| I agree that for smaller companies it's relatively little
| benefit for the amount of work required, but if you're
| overhauling your network for other reasons anyways it
| makes little sense _not_ to do it.
| Control8894 wrote:
| Yes, IPv6-first is definitely the way to do it. Just be
| careful not to run into Github's issue
| (https://www.githubstatus.com/incidents/5y8b8lsqbbyq) or
| Google's issue (https://i.imgur.com/4gGECJ9.png - in case
| you're not familiar, 2002:: is the 6to4 prefix, and
| 2002:a0 is the 6to4 version of 10/8, so I guess somehow I
| was deleting old users from within Google's own network!)
| bobbob1921 wrote:
| I'm sure this will annoy some people, but two hurdles for
| me in adopting ipV6 is, #1-it's difficult/impossible to
| memorize the long v6 addresses versus the easy to
| remember ipv4 addresses (both public and private
| addresses I'm referring to). #2-lack of
| knowledge/understanding of how V6 addresses route versus
| a fairly deep knowledge of V4 addresses route/subnets.
| p_l wrote:
| The basic idea is that whenever you find yourself
| memorising an IPv4 address, there's a failure somewhere.
| Possibly at policy and governance level.
|
| Hell, if you run a modern Microsoft domain (think newer
| than Windows Server 2008), you're hamstringing yourself
| if your network is IPv4 only, because since NT6 Windows
| is _IPv6 first_ system, and there are indeed some
| corporate features that do not work if services aren 't
| available over v6.
| Control8894 wrote:
| > The basic idea is that whenever you find yourself
| memorising an IPv4 address, there's a failure somewhere.
| Possibly at policy and governance level.
|
| Sorry, but that's a load of manure. It's not just about
| memorizing.
|
| People break their DNS so often that it's a meme.
|
| Not everything automatically does a reverse lookup on
| every address it sees, and when it does rDNS could quite
| easily be broken.
|
| So when you need to figure out if a device is in the same
| building as you, is it easier to say "1.2.3. - oh, that's
| my building" or "1234:5678:90ab:cdef:1234:5678:90ab:: -
| oh, that's my building"?
|
| > Hell, if you run a modern Microsoft domain (think newer
| than Windows Server 2008), you're hamstringing yourself
| if your network is IPv4 only, because since NT6 Windows
| is IPv6 first system, and there are indeed some corporate
| features that do not work if services aren't available
| over v6.
|
| Like? I mean I avoid using MS where possible so I
| probably just haven't seen it but I'm quite curious
| what's dependent on it.
| 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.
| jiggawatts wrote:
| This is one of my tricks when evaluating products going
| through some sort of transition from a legacy to a modern
| standard:
|
| I mentally swap the labels[1] when reading their marketing
| or release notes. If it says things like "No longer crashes
| when using IPv6", then I flip that and read it as "No
| longer crashes when using IPv4". That latter statement is
| _absolutely insane_ and would have you abandoning that
| vendor as fast as you can tear up the contract. Nobody bats
| an eye with the first statement! Why not!?
|
| Azure literally had this scenario, where merely enabling
| IPv6 on one network would crash their managed PostegreSQL
| service on _another peered network_ with no recourse other
| than rebuilding everything form scratch without IPv6 to
| roll the change back!
|
| [1] Or a generic placeholder than encompasses both. E.g.:
| "Fix: Enabling _the internet protocol_ no longer causes
| irreversible outages with your database service. "
| simiones wrote:
| The reality today on the Internet is that IPv4 is still
| "the modern IP standard," and IPv6 is the next/future
| standard for early adopters.
| jiggawatts wrote:
| IPv6 is over a quarter of a century old at this point.
| ta1243 wrote:
| I have to support ipv4. Why would I want to _also_ support
| ipv6, increasing my risk and my workload.
|
| If ipv6 had been designed form the start to allow seemless
| transparent access to ipv4 from an ipv6 only client that
| would be fine. But dual stack means twice the work and very
| little benefit (what services are ipv6 only, even today)
| Plasmoid wrote:
| > ipv6 had been designed form the start to allow seemless
| transparent access to ipv4 from an ipv6
|
| It does. It's called NAT64, and it works/breaks as well
| as regular NAT44.
| bigstrat2003 wrote:
| It's not twice the work. It's actually very little work
| to run dual stack.
| WorldMaker wrote:
| > (what services are ipv6 only, even today)
|
| A good majority chunk of cell carriers today have gone
| IPv6-only for phones. They rely on NAT64 gateways (rather
| than CGNAT) to access IPv4-only resources. A lot of
| _consumer_ internet is slowly following that lead as a
| better alternative to CGNAT. At least if your customers
| are consumers we are really close to "You might only
| need to serve IPv6."
|
| (It's the "Enterprise-grade internet" that is
| interestingly lagging and falling behind in IPv6
| adoption, and maybe doesn't see enough reason to support
| IPv6-only well; especially if the cost of IPv4 plateaus
| again, as some suggest it might. Recent AWS cost
| increases for IPv4 have been something of a call to
| action to _some_ Corporations, but in general if you are
| B2B you probably need IPv4 support for a while longer as
| the economic incentives games play out on a long, slow
| horizon.)
| yjftsjthsd-h wrote:
| > Apart from how you can't necessarily unilaterally stop
| using IPv4, even if you can unilaterally start using IPv6.
|
| I thought it was possible to make a pure v6 network and use
| NAT64 as needed? I mean, we can argue if that counts, but I
| argue yes:)
| schoen wrote:
| How about in the other direction (running public services)?
| yjftsjthsd-h wrote:
| Oh yeah, that definitely needs dual stack on the outside.
| You could do v6-only internally, but you should support
| everything you reasonably can for users, which 1. applies
| to a lot of the stack, ex. TLS and HTTP versions, and 2.
| can be more or less a freebie if you're using a CDN or
| the like (ex. cloudflare will do it for you). So yes, I
| was only thinking of client-side.
| schoen wrote:
| Thanks for the clarification. I was mainly thinking of
| server-side! :-)
|
| On the client side there are apparently some subtleties
| about the DNS interaction if you want to literally have
| IPv6-only on the clients (as opposed to IPv4 CGN). If the
| clients do anything to not trust their ISP's view of DNS
| (like DNSSEC enforcement, or using DoH and an outside
| resolver), the ISP can't fool them into thinking that
| they should connect to an IPv6 address for a service
| that, from the point of view of the Internet as a whole,
| is actually IPv4-only.
| ta1243 wrote:
| > I thought it was possible to make a pure v6 network and
| use NAT64 as needed? I mean, we can argue if that counts,
| but I argue yes:)
|
| Can I do "ssh 1.2.3.4" on a pure ipv6 stack yet? Last time
| I looked at ipv6 I couldn't even ping an ipv6 host by doing
| "ping 1234::5678", I had to run a separate tool (ping6)
|
| The nat64 and vice versa should have been the play from the
| start. Want to host a sevice? Put in ipv6 only network,
| host it on 1234:5678::1, have your firewall with a public
| ipv4 address do the port forwarding, taking your public
| 12.34.56.78:1234 and natting it to 1234:5678::1.
|
| Just the same as hosting your service on 192.168.0.1 and
| port forwarding.
|
| But 20 years of dual stack and horrible cludges around
| changing public IPs later and many people still prefer
| ipv4.
| cesarb wrote:
| > Last time I looked at ipv6 I couldn't even ping an ipv6
| host by doing "ping 1234::5678", I had to run a separate
| tool (ping6)
|
| IIRC, it's been over a decade since the "ping" command
| became able to understand both IPv4 and IPv6 addresses;
| it was only during the early adoption of IPv6 by
| userspace that we had separate commands for the new IPv6
| stuff. Quoting https://www.man7.org/linux/man-
| pages/man8/ping.8.html "As of version s20150815, the
| ping6 binary doesn't exist anymore. It has been merged
| into ping. Creating a symlink named ping6 pointing to
| ping will result in the same functionality as before." So
| it seems it has been a long time since you last looked at
| IPv6.
| ectospheno wrote:
| Even with a working NAT64/DNS64 setup the PlayStation 5
| doesn't fully support IPv6 only connections. It will mostly
| work. Until it doesn't. Xbox is in the same spot with some
| games. Don't even get me started with my TVs or numerous
| IoT devices.
|
| I ran IPv6 on xfinity. It works. My devices don't. I like
| my devices. Easier to just not use it.
| braiamp wrote:
| This is something that without some pain inflicted on host
| and network operators, the needle will not move. The CA/B
| Forum could start asking that it's a requirement for CA's to
| issue a certificate that the validation will try AAAA records
| first, and warn if they can't validate, then try A. Then
| later require validation through both AAAA and A records.
| This will prepare most of the hosts to make sure every page
| is accessible through both networks. Then require AAAA
| records only, and not bothering to check A records.
| schoen wrote:
| Let's Encrypt _does_ try AAAA records first and then A.
| That 's what leads to the phenomenon that I described where
| many people end up deciding to delete their AAAA records.
| :-(
|
| I think Let's Encrypt's behavior is correct, and I don't
| think anyone inside Let's Encrypt or CA/B Forum would like
| to inflict "pain [...] on host and network operators"
| beyond the current practice. Let's Encrypt's current
| behavior could be described as _cooperating with_ IPv6
| adoption rather than _compelling_ IPv6 adoption, which
| seems like a reasonable place for a certificate authority
| to be.
|
| There are cases where Let's Encrypt has made choices that
| potentially slightly reduce compatibility in order to
| encourage what it considers technically correct behavior.
| The first one that comes to mind is
|
| https://community.letsencrypt.org/t/adding-random-entries-
| to...
|
| but I know there are others. On the other hand, all of
| those decisions can be justified in terms of improving the
| correctness of _PKI software_ (like not hard-coding things
| that should not be hard-coded). I can 't think of any
| example that's like "we wish this other technical thing
| would happen outside of the PKI, so we'll try to force it
| along", and I don't foresee the broader community getting
| comfortable with that.
| braiamp wrote:
| The power that Lets Encrypt has over domain operators is
| limited. If it becomes a requirement by the CA/B Forum,
| then every CA would have instructions on how to make sure
| you have AAAA valid records and it won't be a matter that
| "LE doesn't work because they fail on this scenario". I'm
| a behavioral scientist (aka economist), and if you want
| the public to change behavior you have to motivate such
| change and here "pain" is defined as what is necessary to
| effect that change, by increasing the cognitive load.
|
| There was a comment below that in the LE forums instead
| of asking people to fix their AAAA records, they ask them
| to remove it. That's exactly the behavior you don't want
| to reward, so you must cause pain.
| polski-g wrote:
| I would love to use IPv6. Verizon's page on IPv6 has
| literally said "check back later" for a _decade_. At this
| point there needs to be taxation penalties applied to
| carriers that don 't support it.
|
| https://www.verizon.com/support/residential/internet/getting.
| ..
| roywashere wrote:
| Odido (formerly T-Mobile) in The Netherlands is rolling out
| a huge glass fiber network, also to my house. They have an
| IPv4-only internet offering w/CGNAT. I'm really looking
| forward to fiber instead of my current DSL but really _not_
| looking forward to CGNAT and no IPv6
| sambazi wrote:
| > CGNAT and no IPv6
|
| there should be an itu mandate to label this kind of
| service distinctly different (e.g internet lite/basic)
| 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.
|
| What would such a standard look like?
|
| Well, we're talking about a vendor-neutral, architecture-
| neutral abstract machine runtime, tuned to host
| persistent, network-mobile, IO-bound, highly-concurrent
| workloads "cheaply" on a highly-multitenant basis.
|
| And Ericsson, one of the largest 3GPP equipment
| providers, created a runtime a few decades back that
| coincidentally fits that set of constraints quite closely
| -- so closely, in fact, that they'd likely just vaguely
| wave at it and say "here, standardize this." (After
| giving its architecture a few security tweaks to achieve
| multitenant safety guarantees, that is.)
|
| Just imagine: every mobile app on your iPhone, embedding
| its own little BEAM-bytecode relup package; one built by
| XCode, compiled from a combination of project source
| files written in a "network dialect" of Swift, plus
| Erlang library dependencies. And then pushed, on app
| launch, to a secure-multitentant Erlang VM sandbox, run
| by your ISP in its edge colo. Wouldn't that be just wild?
| ;)
| caf wrote:
| If Google and/or Apple have gone to the trouble to build
| the network side of this edge-computing infrastructure,
| presumably it's because they think their customers will
| see enough benefit from this to buy more devices. But
| then why would they tie this to the customer's telco
| being on board? Apple/Google surely know how to run a
| data centre, and there doesn't seem to be much that
| couldn't be hosted just as well by them as by each telco;
| on the contrary, owing the network side of the stack is
| going to make it a lot easier for them to make
| performance, security etcetera guarantees. And of course
| it means all their customers can be on board on day 1.
|
| On the telco side, as I understand it the CDN hosting
| isn't seen as a revenue centre - rather, it's there
| because it makes their pipe faster than the competition's
| (for the principle use cases of most of their customers,
| anyway).
| derefr wrote:
| > Apple/Google surely know how to run a data centre, and
| there doesn't seem to be much that couldn't be hosted
| just as well by them as by each telco
|
| Because Apple/Google can only run so many data centers.
| And these DCs are all too high-latency / "out of the way"
| of the connection path _between_ the user 's device and
| the devices it wants to talk to, to make "diverting" the
| connection path to one of these DCs worth it.
|
| Besides that, though -- doing such "diversions" would
| massively increase cost, because it would turn a one-
| backbone-path (or sometimes even zero-backbone-path)
| route into a two-backbone-path route.
|
| Instead of, userA - ispA - userB
|
| and/or, userA - ispA - backbonePath -
| ispB - userB
|
| you'd instead have: userA - ispA -
| backbonePathA - Apple/Google - backbonePathB - ispB -
| userB
|
| Apple/Google would have to _pay for the bandwidth_ to
| connect the two users to _their own_ network -- where, in
| the case of a user running e.g. a BitTorrent seed-box,
| this is an unbounded downside risk! (Remember that by the
| design of such an "offload" system, it _does not charge
| the customer_ for network traffic that transits through
| it -- only for compute. Just like Cloudflare doesn 't
| charge for basic proxying, only for Cloudflare Worker
| compute time. This will _only ever make financial sense_
| if your edge compute is "in" the existing connection
| path -- i.e. hosted in the same DC as one of the path's
| existing hops.)
|
| Now put yourself in Netflix's shoes. You don't _want_ to
| deal with residential ISPs; they 're usually large
| conglomerates that have more bargaining power than a
| random commercial colo facility in a city would have. But
| you do anyway. Why? Because, by doing so, you get a
| connection to the ISP's customers that is:
|
| - extremely low latency
|
| - extremely low bandwidth cost (because there's no need
| to traverse a backbone for any hop -- the CDN's data can
| stay on the un-congested "residential streets" of the
| ISP, without ever needing to get on the "highway" where
| it would have to _fan in_ and wait on an "on-ramp")
|
| - never-degraded QoS -- because their traffic on the
| residential ISP's network is just delivered with a
| default priority class (like everything else on that
| network, other than _maybe_ the residential ISP 's own
| OTT VoIP-based POTS service); whereas, when traversing
| any backbone, other providers who were willing to pay
| more per byte (because they had far fewer bytes to send
| and valued them more -- which is basically _every_
| provider compared to a movie streaming service) get
| higher priority classes, narrowing the virtual pipe [=
| re-allocating to fewer circuits on circuit-TDMI backbone
| routers] and so degrading service for the CDNs whenever
| other higher-priority-rate traffic wants to flow.
|
| The argument for Apple/Google putting their edge compute
| offload into residential ISP DCs would be exactly the
| same. It takes a network path that the customer was
| _already establishing anyway_ , and adds a place for a
| "user-programmable virtual router" to live in that
| network path -- without lengthening the path, making QoS
| worse, or any of that.
|
| ---
|
| But let's go at this another way: if the cost/benefit
| worked out in favor of Apple/Google doing this in their
| own DCs... then _why wouldn 't they have already offered
| this years ago_?
|
| Apple might not be a B2B cloud provider that has
| hypervisor clusters ready for customer use -- but Google
| certainly is. Why isn't "Android Offload Services,
| powered by Google Cloud Run on ARM" a thing?
|
| What I said above (doing so creating a network
| "diversion", doubling backbone connections, wrecking QoS,
| etc) still applies.
|
| But I think there's another obvious reason: if
| Apple/Google ran the DCs themselves, then this is
| something that _would_ require that you pay Apple /Google
| a subscription fee for. Without a subscription fee, it'd
| just be a money pit -- one a short-sighted CFO would
| either never green-light, or cancel after a single
| quarter.
|
| And yet, a subscription model _can 't_ be the model used
| to support the _very first_ instance of such a service
| _at its inception_ , either. "Workload offload" is
| something with (currently) zero customer education behind
| it -- i.e. it's something that customers would have
| absolutely no understanding of the value of, and so would
| never want to pay for, let alone sign up for a
| subscription they might not already be paying just to
| receive, until they _see_ the value of it demonstrated in
| at least _some other_ market, somewhere else.
|
| These two properties create a seeming catch-22: given
| their corporate structures, Apple/Google can't subsidize
| it themselves; and given lack of user education, they
| can't immediately charge for it, either. So what do they
| do?
|
| Well, if Apple/Google can talk _someone else_ into
| hosting their compute racks, in such a way that the CapEx
| of deployment is Apple 's/Google's, but the initial few
| years of OpEx and revenue for the effort winds up on that
| _other party 's_ balance sheets -- then things could
| work. It wouldn't make money, but it also wouldn't (look
| like it's) costing Apple/Google any ongoing money -- so
| they'd be able to keep the project going for its first
| few years, until user education played out and people
| started demanding it.
|
| What properties would this "someone else" doing the
| hosting need to have?
|
| Well, they'd need to be a near-commodity business, always
| in desperate need of "differentiators" to swing customers
| -- i.e. new things that are nearly nothing for them to
| set up and run, but which they can then bundle into some
| subscription service they're charging customers for, such
| that having this feature makes _their_ $60 /mo plan look
| just ever-so-slightly more compelling than their
| competitors' $60/mo plans.
|
| And they need to have a willingness to eat any short-to-
| medium-term OpEx costs associated with doing so, looking
| toward the long-term profits of such systems. They need a
| long demonstrated pattern of doing exactly this, over and
| over.
|
| Ideally, they'd be paying virtually no "real" OpEx -- as
| they'd already have some under-populated DCs laying
| around, with bulk-purchased power commitments and
| bandwidth provided as some kind of internal sweetheart
| deal.
|
| Even more ideally, they'd have lobbyists who would get
| them massive government "technology evolution" subsidies
| for doing anything like this, that would more than pay
| the OpEx costs.
|
| Know any companies like that? Because I sure do!
|
| ---
|
| That being said, I would imagine that the math would work
| out slightly differently for different residential-ISP
| customer-base compositions.
|
| It might be impossible to launch "workload offload" as a
| feature in the Bay Area or other tech-hubs at first, as
| those would be unprofitable if given away for free, due
| to the number of novelty-seeking nerds who'd actually
| make use of (apps that make use of) the service from day
| 1. The ISPs would likely get quite irritated if
| Apple/Google were coming into their DC to constantly rack
| more and more of these servers -- even if the literal
| OpEx works out, they'd have to staff up their DC ops just
| to handle the increased hardware churn rate!
|
| As such, I'd expect an ISP's workload-offload offering,
| to be something rolled out first in big cities that _aren
| 't_ tech hubs, and "proven out" there, mostly by users
| using the feature entirely unaware that they're doing so
| (because it's _the app on your phone_ that decides to
| launch a workload, not you-the-user!)
|
| Viral user education about the benefits of such services
| would filter out from such cities, to the rest of the
| world, where demand for them would build over the course
| of maybe... two years? -- for ISPs to then start actually
| billing (and _usage-based_ billing, with flat-rate
| billing only on premium data plans!) for the service.
| tjoff wrote:
| I fundamentally disagree with most of your points.
|
| It might work for a usecase you have in mind but in
| general, it can't work. And it assumes that the world is a
| perfect place where the incentives are aligned and that
| ISPs cooperates and that you'd actually want to expose your
| phone. As if the tech we have (mobile networks, phone
| batteries, coverage) would allow for it, _which it don 't_.
|
| And somehow denial of service attacks is only worth
| mentioning when you have a dedicated PC with proper
| 100+mbit internet but not when you have a battery powered
| phone with wireless connection?
|
| And I truly fail to see how all anyone could even argue
| that all that complexity would be better than direct
| access.
| 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.
| JoshTriplett wrote:
| I'm all for reclaiming 240/4 eventually, if it can be reliably
| used. But I saw a mention in the article of 0/8 and 127/8, and
| I hope those never get changed. There are too many systems out
| there with assumptions about those addresses, and unlike 240/4
| where the failure mode is "can't reach the host", for 0/8 and
| 127/8 the failure mode has security implications.
| zamadatix wrote:
| I've previously talked about opening this space up (sometimes
| here [1]) in similar light to how Ben does in regards to it
| (more or less) being "an extra source of pain" rather than a
| solution to anything. My opinion has been the same through
| multiple proposals for this, though some have had minor
| differences to considers. There are two main reasons I believe
| this across all of them:
|
| The first is, particularly on opening it up for public
| assignment, all of the compatibility issues mentioned. It's not
| enough that in 2035 99% of things could be compatible when
| talking about existing internet infrastructure - it has to be
| 100% going to work (without hoping everyone just catches up,
| this isn't a separate internet like IPv6's rollout is) if you
| want to bet interoperability of the established internet on it.
| The alternative is let people use it but not on the internet,
| that way they own their own interoperability with themselves or
| anyone directly interacting with their internal network. If
| this were a security issue I'd have different feelings on it
| but it's about convenience so it isn't enough that it's
| possibly more convenient to most 10 years from now. Especially
| since the problem and solutions will have evolved so much 10
| years from now anyways.
|
| The second reason is, even if it does work out 100%, it's not
| much a solution to anything anyways. IPv4 pressure has started
| causing places with large blocks of old IPv4 space moving to
| NAT, carries deploying double NAT via CG-NAT, cloud providers
| looking at public IPv4 address fees, and the entire mobile
| world being IPv6 first with some going as far as IPv6 only with
| NAT64. Each one of these solutions already in place has
| resulted in more usable IP space than this would open up so
| this solution could neither replace them or stop them from
| being needed in the future. Each existing alternative (however
| non-ideal) is either a longer term mitigation or step towards a
| long term solution to the shortage instead of a small basket of
| addresses to throw on the fire. In particular the NAT64 and
| 464xlat solution have proven to be a long term permanent answer
| for the vast majority of the cases people thought they needed
| these kinds of addresses for that would have left them less
| prepared when these too ran out. I particularly don't buy the
| idea that the world just so happens to need exactly a /4 more
| of space and everything would be alright - it only looks that
| way because of the above methods being pressured into
| happening. Remove that pressure and it (at best) can hope to
| delay the rollout numbers of those methods by a decade.
|
| All that said I'm still in support of opening it up for private
| use cases like enabling 0.0.0.0/8 in Linux [2] did (think use
| cases like another /8 of space you can slap your Docker
| container NATs behind or your HA networks behind for software
| that doesn't support v6). Not only do I think that would result
| in less pain for the internet at large I think it would
| actually result in a larger decrease in IPv4 pressure long term
| by giving more spaces to NAT to/from for those not ready/able
| to NAT64 all of their internal services.
|
| [1] https://news.ycombinator.com/item?id=39804231,
| https://news.ycombinator.com/item?id=32796355
|
| [2]
| https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
| 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.
| jeroenhd wrote:
| All the cloud providers I rent services from offer IPv6. It's
| only the really big ones that seem to be dragging their feet.
|
| I suppose the multi-AZ stuff makes things more complicated,
| but my $5 VPS host had IPv6 like what, ten years ago?
|
| This does have one small benefit: since none of the large
| cloud providers seem to do competent IPv6, you can avoid
| scanners, scrapers, and other log polluters on personal
| services by just hosting them on IPv6.
| spacebanana7 wrote:
| Is anyone aware of why those decisions not to adopt IPv6 were
| made? Presumably there've been discussions at both companies
| about it.
| throw0101d wrote:
| > _Is anyone aware of why those decisions not to adopt IPv6
| were made?_
|
| Because they have all the IPv4 address they need and so do
| not see a shortage, unlike _those that are not mega-corps_
| and _are_ struggling:
|
| > _I work for a Native American tribe in the PNW. We
| scrambled to get the reservation reliable internet in the
| later part of 2019. We managed to cover most of the
| reservation with wi-max and wifi with a fiber back haul
| configuration. We are now slowly getting more stable and
| reliable fiber to the home(FttH) service installed to as many
| homes as we can, but it is slow process covering the mostly
| rural landscape doing all the work in house._
|
| [...]
|
| > _We learned a very expensive lesson. 71% of the IPv4
| traffic we were supporting was from ROKU devices. 9% coming
| from DishNetwork & DirectTV satellite tuners, 11% from
| HomeSecurity cameras and systems, and remaining 9% we
| replaced extremely outdated Point of Sale(POS) equipment. So
| we cut ROKU some slack three years ago by spending a little
| over $300k just to support their devices._
|
| * https://community.roku.com/t5/Features-settings-
| updates/It-s...
|
| * https://news.ycombinator.com/item?id=35047624
|
| Anyone who (a) got in early on the IPv4 address land grab, or
| (b) has buckets of cash, can 'safely' ignore IPv6.
| 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 always regarded as downright
| antisocial. 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
| pests wrote:
| Ha, seeing the list of jargon being defined was eye
| opening - I understood everything without a second glance
| but, like you I assume, I've been exposed to this world
| for 25+ years as this point and its second nature.
|
| I remember the first time I used "characters" in front of
| a non-technical friend instead of just the more common
| "letters" or literally anything else.
| inopinatus wrote:
| "octets" is a good one, especially if you have musical
| friends
| JoshTriplett wrote:
| I think "octets" is at this point historical jargon with
| little present value. It dates back to the day when some
| vendors were fighting for non-8-bit bytes. Those systems
| are long dead, and "byte" means "8 bits". Given that, I
| don't know of any context in which "octet" is an
| important distinction rather than an obfuscation.
| pests wrote:
| Still makes a little sense as IPv4 addresses are 32 bytes
| and we break them down into 4 parts of 8 bits each. No
| one ever uses the 32 byte number, which will resolve.
| JoshTriplett wrote:
| IPv4 addresses are 32 _bits_ , or _4 bytes_. "octet"
| still isn't useful there.
| pests wrote:
| On second thought I take disagreement with defining a
| byte as 8 bits. I would say its de facto 8 these days but
| not always and has always been hardware-dependent. If I
| give you a random page of documentation from the last 70
| years of computer history and it's talking about a byte,
| you have no idea if that means 5 bits or 12 or anything
| else.... which is why I think octet is useful here as it
| _always_ means 8 bits and always will.
| JoshTriplett wrote:
| There's a reasonable distinction between "term useful to
| understand historical documentation" and "term useful to
| use in new documentation/communication". No new system or
| protocol or piece of documentation should ever use
| non-8-bit bytes. If you're reading old protocol
| documentation, you get used to "octet" being used in
| place of "byte"; that doesn't mean _new_ documentation
| should cater to systems that haven 't existed for a long
| time.
|
| (Also, this tangent really isn't worth spending time on.)
| pests wrote:
| Yet we seem to have all agreed to use octet, even for new
| documentation. I browsed the recent RFC submissions and
| had to stop looking as pretty much every one I checked
| that was posted this year uses octet. A few examples...
|
| https://www.rfc-editor.org/rfc/rfc9565.txt
|
| https://www.rfc-editor.org/rfc/rfc9598.txt
|
| https://www.rfc-editor.org/rfc/rfc9574.txt
|
| https://www.rfc-editor.org/rfc/rfc9582.txt
|
| So why try to force byte into this role?
|
| (agreed)
| pests wrote:
| I meant 32 bits, of course.
| Sesse__ wrote:
| Characters is a pretty poor term these days, since it can
| refer to any of bytes, code points, extended grapheme
| clusters, or possibly more I haven't thought of.
| pests wrote:
| That was what I was referring to though - grapheme,
| grapheme-like unit, or symbols, letters, numbers, emoji,
| punctuation, etc.
| js2 wrote:
| > Since alias records (a.k.a CNAME records) aren't
| permitted at the apex...
|
| Technically this is a subset of the rule that CNAME
| ("canonical") records cannot co-exist with any other record
| type with the same label. e.g. it's illegal to have
| `foo.example.com` be both a CNAME and an A record. Since an
| SOA record is required at the zone apex, you can't also
| have a CNAME record there. :-(
| sambazi wrote:
| not really TLDR
| 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.
| teddyh wrote:
| > _In that case you would do this kind of query (called
| SRV) for http.tcp. example.com_
|
| You're forgetting the underscores: It's actually
| "_http._tcp.example.com". The underscores are there to
| avoid any possibility of collisions with host names, since
| host names are not allowed to contain underscores, but are
| generally allowed in the DNS.
| PinguTS wrote:
| > However http://example.com cannot use CNAME because it is
| an apex record [snip]. And this caused many websites to
| occupy an IP address unnecessarily.
|
| That's not true. I have an server with a single IP and a
| number of Domains that are served from that single IP like
| http(s)://example.com http(s)://example.org
| http(s)://example.de
|
| All of those delivery completely different websites from
| that single domain. You are mixing up two tings: DNS with
| HTTP(s). In DNS its right but for HTTP(s) it doesn't
| matter.
| billyjobob wrote:
| Of course you can have multiple apex A records that point
| to the same IP address. We are talking about CNAME
| records here. Are your sites using CNAME records or A
| records?
|
| Even if you are using CNAMEs, that's only been possible
| recently due to hacks/workarounds, as bonzini said.
| linsomniac wrote:
| I'm imagining, but someone please correct me if I'm
| wrong, that this is related to the
| policy/standard/convention (?) that IPs have a single
| canonical name, so reverse and forward match. I've never
| really followed that strictly, though I've been aware of
| it and try to follow it as I can, because it makes
| management of DNS a little more sane.
|
| Because of no SRV records for HTTP and no CNAME for apex
| records, you can't follow "one true name per IP" without
| giving an IP to every domain.
| PinguTS wrote:
| Actually reverse and forward match is important for SMTP
| these days. It is one piece in the puzzle to detect spam.
|
| I run may own email server now for more than 20 years.
| Only recently I in-cooperated public RBLs to deny spam. I
| still don't like it to depend on external services for
| this, which flag spam incorrectly.
| bonzini wrote:
| I'm talking purely about DNS, and in fact I wrote
| explicitly that "HTTP can multiplex multiple sites on a
| single IP address", because the problem exists only at
| the DNS level.
|
| A compounding issue is that CDNs (or GitLab/GitHub) want
| to be able to change their IP addresses, so they don't
| want you to use an A record.
| hackernudes wrote:
| Dns A/AAAA record = IP address
|
| Dns SRV record = IP:port
|
| Not sure why SRV never really caught on for most internet
| stuff.
|
| (Edit: SRV records are hostnames, not IPs, so I guess it
| takes two lookups?)
| inopinatus wrote:
| To be precise, SRV records don't immediately return an IP
| address; they return canonical name(s) (i.e. FQDN of hosts)
| whose IP addresses can either be included in the additional
| part of the DNS reply or resolved separately.
|
| In addition to canonical name & port number they also
| include priority & weighting values, although the
| usefulness of these depends on the service.
|
| SRV might not be super visible in the application
| developer's lane, but swim outside and there's a lot of it
| about. It's foundational for SIP, for example (IP
| telephony). Email remains a tremendously significant
| internet utility and SRV is used, albeit not universally,
| for discovery of client endpoints (SMTP submission, IMAP,
| CalDAV etc). However, SRV hasn't replaced MX for SMTP
| between MTAs, perhaps because MX already does basically the
| same and was established years prior. And, well, Jabber is
| dead, but XMPP was another fully worked demonstration of
| SRV's capability.
|
| In more local environments SRV is used for
| resolution/discovery in Active Directory (Microsoft) and
| Bonjour (Apple) - if you listen to the wire on any local
| network you'll often see a ton of SRV over mDNS or DNS-SD.
| Perhaps ironically, one of the objections that sometimes
| arose to using SRV for HTTP was from Active Directory sites
| with zone cuts at _tcp.example.com and facing additional
| complexity in any transition.
| riobard wrote:
| I never understand the reasoning behind the design
| decision that SRV cannot just return IP address and
| forcing clients to query again for A/AAAA again. That
| decision forces an extra RTT before connection can be
| established, which makes people want to avoid SRV
| records. Totally self-inflicted wounds.
| EvanAnderson wrote:
| I'm with you.
|
| Binding IP addresses into the TCP tuple is the thing that makes
| saddest about the could-have-been Internet.
|
| Lack of adoption of SRV records is a close #2. So much IP space
| would have been saved. Load balancing and failover would have
| been so much easier.
|
| (32-bit addresses is up there too...)
| yuliyp wrote:
| I feel like this is a drop in the bucket. Compared to the
| number of clients, the amount of HTTP servers on the internet
| (probably no more than a couple million if I had to guess)
| feels like it takes up a small fraction of the IPv4 address
| space.
| lifeofguenter wrote:
| You are right, approx 2B households alone exist.
|
| Using SRV and increasing IP address space "by 64k" is only
| valuable for large single consumers such as AWS.
| kbolino wrote:
| Most clients sit behind NAT
| jeroenhd wrote:
| The SVCB/HTTPS records won't save us, because of the same
| reason TLS 1.3 pretends to be TLS 1.2: middleboxes everywhere
| have been configured to only let traffic to port 80 and 443
| through. Almost everyone is running an HTTP 1.1 server so
| there's completely transparent fallback for those networks, but
| it also means those records are kind of pointless.
|
| I never really got the point of the new records either. From
| what I can tell, they're just SRV records. A separate record
| class could've made sense with DANE, but nobody implemented it.
| sph wrote:
| > middleboxes everywhere have been configured to only let
| traffic to port 80 and 443 through
|
| They are not everywhere though. They are not on the greater
| Internet. They are not on residential networks. I have access
| to the full 65535 TCP ports everywhere in the world on my
| average Internet connection.
|
| These middleboxes you speak of are appliances paid for and
| placed inside of corporate LANs. They can pay to put more
| modern ones, or just getting rid of them.
|
| The point is that these middleware appliances we often use as
| a scapegoat exist only in well-controlled private networks.
| Why should we care about them?
| zamfi wrote:
| >The point is that these middleware appliances we often use
| as a scapegoat exist only in well-controlled private
| networks. Why should we care about them?
|
| Perhaps for the same reason we only stopped caring about IE
| 6 after its usage dropped below a tiny percentage.
|
| For better or worse, making your website available to as
| many groups of people as possible, regardless of their
| browser selection or network configuration, has been a
| long-standing goal in the community.
|
| If your website isn't available to folks at the offices of
| company X because they use appliance Y, through no fault of
| user Z's, well...that's not ideal, is it?
| the8472 wrote:
| Or they could be ignored so that the users drag their IT
| kicking and screaming into the 21st century once an
| important enough site necessitates it. Corporate users
| usually have more direct influence on their IT than ISP
| customers.
|
| https://blog.chriszacharias.com/a-conspiracy-to-kill-ie6
| zamfi wrote:
| Exactly! That post I think perfectly encapsulates the
| typical line of thinking here.
| chaorace wrote:
| I concur. Corporate LANs are to the internet as VMs are to
| servers. Trunking, VLANs, and NAT have so completely
| decoupled these networks from underlying infrastructure
| that the transport protocol itself is little more than an
| implementation detail. IPv4 remains king because it is
| well-known and cheap -- the fact that we all settled on
| using the same interoperable protocol for both LANs and the
| internet was never a foregone conclusion.
| jeroenhd wrote:
| They're present often enough that the people developing the
| TLS spec had to invent workarounds.
|
| Personally, I would've preferred to ignore the spec
| incompliant middleboxes, or even report an error about
| something meddling with the connection to the user when
| it's obvious they're the cause of any connectivity issues.
| That's not a very popular approach for spec designers,
| though, because they're afraid people will blame the new
| software rather than the Enterprise(tm)
| NetworkProtection(c) box they paid six figures for. After
| all, the software is what changed, not the box!
| teddyh wrote:
| If this proposal is accepted, it will make it less likely that
| people will simply continue to steal random unoccupied and/or
| unimportant ranges of addresses and reuse them for their own
| purposes, which in turn would make IPv4 interconnectivity more
| and more uncertain, which would probably drive IPv6 adoption...
| Hey, wait a minute... I'm suddenly not convinced this is a good
| idea in the long run.
| znpy wrote:
| For f..k's sake can't we switch to ipv6 already?
|
| Let's just put ipv4 on life support, reclaiming 240.0.0.0/4 is a
| bad idea.
| SirMaster wrote:
| I was surprised to find that back when I went to college, every
| computer connected to their network, whether it be the laptops
| that each student had via the required technology package, and
| even personal desktop computers and gaming consoles and every
| device connected to the network in the dorms, every machine was
| given a public facing IP address without NAT.
|
| Even your phone or tablet on the campus wifi got a unique public
| IP...
|
| Of course there were firewalls in place and all the incoming
| ports were blocked, but doesn't that seem like a big waste of
| IPs?
|
| The university owns 155.92.0.0/16 and every machine on the
| network gets a 155.92.x.x IP address.
|
| https://ipinfo.io/AS11500/155.92.0.0/16
|
| Is this normal? Or shouldn't the IPs all be NAT'd behind a few
| public IPs?
| stouset wrote:
| If you own the public IPs, why not use them?
| SirMaster wrote:
| Sure, but should a school even be given all those IPs to be
| used like that?
|
| Seems like a waste to me to have it where every device on the
| campus network gets a public IP, like every students phone,
| laptop, tablet, desktop, game console, etc.
| stouset wrote:
| Today, absolutely not. But the damage was done back when
| those ranges were doled out.
|
| That said at this point I kind of half-seriously prefer
| keeping the IPv4 space as exhausted as possible if it'll
| even slightly drive adoption of IPv6.
| teddyh wrote:
| Why should every individual person have their own physical
| mailing address? Couldn't they just get their paper mail at
| their workplace? Or is it a vital component of democracy and
| individual freedom that people can recieve mail and other
| missives independent of their workplace's curious eyes and
| sufferance?
|
| Or voting. Should really _everybody_ get a vote? Most people
| don't _really_ need to vote. This is evidenced by the huge
| numbers of people who don't vote. And most people who do vote
| do it badly, anyway.
|
| /s
| eep_social wrote:
| This is at least partly historical. Early adopters got
| allocated IP space before it was apparent that it would be
| scarce. I seem to recall that MIT has an entire class A. I
| think the US military had a whole pile of class As as well. I
| haven't kept up with this layer so I don't know whether any of
| this has been returned to ease allocation woes, but I doubt it.
| p_l wrote:
| You were enjoying IPv4 as it should be deployed.
|
| Remember, NAT _breaks_ IPv4. A NAT-ed network is not fully
| compliant IPv4 network.
___________________________________________________________________
(page generated 2024-05-28 23:02 UTC)