Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt

[Martin Huněk <[e-mail]>]

Yes, I suppose so. However it is not actually change in respect to RFC7050. It 
also expects network has NAT64 deployed by checking ipv4olny.arpa.

But I guess that I should explicitly wrote there what should happen in case 
there is only NAT64 SRV pointing to the ".". In this case the NAT64 is not 
present, so end node should not to continue with NAT64 detection (even by 
means of RFC7050).

Idea is that it should track those changes by itself. Basically, your DNS stub 
or recursive resolver tries after the boot/connection detect NAT64 at your 
upstream (by detecting local domain and asking for SRV for 
_nat64._ipv6.<domain>). So from your example:

1) When having only HE tunnel, your ISP would not provide you with NAT64 
service either. It would also be irrelevant as you have IPv4.
2) After you have got native IPv6, your ISP can provide you with NAT64. Your 
router with DNS resolver can detect it via SRV record and use upstream DNS64 
or do DNS64 itself based upon detected prefix.
3) When the upstream NAT64 prefix changes, your resolver would eventually 
discovers that because TTL of SRV record.
4) When you would prefer to run NAT64 locally then you would set up also DNS64 
and make your computers to use it.

If you want the DoH to work with NAT64, you would need to have an actual 
domain and have NAT64 SRV record pointing to your prefix. This is not a 
problem in the network of a larger organization, but it would not 
unfortunately solve DoH vs DNS64 problem for small residential networks after 
CPE. I've just realized it while replying to you. But at least it solves that 
for those with domain. Maybe it could also work with some service like DynDNS 
but with SRV, I would have to think about that little more.

Martin


Dne úterý 12. března 2019 2:00:42 CET, Fred Baker napsal(a):
> Chair hat off.
> 
> The biggest concern or question that I have in this is that it appears that
> networks now have an *expectation* that there is a NAT64 and a DNS64
> somewhere in the network, which to my knowledge is only a reasonable
> expectation during the transition period. To put that in context, I at one
> time used an HE tunnel to provide IPv6 service in my home, and then my
> upstream (which was first Cisco and later Cox) provided that service. So I
> *could* have had a NAT64 in my home, and then the service moved to whoever
> was upstream of me. Over time, One could imagine the service moving again.
> If I were maintaining my DNS service, they would have to track that
> changing landscape, which I could imagine becoming a headache.
> 
> So the intent of the draft makes sense to me. I find myself wondering about
> the operational implications. Maybe you can fill me in?
> > On Mar 11, 2019, at 6:35 PM, Martin Hunek <[e-mail]> wrote:
> > 
> > Signed PGP part
> > Hi,
> > 
> > I suppose it hasn't been. I'm actually new in this, so I'm sorry if I
> > caused any confusion. I haven't found any best practice for submission,
> > so I thought it would be the best to make submission first and discuss
> > and make changes afterwards.
> > 
> > Best Regards,
> > Martin
> > 
> > Dne pondělí 11. března 2019 10:19:51 CET, Jordi Palet Martinez napsal(a):
> >> Confused with this doc. Don’t recall having seen it before and then, when
> >> it was accepted as WG item ?
> >> 
> >> Note: Not meaning to disregard the document contents here.
> >> 
> >> Regards,
> >> Jordi
> >> 
> >>> El 11 mar 2019, a las 9:57, [e-mail] escribió:
> >>> 
> >>> 
> >>> A New Internet-Draft is available from the on-line Internet-Drafts
> >>> directories. This draft is a work item of the IPv6 Operations WG of the
> >>> IETF.
> >>> 
> >>>       Title           : NAT64/DNS64 detection via SRV Records
> >>>       Author          : Martin Hunek
> >>>   
> >>>   Filename        : draft-ietf-v6ops-nat64-srv-00.txt
> >>>   Pages           : 8
> >>>   Date            : 2019-03-11
> >>> 
> >>> Abstract:
> >>>  This document specifies the way of discovering the NAT64 pools in
> >>>  use as well as DNS servers providing DNS64 service to the local
> >>>  clients. The discovery is done via SRV records, which also allows
> >>>  asignment of priorities to the NAT64 pools as well as DNS64 servers.
> >>>  It also allows clients to have diferent DNS providers than NAT64
> >>>  provider, while providing a secure way via DNSSEC validation of
> >>>  provided SRV records. This way, it provides DNS64 service even in
> >>>  case where DNS over HTTPS is used.
> >>> 
> >>> The IETF datatracker status page for this draft is:
> >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-srv/
> >>> 
> >>> There are also htmlized versions available at:
> >>> https://tools.ietf.org/html/draft-ietf-v6ops-nat64-srv-00
> >>> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-srv-00
> >>> 
> >>> 
> >>> Please note that it may take a couple of minutes from the time of
> >>> submission until the htmlized version and diff are available at
> >>> tools.ietf.org.
> >>> 
> >>> Internet-Drafts are also available by anonymous FTP at:
> >>> ftp://ftp.ietf.org/internet-drafts/
> >>> 
> >>> _______________________________________________
> >>> v6ops mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/v6ops
> >> 
> >> **********************************************
> >> IPv4 is over
> >> Are you ready for the new Internet ?
> >> http://www.theipv6company.com
> >> 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.
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> v6ops mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/v6ops
> 
> ----------------------------------------------------------------------------
> ---- The fact that there is a highway to hell and a stairway to heaven is an
> interesting comment on projected traffic volume...