[HN Gopher] Amazon, Verizon found using IPv4 240/4 addresses
___________________________________________________________________
Amazon, Verizon found using IPv4 240/4 addresses
Author : dtaht
Score : 88 points
Date : 2022-08-23 15:51 UTC (7 hours ago)
(HTM) web link (labs.ripe.net)
(TXT) w3m dump (labs.ripe.net)
| pm2222 wrote:
| Couple points:
|
| a. Do linux/windows just take it 240/4 address without special
| attention?
|
| b. Fun time when 240/4 will be released to public in the future
| it's gonna be a huge headache for them.
| cloudymeatballs wrote:
| tacker2000 wrote:
| I guess the big companies are not really keen to move to IPv6,
| since they control large swaths of IPv4 territory anyway. And
| only they would have the power to initiate a move, so i guess we
| are stuck in somewhat of a limbo here...?
| TheDudeMan wrote:
| It doesn't look stuck to me.
| https://www.google.com/intl/en/ipv6/statistics.html
| cm2187 wrote:
| only 40% adoption after 25 years, that's stuck to me.
| gnfargbl wrote:
| Not stuck, but hardly a runaway success. That graph shows
| adoption at 40% and increasing, roughly linearly, at maybe 5%
| a year.
|
| At this rate, it's going to be 2040-2050 before we are in any
| realistic position for an IPv4 switchoff.
| tacker2000 wrote:
| Thank you thats very interesting!
|
| Why does India have such a large adoption rate? Because the
| got newer hardware to start with I guess?
| wmf wrote:
| AWS has the best IPv6 support of any cloud. It came 15 years
| late but they finally caught up.
| bbarnett wrote:
| I think they're waiting for ipv8, as I am, which is really just
| an extra octlet at the start of the IPv4 block.
|
| ipv6 is windows me. Skip over it. Wait for ipv8.
|
| edit: Oh! We could make ivp8 just 16bit instead of an octlet!
| Macha wrote:
| Once you make any change, even just "add another octet",
| you're into the chicken and egg problem IPv6 faced until
| recent years forced the hands of some ISPs. Given that IPv6
| now has something like 20% adoption, there's little point
| starting over with something people view as simpler because
| of smaller changes to the written representation of
| addresses.
| phpisthebest wrote:
| There is alot more changes then just an expanded space with
| ipv6
|
| So while you may have a similar problem it would be FAR FAR
| FAR FAR easier for organizations to adopt an addressing
| system that works EXACTLY the same as ipv4 just with a
| larger address space
|
| then all the other "improvements" they are forcing down
| everyone network (unwanted) in with ipv6
|
| ipv6 spec caused all the problems by biting off more than
| what was needed to solve the problem.
| bbarnett wrote:
| It's easy to start with.
|
| Phase one has us use something in tcp headers, maybe
| something in the reserved area, to set a number. It's OK
| for that to just be maybe 1 to 4 even, or something small
| depending upon bit size requirements.
|
| Since old systems won't use that reserved header space to
| determine anything, they'll ignore it. And _new_ systems
| will exclusively use unroutable address space, like 240
| being discussed here, for routing.
|
| So old systems will drop the 240/ address space, but new
| systems will route it, as it will be 2.240.x.x.x. So only
| compliant systems will see the new address space ; the rest
| won't.
|
| It won't help old systems, but it will mean new systems
| only using old address space, can speak to old systems,
| without breaking them.
|
| Everyone loves sensible change, so unlike ipv6, ipv8 will
| only take 20 years! (What's ipv6 been out for, 25 years and
| not adopted yet?)
| jrockway wrote:
| Rather than changing TCP, we could just make web browsers
| query SRV records to see what port to connect to. Then
| you could host 65535 websites on the same IP address,
| without requiring any software in the middle to check
| Host/ALPN/SNI. (The web is moving to UDP anyway with
| HTTP/3. Not saying the web is the only important part of
| the Internet, but it's a big one.)
|
| IPv6 is kind of over the major adoption hurdle of
| rewriting all software to understand it. Nearly all
| software understands it. I'm not sure anyone really has
| the appetite for that again.
| wollsmoth wrote:
| haha, oh man you had me going there for a second.
| bbarnett wrote:
| I've been thinking, we really just need lots and lots and
| lots of IP addresses, far more than we realise right now.
| ipv8? Should probably be ipv32 or some such.
|
| An example ; when we start throwing smart nano on the
| grass, to see how each blade of grass is doing on your
| lawn. Well, each nano is going to need an IP address, and
| so will all in the neighbourhood. And that's just the
| _grass_.
|
| What about when some scientist wants to track sand
| dispersal patterns, on a beach, after a hurricane? And
| wants to have each grain of sand tagged with its own nano
| hitchhiker? Just think of the IP addresses we'll need then!
|
| And even medicine. What if we want to interally tag each
| cell in our bodies with nano? What if we want to
| bioengineer our body, so that each cell has its own IP
| address? And can report health/condition?
|
| No, we need more, more _more_ IP addresses! So many more.
| jacobyoder wrote:
| > What if we want to interally tag each cell in our
| bodies with nano?
|
| There will need to be multiple addresses for all the
| nano-services running inside each of those nanobots.
| Solution: install a k8s cluster with each nano...
| tacker2000 wrote:
| Yes or install a main router/access point for each human
| that sub-adresses all nanobots. Or do you want them
| exposed to the broader internet?
| vlan0 wrote:
| Society will collapse before we ever have a need for more
| IPs than what's in v6.
| tacker2000 wrote:
| Well, IPv6 has 128 bits, so 3,4 x 10^38 adresses. Surface
| area of the Earth: 5,1 x 10^14 m2. Maybe adressing grass
| blades could be possible with IPv6.
| lbotos wrote:
| I mean, IPv6 is a lot of addresses:
|
| https://www.techtarget.com/whatis/feature/IPv6-addresses-
| how...
| nrdgrrrl wrote:
| SonOfLilit wrote:
| https://xkcd.com/865/
| knorker wrote:
| Amazon and Verizon definitely don't have as many IPs as they
| want or need.
|
| Other clouds too.
|
| And CGNAT is expensive. No. There are some legacy allocations,
| but at least my experience is than nobody has enough.
| bbarnett wrote:
| _In sum, we only found two companies that are using 240 /4 IP
| space privately._
|
| If anything, this is almost a warning from ARIN that this block
| might be finally repurposed. They find no one using it except for
| two companies internally ; they're seeking to see if 240/reserved
| is used or not is seems.
|
| And really, anyone using 240 is to blame if it does get
| repurposed, so it seems like a good idea.
| knorker wrote:
| To blame, maybe. But say you get a class E network. Are you
| fine not being able to talk to anything hosted on AWS?
|
| Blame is not correlated with pain.
| MrStonedOne wrote:
| bbarnett wrote:
| It may take a year or two, but I think AWS would clean up its
| act. I'd be worried about some megacorp using it inside some
| deep internal project, and for a decade after having bizarre
| deliverabilities issues for mail or something, randomly,
| without its staff understanding why.
| icedchai wrote:
| You may have difficulty talking to other things, too. Older
| equipment simply won't communicate with class E addresses.
| It's hard coded in! It works for AWS because they control
| their network, end-to-end.
| knorker wrote:
| I know multiple large companies that would have no choice but to
| block any public use of these, as they have databases where these
| addresses have special meaning.
|
| Yes, obviously that was a terrible choice to make. But it's
| there. And legal compliance means they can't just let these
| addresses in as normal unicast.
|
| So while these can work as rfc1918 and similar, nobody will ever
| want to use these on publicly facing clients or servers. Too many
| places will never support them.
|
| I'd rather be behind 3 layers of CGNAT.
| icedchai wrote:
| Plus there's tons of legacy equipment that simply won't work
| with 240/4. It will be a support nightmare. Arguably, opening
| up 240/4 could've been done around the time we started rolling
| out IPv6... It's a bit late now.
| tedunangst wrote:
| This seems like a rather long post for the equivalent of "haha, I
| can see your underpants." What's the real significance to this vs
| seeing 10/8 show up in a traceroute?
| JonathonW wrote:
| If you're using addresses in the 240/4 block, you're going to
| run into issues when/if those addresses are assigned for public
| use.
|
| It's not necessarily a problem for the general public, but will
| pose a routing problem for those using them internally.
| grogers wrote:
| These are being used as link addresses, they probably aren't
| even routable within Amazon's network. They probably want the
| link addresses to be globally unique so it simplifies
| management or so traceroute reverse lookup is easier (e.g. to
| pinpoint traffic loss). They probably ran out of the other
| RFC3330 usual suspects or something.
|
| I wouldn't read too much into it. If they are using it in a
| way that will break if 240/8 is assigned, I'm sure they will
| fix it quickly.
| tedunangst wrote:
| People have been privately squatting on public networks like
| 11/8 since forever. It's a problem for them, maybe, and a
| mild curiosity for the rest of us. I'm just saying "we saw
| 240 in a traceroute" could have been a tweet, not a research
| paper. I kept scrolling and scrolling trying to find out why
| it wasn't a tweet.
| Melatonic wrote:
| Tell that to China who internally are apparently using all
| kinds of unusable addresses due to the The Great Firewall!
| MrStonedOne wrote:
| gnfargbl wrote:
| The article discusses a 2007 proposal [1] for 240/4 to be used
| as a private address space -- essentially a bigger, alternative
| to 10/8 -- and then goes on to imply/state that the proposal
| failed as it was felt that adding further sticking plasters to
| IPv4 was somehow undermining IPv6 adoption. The point of the
| article seems to be to show that in reality, 240/4 is being
| used as a private address space despite not being officially
| sanctioned as such.
|
| As I think you're pointing out, that's not necessarily
| interesting because if 240/4 _were_ officially sanctioned as
| private space, then these people would likely not want to use
| it, for the same reasons that they aren 't already using 10/8.
|
| [1] https://datatracker.ietf.org/doc/html/draft-wilson-
| class-e-0...
| OJFord wrote:
| For it to be visible at BGP level I suppose they must be used
| publicly? But that aside, as a a bad practice, surely you can
| basically use _any_ IP that you 're not supposed to, as long as
| you don't care that it stops the real one being reachable? I.e.
| 'reserved for future use' can be considered 'private use if you
| must, for now, may change without notice'?
| inopinatus wrote:
| These aren't being announced at the edge. They're appearing in
| traceroute responses, and some are directly reachable from
| inside the AS, which means they're appearing in the IGP.
| Announcing networks in this range to peers would be an huge no-
| no.
|
| You can't just use any IP: some are truly special (e.g. the
| multicast range) and 240/4 is still treated as invalid by many
| currently deployed IP stacks in their off-the-shelf
| configuration. Getting away with this only works at the kind of
| integration scale where you're smelting your own copper, so to
| speak.
| wongarsu wrote:
| They are only visible in traceroutes. Ripe seems to operate
| devices to collect BGP stats that also do periodic traceroute.
| Some of the packets they sent out crossed a router with IPs in
| the 240/4 block, but those are only used internally and not
| advertised outside the AS (apart from the suspicion of
| different Amazon AS advertising their 240/4 addresses to each
| other).
| inopinatus wrote:
| RIPE have been running Internet observatories for decades. I
| remember the members of the TTM (test-traffic measurement)
| project in the late 90s trying to get ISPs to install GPS
| receivers on the DC roof for accurate one-way latency
| observations.
___________________________________________________________________
(page generated 2022-08-23 23:00 UTC)