ARIN Activates IPv4 Unmet Requests Policy(arin.net)
arin.net
ARIN Activates IPv4 Unmet Requests Policy
https://www.arin.net/announcements/2015/20150701.html
45 comments
ha and AWS still can't throw IPv6 on
Neither DNSSEC on Route53. Plenty of technologies are just not available on 'insert popular cloud provider of today'. That's why not everyone there where everyone-else.
DNSSEC is a bad solution. That's why most have not deployed it yet. IPv6 is good. It works and works well.
Why the downvotes? Just because I said something negative about DNSSEC? DNSSEC is a bad solution. More well informed minds than HackerNews have come out as to why DNSSEC is a bad idea. I'm not being mean or spiteful. It really isn't going to work.
http://www.theregister.co.uk/2015/03/18/is_the_dns_security_...
In light of the "Let's Encrypt All the Things" movement, I'm surprised that anyone could ever support DNSSEC.
http://www.theregister.co.uk/2015/03/18/is_the_dns_security_...
In light of the "Let's Encrypt All the Things" movement, I'm surprised that anyone could ever support DNSSEC.
[deleted]
AWS is "working on it." It's not like they're burying their head in the sand and hoping it goes away. These things just take time.
They've been working on it for at least three years. We were really interested in deploying our application on the AWS infrastructure, until they made it clear that IPv6 wasn't going to happen for the foreseeable future. I guess they do get good marks for being transparent on their roadmap and not getting our hopes up.
They might have had issues with various gear, tooling, etc. You'd be surprised how many routing vendors screwed up IPv6 subnetting. Hence, why you need to assign a /126 on PtP links for some gear, instead of a /127. Some vendors still thought IPv6 had a broadcast address (it doesn't). Sure that's just an example and doesn't preclude them from offering it, but maybe they're conservative and wanted to get everything working right before releasing it?
Also, some older gear routed/forwarded IPv6 in software; making it much slower.
Our biggest problem had nothing to do with network hardware. It all came down to developers still writing IP regex's wrong for our app. Maybe I should write an e-book "IPv6 for the node/jquery developer?"
tl;dr it's not in Amazon's market interests to delay IPv6 adoption
Also, some older gear routed/forwarded IPv6 in software; making it much slower.
Our biggest problem had nothing to do with network hardware. It all came down to developers still writing IP regex's wrong for our app. Maybe I should write an e-book "IPv6 for the node/jquery developer?"
tl;dr it's not in Amazon's market interests to delay IPv6 adoption
"Some vendors still thought IPv6 had a broadcast address"
I have never known anyone working with IPv6 for more than a day who doesn't understand that IPv6 does not have a broadcast address. I do not believe any vendor writing a routing stack would fail to understand that. Though, I do agree in early days, they screwed things up. For example, Dell would not route RFC 4193 (FC/7) addresses around 2005. I had to rip out and ship back a dozen of their routers when I realized they weren't going to fix that.
I think you might be onto something about gear though - I've read that Amazon builds their own routers, and routing stack - which means they can't simply deploy a well tested/regressed IPv6 stack, they have to write and test it from scratch. The dark side of doing everything yourself.
I have never known anyone working with IPv6 for more than a day who doesn't understand that IPv6 does not have a broadcast address. I do not believe any vendor writing a routing stack would fail to understand that. Though, I do agree in early days, they screwed things up. For example, Dell would not route RFC 4193 (FC/7) addresses around 2005. I had to rip out and ship back a dozen of their routers when I realized they weren't going to fix that.
I think you might be onto something about gear though - I've read that Amazon builds their own routers, and routing stack - which means they can't simply deploy a well tested/regressed IPv6 stack, they have to write and test it from scratch. The dark side of doing everything yourself.
So what are server hosts going to do now? If I need to scale up and order some more servers when are we going to get to the point where they say no?
I assume that server hosts are going to start charging larger and larger sums of money per month for more than a single IP on a server in order to claw back some of their allocation from their customers in cases where people didn't really need so many. But how long can this go on?
I assume that server hosts are going to start charging larger and larger sums of money per month for more than a single IP on a server in order to claw back some of their allocation from their customers in cases where people didn't really need so many. But how long can this go on?
Up until now, the rational choice was to dole out as many IPv4 addresses as possible, in order to justify a larger allocation from ARIN. Now that the party's over, we should expect ISPs and hosting providers to become more stingy with their addresses: more NATs, more proxies, higher prices.
Any new providers that pop up between now and the date IPv4 becomes irrelevant will be at a competitive disadvantage.
Any new providers that pop up between now and the date IPv4 becomes irrelevant will be at a competitive disadvantage.
> more NATs
Thus finishing the imprimatur[1]. It is an utter travesty that we haven't junked IPv4 yet. NAT removes the most powerful feature of the internet - that anybody can publish without the permission of a central authority - and I fear too many people in the software industry profit from the resulting centralization to resist things like carrier grade NAT.
> the date IPv4 becomes irrelevant
That date was 03-Feb-2011 at the latest[2].
> competitive disadvantage.
The problem is the people with larger IPv4 address blocks who se this competitive disadvantage as a good thing.
[1] https://www.fourmilab.ch/documents/digital-imprimatur/
[2] http://www.potaroo.net/tools/ipv4/index.html
Thus finishing the imprimatur[1]. It is an utter travesty that we haven't junked IPv4 yet. NAT removes the most powerful feature of the internet - that anybody can publish without the permission of a central authority - and I fear too many people in the software industry profit from the resulting centralization to resist things like carrier grade NAT.
> the date IPv4 becomes irrelevant
That date was 03-Feb-2011 at the latest[2].
> competitive disadvantage.
The problem is the people with larger IPv4 address blocks who se this competitive disadvantage as a good thing.
[1] https://www.fourmilab.ch/documents/digital-imprimatur/
[2] http://www.potaroo.net/tools/ipv4/index.html
From the perspective of the ISP many customers are totally incapable of implementing NAT and waste IP addresses like they are dollar bills at the strip club.
This news means they got the first request that was too big to be accepted.
There are still about 300 /24 networks.
[1] https://www.arin.net/resources/request/ipv4_countdown.html
There are still about 300 /24 networks.
[1] https://www.arin.net/resources/request/ipv4_countdown.html
Given the current rate of allocations, those will be gone within a month.
https://www.arin.net/knowledge/statistics/index.html
https://www.arin.net/knowledge/statistics/index.html
Your load balancer has a public IP address. You route requests to the internal LAN on one of the "private" IP blocks (10.0.0.0/8, 192.168.0.0/8)
I suppose that it would be that easy if we were hosting a website. We make an online game though so the general solution isn't going to work for us.
Sure, in principal it's the same but it's going to require a fair bit more manual implementation in our case, not to mention added latency in a very latency sensitive application.
Sure, in principal it's the same but it's going to require a fair bit more manual implementation in our case, not to mention added latency in a very latency sensitive application.
I think your exaggerating the latency effects but anyway you can still buy IPv4 addresses for ~$12/ip. This is really just going to initially hurt service providers which is good because those are the ones who can make large inroads with IPv6
NATs do induce a fair amount of latency. It's not exaggerated. Watch Paul Saab from Facebook talk about how much better IPv6 performs at NANOG 64: https://www.youtube.com/watch?v=EfjdOc41g0s
"... you can still buy IPv4 addresses for ~$12/ip."
About the price of a domainname? (Note I did not use the word "cost". I create dommainnames all the time at the price of $0.)
Given the choice between a domainname and an IPv4 adddress, I would take the IPv4 address.
Also, given the choice between a single, routable IPv4 addresses and a block of IPv6 addresses, I would still choose the IPv4 address.
IPv4 is "simplicity" in comparison to the complexity of IPv6. IPv6 has features I do not need.
Whenever I am granted the choice, I always choose simplicity over complexity.
Most of the time the additonal complexity is not needed and can only cause problems in the long run.
This is only the opinion of one "consumer". Certainly the "market" may have another opinion.
About the price of a domainname? (Note I did not use the word "cost". I create dommainnames all the time at the price of $0.)
Given the choice between a domainname and an IPv4 adddress, I would take the IPv4 address.
Also, given the choice between a single, routable IPv4 addresses and a block of IPv6 addresses, I would still choose the IPv4 address.
IPv4 is "simplicity" in comparison to the complexity of IPv6. IPv6 has features I do not need.
Whenever I am granted the choice, I always choose simplicity over complexity.
Most of the time the additonal complexity is not needed and can only cause problems in the long run.
This is only the opinion of one "consumer". Certainly the "market" may have another opinion.
> "Also, given the choice between a single, routable IPv4 addresses and a block of IPv6 addresses, I would still choose the IPv4 address."
Ah yes, which would likely entail the 'simplicity' of NAT...
Ah yes, which would likely entail the 'simplicity' of NAT...
> IPv6 has features I do not need.
Are you forced to use them? If not, where's the problem?
I for one love ipv6, it restores the end-to-end principle.
Are you forced to use them? If not, where's the problem?
I for one love ipv6, it restores the end-to-end principle.
They're likely referring to scenarios like this:
https://news.ycombinator.com/item?id=8278864 - "IPv6 privacy addresses crashed the MIT CSAIL network"
& the much more complicated host discovery / address assignment process on IPv6 segments.
Still, I think I'd rather deal with some implementation kinks than intentional packet mangling like NAT.
> I create dommainnames all the time at the price of $0
Care to explain how?
Care to explain how?
I'm interested too. My guesses:
- http://www.freenom.com/
- work-for/own a domain registrar
- own a pseudo-TLD like .com.me and are really just creating subdomains
- have a large account / custom pricing deals with a domain registrar such that despite a high total cost, the marginal per-domain cost is approximately $0
- only internally-routable domains e.g. /etc/hosts or company-internal DNS server
- only alternative DNS roots like Namecoin or tor's .onion domains
- http://www.freenom.com/
- work-for/own a domain registrar
- own a pseudo-TLD like .com.me and are really just creating subdomains
- have a large account / custom pricing deals with a domain registrar such that despite a high total cost, the marginal per-domain cost is approximately $0
- only internally-routable domains e.g. /etc/hosts or company-internal DNS server
- only alternative DNS roots like Namecoin or tor's .onion domains
How is v6 more complex than v4? It's simpler. Much simpler.
Instead of a layer 7 proxy couldn't you just use static port forwarding and multiplex servers based on ports?
TCP load balancing would also be an option in your case.
Off topic, but considering HN uses Cloudflare, why isn't it IPv6 enabled?
They have to enable it in their CF account. No idea why they have not. HN hasn't updated their log parsing toolset for IPv6?
And yet almost no server supports ipv6 and almost no consumer isp supports it either.
Comcast, the largest consumer ISP in the US, supports IPv6 on its entire network, and all current modems they supply have it enabled. There are still customers on older modems, and customers who have brought their own modems that do not support it, so only about 50% of Comcast users are actually running IPv6.
Consumer wireless ISPs in the US are also doing pretty good. Verizon has 70% deployment, and AT&T and T-mobile are around 50%.
Consumer wireless ISPs in the US are also doing pretty good. Verizon has 70% deployment, and AT&T and T-mobile are around 50%.
That's simply not true. Over 22% of US Internet consumers have IPv6 addresses. Your mobile phone probably has a (few) IPv6 addresses.
From NANOG 64: https://www.youtube.com/watch?v=EfjdOc41g0s
From NANOG 64: https://www.youtube.com/watch?v=EfjdOc41g0s
You can go to http://testipv6.com/ and check for yourself.
Indeed, 1 out of 5 users in USA today has IPv6.
Indeed, 1 out of 5 users in USA today has IPv6.
Most servers do support IPv6 these days. It's all the networking infrastructure in the middle that's the problem.
That's mostly not accurate. Every transit provider offers IPv6 transit. It's not any different or more expensive for them. Routes are routes and datagrams are datagrams to them.
The stuff that doesn't support IPv6 is mostly older CPE gear (your old firewall, a bunk load balancer, an oddball console server, etc). You really just need a router that supports IPv6 to offer an IPv6 capable server. Maybe a firewall and loadbalancer if that's in your setup, but those should all support IPv6 already.
Things like your access switches and console servers don't require IPv6 addresses yet. You can leave them on IPv4 for now. Your customers aren't going to be accessing them, only you.
The stuff that doesn't support IPv6 is mostly older CPE gear (your old firewall, a bunk load balancer, an oddball console server, etc). You really just need a router that supports IPv6 to offer an IPv6 capable server. Maybe a firewall and loadbalancer if that's in your setup, but those should all support IPv6 already.
Things like your access switches and console servers don't require IPv6 addresses yet. You can leave them on IPv4 for now. Your customers aren't going to be accessing them, only you.
And yet for some reason most co-lo and VM providers I've seen are still incapable of giving their paying customers routable IPv6 addresses.
If, like most people, your servers are sitting in a datacenter, there's going to be a lot of layer-3-aware stuff sitting between you and your users, and empirically it does not support IPv6 end to end.
If, like most people, your servers are sitting in a datacenter, there's going to be a lot of layer-3-aware stuff sitting between you and your users, and empirically it does not support IPv6 end to end.
That's just FUD. Pure and simple. There isn't that much that matters. It's jut routers from edge to core to leaf. Your L2 switches don't care about L3 protocols.
Some of the worse colo vendors aren't offering it because they're lazy or see increased income from higher v4 rental prices.
Some of the worse colo vendors aren't offering it because they're lazy or see increased income from higher v4 rental prices.
> That's just FUD. Pure and simple.
... are you claiming that most co-los, and major VPS providers like AWS, actually do let you use IPv6? Because that's an easily falsifiable claim. Or are you claiming that this is irrelevant and only motivated by a desire to slow IPv6 adoption? Trust me. I've worked on IPv6, I love IPv6, I want it to get out there in the world.
> There isn't that much that matters. It's jut routers from edge to core to leaf.
Oh, you sweet summer child.
The typical hosting setup involves a server behind a NAT on a network that internally looks nice and layered and normal, but that no outsider can get to. When you ask for a public IP address to be assigned to your box, a 1:1 mapping on the NAT box is installed, so that anything directed to "your" public address is mapped to your internal (private) IP. In the middle is a whole host of firewalls (typically IPv4-aware and either not IPv6-capable or not IPv6-configured, since the configuration is a substantial piece of code), VPNs to layer a more customer-friendly network topology on top of the physical one, and on VPS providers a network virtualization layer that is usually not IPv6-ready.
> Some of the worse colo vendors aren't offering it because they're lazy or see increased income from higher v4 rental prices.
I'm sure they would love to see such increased income. And yet, I've never yet seen a co-lo or VPS provider actually charge anything for IPv4 addresses. If you're going to impute malicious intent to these faceless corporations, you need to at least come up with a realistic motive. Otherwise, the "it's hard and they haven't spent the engineer-days" is a lot more convincing of an argument.
Here's a good example that I think shows that this has to do with the inherent difficulty in maintaining two separate layer-3 infrastructures on the same layer-2: Amazon EC2 does not support IPv6. It is impossible to get a public IPv6 address assigned to one, or even to route IPv6 traffic internally between different EC2-internal subnets. However, they've gone to the trouble of making their load-balancer service (ELB) support IPv6 and IPv4, translating TCP, SSL, HTTP, or HTTPS to IPv4 internally. Why would they do such a thing? The rates they charge for an ELB are peanuts; this is not a profit center. This does have the benefit of keeping IPv6 packets out of the internal network, though; that they went through that effort seems to indicate that they consider that problematic.
... are you claiming that most co-los, and major VPS providers like AWS, actually do let you use IPv6? Because that's an easily falsifiable claim. Or are you claiming that this is irrelevant and only motivated by a desire to slow IPv6 adoption? Trust me. I've worked on IPv6, I love IPv6, I want it to get out there in the world.
> There isn't that much that matters. It's jut routers from edge to core to leaf.
Oh, you sweet summer child.
The typical hosting setup involves a server behind a NAT on a network that internally looks nice and layered and normal, but that no outsider can get to. When you ask for a public IP address to be assigned to your box, a 1:1 mapping on the NAT box is installed, so that anything directed to "your" public address is mapped to your internal (private) IP. In the middle is a whole host of firewalls (typically IPv4-aware and either not IPv6-capable or not IPv6-configured, since the configuration is a substantial piece of code), VPNs to layer a more customer-friendly network topology on top of the physical one, and on VPS providers a network virtualization layer that is usually not IPv6-ready.
> Some of the worse colo vendors aren't offering it because they're lazy or see increased income from higher v4 rental prices.
I'm sure they would love to see such increased income. And yet, I've never yet seen a co-lo or VPS provider actually charge anything for IPv4 addresses. If you're going to impute malicious intent to these faceless corporations, you need to at least come up with a realistic motive. Otherwise, the "it's hard and they haven't spent the engineer-days" is a lot more convincing of an argument.
Here's a good example that I think shows that this has to do with the inherent difficulty in maintaining two separate layer-3 infrastructures on the same layer-2: Amazon EC2 does not support IPv6. It is impossible to get a public IPv6 address assigned to one, or even to route IPv6 traffic internally between different EC2-internal subnets. However, they've gone to the trouble of making their load-balancer service (ELB) support IPv6 and IPv4, translating TCP, SSL, HTTP, or HTTPS to IPv4 internally. Why would they do such a thing? The rates they charge for an ELB are peanuts; this is not a profit center. This does have the benefit of keeping IPv6 packets out of the internal network, though; that they went through that effort seems to indicate that they consider that problematic.
If you have a publicly addressable IPv4 address, why would NAT be involved? Every VPS provider I've used assigns your instance a non-RFC1918 address. That's on the host, not on a NAT device. With v6, there's no NAT.
I don't run a VPS/hosting company, so I can't say how many firewalls exist between the edge and customer equipment. I can't imagine that many even offer the service. Today's thought seems to be that's up to the server to filter traffic.
Linode offers IPv6 addresses to each instance. I'm sure there are lots of others that do, too. I can't speak for AWS; I don't work for Amazon.
I don't run a VPS/hosting company, so I can't say how many firewalls exist between the edge and customer equipment. I can't imagine that many even offer the service. Today's thought seems to be that's up to the server to filter traffic.
Linode offers IPv6 addresses to each instance. I'm sure there are lots of others that do, too. I can't speak for AWS; I don't work for Amazon.
> If you have a publicly addressable IPv4 address, why would NAT be involved? Every VPS provider I've used assigns your instance a non-RFC1918 address. That's on the host, not on a NAT device.
On my publicly-addressable EC2 box:
The reason for NAT in this case is that the box has one network interface, and needs to have two IP addresses - one with which it accesses the local network, and one over which public client connections come in. Unfortunately, IPv4 doesn't allow this - yet another problem solved by IPv6, which in the meanwhile is hacked around by means of NAT.
> With v6, there's no NAT.
Yes. I know. Seriously, you're preaching to the choir when it comes to how many problems IPv6 solves, and how much NAT has broken the internet. I just think you have a very rosy view of how far along IPv6 deployment is.
> Linode offers IPv6 addresses to each instance. I'm sure there are lots of others that do, too.
And that is AWESOME. Actually, in my 10 minutes of research, it seems like most of the smaller providers do (a big wave of them, including Linode, added support around 2011). My experience is with AWS and co-los, where the situation is much, much worse. Absolutely, if your provider gives you IPv6, use it. Please.
On my publicly-addressable EC2 box:
ubuntu@ip-10-1-0-213:~$ ifconfig eth0The reason for NAT in this case is that the box has one network interface, and needs to have two IP addresses - one with which it accesses the local network, and one over which public client connections come in. Unfortunately, IPv4 doesn't allow this - yet another problem solved by IPv6, which in the meanwhile is hacked around by means of NAT.
> With v6, there's no NAT.
Yes. I know. Seriously, you're preaching to the choir when it comes to how many problems IPv6 solves, and how much NAT has broken the internet. I just think you have a very rosy view of how far along IPv6 deployment is.
> Linode offers IPv6 addresses to each instance. I'm sure there are lots of others that do, too.
And that is AWESOME. Actually, in my 10 minutes of research, it seems like most of the smaller providers do (a big wave of them, including Linode, added support around 2011). My experience is with AWS and co-los, where the situation is much, much worse. Absolutely, if your provider gives you IPv6, use it. Please.
> Unfortunately, IPv4 doesn't allow [two IP addresses on one network interface]
That has nothing to do with IPv4, and has everything to do with you using obsolete tools (ifconfig). Use “/bin/ip address add $ADDRESS/$NETMASK dev $INTERFACE” and assign as many addresses as you like – the OS and drivers supports it just fine.
(Not that this should convince anyone to stay in the sinking country that is IPv4.)
That has nothing to do with IPv4, and has everything to do with you using obsolete tools (ifconfig). Use “/bin/ip address add $ADDRESS/$NETMASK dev $INTERFACE” and assign as many addresses as you like – the OS and drivers supports it just fine.
(Not that this should convince anyone to stay in the sinking country that is IPv4.)
Time Warner Cable has implemented IPv6 fully for all residential customers (excluding customer owned modems that do not support IPv6). All new internet circuits for commercial DOCSIS and fiber are built with IPv6 also.
I got IPv6 connectivity on my LTE-services. (Sweden)
In addition to other answers, here is some food for thought:
Some operators are already working on turning IPv4 off in their networks:
https://www.youtube.com/watch?v=EfjdOc41g0s
Some operators are already working on turning IPv4 off in their networks:
https://www.youtube.com/watch?v=EfjdOc41g0s