Subject: [BEHAVE] [Technical Errata Reported] RFC6052 (5547)

From: RFC Errata System <[email-masked]>
Date: Tue, 6 Nov 2018 00:53:23 -0800 (PST)

The following errata report has been submitted for RFC6052,
"IPv6 Addressing of IPv4/IPv6 Translators".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5547

--------------------------------------
Type: Technical
Reported by: Fred Baker <[email-masked]>

Section: 3.1

Original Text
-------------
   The Well-Known Prefix MUST NOT be used to represent non-global IPv4
   addresses, such as those defined in [RFC1918] or listed in Section 3
   of [RFC5735].  Address translators MUST NOT translate packets in
   which an address is composed of the Well-Known Prefix and a non-
   global IPv4 address; they MUST drop these packets.

Corrected Text
--------------
The paragraph should be removed.

Notes
-----
IPv4 packets with private addresses are routinely translated to IPv4 packets with global addresses in NAT44. If a 464XLAT CLAT (stateless NAT64) cannot translate a private address to an IPv6 /96 prefix with that address as an IID (or whatever it's called), then the packet may not be translated to an IPv4 packet with a global address by the 464XLAT PLAT (stateful NAT64). This changes the intent of the sender, and in so doing violates the end to end principle. Practically speaking, it means that a network that uses 464XLAT or MAP-T with IPv4 in the subscriber and translating to IPv4 via NAT64 into the IPv4 Internet, it forces the network or the subscriber to purchase global address space. That's just silly. Let the user use private address space in the home or whatever.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6052 (draft-ietf-behave-address-format-10)
--------------------------------------
Title               : IPv6 Addressing of IPv4/IPv6 Translators
Publication Date    : October 2010
Author(s)           : C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li
Category            : PROPOSED STANDARD
Source              : Behavior Engineering for Hindrance Avoidance
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

---

From: Fred Baker <[email-masked]>
Date: Tue, 6 Nov 2018 16:23:55 +0700

On second thought, the exact case is incorrect. I still think it's a silly restriction, but the private address in the case would not be placed into the Well-Known Prefix (and used as a destination address); it would be put into a /64 out of the subscriber's prefix (and used as a source address). So I can live without this change.

> On Nov 6, 2018, at 3:53 PM, RFC Errata System <[email-masked]> wrote:
> 

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

---

From: Christian Huitema <[email-masked]>
Date: Tue, 6 Nov 2018 17:17:43 +0700

> On second thought, the exact case is incorrect. I still think it's a silly restriction, but the private address in the case would not be placed into the Well-Known Prefix (and used as a destination…

Good.

I think that the text should not be changed by an errata. The text is a
fair rendering of our technical assessment at the time. We did not want
to use the WKP to build ambiguous IPv6 addresses, and wanted to make
sure that private IPv4 addresses will be mapped using private prefixes.
It may or may not have been the right decision, but this is definitely
what we intended.

-- Christian Huitema

---

From: Fred Baker <[email-masked]>
Date: Tue, 6 Nov 2018 18:28:04 +0700

> On Nov 6, 2018, at 5:17 PM, Christian Huitema <[email-masked]> wrote:
> 
> 
> 
> to use the WKP to build ambiguous IPv6 addresses,

If the objective was to not create ambiguous addresses, why did we build a well-known prefix? A well-known prefix is probably the best possible way to create ambiguous addresses.

> and wanted to make

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 06 Nov 2018 19:16:30 +0700

The advantage I see with a WKP is that you can roam to another NAT64 (and/or DNS64) without changing configs, and also, that you may ignore the prefix discovery mechanism (I've seen this coded in some places), if you presume that the WKP is the "default" one ...

Regards,
Jordi

-----Mensaje original-----
De: Behave <[email-masked]> en nombre de Fred Baker <[email-masked]>
Fecha: martes, 6 de noviembre de 2018, 18:28
Para: Christian Huitema <[email-masked]>
CC: Congxiao Bao <[email-masked]>, <[email-masked]>, Dave Thaler <[email-masked]>, Xing Li <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Mirja Kuehlewind (IETF)" <[email-masked]>, <[email-masked]>, RFC Errata System <[email-masked]>
Asunto: Re: [BEHAVE] [Technical Errata Reported] RFC6052 (5547)

    

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

**********************************************
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: Tue, 6 Nov 2018 20:52:28 +0700

> On Nov 6, 2018, at 7:16 PM, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 

That, of course, is exactly the problem with RFC 7050. If you are using the preferred resolver, you get one prefix, and if you're using 8.8.8.8 (as many do), you get another. A Well Known Prefix is a great way to pick the wrong one, or one that doesn't exist.
--------------------------------------------------------------------------------
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: Tue, 06 Nov 2018 21:07:04 +0700

Totally agree and is the case that I call "foreign DNS" in draft-ietf-v6ops-nat64-deployment, but I was meaning that, as most of the NAT64 deployments use the WKP, changing among them doesn't break, so at least we "break less".

Regards,
Jordi

---

From: <[email-masked]>
Date: Thu, 8 Nov 2018 14:00:14 +0000

Hi all, 

I echo what Christian said.

Please note that if one wants to relax the constraint about private IPv4 address in 6052, the WKP prefix defined in https://tools.ietf.org/html/rfc8215 (which Fred is surely familiar with) can be used. 

Cheers,
Med

> -----Message d'origine-----
> De : Behave [mailto:[email-masked]] De la part de Christian Huitema
> Envoyé : mardi 6 novembre 2018 11:18
> À : Fred Baker; RFC Errata System
> Cc : Congxiao Bao; [email-masked]; Dave Thaler; Xing
> Li; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Objet : Re: [BEHAVE] [Technical Errata Reported] RFC6052 (5547)
> 
> 
> 
> > On second thought, the exact case is incorrect. I still think it's a silly
> restriction, but the private address in the case would not be placed into the
> Well-Known Prefix (and used as a destination address); it would be put into a
> /64 out of the subscriber's prefix (and used as a source address). So I can
> live without this change.
> 
> Good.
>

---

From: Christian Huitema <[email-masked]>
Date: Fri, 16 Nov 2018 22:00:05 -0800

To be clear, I am not trying to assert that RFC 6052 is technically
perfect. There may very well be good reasons to write an RFC 6052bis. We
have now several years of deployment experience, and we may possibly
have learned a thing or two. I am just saying that the errata process is
the wrong way to do that.

-- Christian Huitema