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

[Fred Baker <[e-mail]>]

On May 14, 2019, at 2:59 AM, JORDI PALET MARTINEZ <jordi.palet=[e-mail]> wrote:
> 
> 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).