Did you miss your
pfSense English Support
2.1 Snapshot Feedback and Problems
IPv6 Configuration Type & Other IPv6 topics
Topic: IPv6 Configuration Type & Other IPv6 topics (Read 843 times)
0 Members and 1 Guest are viewing this topic.
IPv6 Configuration Type & Other IPv6 topics
July 09, 2012, 11:54:47 pm »
I apologize if any of my questions, but I have searched the forums and google and did not come up with useful information. I have an HE gif tunnel setup and working with a /64 and a /48. The HE /64 is set on the LAN interface and I have /64s set on my other interfaces which are netblocks from the HE /48. This is all working.
However, I believe I am missing something and other IPv6 setups are just not clicking. There for I have some IPv6 questions and those same questions related to pfSense. My hope is that someone that really gets all these different IPv6 setups will chime in and give me the piece of the puzzle that is not fitting preventing me from getting this. My next hope is that someone will be able to explain which of these setups work for pfSense 2.1 now, which are flaky and which are planed for 2.1 and 2.2.
1) Can someone please explain the IPv6 transition mechanisms, see list below, and not in the way that the RFCs do? I have read RFCs and many other docs and the part that is not clicking is when you would use each config type. Therefore, what I need is a more plain English and visual explanation. e.g. In this setup your devices behind the router/firewall would only have IPv4 address and then the router/firewall does this work in conjunction with another device, etc. Now I understand that there are a lot IPv6 transition mechanisms in my list below and there are likely more and no one may want to explain them all, so please read my questions below to have a better idea of what information I need.
NAT64 / DNS64
1a) I want to understand the difference between what seem like the same IPv6 transition mechanisms. For example, does my HE gif tunnel setup one of the 6in/to/over4 IPv6 transition mechanisms? If so which? If not, then which of the IPv6 transition mechanisms is it?
1b) What are the differences between 6in/to/over4 IPv6 transition mechanisms.
1c) What is 4in6? Is someone providing a tunnelbroker for IPv4 like HE is for IPv6 or would I setup and manage this "tunnel broker"?
1d) Since I decided to use pfSense 2.1 to test IPv6, I have wanted to test as many of the IPv6 transition mechanisms that I can, but there are two I am most interested in testing. The first is the HE gif tunnel I already have working. The other is a setup that I believe could only be achieved by NAT-PT and NAPT-PT which are deprecated, but may now be described in RFC 2893 and perhaps by any number of the IPv6 transition mechanisms I listed an other others. This is providing access to IPv6 sites from devices that only support IPv4. It looks like I will need a "IPv4-compatible IPv6 address" configuration for at least one of the IPv6 transition mechanisms that allow IPv4 only devices to access IPv6 only devices. So the questions are...
What are the IPv6 transition mechanisms that support this and which does pfSense 2.1 support now and which are planed for 2.1 and 2.2?
Can I setup any of the IPv6 transition mechanisms that support this while still being able to provide dual stack on the same interface? For example let's postulate that setting the IPv6 Configuration Type to 6to4 tunnel on the WAN interface and Track Interface on the LAN interface provides the setup allowing IPv4 only devices to access IPv6 only devices. Then if I wanted to also have dual stack hosts on the same interface, could I use an IP Alias to assign the same IPv6 IP I would assign the interface directly if I was only using the HE gif tunnel?
2) Does the NPt NAT in pfSense 2.1 provide what I need to allow IPv4 only devices to access IPv6 devices. Regardless what does this provide, when and why would I use it?
3) In "System: Advanced: Networking Enable" the option "IPv4 NAT encapsulation of IPv6 packets" exists. What is this and how is it different from using the "IPv6 Configuration Type" "6to4 tunnel" or the HE gif tunnel I setup? What would be entered in the IP address field for this option?
It just might be your luck day, if you only knew.
Re: IPv6 Configuration Type & Other IPv6 topics
Reply #1 on:
July 10, 2012, 12:25:41 am »
Just a tip for anyone interested. My advice is to make sure your servers are Dual Stacked so you won't have to care where the client is coming from. It will just work.
4in6, tunnel IPv4 over IPv6, the reverse of
6in4(6over4), tunnel IPv6 packets over IPv4 to a relay on the other side.
6to4, this automatically generates a IPv6 prefix you can use based on your public IPv4 Address. This breaks if you don't get a public IPv4 address. Which is the case soon since most Local registries will run out of public v4 "soon" and thus start giving users a private address and NAT everything. This transition tech has limited lifetime. Always starts with 2002::/16. It carries the IPv6 traffic over IPv4 like 6in4.
DS-Lite, tunnels your IPv4 over IPv6, you still get NAT from the ISP but the base carrier is IPv6, like 4in6. The benefit from the ISP is that they don't need Public IPv4 to rollout, which is what any starting ISP will need to do starting 2013 because they will get a single /22 for transition purposes only.
6rd, based on the 6to4 mechanism, but the ISP controls the relay which means they can offer a more reliable service, it also works with private IP addresses on the WAN because they can define the relay the client uses. It uses a similar "calculate the local prefix based on the WAN address" as 6to4, but it can have a different prefix from 2002::/16 and is ISP prefix instead.
ISATAP, Teredo, ignore. It's going away. Windows thing. Automatic tunneling mechanism.
NAT64, DNS64, This is what you will use if you have a v6 client, that can not speak IPv4. We'll need this in the near future, mostly for mobile since it's hard to do dual stack there. Otherwise a v6 only device can not reach IPv4 sites. T-Mobile US is running limited scope testing, but most things work fine.
You'll need a black belt in packet capture foo to decode the NAT though. It's positively unreadable. But it's required to go forward.
4rd, rapid IPv4 deployment, but over IPv6. Tunnel your IPv4 over IPv6. This might be used somewhere in the future. This is for ISPs deploying IPv6 only to the client and then to give them a small bit of IPv4 so they can atleast dual stack. It means all equipment between your CPE and the ISP is IPv6 only. Which is something that will happen in 2013+. See DS-Lite which so far the ISPs prefer better.
NAT-PT, NAPT-PT. You mean something like Carrier(Crummy) Grade Nat, or Large Scale(Sucky) NAT.
I feel for anyone that's going to see their internet connection end up like this, sharing a single IP with a few hundred customers and then wondering why the single IP block from the forum just took out a whole lot of customers. All the automatic blocking mechanisms we have today in forum software in the like will wreck havoc with this.
The FBI was complaining about not being ready to track IPv6, that's just silly, they should try and decode connections from such a large NAT and then try to find which of the few hundred users was it.
Please select a destination:
=> Forum rules
=> Messages from the pfSense Team
pfSense English Support
=> Installation and Upgrades
=> General Questions
=> 2.1 Snapshot Feedback and Problems
=> Post a bounty
===> Completed Bounties
===> Expired/Withdrawn Bounties
=> Routing and Multi WAN
=> Traffic Shaping
=> DHCP and DNS
=> PPPoE Server
=> Captive Portal
=> Virtualization installations and techniques
=> General Discussion
=> 1.2.3-PRERELEASE-TESTING snapshots - RETIRED
=> 1.2.1-RC Snapshot Feedback and Problems-RETIRED
=> 2.0-RC Snapshot Feedback and Problems - RETIRED
=> DNS Server testing area - RETIRED
Powered by SMF 1.1.18
SMF © 2013, Simple Machines
Page created in 0.027 seconds with 20 queries.