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

From: [email-masked]
Date: Mon, 11 Mar 2019 01:57:52 -0700

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/

---

From: Jordi Palet Martinez <[email-masked]>
Date: Mon, 11 Mar 2019 10:19:51 +0100

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, [email-masked] escribió:
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> 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.

---

From: Martin Hunek <[email-masked]>
Date: Mon, 11 Mar 2019 10:35:13 +0100

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

---

From: Lee Howard <[email-masked]>
Date: Mon, 11 Mar 2019 11:37:44 -0400

> 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 fi…

On behalf of myself only, don't worry about it.

There's a naming convention that is poorly described at 
https://www.ietf.org/standards/ids/guidelines/  (Section 7).

When first submitting a draft, name it draft-lastname-wg-topic.

Once the draft is adopted, the chairs will tell you to name it 
draft-ietf-wg-topic.

Comment on the draft:

If I understand correctly, your idea is for the home gateway (e.g.) to 
search the DNS Search List for SRV records indicating the presence of a 
NAT64.  Then it should synthesize the DNS64 record, or if it can't, use 
the ipv4only.arpa trick in rfc7050.

I think it would work, but I'm not generally in favor of giving more 
support to people who won't provide forward compatibility. I'd need to 
think about it more.

Lee

---

From: Martin Hunek <[email-masked]>
Date: Mon, 11 Mar 2019 18:20:21 +0100

Hi, Lee see a reply inline.

> Once the draft is adopted, the chairs will tell you to name it 
Thank you for clarification, I've missed it.
> the ipv4only.arpa trick in rfc7050.

Yes, it is the general idea. Think is that not every end user uses DNS servers of its ISP (quad8, quad9, and so on). But doing so, they would lost DNS64 functionality so they would not have NAT64 available as well. Until now, it was negligible, however with DNS over HTTPS, it might get more pressing (as DoH operator is generally third party). In this case, the RFC7050 trick would not work.

DNS64 SRV record would be used if the end node won't be able to actually do DNS64 itself. If it can, then it might just point to NAT64 prefix from corresponding SRV record. If it cannot, than it should use server from DNS64 SRV record when it receives NODATA on AAAA query via usual channel.

With DNS64 SRV record I am actually strugling if it should be mandatory or optional. If I would only like to cover detection of NAT64 prefix for case of DNSSEC validation, then it is not needed. But on the other hand, if I would like it to cover cases in which you would have only stub resolver without ability of DNS64, then the DNS64 SRV would be quite handy.
> support to people who won't provide forward compatibility. I'd need to 

Can you elaborate on "people who won't provide forward compatibility"? I'm not sure what do you mean by that.

Martin

---

From: Lee Howard <[email-masked]>
Date: Mon, 11 Mar 2019 13:50:53 -0400

> Yes, it is the general idea. Think is that not every end user uses DNS servers of its ISP (quad8, quad9, and so on). But doing so, they would lost DNS64 functionality so they would not have NAT64 a…
Yes, people who use DoH have decided that they don't need to reach the 
tens of millions of people using DNS64.
> With DNS64 SRV record I am actually strugling if it should be mandatory or optional. If I would only like to cover detection of NAT64 prefix for case of DNSSEC validation, then it is not needed. Bu…
I don't know how you can make it mandatory. Who's going to enforce the rule?
> Can you elaborate on "people who won't provide forward compatibility"? I'm not sure what do you mean by that.

I mean that people on IPv4-only are not compatible with IPv6, which 
everyone knows is the protocol going forward.

I will also say that people who deploy DoH are knowingly losing 
connectivity. I refer to the first paragraph of Section 10 "Operational 
Considerations" of the DoH RFC, rfc8484:

    Local policy considerations and similar factors mean different DNS
    servers may provide different results to the same query, for
    instance, in split DNS configurations [RFC6950].  It logically
    follows that the server that is queried can influence the end result.
    Therefore, a client's choice of DNS server may affect the responses
    it gets to its queries.  For example, in the case of DNS64 [RFC6147],
    the choice could affect whether IPv6/IPv4 translation will work at
    all.

Lee

---

From: Martin Hunek <[email-masked]>
Date: Mon, 11 Mar 2019 19:23:06 +0100

> tens of millions of people using DNS64.
It really depends, who would actually choose to use it. When web browser vendor chooses to prefer DoH, the end user would be the one without working NAT64/DNS64.
> I don't know how you can make it mandatory. Who's going to enforce the rule?
I mean MUST vs. SHOULD. No one would actually force it.
> everyone knows is the protocol going forward.
This is somehow philosophical issue. If I deploy NAT64/DNS64 it is because I want my IPv6 users to be able to access IPv4 internet. This is something which actually allows me to shutdown IPv4 in internal network sooner. But I understand that it might be even used other way around and allow this way access to internal IPv4 network. This is than slowing IPv6 deployment in particular network, but at least it somehow ease access to such network from IPv6 hosts. So it won't hurt overall. 
>     the choice could affect whether IPv6/IPv4 translation will work at

Thanks for clarification.

Martin

---

From: Gert Doering <[email-masked]>
Date: Mon, 11 Mar 2019 19:28:57 +0100

Hi,

On Mon, Mar 11, 2019 at 01:50:53PM -0400, Lee Howard wrote:
> connectivity. 

Unfortunately, those people that push DoH into browsers etc. are causing 
breakage for *other* people, who wouldn't know who to complain to.

Ceterum censeo, DoH must die.  In flames.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Mar 2019 11:27:15 +1300

Wait a minute... the I-D submission tool is supposed to block such filenames and require WG Chair approval - there was definitely a robotic or human glitch here.

I'd like to know if it was robotic glitch, because that could be fixed ;-). If it was a human glitch, never mind.

Regards
   Brian

