【每日文稿】2024-12-29
今日共有8篇文稿更新，涉及4个area里的4个WG
ART
cbor
- Title: External References to Values in CBOR Diagnostic Notation (EDN)
- Authors: Carsten Bormann(cabo@tzi.org)
- Summary: 本文讨论了在使用CBOR诊断注释时遇到的一些问题，如文本字符串被误认为是注册常数。为了解决这些问题，作者提出了两个新的应用扩展：e''和ref''。e''允许将CBOR数据项从一个CDDL模型导入到文档中的数据项中，而ref''则用于将数据项从外部EDIN文件导入到文档中的数据项中。这两个扩展都需要通过命令行选项启用，并且需要识别相应的CDDL或EDIN模型以获得所需的值。这些应用扩展可以用来管理较大的CBOR文档大小，同时保持其简洁性。此外，这些应用扩展也提供了更清晰的代码结构，并减少了对错误处理的需求。
- Diff: 该文档主要讨论了两个扩展应用：e''和ref''. e''用于从一个CDDL模型引用常量，而ref''则用于引用EDI内的数据项。这两个扩展都是通过在EDN的应用部分使用e''和ref''来实现的。 与旧版相比，新版的主要区别在于： 1. 提供了新的应用程序扩展点e''和ref''，使得可以更有效地管理诊断性注释中的例子大小、代码大小以及实例化例子之间的可组合性。 2. 在对特定元素（如text字符串）进行替换时引入了明确的错误提示，并且将一些不准确的例子更新为正确的方式。 3. 实施了基于文件名或URI引用EDI数据的机制，允许不同例子之间共享和引用同一数据源，从而减少了重复信息。 4. 将处理方法从解析URL和文件名简化为引用EDN作为外部数据，以提高效率。 这些改进使得CBOR诊断注释更加灵活，更容易理解和使用，有助于促进标准化工作。
INT
intarea
- Title: Unicast Use of the Lowest Address in an IPv4 Subnet
- Authors: Seth David Schoen(schoen@loyalty.org), John IETF Gilmore(gnu@intarea.toad.com), David M. Täht(dave@taht.net), Michael J. Karels(mkarels@none.org)
- Summary: 本文是关于IPv4地址使用的一种变化，即在每个IPv4子网内将最低地址（零号）定义为普通无广播地址。这旨在解决网络管理中的问题，同时考虑IPv4地址资源紧张的问题。主要讨论了历史和现状，提出了改变的观点，并且详细介绍了相关标准和修改之处。此外，还提到了IANA、安全性以及实施情况等细节。总的来说，这是对IPv4地址分配政策的一个重要修正，旨在改善网络管理效率和减轻IPv4地址枯竭的压力。 文稿总结如下： - 提出了将最低地址从非广播地址（如“-1”或全一数位）转变为主播地址（主机标识），以增加IPv4子网内的可用地址数量。 - 强调了这一变更的历史背景和当前状况，指出保留最低地址是出于对4.2BSD行为的历史考虑。 - 描述了该变更可能带来的影响，包括兼容性和互操作性问题，以及其对网络安全的影响。 - 详述了IANA的相关考虑，并概述了可能的实施步骤。 总之，本文提供了一个全面的理解和解释，使得读者能够了解IPv4地址变更的背景、原因和潜在影响。
- Diff: 本文讨论了IPv4地址分配中的一个历史问题：保留两个不同的广播地址（网络地址）来支持早期的BSD系统。随着时间的推移，这些广播地址变得不再必要，并且在IPv4协议设计中已经不被使用。因此，该文档提议将最低有效位的IP地址（即二进制表示中的所有零部分）从一个广播地址转换为一个普通可分配的主机地址，以缓解IPv4地址资源枯竭的问题。 主要变化包括： 1. 将最低有效位的地址从广播地址改为普通主机地址。 2. 修改了要求通信层和路由器的行为规范，使其接受或发送指定目的地为最低有效位地址的数据包。 3. 提供了如何配置接口地址以接收最低有效位地址的建议。 4. 通过CIDR标准允许分配和使用最低有效位地址。 该文档还更新了一些相关文件的要求，如《互联Pv4版本4路由器要求》等。总体来说，主要区别在于对IPv4地址分配规则进行了调整，以适应网络环境的变化，减少不必要的广播风暴，提高网络效率。同时，也考虑到安全和兼容性问题。
- Title: Unicast Use of the Formerly Reserved 240/4
- Authors: Seth David Schoen(schoen@loyalty.org), John IETF Gilmore(gnu@intarea.toad.com), David M. Täht(dave@taht.net)
- Summary: 是关于将IPv4地址空间中的240/4部分从"实验性"、"未来使用"或"类E"范围重新定义为普通单播地址的一系列标准文档。该文档提出了以下主要观点： 1. 现有的IPv4实施应该接受在240/4范围内使用的单播地址，包括它们用于网络和主机的编号和地址分配。 2. 考虑到IPv6过渡后已不再有其他保留的地址类型，240/4未被实际需要作为任何特殊用途来标识特定的功能。 3. 经过20多年的实践证明，只有通过大量实验才认识到没有新地址形式的需求，而现在的240/4地址已经被广泛使用，并且不会影响未来的互联网创新和发展。 4. 该文档提出建议，在所有路由器和操作系统上实现对240/4的普通单播支持，以增加可供使用的单播地址数量。这样可以防止将来由于新的地址需求而不得不再次考虑这一部分的保留。 总的来说，《Unicast Use of 240/4》文档提出的解决方案旨在充分利用现有的IPv4地址资源，以便能够满足未来更多的单播需求，同时保持与IPv6协议兼容。
- Diff: 新的文档提出将保留地址空间中的部分240/4区域（历史上的“实验”、“未来使用”或“E类”地址空间）作为通用的无分类单播地址，以解决IPv4地址空间紧张的问题。这包括支持它们进行网络和主机编号，并为DHCP等应用提供自动配置支持。同时，要求所有实施者确认无分类单播地址是240/4的最佳选择，并在实践中推广这种行为，以提高IPv4无分类单播地址的可用性。这使得240/4区域不再被看作“试验”或“未来使用”，而是完全可用的无分类单播地址。 与旧版相比，主要区别在于： 1. 首次提出了将240/4保留为通用无分类单播地址的概念。 2. 提出了兼容性和互操作性的详细讨论。 3. 强调了未来的部署需求以及现有地址空间的实际用途，从而鼓励了其采用。 4. 对已经存在的不合规使用进行了澄清，防止恶意攻击和欺骗。 5. 确定了实施者的责任，以便他们能够准备好接受这些地址用于实验、测试目的。
- Title: Unicast Use of the Formerly Special-Cased 127/8
- Authors: Seth David Schoen(schoen@loyalty.org), John IETF Gilmore(gnu@intarea.toad.com), David M. Täht(dave@taht.net)
- Summary: 本文提出一个提案，将IPv4地址空间中的特殊案例（即127.0.0.0/8）从16个地址减少到16个地址。这将释放大约1亿6千万个IPv4地址供其他可能用途。这样做可以缓解IPv4地址耗尽的压力。 然而，这并不意味着我们可以无限期地使用这些地址。由于IPv6分配了一个单个本地回环地址（::1），我们不应该将这些地址全部用于回环功能。相反，我们应该保留127.0.0.0/16作为唯一可使用的回环网络，并允许其在内部网络中被使用，但外部应阻止它们的传输。 此外，这个范围内的地址不应被硬编码为永远拒绝使用，也不应该通过主机和路由器设置过滤器来只针对127.0.0.0/8地址进行过滤。而是，保持所有主机和路由器都必须处理127.1.0.0到127.255.255.255作为一个通用无序地址范围，并且服务器也应当在配置时指定这些地址。 最后，关于如何处理已分配给127.0.0.0/8地址的实体，例如ISP或现有协议需要访问的地址，以及如何管理和分配这些新可用的地址，这是后续工作的关键问题。
- Diff: 新的英文标准文稿重新定义了IPv4本地回环网络为只包含127.0.0.0到127.0.255.255（127.0.0.0/16）。它要求实施者让前一循环回地址范围内的所有地址都可以通用地用于无条件的使用在互联网上。 主要内容区别： 1. 简化了IPv4地址空间管理，减少了约16万地址分配给专门用途，释放更多可用地址以供其他可能的用途。 2. 历史背景和起源更详细说明了127.0.0.0/8被保留的原因以及后来对这个地址空间的不同处理方式。 3. 提出了一个新的限制：在IPv4地址空间中不应存在1/256的地址用于专门用途，而应该将此部分可使用的地址资源留给其他可能的用途。 4. 对于大多数应用程序来说，只有127.0.0.1被指定作为默认的回环地址，并且可以接受IPv4回环地址配置服务来指定任何其他地址。服务器会根据其配置选择并分配这些地址。 5. 指定了兼容性和互操作性原则，要求实现者遵循一般性的无条件回环地址使用。 6. 对于那些使用特定接口的系统，比如DNS解析器和服务，它们将不再允许使用127.0.0.0/8的地址。 7. 对于后续分配，提出了过渡期间保持一些实验目的地址区用于测试等建议。
- Title: Unicast Use of the Formerly Reserved 0/8
- Authors: Seth David Schoen(schoen@loyalty.org), John IETF Gilmore(gnu@intarea.toad.com), David M. Täht(dave@taht.net)
- Summary: 是关于将IPv4地址空间中的“零”位重新定义为可使用的非保留地址，以缓解网络地址短缺的问题。文稿指出，“零”位不再被禁止使用，并且现在可以用于主机和路由器之间通信，以及用于其他目的。此外，文中还提到了一些特定用途下对“零”的特殊处理。 总的来说，这篇文稿强调了IPv4地址空间中“零”位的重新分配，以及这一变化如何有助于缓解网络地址短缺问题。同时，它也提出了实施新规则的建议，包括避免拒绝这些地址、确保兼容性以及提供足够的测试资源等。 该文档总结了当前互联网标准对于使用“零”位的相关规定，并提出了一种新的解决方案，即允许其在主机和路由器之间的通信中使用。然而，需要注意的是，这种修改并不意味着所有的旧标准都必须遵守新的规则。此外，由于这种改变可能会引起潜在的安全风险，因此在实际应用前还需要进一步评估和验证。
- Diff: 本文档设计了一个新的版本，其目的在于重新定义IPv4地址空间中的“0/8”（或零号网络）部分，并允许这些地址被用于全网广播的无约束使用。这个部分包括了历史上的保留地址，以及在当前的TCP/IP协议和标准中使用的特殊含义。同时，该文档也指出了在处理这些地址时的一些潜在的安全问题，并提出了一些改进措施。 相较于之前的版本，主要的区别是： 1. 从“保留”变更为“未分配”，使这部分地址不再受到保留状态的限制。 2. 对于地址0.0.0.0，提出了“不改变现有解释”的声明，即它仍然是一个未分配的、可用来标识主机的地址。 3. 在兼容性和互操作性方面，指出在某些情况下可能需要对源地址进行过滤以防止恶意流量。 4. 由于0/8地址不再被视为“火星地址”，所以不再强制所有软件都拒绝接受或生成来自0/8范围内的地址的数据包。 5. 提及了其他一些现有用途，如0/8可以作为默认路由或默认路由的扩展等。 6. 详细描述了未来在0/8地址上实施的一些预期行为，比如自动配置机制可能会接收并发送带有此地址的租约或分派。 总的来说，本文档强调了将0/8地址变为全网可用的重要性，并提供了实现这一目标的具体方法，旨在改善IPv4地址空间的利用率。
SEC
tls
- Title: TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key
- Authors: Russ Housley(housley@vigilsec.com)
- Summary: 本文主要讨论了在TLS 1.3握手协议中使用证书和外部预共享密钥（PSK）的概念。该协议允许客户端和服务器通过协商一个证书和外部PSK来认证，以保护未来可能发生的量子计算机的风险。文稿还介绍了外部PSK的性质、使用方法以及与证书验证的结合方式。最后，强调了保护这些PSK的方法，如安全的密钥管理技术，并提出了实施时应考虑的安全性和隐私问题。 总的来说，本文是关于如何利用证书和外部PSK提高安全性的一种解决方案，同时又不影响当前的安全机制。它为未来的量子计算风险提供了保护，并且没有改变现有的身份验证流程。
- Diff: 该文档是关于使用证书和外部预共享密钥（PSK）进行身份验证的新版本。 与旧版本相比，主要区别在于： 1. 新版本引入了TLS 1.3扩展，允许在握手协议中同时包含证书和PSK。 2. 在握手过程中，客户端可以请求证书并协商认证，而无需强制提供PSK。 3. 客户端可以在协商完成后发送证书和证书验证消息来实现基于证书的身份验证。 4. 这个扩展不改变现有的数字签名机制，也不会影响现有的PSKs。 5. 原有PSKs不再被限制只能用于特定的TLS 1.2或1.3算法，而是可以用于所有支持PSK的TLS 1.2和1.3。 总的来说，这个新的扩展允许在没有强制要求的情况下，同时使用证书和PSK进行身份验证，这是对现有加密协议的一个重要改进。
WIT
quic
- Title: Sockets API Extensions for In-kernel QUIC Implementations
- Authors: Long Xin(lucien.xin@gmail.com), Moritz Buhl(ietf@moritzbuhl.de), Marcelo Ricardo Leitner(mleitner@redhat.com)
- Summary: 本文是关于In-kernel QUIC（In-Kernel Quic）协议的一种映射，将QUIC接口转换为一个套接字API。主要讨论了以下几点： 1. 套接字API的定义：包括基本操作、高级操作、数据结构等。 2. 数据类型与结构化信息：包括socket、bind、listen、accept、close等操作，以及相关辅助数据和消息格式。 3. 通知结构与事件处理：包括QUIC事件结构、通知选项、客户端服务器握手等。 4. 网络层操作接口：包括网络层套接字API的使用，如读写操作、设置取消操作等。 5. 安全性考虑：讨论QUIC安全性的实现方法及对TCP/IP标准的影响。 总的来说，本文档旨在提供一种统一的套接字API来支持QUIC服务端和客户端，以便于兼容性和扩展性，并确保性能优化。
- Diff: 是针对In-kernel QUIC（In-kernel QUIC协议）的一个新的标准化文件，旨在提供一种与现有的TCP应用程序相兼容的方式，并且提供了对新的QUIC功能的支持。这个标准定义了一个映射In-kernel QUIC客户端和服务器端点到现有Socket API的方法，使得大多数现有的TCP应用可以迁移到QUIC。 主要内容包括： 1. 与现有TCP应用程序兼容：通过使用已有的Socket API实现In-kernel QUIC的应用程序可以在不进行任何更改的情况下迁移到QUIC。 2. 新功能支持：利用零拷贝技术、网络路径迁移等特性，为QUIC提供了一些性能提升。 3. 网络安全性增强：通过最小化数据复制，以及在NIC上的加密脱机等措施，进一步提高了性能，也为未来优化预留了空间。 4. 标准化的Socket API：它定义了一套标准的Socket API，覆盖了许多操作系统，使QUIC能够无缝地连接多种平台。 5. 协议细节：包括socket、bind、listen、accept、close、setsockopt、getsockopt等基本操作。 总的来说，相较于旧版，新版增加了对In-kernel QUIC的更全面的支持，以及对协议细节进行了详细的描述，从而使得应用可以更加方便地接入QUIC协议。
Unknown
Unknown
- Title: Public Key Hash for Local Domains
- Authors: Dan Wing(danwing@gmail.com)
- Summary: 本文讨论了如何在HTTPS连接中使用本地域名的安全性警告。服务器通过在一个域名中嵌入其公钥哈希来创建一个唯一且易于识别的名称，从而实现与本地域中的安全服务之间的认证。这种做法可以避免对非信任CA证书进行验证的需求，并且不需要客户更新客户端软件以支持此功能。此外，短域名也可以被用于服务器端广告，这样用户就可以看到完整的域名并确保已确认是相同的服务器。 为了防止恶意服务器侵入本地网络，需要实施适当的认证流程和安全策略，如使用可信系统、注册和验证服务器等。同时，客户端也需要采取措施防止恶意自签名证书的影响，如提供更强大的提示或直接拒绝请求。 总的来说，本文旨在简化HTTPS连接的过程，使其更加安全可靠，同时满足不同用户的使用需求。