My isp only give me one ipv6 address no any prefix unless I bridge WAN and LAN

Derelict

They just don't seem to understand that with IPv6 using DNS for even a couple internal hosts is even more important due to the nature of the addresses. Complete PITA when the prefix changes. Even if the internal hosts figure it out pretty quickly, someone has to go change the DNS entries.

Prefix delegations need to be static - as in unchanging.

awebster

The problem is that most big telco ISPs don't want ~~plebeians~~ users running any kind of servers on their residential grade connections; they make their money off of the business connections, consequently their modus operandi is to throw as many sticks in the wheels as possible.
This is of course diametrically opposite to what IPv6 is promising.
IoT is just not going work if the prefixes are dancing around like musical chairs!

Derelict

One of these days they might figure out it's not their internet - it's ours.

johnpoz

Just because they give you your own /whatever doesn't mean they still can not block inbound traffic of server nature if they really felt that strong about it..

Im with derelict here what does it freaking matter what I use the bandwidth for, be it outbound traffic or unsolicited inbound traffic.. Most residential connections are asymmetric in nature anyway.. I for example have 80/10 – what would I be serving up to the public off a shitty ass 10mbit connection anyway other than personal stuff.. I vpn in to get to my network... Anything I would want to serve to the public I would put on a REAL connection.. Even just for the sake I take my network down all the time.. What services would I be providing to the public that goes off all the time?

I do have my ntp server part of the pool.. But this is just a server in a SHIT load of servers and when my score goes below 10, my server isn't listed any more and this happens quite quickly when I go offline.. Its like a secondary monitor to be honest, I get an email when score drops below 10... Tells me something wrong at home even when nobody there, on the road, etc.. ;)

Just sell us fast reliable connectivity, don't freaking block anything at decent price and you will have all the users you could want..

HE is going to be your best best for good reliable IPV6 connectivity -- its a tunnel sure.. But it WORKS, is always UP and prefix doesn't change when the wind blows, and your even have full PTR control.. I think they blocked running smtp on it because of abuse?? Or maybe you have to get special approval and then they open it up??

awebster

@johnpoz:

I think they blocked running smtp on it because of abuse?? Or maybe you have to get special approval and then they open it up??

Just have to show them that you know what you're doing and they'll open it up.

doktornotor

@johnpoz:

I think they blocked running smtp on it because of abuse?? Or maybe you have to get special approval and then they open it up??

Depends on when you registered. Up to certain date, it's not blocked at all, after that date you need to get the "IPv6 sage" grade, and recently, you need a justification to get it unblocked. Ditto for IRC.

johnpoz

Knew it was something like that have been sage for quite some time would have to checked if im blocked have 64 for long time with 48 more recent when i wanted enable it on more of my segments and for vpn clients

awebster

Yeah, I did all that, got the T-Shirt. The only problem I've had is with Gmail, they really don't have their act together to receive SMTP from IPv6 addresses, despite having PTR and TXT records all correctly defined.
You basically have to block SMTP outbound on IPv6 in the hopes that your mail server/client is smart enough to try IPv4 instead. That was some months ago, I gave up trying to bend that spoon.

doktornotor

@johnpoz:

Knew it was something like that have been sage for quite some time would have to checked if im blocked have 64 for long time with 48 more recent when i wanted enable it on more of my segments and for vpn clients

Well, basically if you cannot see the option of unblocking in the control panel and have the traffic blocked, you need to email them…

@awebster:

Yeah, I did all that, got the T-Shirt. The only problem I've had is with Gmail, they really don't have their act together to receive SMTP from IPv6 addresses, despite having PTR and TXT records all correctly defined.
You basically have to block SMTP outbound on IPv6 in the hopes that your mail server/client is smart enough to try IPv4 instead. That was some months ago, I gave up trying to bend that spoon.

No problems with Gmail and SMTP over IPv6 here… (You need the proper PTR record for your mailserver for sure; other than that, check Google docs.)

https://support.google.com/mail/answer/81126?p=ipv6_authentication_error&rd=1#authentication

johnpoz

under the ipv6 for gmail they do state you should have spf or dkim setup aswell… So maybe that is your issue? This is good practice be your ipv4 or 6 if you ask me.

"The sending domain should pass either SPF check or DKIM check. Otherwise, mail might be marked as spam."

awebster

@doktornotor:

No problems with Gmail and SMTP over IPv6 here… (You need the proper PTR record for your mailserver for sure; other than that, check Google docs.)

https://support.google.com/mail/answer/81126?p=ipv6_authentication_error&rd=1#authentication

I'm happy to hear that someone has it working!

I did all the required setup (TXT SPF record and PTR). Gmail inbound would work for a while then start bouncing messages claiming it was spam, then all of a sudden go back to working normally. I just couldn't get it working reliably.
I'd get this message:


