Subject: [v6ops] draft-ietf-v6ops-nat64-srv

From: Ron Bonica <[email-masked]>
Date: Mon, 13 May 2019 13:53:18 +0000

Folks,

Each week between now and IETF 105, we will review and discuss one draft with an eye towards progressing it.

This week, please review and comment on draft-ietf-v6ops-nat64-sr .

                                                             Fred and Ron

Juniper Internal

---

From: Fred Baker <[email-masked]>
Date: Mon, 13 May 2019 09:03:27 -0700

> On May 13, 2019, at 6:53 AM, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> Folks,
> 

That would be: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-srv
https://tools.ietf.org/html/draft-ietf-v6ops-nat64-srv
  "NAT64/DNS64 detection via SRV Records", Martin Hunek, 2019-03-11,

:-)

> Juniper Internal
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 13 May 2019 19:04:07 +0200 (CEST)

> This week, please review and comment on draft-ietf-v6ops-nat64-sr .

I'm generally sympathetic to the problem space this draft tries to solve.

I'm struggling a bit with the different states that the device can end up 
in over time, and also if these lookups should only be done at connect 
time, or do they continue frequently in case the operator changes the 
information? Is there a lifetime to them? If not, why?

Think of a device that is connected for months, how are changes performed? 
What triggers a refresh? The word "time" or "life" (as in lifecycle) 
doesn't exist in the draft.

Perhaps the built in TTL in DNS can be used and lookups are done per 
normal DNS procedures and if the information changes then the settings are 
updated accordingly?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Martin Huněk <[email-masked]>
Date: Tue, 14 May 2019 00:14:36 +0200

Hi thank you for a review.

> information? Is there a lifetime to them? If not, why?

Sure, the SRV record does have the TTL value after which would had to be 
renewed. This way it would keep in line with updated settings. It is not 
explicitly written there, I guess it should be.

Question is if the "local domain" should be renewed as well. I think not due 
to security precaution (domain could be received for example from unsecured RA 
so it might be good to wait for expiration), but I would probably let this 
open as the draft doesn't specify domain detection mechanisms.

> doesn't exist in the draft.

As above, I would mention it in new version, something like: SRV record in use 
must be valid and kept updated according to its TTL value.
> normal DNS procedures and if the information changes then the settings are

Yes, that is the idea.

Thanks again for review, I would appreciate any other thoughts.

Regards,
Martin

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 14 May 2019 06:49:42 +0200 (CEST)

> explicitly written there, I guess it should be.

I made similar remarks for a different draft, which resulted in the 
following diff to that draft:

https://tools.ietf.org/rfcdiff?url2=draft-ietf-mboned-driad-amt-discovery-01.txt

The problem space with AMT tunnels and NAT64/DNS64 usage is of course not 
identical, but there might be something in there that you can take 
inspiration from.

That draft also uses DNS for its discovery mechanism.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 14 May 2019 11:59:34 +0200

Hi Martin,

Re-reading this document now, I found a few clarification/nits that I think should be addressed.

1) The document is reusing 192.0.0.170/171, but in the terminology section it refers for that to the RFC6052, while those addresses where actually defined by RFC7050.

2) Same for the definition of WKA.

3) Intro: This document specifies ... the way of ... / a mechanism for.  As this is not the only way (the/a). You use the same expression in several parts of the document.

4) I think you need to also consider, in addition to DNS over HTTPS, DNS over TLS, over DTLS and DOQ.

5) local area network or station. Not sure what it means "station" here.

6) The one for NAT64 prefix which validation end node MUST implement / end-nodes? Actually I think you should use end-nodes across all the document, but others may disagree here.

7) Server provided / Servers provided

8) In early stage / In the initial stage ?

9) Method of obtaining such information is / The method to obtain ...

10) but it might contain ... / but some possible choices are ...

11) MUST ask / MUST query

12) do have a same values of / do have equal values of ?

