【每日文稿】2024-11-20
今日共有11篇文稿更新，涉及3个area里的6个WG
ART
dmarc
- Title: Domain-based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting
- Authors: Alex Brotman(alex_brotman@comcast.com)
- Summary: 本文是关于Dmarc聚合报告的规定和建议。文稿主要介绍了以下内容： 1. 基本术语，包括DMARC、DMARC反馈等。 2. DMARC反馈文档格式，如报告ID、日期范围等信息。 3. DMARC聚合反馈报告的特点：提供关于DMARC认证结果、纠正措施以及DMARC政策对邮件流的影响的信息。 4. 发送DMARC聚合反馈报告时需要注意的问题，如处理数据大小、接收方是否支持传输等等。 5. 提供了DMARC扩展报告规范，并强调其应被正确格式化为XML文件并纳入到DMARC报告结构中。 总的来说，该文档旨在帮助接收方理解DMARC聚合反馈报告，以便更准确地评估和应用这些信息以改进电子邮件安全策略。
- Diff: 总结： 1. 基本概念和术语定义。 2. DMARC反馈报告概述：提供给接收者的汇总信息，包括日志、检测结果等，以及与DMARC政策相关的其他数据。 3. 版本管理：明确说明此版本为标准草案，旨在标准化DMARC协议。 4. 知识产权声明：遵循RFC系列规范。 区别： 1. 新版增加了对DMARC聚合反馈报告的详细描述，包括发送方如何生成和处理报告，以及报告中的关键元素。 2. 新版引入了对报告的验证机制，以确保其不包含虚假或欺诈性的数据。 3. 新版还涉及对外部目的地的验证要求，以便发现潜在的欺诈行为。
- Title: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- Authors: Todd Herr(todd@someguyinva.com), John R. Levine(ietf@johnlevine.com)
- Summary: 本文介绍了DMARC协议，它是用于邮件认证和反馈的一种标准。DMARC支持域主发布DNS TXT记录来验证电子邮件中的使用域名，并且可以要求报告关于这些域名的使用情况。此外，它还提供了反馈机制，使域主能够获得有关不通过验证的消息的报告。 总结： DMARC是一个用于邮件认证和反馈的协议，支持域主发布DNS TXT记录来验证电子邮件中的使用域名，并允许发送方根据需要请求报告关于这些域名的使用情况。它可以提供反馈机制，让域主获取有关未通过验证的消息的信息。
- Diff: 该文档详细介绍了基于RFC5322.From域的邮件认证、报告和合规（DMARC）协议。它描述了如何使用域名来验证电子邮件消息是否为合法来源，并允许域名所有者选择其对已授权使用的作者域的有效处理策略。此外，还定义了相关术语并提供了一个详细的流程图。 相比于旧版文档，新版增加了新的技术考虑因素，如S/MIME、方法排除、发送人头衔字段、域存在测试等；修订了部分定义；扩展了域所有者行为、报告生成建议等内容；移除了旧版中的错误信息；增加了对IPv6的支持；删除了一些不常用的功能；改进了格式和缩进等。总的来说，新版文档提供了更详尽的信息，提高了文档的可读性和实用性。
INT
madinas
- Title: Randomized and Changing MAC Address: Context, Network Impacts and Use Cases
- Authors: Jerome Henry(jhenry@ieee.org), Yiu Lee(yiu_lee@cable.comcast.com)
- Summary: 本文讨论了无线网络中的MAC地址作为身份标识的问题。文稿分析了使用MAC地址作为身份标识的好处和坏处，以及这种做法可能对用户隐私、网络质量和效率的影响。 文稿指出，在一些情况下，通过随机化MAC地址可以减少在无线网络中进行持续关联的需要，并防止其他设备识别特定设备。然而，这种做法也可能会导致服务中断，如Session建立失败，数据包丢失等。此外，如果多个客户端实施快速变化的MAC地址，则这些服务可能过载。 因此，对于用户隐私和网络质量而言，保持用户的用户体验和网络效率是至关重要的。为了应对这种情况，提出了解决方案，包括使用802.1X与WPA2/WPA3组合，OpenRoaming标准，或采用私人RCM方案。同时，还探讨了现有的安全措施，以保护用户隐私并确保网络质量。 总的来说，文稿强调了在无线网络环境中合理使用MAC地址的重要性，并提出了相应的解决方案。
- Diff: 摘要 为了限制设备、流量、位置和用户的关联所引发的隐私问题，客户和操作系统供应商开始实施MAC地址随机化。当这种随机化发生时，一些网络状态可能会崩溃，从而影响到网络连接质量和用户体验。另一方面，设备可能继续使用其他稳定标识符，从而破坏MAC地址随机化的目的。 然而，这样的地址变化也可能对用户体验造成影响，并损害合法网络操作的效率。长期以来，网络设计者和实现者依赖于假设给定的机器在支持IEEE 802技术的网络中将有一个唯一的网络MAC地址，该地址不会随着时间改变，尽管存在工具可以清除MAC地址来绕过一些网络政策。当这个假设被打破时，网络通信可能会中断。例如，与网络服务之间的会话可能会破裂，并且在网络中的传输可能会突然丢失。如果多个客户端不协调地进行快速MAC地址随机化，则这些网络服务可能会变得过度请求。 同时，有些网络服务依赖于端站（即定义为IEEE 802标准的设备，也称为设备或机器）提供一个标识符，该标识符可以是MAC地址或其他值。如果客户端实施了MAC地址随机化但继续发送相同的静态标识符，则关联单个设备和站的状态将继续即使MAC地址随机化方案生效。在某些环境中，这样的持续关联可能是有益的，但在其他环境中，保护用户隐私的价值可能高于任何连续网络服务状态。 总的来说，列出可能受到MAC地址随机化影响的各种环境，并评估如何维护用户隐私的同时保留用户体验和网络运营效率，这对于识别哪些服务可能受到影响以及解决方案的有效性至关重要。 总体而言，本文档的主要区别在于它详细列出了可能受影响的环境和网络服务，并分析了现有网络服务可能会受到影响的情况，最后提出了维持用户隐私并同时保持用户体验和网络效率的解决方案。
RTG
bess
- Title: Fast Recovery for EVPN Designated Forwarder Election
- Authors: Patrice Brissette(pbrisset@cisco.com), Ali Sajassi(sajassi@gmail.com), Luc André Burdet(laburdet.ietf@gmail.com), John Drake(jdrake@juniper.net), Jorge Rabadan(jorge.rabadan@nokia.com)
- Summary: 本文讨论了Ethernet Virtual Private Network (EVPN)的设计指定转发器选举方案。传统的选举算法可能在多路复用段（multihomed segment）中的多个Provider Edge（PE）设备之间造成VLAN重分配和潜在的环路，导致广播风暴帧的发送回源VLAN。本文提出了一种快速设计指定转发器选举的解决方案，通过在恢复失败或故障PE时进行快照选举来避免这些情况。 主要优点包括：简化握手机制和状态机；保持与现有选举算法的兼容性，不改变选举类型；支持所有PE设备的时钟同步，并利用一种简单的双向信号机制；避免复杂的交换机和状态机；提供更小的延迟事件，同时保持选举过程的同步性；以及确保新的选举结果在恢复过程中不会引起重复流量或层2循环。 总的来说，本文提出了一个简单而有效的快速设计指定转发器选举的方法，旨在克服当前技术中的一些限制并为未来的发展留下空间。
- Diff: 以上新版标准文稿的主要区别在于： 1. 引入了新的算法（Highest Random Weight）来避免多点选举中的状态改变。 2. 提供了一种快速设计指定转发器选举的方法，在链路或节点恢复时提供。 3. 采用简单的双向信号机制，而不是复杂的握手和状态机。 4. 增加了一个时间偏移量到服务切分的时间，以确保不同站点间的选举过程是有序的。 5. 解决了在多点恢复期间可能出现的问题，如循环和丢失的流量。 6. 根据不同的恢复情况，提供了不同的时间偏移量。 7. 遵循了一些设计原则，例如避免复杂的状态机，简单的一对一通信等。 总的来说，新版文稿简化了选举流程，减少了延迟，并引入了新的解决方案来解决可能的问题，使选举更加快速、安全且一致。这些改进使得该方案更加适用于现实环境下的网络收敛。
detnet
- Title: Requirements for Scaling Deterministic Networks
- Authors: Peng Liu(liupengyjy@chinamoblie.com), Yizhou Li(liyizhou@huawei.com), Toerless Eckert(tte@cs.fau.de), Quan Xiong(xiong.quan@zte.com.cn), Jeong-dong Ryoo(ryoo@etri.re.kr), zhushiyin(zhushiyin00659@qq.com), Xuesong Geng(gengxuesong@huawei.com)
- Summary: 这篇文档提出了针对大规模分布式网络进行确定性网络(Scalable Deterministic Networking, SDN)设计时的技术要求。主要讨论了以下几方面： 1. 需要容忍时间不一致：可以使用异步时钟来支持不同时区或没有同步时钟的网络。 2. 支持大单跳传播延迟：需要为大单跳路径提供容错机制，以适应低带宽和高带宽传输的不同需求。 3. 协调处理复杂拓扑中的大量流量：需要满足各种流在多域之间流动的需求，并且能够根据流量类型调整路由策略。 4. 防止流量波动：需要开发多种机制同时运行以确保网络服务的一致性和稳定性。 5. 支持多级机制在单一域内和跨多个域：需要提供不同的资源管理和配置选项。 6. 支持多流聚合：需要对多流进行聚合处理以提高效率。 7. 提供可扩展的数据平面增强要求：包括数据包识别、信息用于保证端到端定准延迟的服务等。 总结来说，文稿提出了一系列技术要求和数据平面增强措施，旨在支持大规模分布式网络的确定性设计和实施。
- Diff: 这篇新的英文标准文稿详细描述了如何在大网络中使用时间不一致、高延迟路径组合和多类型流量等情况下实现端到端的定性延迟服务(Deterministic Networking)。 与旧版相比，主要区别在于： 1. 适应不同时间同步方式（如异步时钟）：尽管这些技术已经存在，但文档强调了需要准备跨多个非同步TSN岛屿的机制来连接它们。 2. 支持单个跳段较大的传播延迟：文档提出了一种方法来支持这种延迟，并解释了为什么需要考虑这种特性。 3. 配合更高带宽速度：文档讨论了如何适应更大范围内的数据速率，以及在不同的端口和节点之间进行调度。 4. 考虑到大规模流数量：文档提到了如何应对大量流的数量问题，包括如何在不同自治系统之间的网络中规划路径。 5. 适应拓扑变化和链路或节点故障：文档说明了如何处理网络中的设备增加或减少的问题，并指出这些变化对实现更高质量的服务可能产生负面影响。 总的来说，这篇新的标准文稿为如何设计并扩展定性网络提供了更详细的指导，以适应各种挑战和限制。
mpls
- Title: Naming the Protocol specified RFC 8029
- Authors: Loa Andersson(loa@pi.nu), Mach Chen(mach.chen@outlook.com), Carlos Pignataro(cpignata@gmail.com)
- Summary: 本文主要对 RFC 8029 中定义的 MPLS Label Switched Path (LSP) Ping 协议名称进行修改。原来该协议被称为 "Multiprotocol Label Switching (MPLS) Data-Plane Failures Detecting", 现在更改为 "MPLS Label Switched Path (LSP) Ping and Traceroute", 带有其对应的缩写。此外，还更新了 IANA 考虑事项部分，并未提及任何安全考虑或参考文献。
- Diff: 新的英文标准文稿详细描述了MPLS Label Switched Path（LSP）Ping和Traceroute协议以及它们的模式，纠正了之前RFC 8029文档中关于该协议名称不明确的问题。此外，它还更新了RFC 8029文档，并提供了相应的规范性引用。 与旧版相比，新版本的主要区别在于： 1. 在RFC 8029文档中正式将“MPLS Label Switched Path Ping and Traceroute”、“MPLS LSP Ping”或“LSP Ping”称为指定协议的名称。 2. 引入了对IANA考虑项的说明，表明没有提出任何IANA请求。 3. 提供了参考文献，包括修订版BSD许可证文本作为保留无错误保证，以及引用了现行的修订版BSD许可证文本。
spring
- Title: NRP ID in SRv6 segment
- Authors: Yisong Liu(liuyisong@chinamobile.com), Changwang Lin(linchangwang.04414@h3c.com), Hao Li(lihao@h3c.com), Liyan Gong(gongliyan@chinamobile.com)
- Summary: 本文讨论了在SRv6网络中的NRP-ID如何携带和处理。主要提出了以下几点： 1. NRP-ID可以在SRv6段中携带，通过设置SRv6段的编码字段来实现。 2. 在不同场景下（如严格路径和非严格路径），NRP-ID可以有不同的分配方式。例如，在严格路径中，NRP-ID是全局唯一的；而在非严格路径中，每个节点可以有自己的本地NRP-ID。此外，还可以考虑使用协议扩展来动态配置NRP-ID的分配。 3. 为了支持网络切片服务，需要考虑如何处理NRP-ID在跨域转发过程中的情况，以及如何保证NRP-ID的一致性。这涉及到对转发表（LSPT）的管理和维护，以确保NRP-ID的有效性和一致性。 总的来说，本文提出了一种新的方法来携带和管理NRP-ID在网络切片服务中的应用。这对于提高网络切片服务的性能和可靠性具有重要意义。
- Diff: 本文提出了一种在SRv6网络中携带NRPID的方法，用于实现网络切片服务。主要内容包括： 1. 引言部分定义了对NRPID的需求和应用场景。 2. 描述适用场景：根据SRv6 TE模式，提出了严格跳转路径承载NRPID的方法，以满足客户流量通过SRv6策略的服务水平协议（SLP）的要求。文中还讨论了非严格跳转路径的情况。 3. 编码NRPID到SRv6段：SRv6段结构定义为LOC:FUNCTION:ARG。将NRPID字段放在ARG部分，用来标识携带该NRPID的网络资源。 4. 部署考虑：在严格的跳转路径下，多个段落被封装在SRH头部，最后一个段落通常表示尾端节点的服务或结束SID，并不需要包含NRPID。其他段落通常是End或End.X类型的，用于指导中间节点转发数据包。不同段落可以携带相同的或不同的NRPID，由控制器或运营商通过CLI配置决定。 5. 行为分析：针对头端节点，当网络切片功能启用时，需要确定承载客户流量的网络切片，然后引导客户流量至SRv6政策并封装IPv6头部和SRH头。同时设置NRPID到段落。这种情况下，节点沿着消息路由使用相同的NRPID来识别与网络切片关联的网络资源。 6. 考虑到分组转发路径：如果跨域场景存在不同NRPID路径，则控制器可能需在每个段落预先写入NRPID，然后向节点发出SRv6政策。节点仅使用SRv6策略封装客户流量。 综上所述，本文档的主要区别在于引入了编码NRPID到SRv6段的机制，并提供了部署、行为分析等详细描述。相比旧版本，本文更侧重于理论性技术细节，以及如何实现在网络切片服务中的具体操作。
- Title: Service Interworking between SRv6
- Authors: Weiqiang Cheng(chengweiqiang@chinamobile.com), Changwang Lin(linchangwang.04414@h3c.com)
- Summary: 本文讨论了在服务间进行SRv6互操作性的几种场景。当运营商部署SRv6时，他们可能无法部署单个SRv6域，或者管理考虑会影响跨域解决方案的实现。针对这些情况，本文描述了三种不同的跨域VPN方法：Option A（VRF-to-VRF）、Option B（仅发布VPN路由）和Option C（多跳EBGP）。Option A使用多个子接口将两个PE路由器连接在一起，并通过一个虚拟路由作用域（VRF）为每个PE分配端点标识符（EPESID），从而将PE视为CE设备；Option B仅将VPN路由发布给相邻AS的ASBR，不创建跨域控制器或层次化控制器，并且在转发过程中需要独立规划路径列表；Option C则采用多跳eBGP方式，在不同AS之间直接发布VPN路由并关联新的行为段来引导流量转发。此外，本文还探讨了在Intra-domain互操作性中的两种方法：Option A（VRF-to-VRF）和Option C（多跳EBGP）。总结来说，本文提出了多种实现跨域SRv6互操作性的方法，并指出了其适用范围。 总的来说，本文提供了实施跨域SRv6互操作性的技术细节，并强调了关键概念和技术之间的关系。它为未来的研究者和工程师提供了一个全面的技术框架，以便解决跨域网络设计中的问题。
- Diff: 新的中文版文档总结如下： 本文介绍了服务互连工作组（Spring）关于SRv6跨域互通的相关工作。当运营商通过SRv6提供服务时，可能会面临多个AS或者同一AS内划分多个SRv6域的情况。这种情况下，需要实现跨域互通的服务间协作。 在SRv6 BE模式下，只需要在同一个AS内部发布点到点路由，并且SRv6转发和BE处理是相同的。对于Option A来说，由于没有涉及跨域控制器，所以可以直接在同区域内的两个PE之间发布VPN路由信息，然后根据这些路由信息转发流量。 在SRv6 TE模式下，由于部署方式不同，可能无法创建端到端的SRv6策略，需要自己规划路径来引导流量。在这一过程中，ASBR需要能够与自身进行多段隧道建立，例如从PE到ASBR、ASBR到ASBR以及从ASBR到PE等。当转发VPN流量时，需要将路由信息组合成全局可达的路径。 总的来说，相比旧版的英文标准文稿，新的中文版对相关技术细节进行了更详细的描述，同时增加了更多场景示例和流程图，使得理解起来更加直观易懂。同时，也明确了后续版本中需要增加的内容。
Unknown
Unknown
- Title: Shared Brotli Compressed Data Format
- Authors: Jyrki Alakuijala(jyrki@google.com), Thai Duong(thaidn@google.com), Evgenii Kliuchnikov(eustas@google.com), Zoltan Szabadka(szabadka@google.com), Lode Vandevenne(lode@google.com)
- Summary: 这篇文档是关于共享压缩格式的详细描述。它扩展了 brotli 数据格式，提供了对共享字典的支持，以及增强了窗口支持和帧结构。 主要目的包括： 1. 增加了对共享字典的支持，可以将字典作为压缩数据的一部分进行使用。 2. 支持更大的压缩窗口，允许更长的数据序列被压缩得更小。 3. 提供了一个框架来存储多个资源，并包含共享字典，使得它们可以作为一个整体进行处理。 4. 通过重新定义压缩块头中的某些字段，使得新格式能够与现有的 brotli 解码器兼容。 总结来说，本文是关于如何在现有 brotli 压缩格式的基础上，增加对共享字典、大窗口以及帧结构的支持，以提供更好的压缩性能。
- Diff: 新版本的英文标准文稿定义了共享比特压缩数据格式的结构，包括新的功能和改进： 1. 共享比特压缩数据格式扩展了比特压缩数据格式，支持共享字典、大窗口和容器格式。 2. 在新的框架下，可以存储多个资源并引用字典。 3. 支持字典共享，实现静态上下文共享，以增加压缩性能。 4. 采用增量编码方式处理距离和窗口位。 5. 提供了可变长度的字典流，并允许动态选择字典。 6. 增加了小窗口模式和距离字母表限制。 7. 定义了帧格式流，提供了多资源容器。 总的来说，主要区别在于增加了字典共享，增强了大窗口能力，并引入了新的帧格式。这些变化有助于进一步提高比特压缩数据格式的性能。
- Title: Efficient RDAP Referrals
- Authors: Gavin Brown(gavin.brown@icann.org), Andy Newton(andy@hxr.us)
- Summary: 本文主要讨论了如何使用HTTP“链接”头部字段在注册数据访问协议（RDA，描述于[RFC7480][RFC7481], [RFC7481], [RFC9082], [RFC9083]等）资源上提供HTTP“链接”头字段以允许RDA客户端高效地确定与资源相关的相关RDA记录的URL。文稿提出了一种方案，即当用户请求一个RDA资源时，服务器可以响应并提供这些关联的RDA资源的URL，而不需要通过其他机制告知服务器其仅对获取这些URL感兴趣。该解决方案旨在减少客户端和服务器之间的通信开销，并提高性能。
- Diff: 以上新的英文标准文档（高效RDAP引用）与旧版的主要区别在于： 1. 新版本中引入了`registrar_link_header`这个扩展点，使得服务器可以在响应头中提供注册商RDAP记录的链接。 2. 在HTTP头部字段方面，引入了`Link`头来描述两个资源之间的关系，这种描述方式更符合HTML中的``元素。 3. 对于GET和HEAD请求，新版本要求服务器在每个指向RDAP资源的链接对象中包含一个`Link`头，同时也可以包括指向其他类型资源的链接。 4. 对于获取元数据的HTTP HEAD请求，如果找不到相关的`Link`头，则可以尝试进行GET请求以提取相关链接。 5. 新版本的文档提供了对服务器端行为规范的正式定义，并指定了特定的联系方式和发布信息。 总的来说，新版本更注重实际应用需求，增强了接口设计的灵活性和可伸缩性，使服务提供商能够根据具体业务需求灵活调整响应策略。
- Title: A method for describing changes made to an email
- Authors: Bron Gondwana(brong@fastmailteam.com)
- Summary: 本文提出了一个描述电子邮件修改的方法，以解决由于邮件修改而无法验证的问题。通过使用Delta格式，可以精确地描述修改后的头部和正文部分，并且可以确定更改的具体原因以及受影响的中间件。此外，该方法还可以应用于复杂情况下的Docker容器镜像，从而确保在多个系统之间复制数据时能够准确无误。 Delta格式采用完整替换的方式处理头部，例如删除主题行、从地址等；同时也可以对正文进行处理，比如添加回复到选项。针对安全方面，文中也详细讨论了可能存在的问题和解决方案。最后，还介绍了IANA考虑事项，如不适用性和兼容性。总之，本文提供了一种有效的方法来管理复杂的电子邮件修改，并保护接收者的利益。
- Diff: 新的文档在背景和动机、Delta格式-头文件、Delta格式-身体、签名覆盖、迭代应用、安全等方面与旧版本有所不同。 在背景和动机部分，介绍了使用DKIM修改的方法，以及如何描述邮件中的变化以确定恶意更改或确认原始邮件未被篡改。 Delta格式-头文件部分，提出了Delta格式来表示邮件头部的变化，包括完全替换所有特定名称的头信息。 Delta格式-身体部分，提供了简单的文本格式化方法，用于表示从输出复制到输入的部分数据范围，以便重创建始状态的邮件。 签名覆盖方面，DKIM2签名覆盖了所有DKIM2-Diff-Body和DKIM2-Diff-Header头信息，为验证目的提供了一个基本框架。 迭代应用部分，说明了如何依次应用算法来恢复原始消息，并确保其完整性。 安全性方面，未具体提及旧版本与新版本之间的差异。 在IANA考虑方面，没有提到旧版本和新版本的具体区别。 在参考文献部分，也没有给出任何具体的引用。 总的来看，新版本主要在Delta格式和Delta格式-身体这两个方面进行了改进和扩展，而其他部分保持了相似性。