IPv6 statics for Comcast Business Class still a non-starter?

Nope, not yet.

Last I heard, an official rep told me it would be "Q3-Q4 of 2015", though that has already come and gone......

I have hit a wall this is absolutely rediculous... I either want out of my contract or some sebelence of a working IPv6 connection... ATT here has it.. WOW here has it... I am sure I can find a WISP here with it... But the ten ton gorilla here cant get their crap togerther or the router 2 hops from me fixed..... This is unaccptable. I WANT SOLID INFORMATION NOW or OUT OF MY CONTRACT. 

The problem with Comcast is that in many areas (like mine) they are the only provider that has decent UPSTREAM high speed available.  CenturyLink also sells "a gig" here but it's downstream only - because, it's all delivered over HDSL using their existing copper infrastructure.

Google Fiber has been making noise about coming into this area but so far GF does not offer static IP address on any accounts at all - it's strictly a residential service.

I'm quite sure Comcast has all of this documented on a map of it's service area - when a large enough percentage of overlapping providers offers similar bandwidth and service pricing - they will suddenly start offering static IPv6.

In several years of complaints about Comcast non-delivery of static IPv6 addressing, I have learned that Comcast is apparently ignorant, incompetent, uncaring, or, some combination of all three. I am not certain that I agree.

I struggle to understand the ongoing business need for static addressing.

Most connections are established by the Fully Qualified Domain Name (FQDN) of the target system being supplied to a name to address service which obtains the required IPv4 or IPv6 address(es) for connection establishment.  If the target is IPv4, chances are good that the NATted host addresses are configured with DHCP reservations and Port Mapping in the local router using the WAN address of the local router.  If the target is IPv6, current usage is the /64 LAN prefix from /56 DHCP-PD followed by the EUI-64 address. In either case, DNS entries can be dynamically updated when the IPv4 WAN address or the /56 Prefix changes - a relatively rare occurence on CBI.  All this seems to work well, so the static IP need must be elsewhere.

Depending on truly static rather than quasi-static IP addressing means is that somewhere IP addresses are being hard-coded into applications or application data. Is this personal preference? Is it because use of Certificates seems to require it? Is there some vendor still writing code that requires static addressing instead of static naming? Or what?  I want to learn.

I would be absolutely delighted if some kind person would expound on the real business requirement for static IP addressing. 

Additional food for thought is that one should really ask for a static IPv6 Prefix Delegation. This is much more specific than generic static IPv6 and probably has a higher probability of implementation by Comcast. 

xz4gb8,

I'll give you 2 examples where static addresses are useful.

-Running a mail server

Many SMTP servers will refuse to send mail to other servers if the receiving server does not have a proper DNS PTR entered by the owner of the IP (in this case Comcast). For example, the mail server for mydomain.com would have an A record of "mail.mydomain.com" and an address of 1.2.3.4. There would also need to be an accompanying PTR for 1.2.3.4, with a hostname of "mail.mydomain.com". Comcast will not enter PTRs for dynamic IPs, so a mail server on Comcast business should currently have a static IP with a corresponding PTR.

-IPsec VPNs

I have come across numerous "VPN routers", primarily marketed towards SOHO/small business users (who I would also imagine are the target audience for using Comcast Business as their ISP). Many of these routers do not have the capabilitiy to connect to other IPsec endpoints via DNS name; they must have IP addresses hard coded into them. Yes, higher quality VPN routers/endpoints can connect via DNS name, but some cannot.

That said, I would call both of these situations "edge cases". For most businesses, dynamic IPs are perfectly fine. I think admins request static IPs primarily because it makes managing things a bit easier, but they're certainly not necessary for most cases.

(btw, on your point abount IP/prefix changes being rare.... I have gone through about 5 or 6 different IPv6 prefixes from Comcast this year, and 2 different dynamic public IPv4 addresses....)

just got a new IPv6 prefix again this morning out of the blue. Looks like the modem was rebooted some time after midnight, maybe the firmware upgraded. So now I am reconfiguring firewall rules and all the good stuff to accommodate the new prefix. No warning. Oddly enough, I often do get automated phone calls about upcoming network maintenance (usually without anything notable happening) but never in cases like this when actual maintenance happens. 

(I do have 5 static IPv4 addresses. )

"...Depending on truly static rather than quasi-static IP addressing means is that somewhere IP addresses are being hard-coded into applications or application data. Is this personal preference? Is it because use of Certificates seems to require it? Is there some vendor still writing code that requires static addressing instead of static naming? Or what?  I want to learn..."

There is a very good reason for static IP assignments that has to do with DNS names.

Anything offering services on the Internet (any server, etc.) needs to be named in the DNS.  Oh sure, you can access www.microsoft.com by putting 2600:1409:a:194::2768 into your web browser, but for many clearly obvious reasons this is unworkable on the Internet.

This means that we have millions of servers out there on the Internet that have DNS names associated with IP addresses.

When a DNS server on the Internet queries for www.microsoft.com it puts that IP address in it's DNS cache.  It uses that cached address until the expiration date.  It gets that expiration date from the DNS server that handed out the response to the query.  If it does not have that name in it's cache it has to do a root query.  Otherwise it serves the name out of it's cache.