13) is not capable of record synthesis / is not capable to perform AAAA record synthesis

14) Method proposed / The method proposed

Further to that, it looks to me that the port definition should be better defined in section 3, either as 0 or prefix length (I will not say mask, because in IPv6 it doesn't exist).

I think it may be interesting to have a section stating why this method is better than others, pros/cons, etc. May be update RFC7051?

Last but not least, I will suggest a grammar/orthography pass. I'm not native English, so probably not the best to do it, but I spotted (some of them repeated in several parts of the document):

a) asignment / assignment
b) diferent / different
c) decadicaly / ?
d) graylist / gray-list ? same for other similar words
e) A such pool / Such pool ?
f) For example when ISP / For example, when an ISP

Regards,
Jordi

El 14/5/19 0:15, "v6ops en nombre de Martin Huněk" <[email-masked] en nombre de [email-masked]> escribió:

    

    
    
    Yes, that is the idea.

    Regards,
    Martin

**********************************************
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 Huněk <[email-masked]>
Date: Tue, 14 May 2019 13:24:45 +0200

Hi Jordi,

thank you for a review, I will try to address those issues and I will try to 
get someone to look at grammar (I'm bit struggling with it).

A reply inline (when there in none, than I agree with that assessment).

Thanks,
Martin

Dne úterý 14. května 2019 11:59:34 CEST, JORDI PALET MARTINEZ napsal(a):
> 1) The document is reusing 192.0.0.170/171, but in the terminology section
> it refers for that to the RFC6052, while those addresses where actually
> defined by RFC7050.
> 
> 3) Intro: This document specifies ... the way of ... / a mechanism for.  As
> this is not the only way (the/a). You use the same expression in several
> parts of the document.
> 

DNS over DTLS, DoT or DoQ should not really matter for NAT64/DNS64 detection 
as it allows to use "global" DNS to discover it. Any transport protocol should 
do the trick as long as the records are signed and their signature is valid.

> 5) local area network or station. Not sure what it means "station" here.

device

> 6) The one for NAT64 prefix which validation end node MUST implement /
> end-nodes? Actually I think you should use end-nodes across all the
> document, but others may disagree here.
> 
> Further to that, it looks to me that the port definition should be better
> defined in section 3, either as 0 or prefix length (I will not say mask,
> because in IPv6 it doesn't exist).
> 
> I think it may be interesting to have a section stating why this method is
> better than others, pros/cons, etc. May be update RFC7051?

I wanted to point that out in mailing list rather then in document itself as 
it might get easily outdated and incomplete. But if you think it should be 
there, than I guess I should add it into document.

> Last but not least, I will suggest a grammar/orthography pass. I'm not
> native English, so probably not the best to do it, but I spotted (some of
> them repeated in several parts of the document):
> 

Will do. And c) should be decimally.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 14 May 2019 14:10:57 +0200

Hi Martin,

If you use Word or similar, copy and paste your draft txt as a blank new document, select all the text, then choose English language. It is not proof safe 100%, but it may help!

See below in-line.

Regards,
Jordi

El 14/5/19 13:25, "v6ops en nombre de Martin Huněk" <[email-masked] en nombre de [email-masked]> escribió:

    Hi Jordi,

    
    Thanks,
    Martin

I don't think so, applications use that bypassing the OS.

    device

I will then suggest to use device across the text. Even better "node" or "host".

I think the document should be self-contained. People that will read it in the future, will not read the mailing list, so references should be to the right document.

---

From: Fred Baker <[email-masked]>
Date: Tue, 14 May 2019 12:59:58 -0700

> 3) Intro: This document specifies ... the way of ... / a mechanism for.  As this is not the only way (the/a). You use the same expression in several parts of the document.

So you are asking him to change "the" to "a"?

> 5) local area network or station. Not sure what it means "station" here.

I presume you're referring to the definition of an "end node".

