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

From: RFC Errata System <[email-masked]>
Date: Sat, 15 Feb 2020 19:35:19 -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:
https://www.rfc-editor.org/errata/eid5984

--------------------------------------
Type: Technical
Reported by: Jordi Palet Martinez <[email-masked]>

Section: 3.3

Original Text
-------------
Organizations deploying stateless IPv4/IPv6 translation SHOULD assign a Network-Specific Prefix to their IPv4/IPv6 translation service.

Corrected Text
--------------
Organizations deploying stateless IPv4/IPv6 translation SHOULD assign a Network-Specific Prefix for the exclusive use of their IPv4/IPv6 translation service.

Notes
-----
This seems obvious but is not. The NSP must only be used for the translation service. If the NSP is used only, for example in an enterprise network, in the LANs, and the translator allows it, it may create conflicts, as the resulting IPv6 address (NSP+IPv4 address) may be the same as a host inside the LAN has been configured with (either manually, or with SLAAC, DHCPv6), etc.

It has been confirmed that at least one vendor already realized this and the implementation doesn't work if the prefix is used both for the translator service and one of the LANs, but there is no explicit documentation on that. So if configured, the box doesn't work, but doesn't report is an an "invalid" config.

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: Christian Huitema <[email-masked]>
Date: Sun, 16 Feb 2020 12:04:48 -0800

Jordi,

The errata process is not the right way to handle this issue. You are
asking for a change in the specification, and such changes should go
through the working group, as part of a standard discussion.

To go to the specific technical point: it is indeed completely doable to
use the same /64 prefix for a local subnet and for a NAT service. The
only requirement is that the NAT be capable to distinguishing between a
translated address and a local address, and that requirement is implicit
in RFC6502. For example, the NAT could reserve <64bit>:dead:beef::/96
for the 6to4 service, and use DUD to defend against hosts configuring an
address in the same /64 prefix. That may not be a perfect solution, but
that's something the working group should discuss, not something to be
handled summarily through the errata process.

-- Christian Huitema

On 2/15/2020 7:35 PM, RFC Errata System wrote:
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: <[email-masked]>
Date: Mon, 17 Feb 2020 09:43:14 +0000

Hi all, 

One further comment: the assumption we have for "stateless translation" is as follows

   In these deployments, internal IPv6 nodes are addressed
   using IPv4-translatable IPv6 addresses, which enable them to be
   accessed by IPv4 nodes.

I don't see any issue with the current text under such assumption.

Cheers,
Med

> -----Message d'origine-----
> De : Behave [mailto:[email-masked]] De la part de Christian
> Huitema
> Envoyé : dimanche 16 février 2020 21:05
> À : RFC Errata System; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : Re: [BEHAVE] [Technical Errata Reported] RFC6052 (5984)
> 
> Jordi,
> 
> > Organizations deploying stateless IPv4/IPv6 translation SHOULD
> assign a Network-Specific Prefix to their IPv4/IPv6 translation
> service.
> >
> > Corrected Text
> > --------------
> > Organizations deploying stateless IPv4/IPv6 translation SHOULD
> assign a Network-Specific Prefix for the exclusive use of their
> IPv4/IPv6 translation service.
> >
> > Notes
> > -----
> > This seems obvious but is not. The NSP must only be used for the
> translation service. If the NSP is used only, for example in an
> enterprise network, in the LANs, and the translator allows it, it may
> create conflicts, as the resulting IPv6 address (NSP+IPv4 address) may
> be the same as a host inside the LAN has been configured with (either
> manually, or with SLAAC, DHCPv6), etc.
> >
> > It has been confirmed that at least one vendor already realized this
> and the implementation doesn't work if the prefix is used both for the
> translator service and one of the LANs, but there is no explicit
> documentation on that. So if configured, the box doesn't work, but
> doesn't report is an an "invalid" config.
> >
> > Instructions:
> > -------------

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 17 Feb 2020 13:46:19 +0100

Hi all,

I agree that this is probably not an errata. However, we could mark this as “Hold for next Document Update”? I guess if there every will be an update, this need further discussion, however, having it in the errata system can help to remember it. Or do think people it should just be rejected for now?

Mirja

> On 17. Feb 2020, at 10:43, <[email-masked]> <[email-masked]> wrote:
> 
> Hi all, 
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Feb 2020 15:51:29 +0000

Hi,

I have already rejected it on the grounds that what is proposed is not something
unclear or that gets wrongly interpreted of what is intended. The proposed
behavior appears to me also to be within what is allowed by the specification.
So it is really only a proposal for further guidance. Something that may be
relevant, but only if a new version of the document is defined. Maybe this
should be changed for Hold for document update. 

Cheers

Magnus

On Mon, 2020-02-17 at 13:46 +0100, Mirja Kuehlewind wrote:
> Hi all,
> 
> I agree that this is probably not an errata. However, we could mark this as
> “Hold for next Document Update”? I guess if there every will be an update,
> this need further discussion, however, having it in the errata system can help
> to remember it. Or do think people it should just be rejected for now?
> 
> Mirja
> 
> 
> 
https://protect2.fireeye.com/v1/url?k=244c0d64-7898013a-244c4dff-8691959ed9b7-c65f53b92dad5084&q=1&e=f4738ef5-d2a3-4f09-87e8-099582e1d0ef&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5984
> > > > Author(s)           : C. Bao, C. Huitema, M. Bagnulo, M. Boucadair,
> > > 
> > > X. Li
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 18 Feb 2020 14:22:03 +1100

Just to respond in a single email.

I've read Christian, Med, and Mirja emails. Happy with that and I agree, if we need to fix it, it should be a new version.

Clearly it may be a misinterpretation of the actual document at least from one vendor implementation, as they don't allow it.

Regards,
Jordi
@jordipalet

El 18/2/20 2:52, "Behave en nombre de Magnus Westerlund" <[email-masked] en nombre de magnus.westerlund=[email-masked]> escribió:

    Hi,

    Cheers
    
    Magnus
    
    On Mon, 2020-02-17 at 13:46 +0100, Mirja Kuehlewind wrote:
    > > > À : RFC Errata System; [email-masked]; huitema@microsoft..com;
    -- 
    Cheers
    
    Magnus Westerlund 

**********************************************
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: <[email-masked]>
Date: Tue, 18 Feb 2020 06:50:38 +0000

Hi Magnus, all,

I do agree with rejecting the errata (rather that hold for document update). 

IMO, there is no confusion under the assumption of Section 3.3 ("internal IPv6 nodes are addressed using IPv4-translatable IPv6 addresses"). May be you may consider updating the "verifier note" to point to that part. 

Cheers,
Med

> De : Magnus Westerlund [mailto:[email-masked]]
> Envoyé : lundi 17 février 2020 16:51
> À : [email-masked]; BOUCADAIR Mohamed TGI/OLN;
> [email-masked]
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> > > One further comment: the assumption we have for "stateless
> translation" is
> > > as follows
> > >
> > > > To go to the specific technical point: it is indeed completely
> doable
> > > > to
> > > > only requirement is that the NAT be capable to distinguishing
> between
> > > > a
> > > > for the 6to4 service, and use DUD to defend against hosts
> configuring
> > > > an
> > > > address in the same /64 prefix. That may not be a perfect
> solution,
> > > > but
> https://protect2.fireeye.com/v1/url?k=244c0d64-7898013a-244c4dff-
> 8691959ed9b7-c65f53b92dad5084&q=1&e=f4738ef5-d2a3-4f09-87e8-
> 099582e1d0ef&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5984
> > > > >