Obviously, if host B can access IPv6 addresses without problems, host A is NOT the problem.

Could it be that with host B, your lack of use of iptables, thus no NAT, is the problem?  172.16.0.0/12 is not a globally routable network.

On the domain name label itself, they should be using a SRV-RR, not an address-type record.  Unfortunately for HTTP, most clients are ignorant of SRV records.

You'll find that many DNS providers do not support SRV records, but they do support MX records pointing to the domain itself. This may be the case for the majority of DNS providers.

Not my problem.  My colocation provider hosts all my domains as secondary name servers (and I run the primary on my box), thus I have every type of RR available to me.

[is]

That's not what he said, at least how I read it.

I interpreted him as saying that with:

example.com.  IN  MX   0  example.com.
example.com.  IN  A     192.0.2.1
example.com.  IN  AAAA 2001:DB8::1

the MX record will not be accepted by his DNS provider because it points to its own label (which with the A-RR and/or the AAAA-RR is a host name as well as a domain and zone name).

Technically, his provider is correct.  Labels which have the SOA-RR (zone names) should not be host names.  Host names should be established UNDER zone names.  (Domain names are the registerable zone names.)


If one wants to enable just the domain name as a "host name" valid for HTTP lookups (e.g. to "drop" a leading "www"), the correct way to do that is with a SRV-RR.  I have found that some clients (browsers and robots) will use the SRV record to find the HTTP server (but this is still very rare).  I know this because I do NOT provide address records for my domain names but do have SRV records at the domain name label and programmed my HTTP server to perform redirection should just the domain name be the queried (virtual) host name, and I see such requests (maybe one per day) in my server's request log.

As to whether a domain or host name should always have an MX-RR, granted it is not an absolute requirement but it does provide for better performance.  Without it, the negative MX-RR answer will be cached for what is usually a much shorter time than a positive answer, so many more uncached lookups will occur.  Standard values of 3 hours for negative answers and 1 day for positive answers means that queries for the absent record at a busy destination will cause up to 8 times the DNS traffic as compared to the positive answer frequency.  As a domain name should not have an address-type record because it should not be also a host name, it should then have an MX-RRset (and probably an SRV-RRset too) for its mail service.  Postfix can use the SRV records.  Sendmail will not.

Aside, regarding SRV records:  Many people skip SRV records for DNS itself.  Granted, how can one use the DNS to find the name servers if one doesn't already have the SRV-RRs in hand?  For the DNS service, the SRV records do not indicate a query path as they do for other services, but only the update path; i.e. the SRV-RRs for the domain service should point at only the primary server (or other DNS server) where zone updates are performed.  NS-RRs continue to indicate where queries are directed.

Don't forget:

label.example.com.  IN  MX  0  .

means that there is no mail service at that label (usually a host name for a machine hosting a dedicated service).  That is not the same as:

label.example.com.  IN  MX  0  localhost.
localhost.                IN  A   127.0.0.1
localhost.                IN  AAAA  ::1

where a host does have mail service but only accepts mail from itself.

I agree with the quotes being necessary.  You forget that "&" is a unix shell metacharacter.

Noted, but maybe the individual tunnel sponsors they contract with may.  It never hurts to ask.

Try Sixxs.net.

Your local IPv4 address isn't your assigned globally reachable IPv4 address.

Your local IPv4 address for the tunnel should be your public IPv4 address.

After changing the Local IPv4 Address to 192.168.0.1, I can ping....

Is your router behind another NAT device?  If so, that's the problem.

The only thing I noted that was different about your setup vs. mine with my DIR-615 is your LAN IPv6 address is set to the "::1" of your subnet, while I let my float to the natural MAC-generated address.

Try setting it to 2001:470:19:1292:BAA3:86FF:FE4A:043E and see if that makes a difference.

The information is available via a "whois" lookup - and indicates France, not Russia.

You listed it among the other subtractions.  That was clear.  Your computation implied comparing 1280 to 1208, not 1300 to 1208.

You explicitly included it in your list of subtracted values from 1280 to arrive at 1208.  Read your message.

Yes, but you subtracted the IPv4 header size from the IPv6 MTU when you should have added it as it's NOT part of the IPv6 MTU size.