My isp only give me one ipv6 address no any prefix unless I bridge WAN and LAN
-
I can get a ipv6 address by RA but no routed /64.
So I must bridge WAN and LAN and disable ipv4 through it.The following is how I can do by one Linux.
I have 4 vlan (LAN), 1 WAN (only need ipv6)
Use brctl bridge all the interface
Use ebtables to disable any ipv4Then all the LAN have correct ipv6 address, no problem.
But I want use Pfsense do this.
And it is very good if the WAN can nat ipv4.i.e. I want ipv4 in NAT but ipv6 passthrough like Netgear router.
-
Choose a provider that gives you /60 or better /56 prefix, or use an HE.NET tunnel with /48; its free!
<rant>I really don't understand why there are ISPs that seems to think that they should restrict their clients to 1 prefix, that just makes no sense! If the ISP gets a /32 prefix, which is the standard default size allocated to ISPs, from their local numbering registry, then they have enough prefixes to give out a single /64 prefix to every single IPv4 host on the ENTIRE INTERNET with lots left over!!
/32 = 2^32 (4,294,967,296) prefixes
/48 = 2^16 (65,536) prefixes
/52 = 2^12 (4,096) prefixes
/56 = 2^8 (256) prefixes
/60 = 2^4 (16) prefixes</rant> -
I really don't understand why there are ISPs that seems to think that they should restrict their clients to 1 prefix, that just makes no sense!
The idiotic IPv4 mentality, I guess… Sigh.
-
I would just go with HE to be honest.. It is so much easier to work with.. you can get a /48 and then use as many /64 as your heart desires on your own network..
Until such time that these ISPs get their stuff together its just easier and more stable too boot. I have tried multiple times to go with comcast native and just more pain than its worth. Biggest issue is when the prefix changes.. Once you have a /48 you don't have to worry about anything changing.. They even give you full control over the PTRs… Your isp isn't doing that for sure..
-
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.
-
The problem is that most big telco ISPs don't want
plebeiansusers 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! -
One of these days they might figure out it's not their internet - it's ours.
-
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??
-
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.
-
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.
-
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
-
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. -
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…
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
-
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."
-
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.
-
example.org. 3323 IN MX 10 mail.example.org. example.org. 3323 IN MX 15 mail6.example.org.
Are those two different mailservers?
-
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.
-
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.
-
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.
-
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?