Things that are attached to local area networks are referred to by various names. People from a telephony background often call them "terminals", for example, and people thinking of mobile telephones or things that look/act like them might call them "handsets". People with an ISO background might call them "end stations", and people from an Internet background might call them "hosts". "Station", which is half of "end station", is one of a number of words used in the same vein.

I do find the definition odd; when it is a "resolver" serving a "station", I would presume that it is the resolver software in a host, the bit of software that gethostbyname() asks for an IP address. That said, the *resolver* software is not the "end node"; the chunk of software that terminates sessions, which includes at least IP and the means by which it communicates with its client (often TCP or UDP, or maybe another instance of IP) and its services (a tunnel SNDCF, or a driver in most cases), and might possibly include such a resolver, is the end node.

> 6) The one for NAT64 prefix which validation end node MUST implement / end-nodes? Actually I think you should use end-nodes across all the document, but others may disagree here.

I'm not entirely sure what text change you're requesting.

I ran the thing through my spell-checker; it came up with the following diff. I wasn't sure what construction was intended by "9632". On "graylist", I have seen it as "greylist", "grey-list" and "grey list".

On the mention of an "IPv6 prefix mask" with attached decadic "IPv4 prefix mask", you're correct that we don't use prefix masks in IPv6; I would go a step further and say we would find the construct distinctly unusual. It is probably derived from the "alternative form" mentioned in the third bullet of section 2.2 from RFC 4291, but has no counterpart in section 2.3, which describes address prefixes. Since IPv4 and IPv6 both use CIDR notation, I would suggest simply using CIDR notation: if I have a prefix 2001:dba::/96 mashed up with 192.0.5.0/26, I might describe it using the IPv6 prefix 2001:dba::c000:500/122.

*** draft-ietf-v6ops-nat64-srv-00.txt	2019-03-11 01:56:27.000000000 -0700
--- draft-ietf-v6ops-nat64-srv-00-1.txt	2019-05-14 12:40:30.000000000 -0700
***************
*** 11,17 ****
     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
--- 11,17 ----
     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
!    assignment 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
***************
*** 120,133 ****
     Port: IPv6 as L3 protocol doesn't use port numbers. Because of that
     this field SHOULD be either set to zero, or SHOULD be used to
     indicate length of network prefix mask in both IPv6 and IPv4
!    protocol, used NAT64. In such case the port 16b integer MUST be
     constructed by directly appending IPv4 pool prefix mask after the

  Martin Hunek          Expires September 11, 2019               [Page 3]

  INTERNET-DRAFT    NAT64/DNS64 detection via SRV Records     March, 2019

!    IPv6 prefix mask decadicaly. Usually this would mean 9632 stating
     that IPv6 prefix with mask /96 is translated into single IPv4
     address (/32).

--- 120,133 ----
     Port: IPv6 as L3 protocol doesn't use port numbers. Because of that
     this field SHOULD be either set to zero, or SHOULD be used to
     indicate length of network prefix mask in both IPv6 and IPv4
!    protocol, used NAT64. In such case the port 16 bit integer MUST be
     constructed by directly appending IPv4 pool prefix mask after the

  Martin Hunek          Expires September 11, 2019               [Page 3]

  INTERNET-DRAFT    NAT64/DNS64 detection via SRV Records     March, 2019

!    IPv6 prefix mask decadically. Usually this would mean ?9632? stating
     that IPv6 prefix with mask /96 is translated into single IPv4
     address (/32).

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 15 May 2019 00:23:54 +0200

Hi Fred, all,

El 14/5/19 22:00, "v6ops en nombre de Fred Baker" <[email-masked] en nombre de [email-masked]> escribió:

    

I was trying to point out several changes in a single line, that are repeated (some of them) across the text. Because this is not the only way for the discovery I think it should be "a" instead of "the" and also replace way with "mechanism":

Actual:

Suggested:
This document specifies a mechanism for discovering the NAT64 pools in

