mstorms, see the attachment below for the Netgear D6400 6rd tunnel values via Centurylink.com.  Also, you can find these values at the following uniform resource locator ( URL ): "https://www.centurylink.com/home/help/internet/modems-and-routers/advanced-setup/enable-ipv6.html.
These values may be difficult to determine at the above-given url, but the values are clear in the attachment included with this post ( a screen shot from my own Netgear D6400 router ).  This should enable you to successfully connect to "ipv6.google.com," for example. 

REWILLIS, I'm having the same issues with my D6400; what values did you use for DRD6 for CenturyLink?

For the past few weeks, I've been having trouble connecting to yahoo mail.   Does anyone know what could be the problem?

I try this with HE IPv6 tunnel.  Nothing happens except a timeout after five minutes.

Code: [Select]

$ curl --verbose --verbose https://mail.yahoo.com
* Rebuilt URL to: https://mail.yahoo.com/
*   Trying 2001:4998:1c:800::1000...
* TCP_NODELAY set
* Connected to mail.yahoo.com (2001:4998:1c:800::1000) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* Operation timed out after 300156 milliseconds with 0 out of 0 bytes received
* stopped the pause stream!
* Closing connection 0
curl: (28) Operation timed out after 300156 milliseconds with 0 out of 0 bytes received

whereas if I do:

Code: [Select]

$ curl --verbose --verbose -4 https://mail.yahoo.comthe response is instantaneous.

A plain http://mail.yahoo.com over IPv6 (port 80) forwards immediately to https://mail.yahoo.com (port 443) which times out.  So http to yahoo over IPv6 is good.

I can get to other IPv6 sites just fine, he.net, youtube, google... with and without https.  ipv6foo on my browser verifies IPv6 connection usage.  I'm filling out this form with https://forums.he.net (port 443) and the site is quite responsive.

I've reproduced this problem on Windows, RHEL and Ubuntu.

since about 1 hour the transfer rates went down to nearly zero;
restarting my endpoint ... didn't help;
what happened?
Thanks,
Walter

After upgrading from Fedora 32 Linux 5.8.18 to 5.9.8 the tunnel via 216.66.84.46 is down.
I am using this setup

ip tunnel add sit1 mode sit remote 216.66.84.46 local 95.154.24.73 ttl 255
ip link set sit1 up
ip addr add 2001:470:1f14:773::2/64 dev sit1
ip route add ::/0 dev sit1

This command normally not used and makes no difference
    ip tunnel 6rd dev sit1 6rd-prefix 2001:470:1f14:773::/64 6rd-relay_prefix 216.66.84.46/32

ip -f inet6 addr

I can ping6 to my end of the tunnel and 216.66.84.46 but not the remote end of the tunnel 2001:470:1f14:773::1
Firewalld has been stopped

Any idea ?

Is your Tunnel endpoint correct on the HE portal?
I see you have HE DDNS configured - is this working and correctly updating your endpoint?
Rather than using the inbuilt DDNS client I use an EEM TCL script that is triggered when the Tunnel interface changes the state to up.  It was a script I found on CCO written in 2009 (ipv6-tunnel-update.tcl) - I am sure you can find it and modify it for your details.
Other than that my configuration looks similar to yours.  I can't ping any IPv6 addresses from the router which I think is an issue with IPv6 inspection I have enabled, however from a client or an IOS switch on the inside I can.

Good luck
Andy

Bump, this is still an issue. Can't really complain about a free service, but it's kind of annoying.

Code: [Select]

