Even with the ability to renumber RFC1918 is just not that large, and when you need to summarize routes/BGP you can't easily re-use empty space from one location in another because it'll blow up your routing tables.
7,174 karma · joined February 18, 2010
Portfolio: http://deltaregeer.com/ Engineering Notebook: http://funcptr.net/
delta@regeer.org
When every set top box, cable modem, customer wifi gateway, and all of your routers/management interfaces need RFC1918 space it goes real quick, real fast.
It gets even worse when you are have to have a lab where you can setup infrastructure that looks/feels exactly like production and thus needs similar setups, now do that for testing/staging... and there's doubling of your required IP space already.
1. IPv4 private with NAT gateway and ELB dual stack providing IPv4/IPv6 for clients
2. IPv4 private with 1:1 ephemeral IP (avoids the NAT gateway tax, but now every VM gets a public IPv4 address) and ELB dual stack providing IPv4/IPv6 for clients
3. IPv6 globally unique with no IPv4 and ELB dual stack providing IPv4/IPv6 for clients
With option 1 you end up paying money for the NAT gateway for any outbound traffic instantiated from the instance (not return traffic through the ELB), this costs you 2 IPv4 addresses (1 for NAT gateway, one for the ELB, ignore AZ's and HA for now)
With option 2 you end up not paying for the NAT gateway, but get a free IPv4 address per VM, so N VM's + 1 ELB IPv4 address is N + 1 IPv4 addresses. (NAT Gateways are expensive, even if you have one sitting mostly idle, and don't forget cross AZ traffic if you have only one NAT gateway but instances in multiple AZ's, or you need to spin up multiple NAT gateways).
With option 3 you end up not paying for the NAT gateway, nor do you use a public IPv4 address. This might not work if your instance needs to reach IPv4 parts of the internet, but if its just API servers that communicate internally, they likely don't need to and can use IPv6 for the remaining traffic. Now you have just 1 IPv4 address on the ELB.
If AWS were able to incentivize its customers to deploy their systems in an IPv6 only configuration this would put pressure on the publishers of software to make sure their systems are IPv6 enabled so that their customers could download it, and it would reduce the amount of public IPv4 addresses that are required across AWS as a whole.
Running an IPv6 only core is entirely possible, and makes sense. No more worrying about overlapping IP space (having worked at two companies where they ran out of RFC1918 space and you had to deal with multiple hops to get into various networks, which is no fun), thus simplifying network management.
Azure's IPv6 support is terrible, and does not support IPv6 only networks: https://docs.microsoft.com/en-us/azure/virtual-network/ip-se... including limitations on the prefix size you can get for your VM's: https://docs.microsoft.com/en-us/azure/virtual-network/ip-se... no /56 like you can get in AWS that you can then slice /64's out of for subnets and no prefix delegation for running container workloads on their own GUA.
Where Azure was ahead was that its load balancers supported targeting IPv6 addresses and thus didn't require IPv4 for forwarding traffic.
AWS fixed that today.
AWS should be lauded, and while it is long overdue (IPv6 core, with IPv4 only on the edge makes so much sense) AWS is the first hyperscaler to do so.
It seems kind of silly to undergo this endeavor, instead of adopting IPv6. We are simply staving off the inevitable with these extensions people keep proposing.
You can use the following:
netstat -rn -f inet | grep default | head -n 1 | awk '{ print $2 }'
scutil --dns
I am guessing its an bug in the tool itself that the user ran into.
https://www.jittruckparts.com/blog/post/3-takeaways-from-the... https://www.ccjdigital.com/maintenance/article/15066337/truc...
There's a lack of shipping options available to get items to the US in the first place, that means that various bits and bobs necessary to manufacture a widget aren't available because they are stuck in a shipping container somewhere around the world and there is no available space to put it on a ship.
That being said, TUV like UL is listed as a Nationally Recognized Testing Laboratory (NRTL) in the United States (for more information see: https://www.tuv.com/usa/en/ctuvus-certification.html) and thus is just as safe.
The UL logo may be more recognizable in the US, however they too certify for both markets, with UL also having their UL EU certification program.
Certain shortcuts for things like managing windows are now behind Fn + a key vs Ctrl + Option + Cmd + key.
While traveling I miss my keyboard, but because its not ortholinear at least it retains similar key position so switching to a different keyboard hasn't caused too many issues.
Not sure where in the world you are, but Sprouts in the US sells milk in glass bottles. You pay a fee, and you get that back when you return the glass bottle the next time you come in to buy more milk.
It's not delivery, but it's a whole lot better for the world than more plastic.
See https://stackoverflow.com/questions/32290167/what-is-the-max... for more information.
Using a longer TLD won't change the maximum length.
In the past 4 weeks I have received 6 resumes for people looking for remote work because they much prefer to live outside the city center and have more room for activities, and they don't want to go back to commuting for hours per day or sitting in traffic.
Find My on your phone already has to get an approximate location, and it does so fairly frequently (since you can track somewhat realtime).
So having an Air Tag piggy back on the same mechanism won't cost a whole lot in terms of having to power on the geolocation capabilities.
Telling users to re-install the system seems a little drastic and seems like the last thing Apple would recommend were you take your machine to the genius bar...
https://appleinsider.com/articles/21/03/04/researchers-rever...