Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How bad is IPv4 address exhaustion?

blog.apnic.net

Post reply on HN
Print view View original

61–70 of 94 posts

Re: How bad is IPv4 address exhaustion?

#61

Post by tzs »

gwbas1c wrote: post #56
mgkimsal wrote: post #50

Earlier quoted context omitted.

the 'dotted quad' format was 'good enough' from a UI perspective (and... fitting in peoples' brains for short term). had we added one or two more spaces - and default all existing addresses to 0.0.x.x.x.x, we'd have had 65000 more blocks of 4 gig spaces. That should have been enough for most countries to have allocated enough space, while making the transition and UI upgrades pretty painless. If there's only a x.x.x.…

> As all the pieces fall in to place - hardware, ISP, OS, web/mail/services - it'll still be a gradual move, unless some major players announce IPv6 only service. If Office365 was "IPv6 only in 2020", that might motivate a lot of orgs to push their IT/ISP to upgrade and migrate. It doesn't even need to be that drastic. Apple, Google, and Microsoft could just check for IPv6 when connecting to a network. If it's missin…

> Constantly showing that nag will put a lot of pressure on major ISPs like Comcast

Comcast is making good progress: http://www.worldipv6launch.org/apps/ipv6week/measurement/ima...

For others, see: http://www.worldipv6launch.org/measurements/

Re: How bad is IPv4 address exhaustion?

#62

Post by jsjohnst »

AckermanMD wrote: post #60

Could IPv4 address exhaustion be staved by opening some of the currently unused /8 blocks? For instance, Apple has the entire 17.0.0.0/8 block. If IPv4 addresses are really becoming scarce and demand is going up, seems like Apple could dole out /24 or /16 bit blocks to RIRs and make some money - which they obviously like to do. So why aren't they doing it? Maybe someone more familiar with the economics of IP has an i…

There’s dozens of cases of this besides just Apple. Frustratingly, if you scan the legacy allocation /8 blocks (not done personally, but know someone who has), most of the ranges have no open ports on a majority of the range. So they literally are serving no justifiable (in my opinion) purpose.

Re: How bad is IPv4 address exhaustion?

#63

Post by jsjohnst »

cesarb wrote: post #49
chrisper wrote: post #37

Earlier quoted context omitted.

When I set up IPv6 I learned that you have to let some things through your firewall, like ICMP, because the IPv6 protocol relies on it. When I blocked everything like I did with ipv4, it eventually stopped working.

If you block everything with IPv4, things stop working too: you have to allow at least some ICMP (for "packet too big" path MTU discovery), otherwise you will have hard-to-diagnose issues.

Less an issue with IPv4 in a consumer sense because the device blocking the ICMP is also commonly doing NAT too.

Re: How bad is IPv4 address exhaustion?

#64

Post by geofft »

pas wrote: post #58
geofft wrote: post #20

Earlier quoted context omitted.

DHCPv4 and DHCPv6 are different (they even run on different ports) and probably they have more experience with monitoring and operating DHCPv4. Honestly I think the fundamental mistake of IPv6 was trying to fix everything else along the way. Certainly there are things that can be fixed in DHCPv4. But there isn't a way to put off that operational work until you're ready to get good at it; there is no way to just get m…

What was the problem with ARP anyway? Why Neighbor Discovery is better?

As I understand it, ARP is abstraction-breaking and hard-codes that IP is running on top of Ethernet or something Ethernet-compatible - you're sending Ethernet packets (with a non-IP EtherType) that reference IP and an IP address, initially over Ethernet broadcast. NDP runs over ICMPv6, which is an IP protocol, and the way it works is that it's sent to well-known IPv6 multicast addresses, ff02::1 for all nodes or ff02::2 for all routers. If you're a node and/or a router, you join those multicast groups. So there's no assumption of Ethernet; that just depends on some link layer with a working multicast. (And broadcast is a perfectly legal implementation of multicast, although if your layer 2 protocol makes it easy to do a better implementation, great.)

Also, there's some multicast fanciness so you join a multicast group based on some hash of your IP address so that NDP packets don't even go to all machines, but just some hash bucket that contains that IP address.

(I think these are good reasons to make a successor to ARP, but I don't think these are good reasons to require that you use the successor protocol if you don't want to NAT, especially given the extent to which deployed networking gear does ARP snooping and IGMP snooping - and does not expect a pile of multicast groups.)

Re: How bad is IPv4 address exhaustion?

#65

Post by spystath »

In the organisation I work for we had IPv4/IPv6 dual stack. Due to IPv4 exhaustion my whole department was shoved behind an NAT, which given the circumstances I find it normal as there is no need for 400+ workstations to have public IPs. The weird thing is that after the switch to NAT IPv6 connectivity was lost. When asking why IPv6 was lost I was told "what do you need it for?".

In the meantime I have residential IPv6 since 2011. I really believe corporate networks are one of the main causes of delay in massive IPv6 adoption. And given the inertia I'm not really expecting them to change soon.

Re: How bad is IPv4 address exhaustion?

#66

Post by Steltek »

AckermanMD wrote: post #60

Could IPv4 address exhaustion be staved by opening some of the currently unused /8 blocks? For instance, Apple has the entire 17.0.0.0/8 block. If IPv4 addresses are really becoming scarce and demand is going up, seems like Apple could dole out /24 or /16 bit blocks to RIRs and make some money - which they obviously like to do. So why aren't they doing it? Maybe someone more familiar with the economics of IP has an i…

I assume it's an asset that's only going increase in value because it's rare. Why offload it now when you'll earn more later?

Re: How bad is IPv4 address exhaustion?

#67

Post by AstralStorm »

tscs37 wrote: post #54
overcast wrote: post #33

Earlier quoted context omitted.

You go ahead, and try relaying an IPv6 address over the phone from one of your end users.

That's why you need a solid solution for DNS, though from my experience, mDNS does a decent enough job to solve it. Instead of the numbers you type in the hostname of a device. IPv6 encourages to improve on the current lackluster DNS solutions some routers have.

Here, the linux routers are way ahead of you. Odhcpd used to handle ipv6 delegations for normal users can coordinate with dnsmasq (often used for ipv4 assignments and dns proxying) or unbound - to assign nice local names.

Three trouble begins at internet scale where mDNS just does not work due to collisions. And ISPs do not want to give you free domain names and especially free dynamic subdomain delegation.

Re: How bad is IPv4 address exhaustion?

#68

Post by scruple »

yAnonymous wrote: post #44
overcast wrote: post #33

Earlier quoted context omitted.

You go ahead, and try relaying an IPv6 address over the phone from one of your end users.

"Sir, please type this into your browser to get to the router web interface: 2001:0db8:85a3:0000:0000:8a2e:0370:7334. I repeat 2001:0db8:85a3:0000:0000:8a2e:0370:7334." "Server IP address could not be found." 5 minutes later... "Now could you please tell me the IPs of all connected devices?" Customer hangs up and cancels his subscription.

Wasn't a similar problem solved by services like URL shorteners? I had to work occasional technical service for products where I was one of the embedded engineers and I leaned heavily on bit.ly at the time to get URLs back and forth from customers and it worked exceedingly well.

So, with that in mind, what would be the major drawbacks to IPv6 address shorteners? You'll always have a certain class of issues such as transcription errors, of course.

Re: How bad is IPv4 address exhaustion?

#69

Post by tscs37 »

AstralStorm wrote: post #67
tscs37 wrote: post #54

Earlier quoted context omitted.

That's why you need a solid solution for DNS, though from my experience, mDNS does a decent enough job to solve it. Instead of the numbers you type in the hostname of a device. IPv6 encourages to improve on the current lackluster DNS solutions some routers have.

Here, the linux routers are way ahead of you. Odhcpd used to handle ipv6 delegations for normal users can coordinate with dnsmasq (often used for ipv4 assignments and dns proxying) or unbound - to assign nice local names. Three trouble begins at internet scale where mDNS just does not work due to collisions. And ISPs do not want to give you free domain names and especially free dynamic subdomain delegation.

I use Pfsense which communicates DHCPv6 leases to Dnsmasq/Unbound fairly easily.

>And ISPs do not want to give you free domain names and especially free dynamic subdomain delegation.

Probably not but for internal resolution a .local or similar TLD is sufficient.

Re: How bad is IPv4 address exhaustion?

#70

Post by AstralStorm »

YouKnowBetter wrote: post #57

From a corporate perspective: we are just scared shitless to implement v6 internally. Keeping (private) v4 working is hard enough. Even drafting a project budget for v6 makes management go balistic. - firewall & IDS upgrades - firewalls rules - accountablity - dynamic DNS - employee education - toolchain updates - upgrades of software - functionality tests Not all companies employ NY or Google level engineers who "ju…

Come on. Firewall rules is one sed call. IDS are dinosaurs and junk that are generally worthless (feel free to show me otherwise).

Since all major OS support ipv6 there's nothing to educate about other than perhaps new IP address form.

Software upgrades? Like what software, OS to support NAT64? Which every major OS supports? (Including Windows 7. The holdouts are ancient telephones and tiny embedded trash.)

Toolchain updates are important... if you use IP addresses directly, bypass the OS network stack and so not support names. This likely means that software is junk that should've been replaced years ago and likely some internal cookery.

This leaves tests and dynamic DNS.

Post reply on HN