cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2448
Views
0
Helpful
3
Replies
Highlighted
Beginner

IPv6 translation approach NAT64

Hi,

Please help me to understand if in a network scenario where AAAA records and A records in registered in public DNS . So in this scenario whether DNS64 along with NAT64 needs to used for IPv6 translation approach or enabling only NAT64 feature on perimeter gateway by configuring static IPv6 to IPv4 address should work ?

When configuring NAT64 whether global IPv6 address needs to be mapped with Public IPv4 address or private IPv4 address of a particular web-application to achieve successful IPv6 client to IPv4 network communication.

Regards,
dhaval

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Enthusiast

DNS64+NAT64 is a solution to the problem of a v6-only client trying to reach a legacy v4-only server.  The v6 client queries for a AAAA record, the only kind it can use, but there is none.  The DNS64 server notices there is however an A record for the server and synthesizes an AAAA lie encoding it.  When the v6 connection request hits the border, the native traffic is passed directly, and the DNS64 lies (which use a different prefix) are diverted to the NAT64 translator, which proxies a v4 connection to the actual server.  If you are trying to reach public IPv4 resources, then the NAT64 translator needs a pool of public IPv4 addresses and v4 routing to do it with.

Note that v4 client to v6 server scenario founders on the impossibility of caching DNS46 entries at ISP scale; there isn't enough v4 address space to get the lifetimes right.  The solution to that is dual-stacking the clients and using native v6 traffic to v6-only services, where are currently very rare.

DMZ servers need to be dual stack at this point, since there is a large legacy v4-only internet of clients, but also a lot of mobile clients which are on v6-only LTE4 cell networks.  The v6 clients have a bad experience if they have to go through at NAT64 translator instead of directly.

Note that because clients have a lot of legacy v4-only applications at present, that a current favorite gimmick is 464xlat, where the client with v6-only transport gets two v6 prefixes, one for native traffic, and one for tunneling a private v4 address to the NAT64 proxy.  The network and client OS have to support this, but the applications don't have to be aware of it if they use simple TCP connections.

In the DNS64+NAT64 scenario, the client might register an AAAA address in DNS, the DNS64 service might register both A and AAAA, and the NAT64 gateway might register both A and AAAA.

Did that help?

-- Jim Leinweber, WI State Lab of Hygiene

View solution in original post

3 REPLIES 3
Highlighted
Enthusiast

DNS64+NAT64 is a solution to the problem of a v6-only client trying to reach a legacy v4-only server.  The v6 client queries for a AAAA record, the only kind it can use, but there is none.  The DNS64 server notices there is however an A record for the server and synthesizes an AAAA lie encoding it.  When the v6 connection request hits the border, the native traffic is passed directly, and the DNS64 lies (which use a different prefix) are diverted to the NAT64 translator, which proxies a v4 connection to the actual server.  If you are trying to reach public IPv4 resources, then the NAT64 translator needs a pool of public IPv4 addresses and v4 routing to do it with.

Note that v4 client to v6 server scenario founders on the impossibility of caching DNS46 entries at ISP scale; there isn't enough v4 address space to get the lifetimes right.  The solution to that is dual-stacking the clients and using native v6 traffic to v6-only services, where are currently very rare.

DMZ servers need to be dual stack at this point, since there is a large legacy v4-only internet of clients, but also a lot of mobile clients which are on v6-only LTE4 cell networks.  The v6 clients have a bad experience if they have to go through at NAT64 translator instead of directly.

Note that because clients have a lot of legacy v4-only applications at present, that a current favorite gimmick is 464xlat, where the client with v6-only transport gets two v6 prefixes, one for native traffic, and one for tunneling a private v4 address to the NAT64 proxy.  The network and client OS have to support this, but the applications don't have to be aware of it if they use simple TCP connections.

In the DNS64+NAT64 scenario, the client might register an AAAA address in DNS, the DNS64 service might register both A and AAAA, and the NAT64 gateway might register both A and AAAA.

Did that help?

-- Jim Leinweber, WI State Lab of Hygiene

View solution in original post

Highlighted

Hi Jim,

Thanks for the useful information .

With reference to above information . If suppose i have AAAA records for applications registered in Public DNS so in this case the traffic from IPv6 client trying to access legacy applications running on IPv4 address . The request from client with IPv6 address goes to DNS where DNS resolves FQDN with AAAA records and returns AAAA IPv6 address details to client . IPv6 Global unicast address is routed to NAT64 translator where the IPv6 address is statically mapped to IPv4 address of  applications .

Is the above scenario understood by me correctly ? is this the pattern how NAT64 enabled device should work ?

Regards,

Dhaval 

Highlighted

If you have AAAA records published in DNS for an application, v4-only clients won't query it and will ignore you, while dual-stack and v6-only clients will make direct IPv6 connections.  Which is why your services at this point should be migrating to dual-stack, at least at your border, and publishing both v4 A records and v6 AAAA records in DNS.   The dual-stack thing at the border could be a load-balancer, for example, which might make v4-only connections back into a legacy server farm, but the clients won't care about that.  The load balancer is not really doing DNS64/NAT64 in this case.

NAT64/DNS64 translators are network middleware boxes, which the v6-only clients and v4-only servers are unaware of.  The server is only publishing a v4 A record in DNS, the client has only v6 transport.  The DNS64 box synthesizes a fake AAAA record which encodes information about a routing prefix which will hit the NAT64 box, the v6-client host part, and the v4 address of the server. In order to make it all fit, either the DNS64 box has to inform the NAT64 box about the v6 client address (dynamic mappings case), or it has to be ISP-specific with large v6 prefixes (say, /20) so that there is room to encode the ISP prefix (say, 20 bits), some subnet info for the client (say, 12 bits), the v4 address of the server (32 bits), and the v6 host part of the client (64 bits) for a stateless mapping.  This is only possible because v4 addresses are so much smaller than v6 addresses.