FTTH (Fiber to the home) ISPs and CGNAT

[MWareman]

Word of warning. Many FTTH providers are using CGNAT these days. This breaks direct connections to ISY (if you do not use either portal).

 

How to tell? Well, ISPs have a special IP range designated for CGNAT:

 

100.64.0.0/10 (or from 100.64.0.0 thru 100.127.255.255)

 

So, if the public IP address of your router is in that range, port forwards if your router will never work.

 

His is covered if RFC6598 if you want to read the story details.

 

I just switched, and had o pay an extra $10/month for a static IP (the only way they could give me a public IP apparently).

[KeviNH]

$10/month for a true static IP and a contract that doesn't forbid running servers is about par for the course.

 

Carrier Grade NAT (CGNAT) is great for ISPs, but does pose this problem for end-users who want to accept incoming connections from hosts outside their local ISP's network.   Nearly all IoT devices are designed to bring up outbound tunnels to the cloud instead of relying on uPNP or other port-forwarding mechanisms, so are unaffected by NAT.

 

If you are network savvy and don't have significant bandwidth/latency requirements, you can use Amazon EC2 or Google Compute Engine to allocate a public IP and tunnel incoming connections back to your home network.   Generally free for the first few gigabytes/month.

[MWareman]

$10/month for a true static IP and a contract that doesn't forbid running servers is about par for the course.

 

..

 

If you are network savvy and don't have significant bandwidth/latency requirements, you can use Amazon EC2 or Google Compute Engine to allocate a public IP and tunnel incoming connections back to your home network. Generally free for the first few gigabytes/month.

I fully agree that $10/month is par for the course. It's just frustrating... However, to get GB speeds and be rid of Comcast it's worth it...

 

I did try a reverse tunnel (to a vps in the same city with low latency) but for VoIP the additional jitter was a problem. I opted for the $10/month to not have to deal with it.

 

Mainly, I posted so others are aware (since we see a lot of 'how do I access my ISY remotely without portal' type posts). Fundamentally, if your 'public' IP is in the range above, publishing won't work no matter what you do to your router or ISY. Cheapest option would be to buy either the ISY Portal or Mobilinc Connect - both of which give remote access to your ISY without the need of port forwarding.

[KeviNH]

Mainly, I posted so others are aware (since we see a lot of 'how do I access my ISY remotely without portal' type posts). Fundamentally, if your 'public' IP is in the range above, publishing won't work no matter what you do to your router or ISY. Cheapest option would be to buy either the ISY Portal or Mobilinc Connect - both of which give remote access to your ISY without the need of port forwarding.

Good point -- People might think about the RFC1918 addresses as being non-routable, but not recognize a 100.64, 100.65, etc address as being just as big a show-stopper as 172.17

[giesen]

Carrier Grade NAT (CGNAT) is great for ISPs, but does pose this problem for end-users who want to accept incoming connections from hosts outside their local ISP's network.

As someone who is involved in running the network of an ISP, I can tell you CGNAT is great for exactly no one. For end users the downsides are obvious. For ISPs, it adds additional complexity, additional cost (both capital and operational), makes it difficult to deal with compliance/abuse, and is just generally painful.

 

The only reason it exists is it allows you to have more subscribers with fewer IP addresses. IPv6 adoption can't come fast enough!

 

So UDI, any word on IPv6 support?

 

Sent from my SM-N910W8 using Tapatalk

[paulbates]

The problem with IPV6 adoption is the complexity. Really what was needed was more address bits to line up with MAC addresses and cover trillions of devices... I'll compare that to asking for fireworks. What was delivered was a complex nuclear explosion. As a result, its not really been made a priority, primarily because complexity and cost that can't be explained to businesses / customers. IT departments are in the same boat, everyone needs to be trained to understand it, implement and support it, and there are too many other priorities in the way.

 

One major problem is millions of web hosting servers that people want to visit that are all on IPV4 only. The admins don't know IPV6, why change?... nobody is threatening to take away IPV4 from them. Or there are vertical software package issues: as an example, I believe IPBoard, this forum's software, doesn't support IPV6..and it probably not high on their feature request list. So the roots grow back pretty far.

 