Yeah,  I may be wrong, but in IETF I think we use node or host or device, but not so much station.

    
Available instead of "serving" ? anyway, yes, the definition is a bit strange.

"end-nodes" (plural) instead of end node (singular)

I understood 9632 as 96 bits / 32 bits, using decimal notation.

    

    
    --- 120,133 ----

---

From: Martin Huněk <[email-masked]>
Date: Wed, 15 May 2019 00:40:02 +0200

Hi Jordi,

reply in-line.

Dne úterý 14. května 2019 14:10:57 CEST, JORDI PALET MARTINEZ napsal(a):
> Hi Martin,
> 
> If you use Word or similar, copy and paste your draft txt as a blank new
> document, select all the text, then choose English language. It is not
> proof safe 100%, but it may help!
> 
> See below in-line.
> 
> Regards,
> Jordi
> 
> 
> 
> El 14/5/19 13:25, "v6ops en nombre de Martin Huněk" <[email-masked]
> en nombre de [email-masked]> escribió:
> 
>     Hi Jordi,
> 
>     thank you for a review, I will try to address those issues and I will
> try to get someone to look at grammar (I'm bit struggling with it).
> 
>     > Re-reading this document now, I found a few clarification/nits that I
>     > think
>     > should be addressed.
>     > 
>     > 4) I think you need to also consider, in addition to DNS over HTTPS,
>     > DNS
>     > over TLS, over DTLS and DOQ.
> 
>     DNS over DTLS, DoT or DoQ should not really matter for NAT64/DNS64
> detection as it allows to use "global" DNS to discover it. Any transport
> protocol should do the trick as long as the records are signed and their
> signature is valid.
> 

Sure, but then they act as stub resolver and as such should act according to 
this document. They are then an end nodes. I'm considering end node to be a 
resolver (DNS over whatever).

> I will then suggest to use device across the text. Even better "node" or

Think is that end node doesn't have to be a same as host/device. I would 
consider a web browser using DoH to be a separate end node to the DNS anyway, 
as we are talking DNS64 anyway.

>     > 13) is not capable of record synthesis / is not capable to perform
>     > AAAA
>     > record synthesis
>     > 
>     I wanted to point that out in mailing list rather then in document
> itself as it might get easily outdated and incomplete. But if you think it
> should be there, than I guess I should add it into document.
> 
> I think the document should be self-contained. People that will read it in
> the future, will not read the mailing list, so references should be to the
> right document.

Fair enough.

> 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: Erik Kline <[email-masked]>
Date: Tue, 14 May 2019 18:08:41 -0700

*From: *Mikael Abrahamsson <[email-masked]>
*Date: *Mon, 13 May 2019 at 10:04
*To: *Ron Bonica
*Cc: [email-masked]

> I'm generally sympathetic to the problem space this draft tries to solve.

Really?  I don't see it yet.  I don't foresee any client implementing this
level of complexity -- it doesn't actually buy them anything.

---

From: Dan Wing <[email-masked]>
Date: Wed, 15 May 2019 16:29:09 -0700

On May 14, 2019, at 6:08 PM, Erik Kline <[email-masked]> wrote:
> From: Mikael Abrahamsson <[email-masked]>
> Date: Mon, 13 May 2019 at 10:04
> To: Ron Bonica
> Cc: [email-masked]
> 
> Really?  I don't see it yet..  I don't foresee any client implementing this level of complexity -- it doesn't actually buy them anything.

