Subject: [v6ops] nit picky comments on draft-palet-v6ops-464xlat-opt-cdn-caches-00.txt

From: Fred Baker <[email-masked]>
Date: Sat, 23 Mar 2019 02:40:05 -0700

In at least two cases, you use the word “precedent” in the draft. I’m pretty sure you meant “preceding”.

In one place, you also used an address 2001:db8::192.0.5.1 or something like that. I had a case recently in which I Really Really wanted to use an address like that, but as I understand the Addressing Architecture, it’s no defined. ::192.0.5.1 is defined, and ::ffff:192.0.5.1 is defined, but using an IPv4 address in the IID of a generalized /96 prefix is not defined. I’m not sure what to do about that besides adding a sentence to the effect that the reader is expected to understand the intent in the example.

A little less nit-picky - you mention “forcing” a client to request a AAAA record in some cases. Why not simply carry the indicated AAAA record, whatever its address might be, as “additional information” in the DNS response? If the host is IPv6-capable, it has the option of using it...

---

From: Lencse Gábor <[email-masked]>
Date: Sat, 23 Mar 2019 11:07:28 +0100

Hi Fred,

I think Jordi uses IPv4-embedded IPv6 addresses defined in RFC 6052. 
Besides the NAT64 "Well-Known Prefix" (64:ff9b::/96), one can use a 
"Network-Specific Prefix", please refer to: 
https://tools.ietf.org/html/rfc6052#page-5

So, IMHO, it is correct:

        EAMT entry                     192.0.2.1  2001:db8::192.0.2.1

Best regards,

Gábor

3/23/2019 10:40 AM keltezéssel, Fred Baker írta:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 23 Mar 2019 18:16:14 +0100

Hi Fred,

El 23/3/19 10:41, "Fred Baker" <[email-masked]> escribió:

-> right and corrected in my internal draft-01

-> I believe this is correct, and actually Lencse explained it in another email (thanks for that !). I will include a note to explain it in the draft, so it is more evident.

-> reworded it thanks ! I think this makes it:

4.  CLAT/DNS-proxy-EAMT-based Solution Approach
   If the CLAT, as commonly is the case, is also a DNS proxy/stub
   resolver, it may be possible to modify the behavior, so when there is
   a query for an A record, and there is not a query for the AAAA record
   from the same source, the DNS resolver can actually perform an AAAA,
   unless the information is not already present in the Additional
   Section, as per Section 3 of [RFC3596].  If the response doesn't
   contain the WKP or NSP, it means that the destination is
   IPv6-capable, so the CLAT can create/update an entry for an Explicit
   Address Mapping [RFC7757].

   This way, an EAMT is maintained automatically by the DNS proxy/stub
   resolver in the CLAT, and the CLAT is responsible to prioritize any
   available entries in the EAMT, versus the use of the synthetic AAAA.

   Following this approach, the IPv6-native path will take precedence
   and traffic will not be forwarded to the NAT64.

**********************************************
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: Fred Baker <[email-masked]>
Date: Sat, 23 Mar 2019 18:32:54 +0100

> On Mar 23, 2019, at 11:07 AM, Lencse Gábor <[email-masked]> wrote:
> 
> Hi Fred,
> 
> I think Jordi uses IPv4-embedded IPv6 addresses defined in RFC 6052. Besides the NAT64 "Well-Known Prefix" (64:ff9b::/96), one can use a "Network-Specific Prefix", please refer to: https://tools.ietf.org/html/rfc6052#page-5
> 
> So, IMHO, it is correct:

I don't think so. RFC 6052 lays out where bits go; yes, that's what Jordi intends. I'm commenting on the *text* in the document, not the bits the text represents.

Observe https://tools.ietf.org/html/rfc4291#section-2.2 and https://tools.ietf.org/html/rfc4291#section-2.5.5. It only applies the format to ipv4-embedded (IPv4-Compatible and IPv4-Mapped) addresses, which RFC 4291 deprecates.

Happy to be wrong; I called it a nit. But I want to make sure we're on the same topic before we call it an error...

>> A little less nit-picky - you mention “forcing” a client to request a AAAA record in some cases. Why not simply carry the indicated AAAA record, whatever its address might be, as “additional infor…

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 23 Mar 2019 18:42:11 +0100

Hi Fred,

After responding you, I decided to change it, because it may confuse folks with an NSP case, which is not what I'm describing.

