NAT64 and 4rd

[kasperd]

I was wondering about the possible situation where somebody might want to deploy NAT64 for a small network, but due to shortage couldn't get an IPv4 address for the outer interface on the NAT.

One possible solution would be to use 4rd between the outer interface on the NAT and a 4rd gateway at the provider. Does anybody here know, if such a combination of NAT64 and 4rd has been done?

[wswartzendruber]

As best I can tell, 4RD hasn't been finalized yet.  There is RFC4925, but that is only a problem statement.

Regardless, 4RD and NAT64 will probably need to take place on the same device.

Perhaps 4in6 would be more suitable?

[kasperd]

As best I can tell, 4RD hasn't been finalized yet.

I believe you are right. But I assume there exist implementations of the current draft.

Regardless, 4RD and NAT64 will probably need to take place on the same device.

Not necessarily, but integrating the two was the idea I was asking about.

If they are kept separate there would be one level of NAT in the NAT64 and another level of NAT in the 4rd gateway, and then yet another stateless translation in the 4rd relay. By combining NAT64 with the 4rd gateway a level of NAT could be eliminated. But has anything like that been done?

Perhaps 4in6 would be more suitable?

4in6 doesn't specify any method for allocating a subset of port numbers to each customer. Being able to share a single IPv4 address among multiple customers with only stateless equipment at the ISP is the entire point of 4rd. The reversible packet translations between IPv4 and IPv6 that are used in 4rd do however look ridiculous to me. Since they don't appear to have any intention of actually use those for communicating with IPv6 hosts, I really think 4rd would have been simpler and cleaner if it had used 4in6 packet format instead.

[wswartzendruber]

I would imagine the NAT64 device would need both IPv6 and IPv4 access.  Otherwise, it wouldn't have enough to NAT between.

[kasperd]

I would imagine the NAT64 device would need both IPv6 and IPv4 access.

It doesn't need both protocols on both sides of the NAT. It needs IPv6 connectivity to the LAN and IPv4 connectivity to the Internet backbone, that's all. It does not need any connectivity to the IPv6 backbone. In the situations where you'd use NAT64, the LAN would run IPv6, and communication with the IPv6 backbone would not get anywhere near the NAT64 device.

And the connectivity from the NAT64 device to IPv6 LAN and IPv4 backbone does not have to be native, it could be a tunnel. That's why I was asking about 4rd, because it is a sort of tunnel that would make sense in some of those scenarios where you'd want to deploy NAT64. 4rd by design integrates tunnelling and NAT (though the tunnelling in 4rd looks more like a bad hack than a tunnel).

So if NAT64 and 4rd were kept separate such that communication from LAN to backbone goes through NAT64, another layer of NAT in the 4rd device, packet translation in the 4rd device, and another packet translation in the 4rd relay. By integrating the two, it would be possible to get rid of a layer of NAT such that there would be only one layer of NAT instead of two.

An integrated NAT64 and 4rd like I described would actually not need native IPv4 access on either side. IPv6 access would be sufficient, and if you wanted to, you could run both the LAN and WAN side of such a NAT device on a single network interface.

[wswartzendruber]

It needs IPv6 connectivity to the LAN and IPv4 connectivity to the Internet backbone, that's all.

I'm glad we were in agreement.   :)

By "access" I meant "address."  At home, I use fdbd:d93c:c8d5:ffff::/96 for NAT64, so that's not globally routable.  If I were running something like 4RD, I would imagine having a virtual interface with an IPv4 address, and that would be my "access" on the IPv4 side.

[kasperd]

By "access" I meant "address."  At home, I use fdbd:d93c:c8d5:ffff::/96 for NAT64, so that's not globally routable.

That could work, but is it any better than 64:ff9b::/96?

If I were running something like 4RD, I would imagine having a virtual interface with an IPv4 address, and that would be my "access" on the IPv4 side.

You couldn't do just that, because the point of 4rd is to split an IPv4 address among multiple users. If you just had a virtual interface with the public IPv4 address, which you are sharing, then the IPv4 stack would think it had that entire IPv4 address to itself.

You could still make NAT work if you carefully configured the NAT part to know which subset of the port numbers it is allowed to use. But that would still break in case two users of the same IPv4 address needed to communicate directly with each other.

I don't think a virtual interface with the public IPv4 address assigned to it, would work very well. Rather I think the NAT functionality and the 4rd functionality has to be integrated outside of the IPv4 stack. You'd still have a virtual interface, but it wouldn't be assigned the public IPv4 address. It would be an RFC1918 IPv4 address. And as IPv4 packets are sent to the virtual interface it does both NAT and 4rd before an IPv6 packet comes back from the virtual interface and is passed on to the IPv6 WAN.

Integrating NAT64 with 4rd would look pretty much the same except that the packets going in and out of the virtual interface would both be IPv6 packets, with some of them being for the LAN side and others being those hacky 4rd packets, which can be translated back into the original IPv4 packet.

[wswartzendruber]

By "access" I meant "address."  At home, I use fdbd:d93c:c8d5:ffff::/96 for NAT64, so that's not globally routable.

