Subject: [Errata Rejected] RFC7421 (5699)

From: RFC Errata System <[email-masked]>
Date: Sat, 18 Dec 2021 14:37:04 -0800 (PST)

The following errata report has been rejected for RFC7421,
"Analysis of the 64-bit Boundary in IPv6 Addressing".

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

--------------------------------------
Status: Rejected
Type: Editorial

Reported by: Alexandre PETRESCU <[email-masked]>
Date Reported: 2019-04-19
Rejected by: Erik Kline (IESG)

Section: GLOBAL

Original Text
-------------
Internet Engineering Task Force (IETF)                 B. Carpenter, Ed.
Request for Comments: 7421                             Univ. of Auckland
Category: Informational                                         T. Chown
ISSN: 2070-1721                                     Univ. of Southampton
                                                                 F. Gont
                                                  SI6 Networks / UTN-FRH
                                                                S. Jiang
                                            Huawei Technologies Co., Ltd
                                                             A. Petrescu
                                                               CEA, LIST
                                                          A. Yourtchenko
                                                                   Cisco
                                                            January 2015

Corrected Text
--------------
Internet Engineering Task Force (IETF)                 B. Carpenter, Ed.
Request for Comments: 7421                             Univ. of Auckland
Category: Informational                                         T. Chown
ISSN: 2070-1721                                     Univ. of Southampton
                                                                 F. Gont
                                                  SI6 Networks / UTN-FRH
                                                                S. Jiang
                                            Huawei Technologies Co., Ltd
                                                          A. Yourtchenko
                                                                   Cisco
                                                            January 2015

Notes
-----
For some reason I got in the group, then participated positively to the discussion, and I let myself tempted to have my name up on the first page of a published RFC; but finally, after much time and reflexion, I think I do not agree with the effects of this RFC.

I do not agree that 64bit is a boundary.

Remark: you are asking Type 'Technical' or 'Editorial'; only one choice is possible.  I do not understand that.  My issue is both.
 --VERIFIER NOTES-- 
Quoting the AD at the time: "RFCs are immutable once published. Period."

For more discussion, see the mail archive thread https://mailarchive.ietf.org/arch/msg/ipv6/HzHbbAqaa4qquKNjaYtv3Te7IJc/

--------------------------------------
RFC7421 (draft-ietf-6man-why64-08)
--------------------------------------
Title               : Analysis of the 64-bit Boundary in IPv6 Addressing
Publication Date    : January 2015
Author(s)           : B. Carpenter, Ed., T. Chown, F. Gont, S. Jiang, A. Petrescu, A. Yourtchenko
Category            : INFORMATIONAL
Source              : IPv6 Maintenance
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Tue, 21 Dec 2021 10:08:24 +0000

Though this is not about a tech discussion thread, I would like to comment on this.

1) The boundary of 64-bit is not a MUST, and it has been stated in many RFCs even in this RFC. https://datatracker.ietf.org/doc/html/rfc7421#section-4.3.2

2) The main reason why we have this boundary may be the IID can be generated by the MAC address. But EUI-modified is not suggested due to security and privacy considerations https://datatracker.ietf.org/doc/html/rfc8064#section-3. 

3) For end user address allocation, the SLAAC can also support flexible prefix allocation, same to DHCPv6. https://datatracker.ietf.org/doc/html/rfc7217#section-5

4) For infrastructure address, they are configured, and operators may use longer prefix to save addresses. 

5) RFC7608 describes that any length of IPv6 prefix MUST can be processed by IPv6 node, so 64-boundary is not a MUST. https://datatracker.ietf.org/doc/html/rfc7608

Many people trust that the IPv6 has a  64/64 format, but we don't. Only some specific address type may have, like ULA, LLA, https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

It seems like we need to help to understand IPv6 better.

In the end, it is so happy to have free time to read RFCs and writing emails. Happy holidays guys!

Respect,
Cheng

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of RFC Errata System
Sent: Sunday, December 19, 2021 6:37 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Sheng Jiang <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Errata Rejected] RFC7421 (5699)

The following errata report has been rejected for RFC7421, "Analysis of the 64-bit Boundary in IPv6 Addressing".

Reported by: Alexandre PETRESCU <[email-masked]> Date Reported: 2019-04-19 Rejected by: Erik Kline (IESG)

Section: GLOBAL

Original Text
-------------

Corrected Text
--------------

Notes
-----

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 22 Dec 2021 02:02:08 +0000

Since I have already in the mail copied list, here is my opinion. The 64-bit is a meaningful boundary. In a few scenarios, we have relevant definitions and applying rules. However, I also agree this boundary is NOT mandatory or a MUST. It can be override with certain conditions under certain scenario. One example is, in a limited domain that the owner have full control, the network owner can allocate any-length prefix as they prefer in either shorter or longer way, and they can also give any semantic(s) to the rest bits.

Regards,

Sheng

> From: Chengli (Cheng Li)
> Sent: Tuesday, December 21, 2021 6:08 PM
> To: RFC Errata System <[email-masked]>;
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Sheng Jiang
> <[email-masked]>; [email-masked]; [email-masked]
> Subject: RE: [Errata Rejected] RFC7421 (5699)
> 
> 1) The boundary of 64-bit is not a MUST, and it has been stated in many RFCs
> even in this RFC. https://datatracker.ietf.org/doc/html/rfc7421#section-4.3.2
> 
> 2) The main reason why we have this boundary may be the IID can be
> generated by the MAC address. But EUI-modified is not suggested due to
> security and privacy considerations
> https://datatracker.ietf.org/doc/html/rfc8064#section-3.
> 
> 3) For end user address allocation, the SLAAC can also support flexible prefix
> allocation, same to DHCPv6.
> https://datatracker.ietf.org/doc/html/rfc7217#section-5
> 
> 5) RFC7608 describes that any length of IPv6 prefix MUST can be processed by
> IPv6 node, so 64-boundary is not a MUST.
> https://datatracker.ietf.org/doc/html/rfc7608
> 
> Many people trust that the IPv6 has a  64/64 format, but we don't. Only some
> specific address type may have, like ULA, LLA,
> https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xh
> tml
> 
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Sheng Jiang
> <[email-masked]>; [email-masked]; [email-masked]
> Reported by: Alexandre PETRESCU <[email-masked]> Date
> Reported: 2019-04-19 Rejected by: Erik Kline (IESG)
> 
> Section: GLOBAL
> 
> Original Text
> -------------
>                                                   SI6 Networks /
> UTN-FRH
>                                                              A.
> Petrescu
>                                                           A.
> Yourtchenko
>                                                   SI6 Networks /
> UTN-FRH
>                                                           A.
> Yourtchenko
> For some reason I got in the group, then participated positively to the
> discussion, and I let myself tempted to have my name up on the first page of a
> published RFC; but finally, after much time and reflexion, I think I do not agree
> with the effects of this RFC.
> 
> Remark: you are asking Type 'Technical' or 'Editorial'; only one choice is possible.
> I do not understand that.  My issue is both.
>  --VERIFIER NOTES--
> For more discussion, see the mail archive thread
> https://mailarchive.ietf.org/arch/msg/ipv6/HzHbbAqaa4qquKNjaYtv3Te7IJc/
>

---

From: Erik Kline <[email-masked]>
Date: Tue, 21 Dec 2021 18:14:19 -0800

I suppose some discussion was an inevitable risk but: this was a
simple erratum opened by a listed author to request removing said
author's name from a document.

Happy perihelion holidays,
-ek