Comcast Support doesen't undrstand IPv6

I am rather irked.

I called into Comcast technical support with an extremely "Network Troubleshooting 101" problem.

We run a mailserver. It is on a Comcast Business account and it has a static IPv4 address on it. Because we live in a city that does not yet have IPv6 (Portland OR, and yes I just signed up for the Comcast beta IPv6 test) we have a tunnel to Hurricaine Electric

Our mailserver thus has an IPv6 address on it as well as IPv4 (it is dual-numbered)

We have users who are attempting to send e-mails to customers on Comcast. I can see in or mailserver log a successful connection and delivery. Here's a snippit (e-mail address has been changed)

Apr 22 12:18:47 smtp sm-mta[16097]: r3MJIbxt016094:
to=@comcast.net>, delay=00:00:10, xdelay=00:00:10,
mailer=esmtp, pri=3
3254, relay=mx2.comcast.net. [IPv6:2001:558:fe2d:70::22], dsn=2.0.0,
stat=Sent (T7Jh1l00Z1HiJgm047JjQh mail accepted for delivery)

Source IP on that is 2001:470:c1aa::1 As you can see from the log, Comcast's mailserver took the

mail message via IPv6 AS IT IS SUPPOSED TO DO IF IT ADVERTISES IPv6 MX RECORDS. and the server ACKNOWLEDGED SUCCESSFUL RECEIPT.

But, the Comcast subscriber never gets the mail message in their Comcast inbox.

I have no problem sending to gmail addresses via IPv6.

My bitch is that when I called into Comcast tech support, the first thing the guy does is verify a PTR record exists. He tells me one does not. I tell him, sorry but according to many IPv6 PTR lookup tools on the Internet, yes it does. Then he tells me that he can't access any of these websites, he can only look at internal tools that look at their own PTR records.

WTF?!?!?

If Comcast is assigning /48's THEN THEY ARE DELEGATING IPv6 PTR records since delegation is done on a nibble boundary. There's NO EFFING WAY that he can lookup a PTR record in Comcast's database using some querytool that doesen't use dns BECAUSE IT ISN"T IN the Comcast database. He MUST use DNS.

I told the guy point blank - escalate this. He did.

Let me make this very clear. In many markets Comcast supplies IPv6 as well as IPv4. If Comcast's front-line tech support people are ignorant of IPv6 then they need to be educated. If the tools that they are given to help people are IPv4 ONLY then they need to be fixed.

HOW IN THE HECK can a support tech help anyone if they can't bring up a website? WTF is that all about?

The Comcast ticket# is CR318410213

Responses

tmittelstaedt

Problem solver

•

326 Messages

10 years ago

IPv6 was designed for distribution of /64 addresses to a single HOST, /48 addresses to a SITE.

This business of trying to slice IPv6 down futher is idiotic. It's coming from an IPv4 mindset.

You give a site a /48 and it will never, ever, bother you again for more addresses, EVER. You use sparse allocation to make holes all over your network, then you can reduce your route table down to just a few entries. Then you are not having to use routers that have to be able to do lookups in a 100K entry route table full of /32s in a microsecond.

Every single ISP on the face of the Earth coudl get a single IPv6 allocation that has 100 times more numbers in it than the ENTIRE INTERNET TODAY and you still wouldn't use more than a half a percent of the entire IPv6 numberspace.

"if the earth were made entirely out of 1 cubic millimetre grains of sand, then you could give a unique [IPv6] address to each grain in 300 million planets the size of the earth" - Wikipedia

0

Eric

New Contributor

•

10 Messages

9 years ago

Re servers needing static IP addresses.

It is actually a bit more subtle than this. Remember that IPv6 privacy causes address randomization. This is a good thing, as it prevents tracking, but does mean that you need to be aware of what happens to your address assignments.

For example, for Mail servers, you write the SPF records as a range of addresses - the range your server can adopt - instead of a single address as is done for IPv4. (Unless you are Google, and have done something stupid to break IPv6 addressing.) For receiving, your server can use any of the addresses it has adopted in the past, so you advertise via DNS the first IPv6 address it used. [Comments based on OS X Server implementation.]

0

flybynight

New problem solver

•

70 Messages

9 years ago

couple wrong things here:

First of all, a /64 is assigned to a network, and a host will pick one or more addresses from the /64. This can happen in various ways (Router Advertisements, DHCP, static). For a server, it is perfectly fine to assign a static address to receive e-mail in addition to whatever other addresses are assigned. For SPF records to send e-mail it may be easiest to define the /64 as your mail server may have multiple addresses.

For privacy enhanced addresses, your "first address" will typically only survive for 7 days and you will not be able to accept email using it after 7 days (7 days is the default parameter in Linux, OS X and Windows).

In addition, you should be careful about using IPv6 MX records at this point. Sendmail, a very popular mail server, has a broken implementation in that it will not fall back to IPv4 in case the IPv6 connection fails. So if you have an IPv6 MX record, mail servers with broken IPv6 connectivity will not be able to connect. Given the number of badly implemented tunnels, this is somewhat likely. However, there are not a lot (any?) IPv6 only mail servers right now. Sticking with IPv4 is safer at this point and SMTP works fine with NAT.

0

1
2