With NORMAL servers on the Internet that have static IPs, that IP address seldom changes and when it does change the admin has advance notice.  So, the admin will go into the DNS cache and artifically reduce the expiration date to maybe a few minutes, a couple days before renumbering.

What this means is that in an Internet with static IPs, most DNS queries are served from DNS server caches.  They are not queries that trigger a root server query.

Now look at an Internet with DYNAMIC ips.  Because the IP may change without warning, the admins knock the TTL down in their DNS servers.  Otherwise, their IP may change and it could be a few days before all the DNS servers out on the Internet that have records to their server have those records expire, and pull a fresh copy.

We may have millons of servers.  But, we only have about 14 root servers.  If everyone had no static Ips on their servers then none of the DNS servers on the Internet would be able to cache records, and so EVERY QUERY FROM EVERY HOST ON THE INTERNET even the lowliest end user out there - would trigger a root server query.

The roots could not take this, they would fail.  And all name resolution on the Internet would disappear.

This is not a edge case as train_wreck said.  This is a serious issue and it is why use of dynamic IP addresses for servers is discouraged.  When you do it, you are unfairly taking more of your share of root server resources, which is exactly what a spammer does.

And one more thing.  We cannot reduce the Internet to a handful of servers out there.  The infrastructure simply would not support it.  If everyone on the Internet used Gmail, gmail would melt down.

Acording to http://www.root-servers.org today at 4:30 EST, there were 561 DNS root server instances. One can only guess at the thousands of recursive DNS servers queried directly by end systems.

Since most end systems query using whatever DNS server address(es) are provided by the ISP, It is the ISP resolver that queries (and caches) any requisite root queries. The ISP resolver may also cache replies for lower level or even fully qualified domain names, not just TLDs. Repeated queries are then be served data previously cached until TTL expiration. This caching is completely independent of how a particular DNS record is created, either by static entry or by dynamic DNS update.

So, potential root server queries to any given DNS root server instance are orders of magnitude less than suggested above.

---

@flybynight wrote:

just got a new IPv6 prefix again this morning out of the blue. Looks like the modem was rebooted some time after midnight, maybe the firmware upgraded. So now I am reconfiguring firewall rules and all the good stuff to accommodate the new prefix. No warning.

 

---

That is odd..  What modem is it?

I would be happy with DHCP supplied IPv6, but comcast business support can't even provide a solution for that.

Hello Everyone,

I apologize but at this time we do not have an offical release date for static IPv6 address. Please check back here for future updates.

No, xz4gb8 you are completely incorrect in your assumption of how DNS servers work.   You said:

"Since most end systems query using whatever DNS server address(es) are provided by the ISP, It is the ISP resolver that queries (and caches) any requisite root queries..."

that so far is correct

"..The ISP resolver may also cache replies for lower level or even fully qualified domain names, not just TLDs. Repeated queries are then be served data previously cached until TTL expiration...."

That is also correct.

"...This caching is completely independent of how a particular DNS record is created, either by static entry or by dynamic DNS update..."

This is flat out wrong.  The ISP DNS server uses the TTL that comes from the address record SOA for the domain that was queried.  If it did not and used it's own TTL  (ie: overrode the  TTL supplied by the root servers for a particular domain) then there would be no way for the administrator of a particular domain to use dynamic DNS.    Their IP would change and they would update the authoratative DNS server for their domain - but all these ISP DNS servers out on the Internet would only pull an updated record when they felt like it - which could be weeks later.

There's an excellent Nutshell book called DNS & Bind which you ought to read.  Sorry to have to lay a guilt trip back on you for your use of dynamic DNS on your server!

tmittelstedt,

Just to set the record straight since you are making personal statements regarding my knowledge of DNS:

You wrote that I am "completely incorrect" and then point out parts of what I wrote as correct.  This is not logically consistent.

One can create a DNS resource record by manually typing a zone file or by any automatic method. A TTL value provides information for a caching resolver in a consistent manner regardless of how the resource record is created. A querying resolver, whether part of an end system or part of a recursive DNS server, does not learn anything about the resource record creation method from a TTL value.

Among other reference books I first used last century was Cricket & Liu's excellent book. I would have to dig out archived records to tell you exactly when I put my first enterprise DNS servers on the Internet. It was in the mid 1990s.

I'm not feeling guilty and do not use dynamic DNS on my server. I now let others provide DNS services for me.

Please confine your statements to facts and do not attack me personally again.

OK xz4gb8, I will say this, then.  There is absolutely no problem if a dynamic DNS server sets a TTL for an automatically created address record to the same long value that normal DNS server operators use.

This will prevent a querying resolver in a DNS server that fetches a record from deleting it from it's cache within a few seconds and allow the DNS server caching mechanism to work properly in DNS servers across the Internet.

However that also means that if a host reboots and gets assigned a different IP address that it will be quite a while before other hosts on the Internet realize it has a different IP address.  Which essentially removes the entire point of dynamic DNS in the first place.

I don't see a problem with that.