Sometimes I have doubts.
-
I assume you never operated a public NAT64 service. There are networks between the NAT64 gateway and the client which are completely outside of my control. But I can achieve high availability by running multiple NAT64 gateways in independent locations.
I have health checks of the gateways which automatically updates DNS64 accordingly. And I give clients addresses using multiple prefixes to allow for client-side failover. Client-side failover is crucial as sometimes individual clients are unable to reach specific gateways for reasons that are on networks that I don't use myself and thus outside the visibility of my health checks.
A client with a good implementation of fallback between AAAA records works great in this scenario. 464-xlat doesn't handle this as well.
-
Could you please send this observation to the mailinglist?
I have done so in the past, but their mailing list software is not letting my mails through.
-
I assume you never operated a public NAT64 service. There are networks between the NAT64 gateway and the client which are completely outside of my control. But I can achieve high availability by running multiple NAT64 gateways in independent locations.
I have health checks of the gateways which automatically updates DNS64 accordingly. And I give clients addresses using multiple prefixes to allow for client-side failover. Client-side failover is crucial as sometimes individual clients are unable to reach specific gateways for reasons that are on networks that I don't use myself and thus outside the visibility of my health checks.
A client with a good implementation of fallback between AAAA records works great in this scenario. 464-xlat doesn't handle this as well.
You are right. I never operated public NAT64 services. (and I don't use yours, because they weren't not reliable for me in the past - sorry to say that).
But beside the fact of your engagement - from the Telekom (the gateway I use all the time, not public) I don't expect changing prefixes, I expect more or less good monitored reliability.
-
You are right. I never operated public NAT64 services. (and I don't use yours, because they weren't not reliable for me in the past - sorry to say that).
But beside the fact of your engagement - from the Telekom (the gateway I use all the time, not public) I don't expect changing prefixes, I expect more or less good monitored reliability.
My employers network has also only one gateway as far as i know. (of course he maintains it, but probably the interrupts are so short, nobody notices it)
-
My employers network has also only one gateway as far as i know. (of course he maintains it, but probably the interrupts are so short, nobody notices it)
To introduce more complexity at client side is not the right way, I think.
Anyway, It is a transition technology - not planned to stay for ever.
-
To introduce more complexity at client side is not the right way, I think.
Anyway, It is a transition technology - not planned to stay for ever.
Client side failover is a necessity if you want reliability. Even when IPv4 is long gone, I predict the failover code is here to stay. The failover code may even get a little bit more sophisticated.
If we want to minimize client side complexity during the transition, then DNS64 is the way to go. Dual-stack and 464xlat both add complexity on the client side, which you can avoid when using DNS64.
I agree transition technologies should not stay forever. Had people been upgrading in due time, we would never have needed DNS64 and NAT64 in the first place.
-
Client side failover is a necessity if you want reliability. Even when IPv4 is long gone, I predict the failover code is here to stay. The failover code may even get a little bit more sophisticated.
If we want to minimize client side complexity during the transition, then DNS64 is the way to go. Dual-stack and 464xlat both add complexity on the client side, which you can avoid when using DNS64.
I agree transition technologies should not stay forever. Had people been upgrading in due time, we would never have needed DNS64 and NAT64 in the first place.
But at your DNS64 servers it is unnecessarily complex. They provide three different NAT64 prefixes.
No CLAT implementation can switch between three instances simultaneously. Android's CLAT is quite mature.
Client failover isn't there - for 12 years. -
But at your DNS64 servers it is unnecessarily complex. They provide three different NAT64 prefixes.
No CLAT implementation can switch between three instances simultaneously. Android's CLAT is quite mature.
Client failover isn't there - for 12 years.The NAT64 GW has to be good. Just a similar example:
cgn - it has also no second chance at the client. It works or it doesn't work. -
The NAT64 GW has to be good. Just a similar example:
cgn - it has also no second chance at the client. It works or it doesn't work.That just supports the point I am making. Use of DNS64+NAT64 can achieve some benefits that are hard to achieve with 464-XLAT and close to impossible with an IPv4-only CGN.
The added complexity on the DNS64 servers is minor. And if that means end-users can have a simpler setup on their network, I think it's a good trade-off.
I have considered implementing a 464-XLAT that can utilize redundant NAT64 gateways. But so far I haven't had time for that.
-
I have done so in the past, but their mailing list software is not letting my mails through.
@kasperd @tschaefer @camille IETF ?
-
Yes. I received an automated response stating:
Your mail to 'v6ops' with the subject Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-only-resolver-00.txt Is being held until the list moderator can review it for approval. -
That just supports the point I am making. Use of DNS64+NAT64 can achieve some benefits that are hard to achieve with 464-XLAT and close to impossible with an IPv4-only CGN.
The added complexity on the DNS64 servers is minor. And if that means end-users can have a simpler setup on their network, I think it's a good trade-off.
I have considered implementing a 464-XLAT that can utilize redundant NAT64 gateways. But so far I haven't had time for that.
@kasperd @tschaefer
Regarding Implementation of ipv4only.arpa on DNS64 resolvers.
From RFC 8880
"All DNS64 recursive resolvers MUST recognize 'ipv4only.arpa' (and all of its subdomains) as special, and they MUST NOT attempt to look up NS records for 'ipv4only.arpa' or otherwise query authoritative name servers in an attempt to resolve this name. Instead, DNS64 recursive resolvers MUST act as authoritative for this zone, by generating immediate responses for all -
@kasperd @tschaefer
Regarding Implementation of ipv4only.arpa on DNS64 resolvers.
From RFC 8880
"All DNS64 recursive resolvers MUST recognize 'ipv4only.arpa' (and all of its subdomains) as special, and they MUST NOT attempt to look up NS records for 'ipv4only.arpa' or otherwise query authoritative name servers in an attempt to resolve this name. Instead, DNS64 recursive resolvers MUST act as authoritative for this zone, by generating immediate responses for allqueries for 'ipv4only.arpa' (and any subdomain of 'ipv4only.arpa'),
"
@tschaefer @kasperd -
queries for 'ipv4only.arpa' (and any subdomain of 'ipv4only.arpa'),
"
@tschaefer @kasperdI have seen some inconsistent behavior of BIND9 in that regard. However I am done filing bug reports about that software.
-
R relay@relay.infosec.exchange shared this topic