# ping 216.66.84.46
PING 216.66.84.46 (216.66.84.46) 56(84) bytes of data.
64 bytes from 216.66.84.46: icmp_seq=1 ttl=60 time=10.7 ms
64 bytes from 216.66.84.46: icmp_seq=2 ttl=60 time=10.4 ms
64 bytes from 216.66.84.46: icmp_seq=3 ttl=60 time=10.8 ms
64 bytes from 216.66.84.46: icmp_seq=4 ttl=60 time=10.4 ms
64 bytes from 216.66.84.46: icmp_seq=5 ttl=60 time=11.3 ms
64 bytes from 216.66.84.46: icmp_seq=6 ttl=60 time=12.0 ms
64 bytes from 216.66.84.46: icmp_seq=7 ttl=60 time=10.2 ms
64 bytes from 216.66.84.46: icmp_seq=8 ttl=60 time=46.5 ms
64 bytes from 216.66.84.46: icmp_seq=9 ttl=60 time=10.9 ms
64 bytes from 216.66.84.46: icmp_seq=10 ttl=60 time=10.8 ms
64 bytes from 216.66.84.46: icmp_seq=11 ttl=60 time=83.7 ms
64 bytes from 216.66.84.46: icmp_seq=12 ttl=60 time=10.7 ms
64 bytes from 216.66.84.46: icmp_seq=13 ttl=60 time=10.6 ms
64 bytes from 216.66.84.46: icmp_seq=14 ttl=60 time=10.3 ms
64 bytes from 216.66.84.46: icmp_seq=15 ttl=60 time=10.7 ms
64 bytes from 216.66.84.46: icmp_seq=16 ttl=60 time=10.3 ms
64 bytes from 216.66.84.46: icmp_seq=17 ttl=60 time=10.6 ms
64 bytes from 216.66.84.46: icmp_seq=18 ttl=60 time=10.2 ms
64 bytes from 216.66.84.46: icmp_seq=19 ttl=60 time=10.8 ms
64 bytes from 216.66.84.46: icmp_seq=20 ttl=60 time=10.8 ms
64 bytes from 216.66.84.46: icmp_seq=21 ttl=60 time=10.3 ms
64 bytes from 216.66.84.46: icmp_seq=22 ttl=60 time=13.3 ms
64 bytes from 216.66.84.46: icmp_seq=23 ttl=60 time=10.9 ms
64 bytes from 216.66.84.46: icmp_seq=24 ttl=60 time=11.0 ms
64 bytes from 216.66.84.46: icmp_seq=25 ttl=60 time=42.3 ms
64 bytes from 216.66.84.46: icmp_seq=26 ttl=60 time=10.9 ms
64 bytes from 216.66.84.46: icmp_seq=27 ttl=60 time=10.7 ms
64 bytes from 216.66.84.46: icmp_seq=29 ttl=60 time=11.1 ms
64 bytes from 216.66.84.46: icmp_seq=30 ttl=60 time=11.5 ms
64 bytes from 216.66.84.46: icmp_seq=31 ttl=60 time=114 ms
64 bytes from 216.66.84.46: icmp_seq=32 ttl=60 time=10.3 ms
64 bytes from 216.66.84.46: icmp_seq=33 ttl=60 time=10.6 ms
64 bytes from 216.66.84.46: icmp_seq=34 ttl=60 time=11.0 ms
64 bytes from 216.66.84.46: icmp_seq=35 ttl=60 time=10.9 ms
^C
--- 216.66.84.46 ping statistics ---
35 packets transmitted, 34 received, 2.85714% packet loss, time 34049ms
rtt min/avg/max/mdev = 10.177/17.977/113.854/21.996 ms


Code: [Select]

                            My traceroute  [v0.94]
ipoac.nl (82.169.214.136) -> 216.66.84.46            2020-11-17T16:11:17+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                     Packets               Pings
 Host                              Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 195-190-228-169.fixed.kpn.net   0.0%   132    5.9  11.8   4.8  47.7  11.1
 2. kpn-as1136.kpn-rt-dc2.nl-ix.ne 89.3%   131   11.1  10.5  10.0  11.3   0.4
 3. (waiting for reply)
 4. 100ge2-1.core1.ams1.he.net      0.0%   131   10.8  10.9   9.8  12.2   0.4
 5. tserv1.ams1.he.net              0.8%   131   10.7  18.3  10.1 110.0  20.2
I'm also seeing the same packet loss and latency spikes when pinging tserv1.ams1.he.net from a native IPv6 address....

OK, you might be on to something there....
The DNS servers are Windows 2019 DC's.  If I capture the DNS traffic when looking up the MX record 'gmail.com' the reply contains the list of server names and priorities plus the reply also contains additional records for entries that are already cached on the DNS server.  For each of the cached hosts the A record IPv4 address is listed 1st.
I can replicate the behaviour by clearing the cache on the client and the server then doing a nslookup for the MX record.  The 1st reply shows no additional records, however if I lookup the A & AAAA records for one of the hosts in the MX record reply and then run the nslookup on the MX records I see the host in the additional records.
If I repeat the behaviour with googles DNS (2001:4860:4860::8844, or 8.8.8. I never see these additional records in the reply.

This must be a side effect of the DNS server behaviour with Windows Server 2019?  I have had a quick search but not found anything so far.

For the time being I have created an ACL on the edge router to drop IPv4 SMTP traffic from the Exchange server to the two google SMTP servers.

Andy

1). You expect Microsoft to do the RFC correct thing?
2). Look at your resolver results.  IPv4 entries are all appearing first, so the mailer is trying IPv4 first as a result.  Probably very little to no randomization of the order of the answers.  Maybe you need to tell your DNS to prefer AAAA over A in its answers (if the mail server lacks such a feature), assuming you have such a setting (BIND does) and appropriate administrative access.

I think this might be a quirk of Exchange 2016 or maybe a combination of Exchange 2016 running on Windows Server 2016.

