Hi Warren,
I agree this is needed, as RFC7050 is widely implemented, even in the case of RFC8305 for allowing a somehow “equivalent” functionality as the CLAT for literal addresses. For the same reasons this document mention, in draft-ietf-v6ops-nat64-deployment, I have: The learning of the IPv6 prefix could be solved by means of adding the relevant AAAA records to the ipv4only.arpa. zone of the service provider recursive servers, i.e., if using the WKP (64:ff9b::/96): ipv4only.arpa. SOA . . 0 0 0 0 0 ipv4only.arpa. NS . ipv4only.arpa. AAAA 64:ff9b::192.0.0.170 ipv4only.arpa. AAAA 64:ff9b::192.0.0.171 ipv4only.arpa. A 192.0.0.170 ipv4only.arpa. A 192.0.0.171 and: 8. IANA Considerations This document does not have any new specific IANA considerations. Note: This section is assuming that https://www.rfc-editor.org/errata/eid5152 is resolved, otherwise, this section may include the required text to resolve the issue. So I support this. I wonder if we should ask DNSOP WG to reconsider this as a WG document and proceed the normal way. Regards, Jordi De: DNSOP <dnsop-boun...@ietf.org> en nombre de Warren Kumari <war...@kumari.net> Fecha: miércoles, 4 de julio de 2018, 22:27 Para: dnsop <dnsop@ietf.org> Asunto: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa Dear DNSOP, Stuart Cheshire & David Schinazi have asked me to AD sponsor the draft-cheshire-sudn-ipv4only-dot-arpa document [0] .. >From the document: "The specification for how a client discovers its network's NAT64 prefix [RFC7050] defines the special name 'ipv4only.arpa' for this purpose, but declares it to be a non-special name in that specification Domain Name Reservation Considerations section. Consequently, despite the well articulated special purpose of the name, 'ipv4only.arpa' was not recorded in the Special-Use Domain Names registry as a name with special properties. This document formally declares the actual special properties of the name, and adds similar declarations for the corresponding reverse mapping names." RFC7050 ("Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis") is worth reading before reading this. If you are mainly a DNS person, this may be...surprising. When reading draft-cheshire-sudn-ipv4only-dot-arpa there are a few things worth keeping in mind: 1: This is a fairly specialized function - it is used by NAT64 clients to discover the prefix used for synthesis ("normal" people / applications never need to resolve this). The main people who will deal with this are mobile / stack vendors, and NAT64 providers. 2: RFC7050 has a large amount of text around DNSSEC, what to do with DNSSEC, etc. Note that this DNSSEC is for the FQDN of the *NAT64 device*, not the ipv4only.arpa name. 3: Devices use this mechanism to discover the IPv6 prefix used for IPv6 address synthesis - different interfaces (e.g cellular and wifi) will have different prefixes. This means that clients must do this query using the resolver learned on / appropriate for that interface. This is the main bit which is weird for a DNS person - the response from the resolver for your cellular interface connected to T-Mobile contains T-Mobile's NAT64 prefix; the response from the resolver learnt over your wifi connection to the IETF network contains the NAT64 prefix you use on the IETF network. DNS isn't really being used here for resolving names, rather DNS is being used a signalling mechanism (a rude t-shirt springs to mind here). What this draft does is: 1: record this in the SUDN registry; RFC7050 answered the RFC6761 questions, but didn't actually ask the IANA to update the registry. 2: requests that the IANA make ipv4only.arpa be an insecure delegation (see #2 above) - this removes some special handling and complexity. 3: specifies that you have to use the resolvers learn on an interface for these queries. The whole purpose of these queries is to learn the *local* NAT64 prefix - asking a public recursive isn't going to help you here. 4: This is under .arpa (and is already in wide use) - it doesn't have the sticky policy problems that many SUD names have. I've agreed to AD sponsor this, but would really appreciate your review and input. RFC7050 is deployed - this improves / clarifies things. 1: The authors have previously presented this document at DNSOP meetings - there was some discussion, but no real interest in adopting or shouts of outrage about it. 2: I've asked the DNSOP chairs if I can use the DNSOP list for discussion of this (and they agreed) 3: This was originally a product of the (now closed) BEHAVE WG - I've spoken with Spencer (the BEHAVE AD) who has no objections. 4: I've asked the IESG and there were no objections either. 5: As this touches .arpa I'm also asking the IAB for input. 6: Dave Thaler (who was the document shepherd for RFC7050) has kindly agreed to be shepherd for this document too. W [0]: note that they asked this before the current "ipv4only.arpa's delegation should be insecure." thread - https://mailarchive.ietf.org/arch/msg/dnsop/zbcQhok-dCE8kh6C6KofBL1tAXY -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