On 12-Mar-19 04:37, Lee Howard wrote:
> There's a naming convention that is poorly described at https://www.ietf.org/standards/ids/guidelines/  (Section 7).
> 
> Once the draft is adopted, the chairs will tell you to name it draft-ietf-wg-topic.
> 
> 
> Comment on the draft:
> 
> If I understand correctly, your idea is for the home gateway (e.g.) to search the DNS Search List for SRV records indicating the presence of a NAT64.  Then it should synthesize the DNS64 record, or if it can't, use the ipv4only.arpa trick in rfc7050.
> 
> I think it would work, but I'm not generally in favor of giving more support to people who won't provide forward compatibility. I'd need to think about it more.
> 
> Lee
> 
> 
>> Best Regards,
>> Martin
>>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 11 Mar 2019 23:47:12 +0100

I guessed so, and I'm sure it was that way, so that's why I got really confused!

I was thinking: my god, I lost a full thread for so many months? I've lost my memory or what?

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Brian E Carpenter <[email-masked]>
Fecha: lunes, 11 de marzo de 2019, 23:27
Para: Lee Howard <[email-masked]>, <[email-masked]>
Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt

    
    Regards
       Brian

---

From: Fred Baker <[email-masked]>
Date: Tue, 12 Mar 2019 08:58:22 +0900

> On Mar 11, 2019, at 6:19 PM, Jordi Palet Martinez <jordi.palet=[email-masked]> wrote:
> 

As Martin says, it's a brand new doc, and there's a glitch in the title. It was rejected on initial submission because the date was malformed. I took the executive perspective that, especially since the author is in the Czech Republic, it would be better to have the topic on the table and discuss it than get all quibbly with a new author.

I would invite commentary on the substance of the draft, which has to do with how one determines the prefix one should use in a CLAT, and proposes a solution in an SRV record. If there is working group interest, we can invite Martin to discuss it at IETF 104.

---

From: Fred Baker <[email-masked]>
Date: Tue, 12 Mar 2019 10:00:42 +0900

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 <[email-masked]> wrote:
> 
> Signed PGP part
> Hi,
> 

--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

---

From: Fred Baker <[email-masked]>
Date: Tue, 12 Mar 2019 10:19:24 +0900

> On Mar 12, 2019, at 7:27 AM, Brian E Carpenter <[email-masked]> wrote:
> 

There were a couple of glitches, and I'm part of one of them in that I asked the Secretariat to post the draft for discussion. Blame me.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Mar 2019 14:39:21 +1300

> There were a couple of glitches, and I'm part of one of them in that I asked the Secretariat to post the draft for discussion. Blame me.

No blame, except possibly that our newcomers' documentation doesn't properly cover the draft naming rules. You'd think it would be clear in section 7 of https://www.ietf.org/standards/ids/guidelines/ but it isn't, from a newcomer's point of view.

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Tue, 12 Mar 2019 16:19:07 +0100

>I would invite commentary on the substance of the draft, which has to do 
>with how one determines the prefix one should use in a CLAT, and 
>proposes a solution in an SRV record. 

Let me summerize this proposal as: take the search list you get in an RA
option (or from DHCPv6), prepend some strings and use that to look up the
NAT64 translation prefix and other information in DNS.

At first glance it seems clever. And certainly RA/DHCPv6 agnostic.

What I'm worried about is overloading the DNS search list with network 
configuration.

Suppose an organisation or ISP has the same search list everywhere but
some networks have NAT64 and others don't (or different networks have different
prefixes).

You can add a dummy name to the search list, but that name will then attract
DNS lookups.

Another question, how robust is the search list. Do CPEs obtain the search list
from the upstream ISP and then announce them downstream?

---

From: Martin Huněk <[email-masked]>
Date: Tue, 12 Mar 2019 23:21:15 +0100

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?
> > 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
> > 
> >>> 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.
> >>> 
> >>> 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.
> >>> 
> >> 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.
> >> 
> >> 
> >> 
> ----------------------------------------------------------------------------
> ---- The fact that there is a highway to hell and a stairway to heaven is an
> interesting comment on projected traffic volume...

---

From: Martin Huněk <[email-masked]>
Date: Tue, 12 Mar 2019 23:23:47 +0100

Dne úterý 12. března 2019 0:58:22 CET, Fred Baker napsal(a):
> > On Mar 11, 2019, at 6:19 PM, Jordi Palet Martinez
> > <jordi.palet=[email-masked]> wrote:
> > 
> As Martin says, it's a brand new doc, and there's a glitch in the title. It
> was rejected on initial submission because the date was malformed. I took
> the executive perspective that, especially since the author is in the Czech
> Republic, it would be better to have the topic on the table and discuss it
> than get all quibbly with a new author.
> 
> with how one determines the prefix one should use in a CLAT, and proposes a
> solution in an SRV record. If there is working group interest, we can
> invite Martin to discuss it at IETF 104.

I would be delighted to discuss it with you and WG in person.

Martin

---

From: Martin Huněk <[email-masked]>
Date: Tue, 12 Mar 2019 23:44:50 +0100

Dne úterý 12. března 2019 16:19:07 CET, Philip Homburg napsal(a):
> some networks have NAT64 and others don't (or different networks have
> different prefixes).
> 

I such case it could be solved by multiple views to the zone or higher order 
subdomain in DNSSL. Like: example.net, areaXYZ.example.net. I agree that it 
would attract DNS lookups so it might not be ideal.
> 
> Another question, how robust is the search list. Do CPEs obtain the search
> list from the upstream ISP and then announce them downstream?

Yes, this is major setback for solving DoH vs. DNS64 issue as DNSSL is not 
transitive through CPE (and it might brake things if it would be). I'll try to 
come up with some solution for that. It seems like I've been looking on that 
from just one angle.

Martin