The part of the I-D that seems useful is the ability to use a centralized DNS server (e.g., 1.1.1.1, 8.8.8.8, some might say "DoH") which is not participating in the DNS64/NAT64 infrastructure (and thus doesn't do the normal DNS64 synthesis) and having the client synthesize AAAA.  But RFC7050 already anticipated that need for client synthesis of AAAA with its existing support for client-side DNSSEC.  Perhaps a a document that described how to elicit an RFC7050 response (that is, elicit a synthesized address) and have the client use that information when communicating to a centralized DNS server could be helpful.  A careful read of RFC7050 should be sufficient to implement that, at least that was our intent when we wrote RFC7050 that it would be clear enough how the client can do its own synthesis.

I agree with Erik that the NAT64 balancing seems a lot of effort for the client with little gain for the client. NAT64 as a technology will diminish as native IPv6 overcomes the IPv4 inertia so engineering fancy NAT64 solutions is not "where the hockey puck is going", as they say.

-d

---

From: Gábor Lencse <[email-masked]>
Date: Thu, 16 May 2019 12:04:09 +0900

On 5/16/2019 08:29, Dan Wing wrote:

[...]
> I agree with Erik that the NAT64 balancing seems a lot of effort for the client with little gain for the client. NAT64 as a technology will diminish as native IPv6 overcomes the IPv4 inertia so eng…

I agree that NAT64 should finally diminish, but I don't think that its 
diminishing would be imminent. On the contrary, I expect that it will be 
used for at least a decade or even more.

My student has just finished her BSc final project thesis about 
examining the transition to IPv6 on the basis of available statistics. 
Her conclusion is that the IPv6 transition technologies will remain with 
us for a long time. Some technologies that aimed to help the early 
adoption of IPv6 (such as 6to4 or 6rd) are diminishing and give their 
place to the IPv4aaS technologies, where also DNS64 and NAT64 belong to.

Therefore, I think it is worth dealing with this draft, which could be a 
useful update to RFC 7050.

Best regards,

Gábor Lencse

---

From: Dan Wing <[email-masked]>
Date: Thu, 16 May 2019 14:08:21 -0700

On May 15, 2019, at 8:04 PM, Gábor Lencse <[email-masked]> wrote:
> I agree that NAT64 should finally diminish, but I don't think that its diminishing would be imminent. On the contrary, I expect that it will be used for at least a decade or even more.
> 
> My student has just finished her BSc final project thesis about examining the transition to IPv6 on the basis of available statistics. Her conclusion is that the IPv6 transition technologies will remain with us for a long time. Some technologies that aimed to help the early adoption of IPv6 (such as 6to4 or 6rd) are diminishing and give their place to the IPv4aaS technologies, where also DNS64 and NAT64 belong to.
> 
> Therefore, I think it is worth dealing with this draft, which could be a useful update to RFC 7050.

Any feedback on my other comments?  As an example, today, we don't have a way for client systems to chose outgoing IPv4 gateways (routers) or outgoing IPv4 NATs.  Well, we don't have a way that works.  The NAT64-SRV document assumes some sort of unstated relationship between IPv4 routing and DNS names, but I couldn't understand the assumed relatinoship (e.g., is all of example.com's IPv4 space always accessible behind a specific NAT64, and if it isn't, how is that expressed.  A concrete example is Apple's 17.0.0.0/8 allocation which has a couple of subnets publicly routable, and I struggle how a NAT64 operated within Apple's network with NAT64-SRV would be configured with SRV records and how the client does all the stuff it needs to do.  Naturally, not all clients will support NAT64-SRV so I guess the answer is NAT64-SRV-aware clients "work better", but all clients will work (somewhat worse, I presume with less-performant paths).

-d

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 17 May 2019 10:17:27 +0200 (CEST)

On Tue, 14 May 2019, Erik Kline wrote:

> Really?  I don't see it yet.  I don't foresee any client implementing 
> this level of complexity -- it doesn't actually buy them anything.

I'd like the client to be aware of the fact that it is or isn't behind a 
DNS64 resolver and potentially understand that it has access to both 
types. If the device decides it has dual stack connectivity it can opt to 
not use the DNS64 resolver if it so chooses.

I ran into problems with this when I was involved in rolling out IPv6 in 
mobile, it was hard to decide whether to use DNS64 or not, for which 
clients etc.