Say I have the following IPv6 prefix assigned to me by my ISP :

  • 2a01:1000:1000::/48 with 2a01:1000:1000::1/48 assigned to my VPN server.

I set up a VPN with a /64 from that block to assign to my VPN clients :

  • 2a01:1000:1000:FFFF::/64

Let's say all traffic (Internet included) is routed across my VPN gateway. What will be the source IPv6 address of the packet when exiting the VPN gateway and going to the server ? Will it be the VPN gateway's IPv6 (2a01:1000:1000::1), or will it use the client's VPN IPv6 (2a01:1000:1000:FFFF) ?

Taking the example of an IPSec VPN, will the Inner source IP in image 1. (when the packet from the client arrives on the VPN gateway) be used as the source IP in image 2. (when the VPN gateway sends to the server) ?


enter image description here


The source address on the IPv6 packet will be the address of the source host, and the destination IPv6 address will be the address of the destination host. This is the premise of IP.

NAT breaks this by translating either or both the source and destination address. NAT was created to extend the life of IPv4 at the expense of breaking the IP design and causing problems for many protocols. IPv6 has enough addresses to restore the original IP end-to-end paradigm. IPv6 doesn't have NAT so the original source and destination IPv6 addresses placed on the IPv6 packet by the source host are what reaches the destination host.

In addition to the VPN tunnel mode of IPv4, IPv6 has added a VPN packet mode, where the packet contents are encrypted. This allows end-to-end encryption without using a tunnel (encapsulation of the original packets inside tunnel packets).

  • What do you mean IPv6 does not have NAT ? It does have NAT, NAT66 and NPTv6. There is even an RFC that (begrudgingly) recognizes the need of NAT in IPv6 in specific setups (multihoming). In addition to that, in my example I said my ISP gave me a /48, but the truth is that I have a /128. So I am going to use ULA for my VPN and NAT66. – pHeoz Apr 17 '18 at 20:27
  • Actually, it doesn't. RFC 6296, IPv6-to-IPv6 Network Prefix Translation is EXPERIMENTAL, not STANDARDS TRACK: "This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation." – Ron Maupin Apr 17 '18 at 20:32
  • @pHeoz, if you read the RFC, you will see that NAT breaks many IPv6 features, and the experimental IPv6 NAT is only a one-to-one NAT, not NAPT, as is common with IPv4: "Since there is significant detriment caused by modifying transport layer headers and very little, if any, benefit to the use of port mapping in IPv6, NPTv6 Translators that comply with this specification MUST NOT perform port mapping." – Ron Maupin Apr 17 '18 at 20:38
  • /128 - seriously? How greedy is that? An ISP gets at least /32, so they want to have 80 octillion customers? That's gonna be at least half the Milky Way... – Zac67 Apr 17 '18 at 20:43
  • 1
    I have read RFC 6177 - and it never says an ISP MUST distribute /48, /56, or /64. It's only a 'strong recommendation'. So because of that, many ISPs will assign /128 to their customers because they can't be bothered, or whatever reason. – pHeoz Apr 17 '18 at 20:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.