If I was showing examples with the NSP it will be correct to use the RFC6052 format (it is still correct for the examples using the WKP).

So, I keep:

       www.example.com                   A       192.0.2.1
       CLAT translated to                        64:ff9b::192.0.2.1
       CDN IPv6 interface must be                64:ff9b::192.0.2.1
       Operator must have a specific route to    64:ff9b::192.0.2.1

But moved the other one to regular documentation addresses:

        www.example.com                   A       192.0.2.1
                                          AAAA    2001:db8::a:b:c:d
        EAMT entry                     192.0.2.1  2001:db8::a:b:c:d
        CLAT translated to                        2001:db8::a:b:c:d
        CDN IPv6 interface already is             2001:db8::a:b:c:d
        Operator already has a specific route to  2001:db8::a:b:c:d

Regards,
Jordi

El 23/3/19 18:33, "v6ops en nombre de Fred Baker" <[email-masked] en nombre de [email-masked]> escribió:

    

    
    >> In at least two cases, you use the word “precedent” in the draft. I’m pretty sure you meant “preceding”..
    >>

---

From: 神明達哉 <[email-masked]>
Date: Sat, 23 Mar 2019 16:24:30 -0700

At Sat, 23 Mar 2019 18:32:54 +0100,
Fred Baker <[email-masked]> wrote:

> I don't think so. RFC 6052 lays out where bits go; yes, that's what Jordi
intends. I'm commenting on the *text* in the document, not the bits the
text represents.
>
> Observe https://tools.ietf.org/html/rfc4291#section-2.2 and
https://tools.ietf.org/html/rfc4291#section-2.5.5. It only applies the
format to ipv4-embedded (IPv4-Compatible and IPv4-Mapped) addresses, which
RFC 4291 deprecates.
>
> Happy to be wrong; I called it a nit. But I want to make sure we're on
the same topic before we call it an error...

I'm confused.  Are you saying 2001:db8::192.0.5.1 is not a valid
textual IPv6 address?  In my understanding that's perfectly valid
(probably quite uncommon, though).  I'm especially confused as you
referred to Section 2.2 of RFC4291... It states:

   3. An alternative form that is sometimes more convenient when dealing
      with a mixed environment of IPv4 and IPv6 nodes is
      x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
      the six high-order 16-bit pieces of the address, and the 'd's are
      the decimal values of the four low-order 8-bit pieces of the
      address (standard IPv4 representation).  Examples:
[...]

Although the "examples" only show the case of x:x:x:x:x:x being either
0:0:0:0:0:0 or 0:0:0:0:0:FFFF, I interpret the above text as 'x' can
be any hexadecimal value.

And btw, RFC4291 does not deprecate IPv4-mapped IPv6 addresses (it
only deprecated IPv4-compatible IPv6 addresses).

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 24 Mar 2019 15:22:32 +1300

On 24-Mar-19 12:24, 神明達哉 wrote:
> Fred Baker <[email-masked] <mailto:[email-masked]>> wrote:
> 

I agree. It's just another way of writing 2001:db8::c000:501

    Brian

---

From: Fred Baker <[email-masked]>
Date: Sun, 24 Mar 2019 04:49:08 +0100

If I'm wrong, I'm wrong.

> On Mar 24, 2019, at 12:24 AM, 神明達哉 <[email-masked]> wrote:
> 

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 24 Mar 2019 08:25:49 +0100

Let me try again …

Only IPv4-compatible IPv6 addresses are deprecated, and that means only ::IPv4 is deprecated (so only if starts with 96 cero-bits).
Representing an IPv4/IPv6 translated address in this way is explicitly mention in RFC6052, for both cases, the WKP and NSP.
However, my example in draft-palet-v6ops-464xlat-opt-cdn-caches (section 4) by using that textual representation and the same IPv4 address in the AAAA record, may be interpreted as an NSP, which is not the case. The example at Section 3 is clear because it is a WKP.

So, in the next version (-01) I’ve changed the example at section 4. I’d previously already added a similar example at section 5.

It will be nice if there are any new comments, as I plan to upload today/tomorrow a new version :-)

Regards,

Jordi

El 24/3/19 0:25, "v6ops en nombre de 神明達哉" <[email-masked] en nombre de [email-masked]> escribió:

--
JINMEI, Tatuya

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