Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-03.txt

From: [email-masked]
Date: Tue, 28 Jul 2020 07:15:35 -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           : 464XLAT/MAT-T Optimization
        Authors         : Jordi Palet Martinez
                          Alejandro D'Egidio
	Filename        : draft-ietf-v6ops-464xlat-optimization-03.txt
	Pages           : 24
	Date            : 2020-07-28

Abstract:
   IP/ICMP Translation Algorithm (SIIT) can be used to provide access
   for IPv4-only hosts or applications to IPv4-only or dual-stack
   destinations over IPv6-only infrastructure.  In that case, the
   traffic flows are translated twice: first from IPv4 to IPv6
   (stateless NAT46 at the ingress point to the IPv6-only
   infrastructure) and then from IPv6 back to IPv4 (stateful NAT64, at
   the egress point).  When the destination is IPv6-enabled, the second
   translation might be avoided.  This document describes a possible
   optimization to 464XLAT and MAP-T to avoid translating IPv6 flows
   back to IPv4 if the destination is reachable over IPv6.  The proposed
   solution would significantly reduce the NAT64 utilization in the
   operator's network, increasing the performance.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat-optimization/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-v6ops-464xlat-optimization-03
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimization-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-optimization-03

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: Tue, 28 Jul 2020 16:17:55 +0200

Hi all,

Sorry, was a bit congested with other work last week to finish this version.

I'm still working in some of the previous emails, to make sure that this version has addressed them. I will be responding ASAP.

Regards,
Jordi
@jordipalet

El 28/7/20 16:16, "[email-masked] en nombre de [email-masked]" <[email-masked] en nombre de [email-masked]> escribió:

    Abstract:

    _______________________________________________
    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: Erik Nygren <[email-masked]>
Date: Thu, 30 Jul 2020 14:40:22 -0400

This version improves, but still seems to be missing some important items.
I'm also still worried that it may not be safe enough and may still cause
more problems than it solves, especially if implementations are buggy.
(Buggy implementations in CPEs will be really hard to debug or trace back
for people outside the network, will be hard/impossible to get fixed,  and
will
result in dual-stack content getting switched to IPv4-only to work around
issues.

Some specific thoughts:

* Would it make sense to change away from the "MUST" implement
  and instead require all modes to be used only with configuration by
  the network operator?  (Having that configuration include an allowlist
  of IP(v4) prefixes which are candidates for the optimization may further
help.)
  This at least allows this to get disabled in cases where it causing
problems
  while still letting network operators use it for content they want to
optimize
  in coordination with CDN partners.  Using this with off-the-shelf CPEs
seems
  dangerous as bugs there can have high damage risk to IPv6 content
deployment
  without a good path to fix.

* I don't see a mention about risks of clients ignoring TTL yet?  Maybe I
missed
  it or maybe this is next version?  Keeping entries in a stale state for
some time
  past their TTL expiry helps.

* We should add the security risk discussed previously to Security
Considerations.
  (ie, clients/apps ignoring DNS TTL can still be hijacked to other IPs
even without
  DNS spoofing if an app with the same MAC (same device or behind a
NAT/router)
  does a DNS lookup to an attacker-controlled hostname.)

* It would be good to mention that some consumer electronics ship with
  alternate resolvers configured (eg, Chromecast).

* It would be good to clarify that even if a hostname is IPv4-only (ie,
AAAA returns
  a DNS64-synthesized address) that the entry must still be marked
  invalid if the A record matches but the FQDN mismatches.
  (Maybe I missed this in there?)

On Tue, Jul 28, 2020 at 10:24 AM JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

> I'm still working in some of the previous emails, to make sure that this
> version has addressed them. I will be responding ASAP.
>
> Regards,
> Jordi
> @jordipalet
>
>
>
> El 28/7/20 16:16, "[email-masked] en nombre de
> [email-masked]" <[email-masked] en nombre de
> [email-masked]> escribió:
>
>
> 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.
>
>
>