That could work, but is it any better than 64:ff9b::/96?

For me, the well-known prefix isn't an option.  It's against specification to map between that and an RFC1918 subnet, which is what I'm doing.

[kasperd]

By "access" I meant "address."  At home, I use fdbd:d93c:c8d5:ffff::/96 for NAT64, so that's not globally routable.

That could work, but is it any better than 64:ff9b::/96?

For me, the well-known prefix isn't an option.  It's against specification to map between that and an RFC1918 subnet, which is what I'm doing.

Using NAT64 with RFC1918 addresses sounds like a bad idea in the first place, regardless of which prefix it is done with. And avoiding NAT64 with RFC1918 addresses is exactly the reason why I was asking about the idea of integrating NAT64 with 4rd.

[wswartzendruber]

Why is it a bad idea?  All of my NAT64 traffic happens in the fc00::/7 block, and that's non-routable.

[kasperd]

Why is it a bad idea?  All of my NAT64 traffic happens in the fc00::/7 block, and that's non-routable.

You are mixing things up, I said it was a bad idea to use RFC1918 addresses for NAT64, since that introduces an extra layer of NAT. It is the extra layer of NAT, which is a problem, and that is unavoidable if you are using RFC1918 addresses.

[wswartzendruber]

...that introduces an extra layer of NAT.

Not for me, it doesn't!  ;D

With iptables you can NAT two subnets in parallel through a physical interface.  So 192.168.0.0/24 is for my LAN hosts, and 192.168.1.0/24 is for NAT64 mapping.

EDIT (in case it isn't clear):

WAN: eth0
LAN: eth1
NAT64: nat64

eth0 MASQUERADEs traffic from both nat64 and eth1.

Although I suppose you're probably stalking about stateless NAT, in which case I still don't have a choice because Comcast gives me one IP to work with.

[kasperd]

192.168.1.0/24 is for NAT64 mapping.

You cannot use that to communicate with any servers, so you are going to need another layer of NAT.

I suppose you're probably stalking about stateless NAT

No. There is not much useful you can do with stateless NAT, and neither of the NATs in question can be stateless.

Comcast gives me one IP to work with.

Using that IP for NAT64 would give you the least problems.

[wswartzendruber]

192.168.1.0/24 is for NAT64 mapping.

You cannot use that to communicate with any servers, so you are going to need another layer of NAT.

I suppose you're probably stalking about stateless NAT

No. There is not much useful you can do with stateless NAT, and neither of the NATs in question can be stateless.

Comcast gives me one IP to work with.

Using that IP for NAT64 would give you the least problems.

Tayga is a stateless NAT64 implementation.  All it does is translate between a specified IPv6 range and a specified IPv4 range.  When it needs to do translation, it will dynamically map an IPv4 address to an IPv6 one for about two hours.  Or you can statically define your own mappings in tayga.conf.  Tayga will create a new virtual interface inside the Linux kernel who's sole job is to perform the address translation.  So you setup your kernel routing table to send your previously defined IPv4 and IPv6 ranges to it.  They call this a stateless NAT64 implementation because there is always one and only one IPv6 address mapped to any IPv4 address at any given time.

If you need stateful NAT64, which most people will, you can tell iptables to map between the virtual NAT64 interface and your physical WAN interface.  So that results in one layer of stateless NAT and one layer of stateful NAT.

I don't understand your comment about not being able to communicate with servers.

Also, I don't appear to be having any problems NAT'ing my LAN and NAT64 ranges together at once.

[kasperd]

When it needs to do translation, it will dynamically map an IPv4 address to an IPv6 one for about two hours.

That makes it stateful.

They call this a stateless NAT64 implementation because there is always one and only one IPv6 address mapped to any IPv4 address at any given time.

That means you'll need as many IPv4 addresses as you have IPv6 addresses communicating through the NAT.

If you need stateful NAT64, which most people will, you can tell iptables to map between the virtual NAT64 interface and your physical WAN interface.  So that results in one layer of stateless NAT and one layer of stateful NAT.

No, you have two layers of stateful NAT.

According to your description, Tayga can avoid connection tracking, but it is still stateful. And the way they avoid connection tracking actually force you to have another layer of NAT, which has to do connection tracking anyway.

If you lose state on either of those levels of NAT, you lose all connections. If you are running both levels of NAT on the same host, then that may not be a problem.

Avoiding connection tracking is not a bad thing, and the code of Tagya is probably a lot smaller due to that fact. In that regard it is a sensible design decision. If the goal was to reuse existing connection tracking available in conventional IPv4 NAT implementations, then the design sounds right. It's not because existing connection tracking implementations are great, but if the alternative was something quickly hacked together for just Tagya, then even a mediocre connection tracking implementation may be better.

A proper implementation of NAT64 that does its own connection tracking would still be better, but also a lot more work to implement.

I don't understand your comment about not being able to communicate with servers.

If you use an RFC1918 address as source address when trying to communicate with a server on the Internet, it is not going to work. Most likely the packet will be dropped before reaching the server, due to the source address. Even if the packet made it there, any reply would never make it back.