The 'flip side', ISP: If comcast wanted to force all of its members to IPV6 only, it wouldn't happen because of the above, the bulk of web hosting sites are still IPV4 only...  if you thought people hated them now....

 

This is like a dog chasing its tail. It will only work like the HDTV conversion many years ago; A problem that is big and dangerous enough to mandate/regulate a solution in the middle to make it all parties' priority in a specified time window. No one group (ISPs, Web hosters, iot mfgs) is going to solve it in a meaningful way on their own.  My 6 years using comcast IPV6 has not been really worth it. My router continues to see a few more IPv6 connections every year, but nothing tells me I'll be fully cut over anytime soon.

 

Personally I'd prefer UDI keep its effort on the general release V5 and this be considered later.

[giesen]

The problem with IPV6 adoption is the complexity. Really what was needed was more address bits to line up with MAC addresses and cover trillions of devices... I'll compare that to asking for fireworks. What was delivered was a complex nuclear explosion. As a result, its not really been made a priority, primarily because complexity and cost that can't be explained to businesses / customers. IT departments are in the same boat, everyone needs to be trained to understand it, implement and support it, and there are too many other priorities in the way.

 

One major problem is millions of web hosting servers that people want to visit that are all on IPV4 only. The admins don't know IPV6, why change?... nobody is threatening to take away IPV4 from them. Or there are vertical software package issues: as an example, I believe IPBoard, this forum's software, doesn't support IPV6..and it probably not high on their feature request list. So the roots grow back pretty far.

 

The 'flip side', ISP: If comcast wanted to force all of its members to IPV6 only, it wouldn't happen because of the above, the bulk of web hosting sites are still IPV4 only...  if you thought people hated them now....

 

This is like a dog chasing its tail. It will only work like the HDTV conversion many years ago; A problem that is big and dangerous enough to mandate/regulate a solution in the middle to make it all parties' priority in a specified time window. No one group (ISPs, Web hosters, iot mfgs) is going to solve it in a meaningful way on their own.  My 6 years using comcast IPV6 has not been really worth it. My router continues to see a few more IPv6 connections every year, but nothing tells me I'll be fully cut over anytime soon.

 

Personally I'd prefer UDI keep its effort on the general release V5 and this be considered later.

 

 

I'm not saying IPv6 doesn't have its own challenges, but it's not as complex as most people think. In many ways, it's much simpler than IPv4. And the scales are slowly tipping in IPv6's favour. IPv4 is becoming increasingly more scarce, so while no one is taking away an IPv4 host's addresses (yet), as IPv4 address space becomes more and more valuable, costs will rise for those addresses (as MWareman already found out). Also, the overall market is growing, so new entrants (or existing companies that want to expand) will find it increasingly more and more difficult to get the IPv4 address space they need. This will lead to to technical hacks (like CGNAT), making services more difficult to implement and support. If you think dealing with NAT'd customers is fun for services like VOIP, wait until they're double-NATed with no ability to do port forwarding, etc.

 

Eventually IPv4 will become so expensive to implement and support that IPv6 will become a no-brainer, and those who moved early to support it will have a huge advantage. They'll have the infrastructure already rolled out, and have the organizational knowledge to support it. IPv6 has already reached mainstream support, with the largest destinations on the Internet (Google, Youtube, Facebook, Netflix, AWS etc) fully supporting it, and larger providers like Comcast offering it to their customers. Sure, smaller hosters are definitely lagging behind; but most of the major hosting software (cPanel, Plesk, DirectAdmin) all support it; so even if it's not enabled yet it's pretty straightforward to get it going. All of the major VPS providers support IPv6. At this point if you haven't at least been planning a roll-out, you're already behind.

 

I agree UDI has some very important priorities that should take precedence over IPv6 support (namely getting 5.0 out the door), but they should at least have plans in the works to get it supported.

[Michel Kohanim]

Hi giesen,

 

Already planned!

 

With kind regards,

Michel