Sometimes I have doubts.
-
Sometimes I have doubts. I thought Jordi knows what he is talking about.
https://mailarchive.ietf.org/arch/msg/v6ops/41ymS9wyC2V_hODUfnrB_E-v-AQ/
...ipv4only.arpa... In my opinion in general is not being implemented in networks. Not confirmed if implemented in hosts and what happens if hosts or the network don’t properly implement it. I tend to think, based on experience....Of course RFC 9872 exists. To deprecate RFC 7050 is justified in long term. But to state, that RFC 7050 isn't used is
-
Sometimes I have doubts. I thought Jordi knows what he is talking about.
https://mailarchive.ietf.org/arch/msg/v6ops/41ymS9wyC2V_hODUfnrB_E-v-AQ/
...ipv4only.arpa... In my opinion in general is not being implemented in networks. Not confirmed if implemented in hosts and what happens if hosts or the network don’t properly implement it. I tend to think, based on experience....Of course RFC 9872 exists. To deprecate RFC 7050 is justified in long term. But to state, that RFC 7050 isn't used is
@tschaefer implemented by Free Mobile and by des.services
-
@tschaefer implemented by Free Mobile and by des.services
Unfortunately I had not subscribed the mailing list, since it was to much traffic in the past for me.
His original question is here
[v6ops] actual deployment of RFC7050/RFC8880 "experiment"
Search IETF mail list archives
(mailarchive.ietf.org)
He repeated it also via the ipv6wg list at ripe.
"means *having ipv4only.arpa zone* available in the resolvers of the operators."
I don't know if he knows how DNS64 works. There is no special treatment needed.
-
Unfortunately I had not subscribed the mailing list, since it was to much traffic in the past for me.
His original question is here
[v6ops] actual deployment of RFC7050/RFC8880 "experiment"
Search IETF mail list archives
(mailarchive.ietf.org)
He repeated it also via the ipv6wg list at ripe.
"means *having ipv4only.arpa zone* available in the resolvers of the operators."
I don't know if he knows how DNS64 works. There is no special treatment needed.
Yeah, ipv4only.arpa exists on authoritative DNS servers and is served essentially like a name would have been served from any other TLD. As far as I recall there is an RFC recommending that DNS recursors hard-code that particular name in order to not need depend on authoritative DNS for that name. But last I checked BIND 9 would query authoritative servers for the name.
DNS64 can work just fine without special casing ipv4only.arpa. It can just translate it like any other IPv4-only domain name, and clients can use that for discovery.
I can definitely confirm that Android supports ipv4only.arpa for NAT64 discovery by default. It might support other methods as well, and I haven't verified which order it will try the methods on a network that supports different methods. None of the NAT64 deployments I have personally encountered used the well-known prefix. So I think falling back to the well-known prefix isn't a great option.
As an operator of public NAT64 gateways I will say that using ipv4only.arpa for NAT64 discovery is not perfect, but all the alternatives I have seen are worse. An inherent drawback of ipv4only.arpa is that it cannot handle scenarios where different NAT64 prefixes are being used depending on IPv4 range. That part is supported when DNS64 is being used.
Another drawback is more of an implementation shortcoming. 464-xlat implementations usually don't support use of multiple NAT64 prefixes for redundancy and will rather just pick one and stick with it. And it's not guaranteed that a client will pick up changes of prefix in a timely fashion.
So if a NAT64 gateway goes down for maintenance it may be necessary for 464-xlat users to disconnect and reconnect in order to switch to a different prefix. Use of PREF64 is worse for that use case. Users actually have to change their router configuration in order to apply the changes. There appears to exist no standardized mechanism for a public NAT64 service to communicate prefix changes to routers of users.
In theory a router could make use of ipv4only.arpa to do NAT64 prefix discovery and communicate this downstream using PREF64. But I haven't heard of any implementation doing this, and I don't see any advantage of this over the client doing discovery directly using ipv4only.arpa.
-
R relay@relay.infosec.exchange shared this topic
-
Yeah, ipv4only.arpa exists on authoritative DNS servers and is served essentially like a name would have been served from any other TLD. As far as I recall there is an RFC recommending that DNS recursors hard-code that particular name in order to not need depend on authoritative DNS for that name. But last I checked BIND 9 would query authoritative servers for the name.
DNS64 can work just fine without special casing ipv4only.arpa. It can just translate it like any other IPv4-only domain name, and clients can use that for discovery.
I can definitely confirm that Android supports ipv4only.arpa for NAT64 discovery by default. It might support other methods as well, and I haven't verified which order it will try the methods on a network that supports different methods. None of the NAT64 deployments I have personally encountered used the well-known prefix. So I think falling back to the well-known prefix isn't a great option.
As an operator of public NAT64 gateways I will say that using ipv4only.arpa for NAT64 discovery is not perfect, but all the alternatives I have seen are worse. An inherent drawback of ipv4only.arpa is that it cannot handle scenarios where different NAT64 prefixes are being used depending on IPv4 range. That part is supported when DNS64 is being used.
Another drawback is more of an implementation shortcoming. 464-xlat implementations usually don't support use of multiple NAT64 prefixes for redundancy and will rather just pick one and stick with it. And it's not guaranteed that a client will pick up changes of prefix in a timely fashion.
So if a NAT64 gateway goes down for maintenance it may be necessary for 464-xlat users to disconnect and reconnect in order to switch to a different prefix. Use of PREF64 is worse for that use case. Users actually have to change their router configuration in order to apply the changes. There appears to exist no standardized mechanism for a public NAT64 service to communicate prefix changes to routers of users.
In theory a router could make use of ipv4only.arpa to do NAT64 prefix discovery and communicate this downstream using PREF64. But I haven't heard of any implementation doing this, and I don't see any advantage of this over the client doing discovery directly using ipv4only.arpa.
Could you please send this observation to the mailinglist?
-
Yeah, ipv4only.arpa exists on authoritative DNS servers and is served essentially like a name would have been served from any other TLD. As far as I recall there is an RFC recommending that DNS recursors hard-code that particular name in order to not need depend on authoritative DNS for that name. But last I checked BIND 9 would query authoritative servers for the name.
DNS64 can work just fine without special casing ipv4only.arpa. It can just translate it like any other IPv4-only domain name, and clients can use that for discovery.
I can definitely confirm that Android supports ipv4only.arpa for NAT64 discovery by default. It might support other methods as well, and I haven't verified which order it will try the methods on a network that supports different methods. None of the NAT64 deployments I have personally encountered used the well-known prefix. So I think falling back to the well-known prefix isn't a great option.
As an operator of public NAT64 gateways I will say that using ipv4only.arpa for NAT64 discovery is not perfect, but all the alternatives I have seen are worse. An inherent drawback of ipv4only.arpa is that it cannot handle scenarios where different NAT64 prefixes are being used depending on IPv4 range. That part is supported when DNS64 is being used.
Another drawback is more of an implementation shortcoming. 464-xlat implementations usually don't support use of multiple NAT64 prefixes for redundancy and will rather just pick one and stick with it. And it's not guaranteed that a client will pick up changes of prefix in a timely fashion.
So if a NAT64 gateway goes down for maintenance it may be necessary for 464-xlat users to disconnect and reconnect in order to switch to a different prefix. Use of PREF64 is worse for that use case. Users actually have to change their router configuration in order to apply the changes. There appears to exist no standardized mechanism for a public NAT64 service to communicate prefix changes to routers of users.
In theory a router could make use of ipv4only.arpa to do NAT64 prefix discovery and communicate this downstream using PREF64. But I haven't heard of any implementation doing this, and I don't see any advantage of this over the client doing discovery directly using ipv4only.arpa.
Thanks.
But about the maintenance/disruption of NAT64 GW service: I would expect a rerouting or useful failover on the network/server side, never a change of the prefix! It would need to be changed by DNS64 too. -
The other problem of using more than one clat interface is a rare edge case in my opinion.
Even my smartphone switches well from IPv6 only mobile network to IPv6 only WiFi and vice versa.
Only the windows preview doesn't refresh CLAT when changing from one IPv6 only network to another.
But the windows preview isn't suitable for everyday use anyway yet. -
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
