RE: [Errata Rejected] RFC7421 (5699)

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

> -----Original Message-----
> From: Chengli (Cheng Li)
> Sent: Tuesday, December 21, 2021 6:08 PM
> To: RFC Errata System <rfc-editor@rfc-editor.org>;
> alexandre.petrescu@gmail.com; brian.e.carpenter@gmail.com;
> tjc@ecs.soton.ac.uk; fgont@si6networks.com; Sheng Jiang
> <jiangsheng@huawei.com>; alexandru.petrescu@cea.fr; ayourtch@cisco.com
> Cc: ipv6@ietf.org; iesg@ietf.org
> Subject: RE: [Errata Rejected] RFC7421 (5699)
> 
> 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.xh
> tml
> 
> 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:ipv6-bounces@ietf.org] On Behalf Of RFC Errata System
> Sent: Sunday, December 19, 2021 6:37 AM
> To: alexandre.petrescu@gmail.com; brian.e.carpenter@gmail.com;
> tjc@ecs.soton.ac.uk; fgont@si6networks.com; Sheng Jiang
> <jiangsheng@huawei.com>; alexandru.petrescu@cea.fr; ayourtch@cisco.com
> Cc: ipv6@ietf.org; iesg@ietf.org
> Subject: [Errata Rejected] RFC7421 (5699)
> 
> 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 <alexandre.petrescu@gmail.com> 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
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------