<<< 550-5.7.1 [2001:470:x:y::z      12] Our system has detected that
<<< 550-5.7.1 this message is likely unsolicited mail. To reduce the amount of spam
<<< 550-5.7.1 sent to Gmail, this message has been blocked. Please visit
<<< 550 5.7.1 https://support.google.com/mail/answer/188131 for more information.

I was initially thinking that it was Google doing some funky IPv4 to IPv6 AS number correlation to see if known domains were popping up from different ASes or different geographically disparate places since the HE.NET tunnel clearly does both, but its not related to HE.NET address space either as I've had similar issues with native IPv6 setups from the same AS as the IPv4 sending email into Google where it works intermittently.

Here's my obfuscated output, I can't find anything wrong though.

MX lookup


# dig example.org mx @8.8.8.8

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> example.org mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15441
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;example.org.                  IN      MX

;; ANSWER SECTION:
example.org.           3323    IN      MX      10 mail.example.org.
example.org.           3323    IN      MX      15 mail6.example.org.

;; ADDITIONAL SECTION:
mail.example.org.      1480    IN      A       72.x.x.x
mail6.example.org.     2026    IN      AAAA    2001:470:x:y::z

TXT lookup; 3 queries, setup the same way Google has setup their SPF records!


# dig example.org txt @8.8.8.8

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> example.org txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40448
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;example.org.                  IN      TXT

;; ANSWER SECTION:
example.org.           2295    IN      TXT     "v=spf1 include:_spf.example.org include:_spf2.example.org  ~all"

# dig _spf.example.org txt @8.8.8.8

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> _spf.example.org txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50484
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_spf.example.org.             IN      TXT

;; ANSWER SECTION:
_spf.example.org.      2256    IN      TXT     "v=spf1 a mx ip4:72.x.x.x ~all"

# dig _spf2.example.org txt @8.8.8.8

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> _spf2.example.org txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61342
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_spf2.example.org.            IN      TXT

;; ANSWER SECTION:
_spf2.example.org.     2248    IN      TXT     "v=spf1 ip6:2001:470:x:y::z ~all"

PTR lookup


# dig -x 2001:470:x:y::z @8.8.8.8

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> -x 2001:470:x:y::z
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17032
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;z.z.z.z.0.0.0.0.0.0.0.0.0.0.0.0.y.y.y.y.x.x.x.x.0.7.4.0.1.0.0.2.ip6.arpa. IN PTR

;; ANSWER SECTION:
z.z.z.z.0.0.0.0.0.0.0.0.0.0.0.0.y.y.y.y.x.x.x.x.0.7.4.0.1.0.0.2.ip6.arpa. 41656 IN PTR mail6.example.org.

doktornotor


example.org.           3323    IN      MX      10 mail.example.org.
example.org.           3323    IN      MX      15 mail6.example.org.

Are those two different mailservers?

awebster

No they are the same box. I initially had just mail, but that didn't work so I split out the ipv6 address of the server into a separate hostname for troubleshooting.

doktornotor

This is really not how it should be done. There should be a single MX record, with PTRs for both A and AAAA records that resolve back to mail.example.com. "That didn't work" - as usually - ain't a useful problem description. Also, the SPF needs the A record added.

johnpoz

So what does the email server report mail or mail6? If the ptr and forward don't match = spam.. so you could have problems using 2 names when only 1 server.

awebster

Thanks…
Didn't work means it exhibited the same random gmail bounce messages on sending to @gmail and @gmail_hosted recipients. Before and after splitting out the ipv6 host didn't change the observed behaviour, so p
@doktornotor:

Also, the SPF needs the A record added.

Not sure I understand that, care to elaborate?

doktornotor

You need ip4:x.x.x.x in there besides the ip6 in the TXT record. If you are only sending mail from the one MX, all you need is:

Like:


example.org.      2256    IN      TXT     "v=spf1 mx ~all"

(Meanwhile, if you got yourself a spammer reputation on that /64 already, you'd be better off deleting the tunnel and requesting a new one with HE. Also, I'd make sure any outbound SMTP is blocked from LAN, except for the mailserver IP. Otherwise, requesting new prefixes over and over again gets annoying quickly…)

awebster

Thanks very much dok!

You put me on the right track. Problem was subtle, but makes sense now in hindsight.
I had stacked the SPF records, just as Google does, but if you put a "a" or "mx" inside the TXT record it is applying it to the fqdn of the stacked record, not the base record from which it was included originally.
So while I had _spf.example.org. IN TXT "v=spf1 a mx ip4:72.x.x.x ~all", the SPF parser was looking for an A and MX record in _spf.example.org, not in example.org which included _spf.example.org.

I've cleaned it up, folded mail6 back into mail and I'll give it another spin. Strange though that it never has issues with IPv4 delivery, yet that is where the source of the problem lies.