The hostname www.eftps.gov has both A and AAAA records, but the site is only reachable via IPv4. Worse, the IPv6 connectivity is broken in such a way that Firefox and Internet Explorer do not fall back to IPv4. Tracing is broken for both protocols. The 10-net addresss in the IPv4 path were cute.
Calling their technical support was an exercise in futility. Supposedly they forwarded messages on to the right people; but the site is still broken after over a week's wait. If someone knows the admins behind the EFTPS website and can forward this to them, the accounting firm for which I work would appreciate it.
Thanks,
I tried to this a month ago, no luck 
i.e. nothing back from them, just goes into no answer e-mail space!
Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition"
Link Technologies, Inc -- Mikrotik & WISP Support Services
Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs
-- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace
if only some us-gov folks read this mailing list...
maybe someone form NIST could aim the right question to the right
eftps.gov people?
you'd think helping the taxman would be appreciated.
if only some us-gov folks read this mailing list...
maybe someone form NIST could aim the right question to the right
eftps.gov people?
you'd think helping the taxman would be appreciated.
it's probably also fair to point out that ... it seems to be working.
(AAAA and A)
if only some us-gov folks read this mailing list...
maybe someone form NIST could aim the right question to the right
eftps.gov people?
you'd think helping the taxman would be appreciated.
it's probably also fair to point out that ... it seems to be working.
(AAAA and A)
and traceroute/traceroute6 seems to work to the prem...
6 cr1.attga.ip.att.net (12.122.1.173) 79.126 ms 71.722 ms 74.646 ms
7 cr2.dlstx.ip.att.net (12.122.28.174) 74.001 ms 74.127 ms 74.198 ms
8 cr1.dlstx.ip.att.net (12.122.1.209) 75.261 ms 75.305 ms 75.405 ms
9 cr1.phmaz.ip.att.net (12.122.28.182) 73.070 ms 73.381 ms 73.408 ms
10 12.123.206.173 (12.123.206.173) 71.586 ms 70.289 ms 70.048 ms
11 12.87.83.6 (12.87.83.6) 71.226 ms 71.290 ms 71.526 ms
12 * * *
6 2600:803:95f::d (2600:803:95f::d) 4.618 ms 4.951 ms *
7 2600:805:51f::12 (2600:805:51f::12) 49.616 ms 49.726 ms 49.672 ms
8 2600:805:51f::12 (2600:805:51f::12) 48.548 ms 48.561 ms 48.75 ms
9 2620:10f:400e:1::6 (2620:10f:400e:1::6) 50 ms 53.366 ms 50.704 ms
10 * * *
so, what's broken?
The end-user machines I tested on are behind 6in4 tunnels (MTU 1480). They open the TCP connection, but never load a page. They don't complete the HTTPS SSL handshake. On port 80, they send the HTTP request, but never get a response to GET /.
It works for me (http)
Cannot ping, so maybe they filtered the whole ICMPv6 and you have a MTU
problem. But that is only a guessing.
as
see, now we're getting information that FDC/IRS could actually use! 
This looks like an MTU issue then?
so, a suggestion to eftps.gov/irs/fdc is to simply clamp MSS on their
servers, no?
I might instead suggest a read of RFC 4890.
it might not be their (eftps.gov's) fault though... but sure.
If you run a server you should be expecting PTB for both IPv4 and
IPv6. If you have broken equipement in front of the server you can
set IPV6_USE_MIN_MTU to 1 on IPv6 sockets. There is no excuse to
have connections broken due to PMTUD.
sure there is! "my isp filters icmp"
You don't have a ISP then. You have a fraudster.
Mark
Setting IPV6_USE_MIN_MTU on a IPv6 socket is a couple of lines of
code in the http server. Been there, done that. If you can't do
that then set the interface MTU to 1280. I repeat there is no
excuse to have connection broken due to PMTU issues. A compentent
sys admin can work around upstream problems.
Mark