I have had a Windows 2012R2 server running Exchange 2013 for a couple of years.  Its a standalone Exchange server that's a member server in an AD domain.  I have native IPv6 via HE with my own /48 prefix and my egress IPv4 traffic is NAT'd to a single dynamic IPv4 address.
It has been working flawlessly for a couple of years.  It took me a bit of time to get the various DNS records correct initially, however its been flawless since.
I recently decided to retire the Exchange 2013 VM and replace it with Exchange 2016.  I built a Windows 2016 server (Version 1607 OS Build 14393), got it patched to the latest versions of everything, added the prerequisites, prepared AD and then installed Exchange 2016 CU18.  I then migrated everything over and then finally updated various DNS records and the external firewall NAT/Rules.  Everything was working or so I thought.  Then I sent an email to a Gmail recipient and got an undeliverable message from google:

mx.google.com gave this error:
[x.x.x.x] The IP you're using to send mail is not authorized to send email directly to our servers. Please use the SMTP relay at your service provider instead. Learn more at https://support.google.com/mail/?p=NotAuthorizedError n13si8706925wrj.468 - gsmtp

After digging through various logs I can see that the Exchange 2016 server is using the IPv4 address of the server with the highest ranking MX record, even though it has both A & AAAA records.

2020-11-13T11:48:31.794Z,08D887BD691B7D56,SMTP,gmail.com,+,DnsConnectorDelivery 8fb227fc-ba17-49d2-947e-d54dbfcdc25e;QueueLength=TQ=1;RN=1;.
2020-11-13T11:48:32.041Z,08D887BD691B7D56,SMTP,gmail.com,>,"gmail-smtp-in.l.google.com[74.125.133.26, 2a00:1450:400c:c07::1a], alt1.gmail-smtp-in.l.google.com[209.85.233.27, 2a00:1450:4010:c03::1b], alt2.gmail-smtp-in.l.google.com[172.253.118.27, 2404:6800:4003:c05::1b], alt3.gmail-smtp-in.l.google.com[108.177.9..."
2020-11-13T11:48:32.059Z,08D887BD691B7D56,SMTP,gmail.com,>,Established connection to 74.125.133.26

If I block connections to the IPv4 address of the Google SMTP server (74.125.133.26) then it fails the initial connection but retries the IPv6 address which works:

2020-11-13T11:52:13.905Z,08D887BD691B7D59,SMTP,gmail.com,+,DnsConnectorDelivery 8fb227fc-ba17-49d2-947e-d54dbfcdc25e;QueueLength=TQ=1;RN=1;.
2020-11-13T11:52:13.905Z,08D887BD691B7D59,SMTP,gmail.com,>,"gmail-smtp-in.l.google.com[74.125.133.26, 2a00:1450:400c:c07::1a], alt1.gmail-smtp-in.l.google.com[209.85.233.27, 2a00:1450:4010:c03::1b], alt2.gmail-smtp-in.l.google.com[172.253.118.27, 2404:6800:4003:c05::1b], alt3.gmail-smtp-in.l.google.com[108.177.9..."
2020-11-13T11:52:16.752Z,08D887BD691B7D59,SMTP,gmail.com,>,Failed connection to 74.125.133.26:25 (TimedOut:0000274C)[TargetIPAddress:74.125.133.26:25|MarkedUnhealthy|FailureCount:1|NextRetryTime:2020-11-13T11:53:16.751Z]
2020-11-13T11:52:16.753Z,08D887BD691B7D59,SMTP,gmail.com,-,Messages: 0 Bytes: 0 (Attempting next target)
2020-11-13T11:52:16.753Z,08D887BD691B7D5A,SMTP,gmail.com,*,Session Failover; previous session id = 08D887BD691B7D59; reason = SocketError
2020-11-13T11:52:16.753Z,08D887BD691B7D5A,SMTP,gmail.com,+,DnsConnectorDelivery 8fb227fc-ba17-49d2-947e-d54dbfcdc25e;QueueLength=TQ=0;RN=1;.
2020-11-13T11:52:16.775Z,08D887BD691B7D5A,SMTP,gmail.com,>,Established connection to 2a00:1450:400c:c07::1a
2020-11-13T11:52:17.344Z,08D887BD691B7D5A,SMTP,gmail.com,-,Messages: 1 Bytes: 3736 ()

If I open a command prompt on the Exchange 2016 and attempt to telnet to gmail-smtp-in.l.google.com on port 25 it connects using IPv6 which is what I would expect with Windows 2016 as it prefers IPv6 over IPv4 by default.
What appears to be happening is the Exchange MTA is preferring IPv4 for outbound SMTP connections.  I don't think this was the case with Exchange 2013 (or a combination of Server 2012R2 and Exchange 2013).

I am going to bring the original Windows 2012R2 server back online and install Exchange 2016 on it and then add a specific send connector for *.gmail.com via this and see what happens.

Andy