今日共有21篇文稿更新，涉及6个area里的16个WG

ART

ecrit

1. draft-ietf-ecrit-lost-planned-changes-12

  • Title: Validation of Locations Around a Planned Change
  • Authors: Brian Rosen(br@brianrosen.net)
  • Summary: 本文定义了一个延伸到位置到服务翻译协议（LoST）（RFC5222）的新接口，该接口允许LoST服务器通知客户端计划更改的位置信息。这个新接口仅对验证功能有用，对于没有验证功能的LoST客户端来说是无用的。它允许一个LoST客户端请求在特定日期前进行位置数据的验证，这样当先前有效的记录变为无效时，或者新的记录变得有效时，可以及时更新位置数据。 此外，本文还提供了一个常规XML规范，用于替代之前使用的RelaxNG标准。它也可以与其他ISO标准兼容，例如ISO 17442和ISO 19931。
  • Diff: 该文档定义了一个扩展到Location to Service Translation（LoST）协议的功能，允许LoST服务器通知客户端计划中的位置数据变更。这主要是针对验证功能，便于维护和同步数据。在旧版本中，由于RelaxNG格式不被广泛支持和理解，使用了更复杂的XML格式代替，但没有提供一个统一的规范。而在新版本中，使用了规范的XML格式，并提供了替代的Schema文件，使得不同的实施可以互操作。此外，在新版本中还引入了新的元素如"asOf"、"revalidateAfter"等，这些都使得协议更加完善和易用。 总体来说，新版本的主要区别在于： 1. 使用规范的XML格式，简化了开发工作并降低了学习成本。 2. 引入了"asOf"和"revalidateAfter"两个关键元素，帮助客户端提前规划数据更新，避免盲目重新验证。 3. 提供了标准化的替换XML Schema，以兼容旧版的RelaxNG形式。 这些改进使LoST协议变得更加稳定和易于维护。

sipcore

1. draft-ietf-sipcore-siprec-fix-mediatype-00

  • Title: Updates to SIPREC correcting Metadata Media Type
  • Authors: Dan Mongrain(dan.mongrain@motorolasolutions.com)
  • Summary: 本文主要对RFC 7865和RFC 7866两份文件进行修正，以正确标注SIP媒体录制（SIPREC）协议中的录音元数据。文中指出，在这两份文档中都存在错误，因为它们使用了不同的媒体类型来标识录音元数据，并且没有将新的媒体类型注册到IANA。因此，本文更新了RFC 7866，使其与RFC 7865保持一致，同时向IANA提交了新的媒体类型“application/rs-metadata+xml”。此外，本文还提供了相关的安全性、IANA考虑等信息。

INT

6man

1. draft-templin-6man-omni3-25

  • Title: Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces
  • Authors: Fred Templin(fltemplin@acm.org)
  • Summary: 本文主要讨论了IPv6下，多接口网络（OMNI）技术的基本概念和结构。文中详细描述了OMNI接口模型、最大传输单元（MTU）、适应层（OAL）服务、Ethernet兼容性链路层帧格式、地址映射等关键概念和技术细节。同时，还对IP头部扩展、端到端路由、安全措施等方面进行了讨论。总的来说，本文提供了关于如何在多接口环境中进行IPv6通信的技术指南。
  • Diff: 是关于在多链路网络（OMNI）接口上传输IP包和控制消息的技术文档。主要介绍了以下几点： 1. 基于端到端多链路原则，客户端可以将多个独立的下层接口视为单一逻辑链路来实现通信性能和可靠性目标。 2. 支持基于移动性和多网段的跨段多路径拓扑。 3. 提供了面向连接服务以支持安全可靠的服务传递，如安全重定向、代理服务器容错等。 4. 定义了扩展协议用于管理多链路网络中的动态变化，并为多链路网络提供地址映射。 5. 定义了与IPv4兼容的数据包重组算法，以及IPv6兼容的地址映射模型。 6. 定义了物理层帧格式、OMNI地址族和节点标识符等相关技术细节。 与之前的英文标准文稿相比，该文稿的主要区别在于对OMNI架构的理解更为深入，不仅包括多链路特性，还包括多网段环境下的部署方法和多链路路由策略。此外，增加了对IPv6扩展协议的支持，进一步增强了网络性能和可靠性。总体而言，本文旨在为OMNI架构提供详细的实现指南和技术规范。

intarea

1. draft-chroboczek-intarea-v4-via-v6-02

  • Title: IPv4 routes with an IPv6 next hop
  • Authors: Juliusz Chroboczek(jch@irif.fr), Warren "Ace" Kumari(warren@kumari.net), Toke Høiland-Jørgensen(toke@toke.dk)
  • Summary: 本文主要讨论了IPv4路由中的IPv6下一个跳地址问题。在当前的网络架构下，路由器往往需要为每个IPv4地址分配一个相应的IPv6地址作为下一个跳地址。然而，这种方式限制了网络的灵活性，因为没有IPv4地址就无法使用传统的IPv6路由协议。 本文提出了“v4-via-v6”（IPv4通过IPv6）技术，允许IPv4路由跨越仅使用IPv6地址配置的网络，从而构建无IPv4地址但依然可以与边缘主机进行IPv4通信的网络。这一技术可以减少对静态配置的依赖，并使网络的核心部分没有固定IP地址，从而降低手动配置的工作量。 此外，文稿还探讨了IPv4路由与IPv6路由之间的相互兼容性以及可能遇到的一些挑战和解决方法。例如，在一些IGP中，如多拓扑路由协议（OSPF），支持IPv4和IPv6路由混合发布；IPv4路由信息可以携带IPv6下一个跳地址来实现IPv4到IPv6的转换。 最后，文稿指出了在实际部署过程中可能出现的安全性和隐私方面的考虑，并强调了未来文档整理的重要性。总体而言，该文旨在提供一种更加灵活、安全且高效的技术解决方案，以满足未来的互联网需求。
  • Diff: 该文档提出了一种名为“v4-via-v6”的技术，它允许IPv4路由通过IPv6下一跳地址进行传播。这样做的目的是为了建立一个只有IPv6地址的网络区域，并且仍然提供IPv4服务。与传统的IPv4下一跳路由不同，这种技术使用了IPv6下一个跳地址来构建路由表。同时，由于IPv6下一个跳地址可以是自动配置的，因此使用这样的路由还可以减少对静态分配IPv4地址的需求。 与旧版本相比，本文档的主要区别在于： 1. 简化了文档结构和格式，使其更易于阅读。 2. 对一些概念进行了扩展，例如IPv4下一跳地址、IPv6下一个跳地址等。 3. 提供了一些实用案例和示例，帮助读者更好地理解这个技术。 4. 更详细地讨论了IPv4下一跳路由的可能安全问题以及如何解决这些问题。 总的来说，新的版本更加详实、清晰，适合专业人士阅读和参考。

ntp

1. draft-ietf-ntp-update-registries-17

  • Title: Updating the NTP Registries
  • Authors: Rich Salz(rsalz@akamai.com)
  • Summary: 本文主要对网络时间协议(NTP)和网络时间安全(NTS)中的注册表进行了更新。更新了NTP的几个重要注册表，包括Reference ID、Kiss-o'-Death、Extension Field Types以及网络时间安全（NTS）的某些注册表。 更新后的注册表更严格地遵循了标准规范要求，例如，所有新添加的字段都限定了长度为ASCII字符或数字，并且在编码方式上也有所变化。此外，还新增了一些新的注册表，如NTS Key Establishment Record Types和NTS Next Protocols等，以满足NTS的安全需求。更新后的新注册表有助于确保网络时间服务的稳定性和安全性。
  • Diff: 本文是关于更新网络时间协议(NTP)和网络时间安全(NTS)文档中的注册表的文档。 主要区别在于： 1. 修改了NTP参考标识符代码规则，要求使用ASCII字母或数字，并明确说明了保留值。 2. 对扩展字段类型进行了更新，将范围从0x0000到0xFFFF的字段标记为实验性用途，避免与原实施不符的应用产生兼容问题。 3. 更新了NTS注册表，增加了新的注册项，如NTS错误码、警告码等，以及对一些已有的字段进行修改以符合当前的编码规则和处理方式。 以上这些变化使得规范更加完整且准确地反映了NTP和NTS的实际使用情况。

OPS

dnsop

1. draft-ietf-dnsop-rfc8624-bis-03

  • Title: DNSSEC Cryptographic Algorithm Recommendation Update Process
  • Authors: Wes Hardaker(wjhns1@hardakers.net), Warren "Ace" Kumari(warren@kumari.net)
  • Summary: 本文主要更新了DNSSEC协议中的算法推荐和使用指南，将现有的DNSSEC算法要求与建议从RFC8624移至IANA注册表。通过这种方式，可以更方便地进行更新，并使未来的更改更容易发布和参考。新增的使用和实施建议有助于确保DNS解析器和权威服务器之间的兼容性，同时为未来的扩展做好准备。本文还引入了新的算法需求等级，并给出了相应的推荐值。总的来说，本文旨在简化DNSSEC实施过程，提供更好的安全性保障。 请注意，由于这是摘录自标准文档，实际文稿会包含更多的细节和例子，这里只是概括性的总结。
  • Diff: 新的DNSSEC算法更新规范文档（draft-ietf-dnsop-rfc8624-bis-03）在以下几个方面进行了改进： 1. 将现有的DNSSEC算法要求和建议从RFC8624转移至IANA登记册，以使它们更易于管理和参考。 2. 在“DNS系统算法数字”表中添加了用于DSS签名（DS）资源记录（RR）类型摘要算法的推荐值为MAY的列。 3. 在“摘要算法”表中添加了用于DNSSEC授权签名（DS）资源记录（RR）类型的摘要算法的推荐值为MAY的列。 4. 增加了两个新的推荐值：对于用于DSS验证的摘要算法，使用推荐值MAY；对于用于DSS授权签名的摘要算法，使用推荐值MAY。 5. 对于摘要算法和签名算法，都增加了实施推荐值为MAY的列。 6. 这些更改使得DNSSEC算法选择更加容易理解，并且可以更好地反映当前的最佳实践。 与旧版文档相比，新文档的主要区别在于它将现有的算法要求和建议转移到了IANA登记册中，并允许在未来进行更改。此外，这些更改使得DNSSEC的选择过程更容易管理，并且有助于标准化和兼容性。

sidrops

1. draft-ietf-sidrops-aspa-profile-19

  • Title: A Profile for Autonomous System Provider Authorization
  • Authors: Alexander Azimov(a.e.azimov@gmail.com), Eugene Uskov(eu@jetlend.ru), Randy Bush(randy@psg.com), Job Snijders(job@sobornost.net), Russ Housley(housley@vigilsec.com), Ben Maddison(benm@workonline.africa)
  • Summary: 本文定义了一个用于自治系统提供商授权（ASPA）对象的加密消息语法（CMS）保护内容类型，用于在资源公钥基础设施（RPKI）中使用。ASPA是通过数字签名来证明的一个对象，其中包含了关于一个自治系统的标识持有人（客户自治系统，CAS）及其提供的其他自治系统（ASes）的信息。本文提供了ASN.1语法和元数据格式，以及验证ASPA的有效性步骤，并描述了IANA注册的相关细节。 主要总结如下： 1. 提供了ASN.1语法定义了ASPA的内容类型。 2. 定义了ASPA的内容，包含客户ASID、提供者列表等信息。 3. 描述了验证ASPA的有效性的过程。 4. 增加了相关的IANA注册信息。 该文档为实施者和操作人员提供了指导，以确保正确使用ASPA来进行路由验证。它还提供了有关如何实现、实施和测试ASPA的具体建议和最佳实践。
  • Diff: 以上新版英文标准文稿定义了一个名为Autonomous System Provider Authorization (ASPA)的对象保护的加密消息语法（CMS）内容类型，用于在资源公共密钥基础设施（RPKI）中作为认证对象使用。该文档的主要区别在于： 1. 该内容型对象由客户自治系统（AS）表示，并指定其授权实体为AS的提供商或延伸节点（IXP路由服务器）。此外，它还包含了列表中的一个AS及其所代表的运营商。 2. ASPA对象包含了一组授权的AS，这些AS被指定为该客户的提供商网络。当验证时，用户可以将ASPA对象用于检测和缓解路由泄漏。 3. 比较旧版，新的草案提出了更高的验证要求，并建议对特定情况下超过上限值的AS数量进行处理。同时，该草案新增了关于RPKI签名对象、证书注册机构等的新考虑点。这体现了随着互联网发展的需要，草案在安全性、结构等方面有了进一步的发展。

RTG

idr

1. draft-ietf-idr-ts-flowspec-srv6-policy-05

  • Title: Traffic Steering using BGP FlowSpec with SR Policy
  • Authors: Jiang Wenying(jiangwenying@chinamobile.com), Yisong Liu(liuyisong@chinamobile.com), Shunwan Zhuang(zhuangshunwan@huawei.com), Gyan Mishra(gyan.s.mishra@verizon.com), Shuanglong Chen(chenshuanglong@huawei.com)
  • Summary: 主要介绍了在SR（源路由）网络中，通过BGP流量规格导SR政策的方法。这种方法可以用于SR-MPLS和SRv6应用场景，例如通过携带流量规格信息到头端设备进行分发，并根据流量规格选择合适的路径。该技术还可以用来指示尾端功能，如断点服务等。此外，文稿还讨论了可能的错误处理方式以及使用的安全措施。 总结而言，本文提出了一种利用BGP流量规格导SR策略的技术，以提供更有效的流量引导和控制，适用于SR-MPLS和SRv6网络。
  • Diff: 以上是针对的新版本文档总结。 在内容方面，相较于旧版本，该文档主要增加了以下几方面的区别： 1. 提出了BGP流规格使用方法，可以在SR Policy中指导数据流进入特定的SR Policy，并指示尾端设备的功能信息（如端点函数）。 2. 涉及了SR-MPLS和SRv6应用场景的介绍，包括定义了SR-MPLS、SRv6的概念和它们各自的数据包转发模型。 3. 对于SR-MPLS和SRv6，提供了具体的操作示例和运行代码，包括如何设置SR Color Extended社区和Flow-spec Redirect到IPv4和IPv6 Next-hop动作等。 4. 对于SR-MPLS和SRv6应用案例进行了详细介绍，展示了如何通过BGP流量规格进行数据流的引导和处理。 总的来说，新版本不仅丰富了文档内容，还更加具体地介绍了如何在不同场景下使用BGP流规格实现流量调度，这对于推动SR-MPLS和SRv6网络的发展具有重要意义。


2. draft-ietf-idr-sr-policy-nrp-02

  • Title: BGP SR Policy Extensions for Network Resource Partition
  • Authors: Jie Dong(jie.dong@huawei.com), Zhibo Hu, Ran Pang(pangran@chinaunicom.cn)
  • Summary: 本文件定义了在BGP协议中扩展SR策略，以指定网络资源分区（NRP）的机制。该机制允许通过BGP分发不同NRP相关的SR策略候选路径。 文稿主要分为以下几个部分： 1. 引言：介绍了SR策略、网络资源分区的概念和工作原理。 2. NRP标识符的定义：在BGP隧道封装属性中添加一个新的子TLV - NRP子TLV，用于指定SR策略与特定NRP的关系。 3. 程序设计：在使用SR策略进行流量分配时，需要确保每个SR策略都与一个或多个NRP关联，并将相关的信息附加到SR策略的候选路径上。 4. 可扩展性考虑：讨论了增加额外信息带来的影响以及如何在数据包中编码NRP子TLV以实现SR策略的不同实例。 5. 安全性考虑：总结了BGP和BGP SR策略的相关安全措施。 6. 互连网地址组织：没有对IANA注册表进行更新。 总的来说，本文旨在提供一种新的方法来支持网络切片服务，同时保持网络切片的可扩展性和安全性。它还为未来的研究提供了指导原则。
  • Diff: 在新的标准文档中，增加了关于网络资源分区（NRP）标识SR政策的子标签。这个子标签可以在BGP隧道封装属性中携带，并且在接收SR政策路由时，如果该路由被选为最佳路径，则头节点需要将NRP标识和选定的候选路径段列表附加到发送给SR政策的包的头部中。此外，还讨论了SR政策如何通过BGP进行扩展来支持不同网络资源分区的网络切片服务。 与旧版本相比，主要有以下几点区别： 1. 新版文档增加了对网络资源分区标识子标签的支持。 2. 支持使用BGP分发SR政策候选路径。 3. 定义了如何指定SR政策和网络资源分区之间的关系，以使对于服务流量可以附加相关的信息。 4. 提出了网络切片服务可以通过网络资源分区实现的概念。

lsvr

1. draft-ietf-lsvr-applicability-20

  • Title: Usage and Applicability of BGP Link-State Shortest Path Routing (BGP-SPF) in Data Centers
  • Authors: Keyur Patel(keyur@arrcus.com), Acee Lindem(acee.ietf@gmail.com), Shawn Zandi(szandi@linkedin.com), Gaurav Dawra(gdawra.ietf@gmail.com), Jie Dong(jie.dong@huawei.com)
  • Summary: 这篇文档讨论了BGP链路状态最短路径路由(BGP-SPF)技术在使用Clos或胖树拓扑的数据中心网络中的适用性和必要性。文稿首先概述了BGP-SPF技术及其在数据中心网络中的优势，如简化三层路由和操作，提高收敛速度等。 然后，它解释了为什么需要在数据中心网络中部署BGP-SPF扩展，并提供了简化的指导原则来部署这种技术。文稿进一步讨论了BGP-SPF技术在Clos网络中的具体应用场景、部署模型以及与传统BGP网络的兼容性。 最后，它总结了BGP-SPF技术如何改进数据中心网络的收敛，同时保留了传统BGP的优势，并指出非CLOS或胖树拓扑下也可以部署这种技术。 总的来说，该文档为数据中心网络管理员提供了一种简单的方法来实现更高效的三层路由和操作，同时也指出了非CLOS或胖树拓扑下的潜在可能性。
  • Diff: 该文档为（网络工作小组、K. Pat

mpls

1. draft-ietf-mpls-p2mp-bfd-09

  • Title: Bidirectional Forwarding Detection (BFD) for Multipoint Networks over Point-to-Multi-Point MPLS Label Switched Path (LSP)
  • Authors: Greg Mirsky(gregimirsky@gmail.com), Gyan Mishra(gyan.s.mishra@verizon.com), Donald E. Eastlake 3rd(d3e3e3@gmail.com)
  • Summary: 该文档详细描述了使用双向检测（BFD）协议在多点网络中的应用，特别是对于多路径多点（p2mp）标签交换路径（LSP）和分段路由（SR）的多点政策。它还讨论了IPv6链路本地地址的适用性，并建议使用IPv6链路本地地址代替IPv4链路本地地址。此外，它还提供了对头通知的描述，以解决多点网络中的数据平面与控制平面之间的不一致问题。 总结：该文档概述了使用双向检测（BFD）协议在多点网络中的应用，特别针对p2mp标签交换路径和分段路由的多点政策。同时，也强调了IPv6链路本地地址的适用性和建议使用IPv6链路本地地址代替IPv4链路本地地址的方法。此外，还提供了解决多点网络中数据平面与控制平面之间不一致问题的头通知方法。
  • Diff: 摘要 本文档描述了使用双向检测（BFD）在多点网络中检测数据平面故障的方法，以及如何将BFD协议用于多点或多播网络中的分组转发等价类（P2MP）标签交换路径（LSP）。同时更新了[RFC8562]并推荐IPv6地址为多点头和尾分配的唯一标识符，并指出IPv4映射到IPv6的唯一标识符应避免使用。 该文档还讨论了如何通过头部通知尾部来对多点MPLS LSP进行故障检测，以及在多点MPLS LSP上如何使用头部来验证控制平面与数据平面的一致性。此外，它讨论了使用头部的通知方法，例如无响应模式。 总的来说，该文档介绍了如何利用BFD检测多点MPLS LSP上的数据平面故障，并提供了相应的解决方案。

pce

1. draft-ietf-pce-stateful-interdomain-06

  • Title: PCEP Extension for Stateful Inter-Domain Tunnels
  • Authors: Olivier Dugeon(olivier.dugeon@orange.com), Julien Meuric(julien.meuric@orange.com), Young Lee(leeyoung@huawei.com), Daniele Ceccarelli(dceccare@cisco.com)
  • Summary: 本文是关于在多协议标签交换路径工程(MPLS-TE)/一般化多协议标签交换(GMPLS)标签交换路径上建立跨域路径的一种新方法。这种新的方法允许在不使用另一侧边界路由器之间进行信号的情况下,通过本地区域边缘节点(BN)和下游边界的特定连接来构建跨域路径。 该方法利用了状态机计算路径(compute path)模式以及双向递归(backward recursive)或分层(hierarchical)机制。通过使用一个定向回路标签(stitching label)和一个新的关联类型(new association type),本文定义了用于跨越不同行政区域的路径的两种新的协议能力。此外,还定义了新的PCEP通信协议、新的PCE标识符(PCEP Capability)、新的PCE通知(Type)和新的PCE错误值(Error)。这些概念使操作员能够灵活地构建意图基于网络的业务。 本文主要关注如何在跨域环境中使用PCEP直接将跨域路径设置为隧道。它强调了在不依赖于标签交换协议(IS-IS)等其他跨行政区域信号的情况下实现这一点的重要性。文稿最后总结了这些技术如何有助于构建安全可靠的跨域网络环境,并给出了相应的考虑和建议。
  • Diff: 这个新的版本标准文稿的主要区别在于： 1. 定义了“缝合标签”（Stitching Label）的概念，用于在不使用RSVP-TE或段路由的情况下，通过PCEP直接进行端到端路径的串接和嵌套。 2. 对于隧道、路由和协议进行了简化和扩展，以满足状态化路径计算元素（PCE）的需求。它定义了新的关联类型（Association Type）、新的PCEP通信协议（PCEP Capability）以及新的PCE错误值（PCE Errors）和通知类型（PCE Notifications）。 3. 在隧道和路由协议的管理方面，引入了新的PCE能力（Inter-Domain PCE Capability），允许跨域路径的创建，并定义了新的区域边界节点（BN）接口，来支持跨域路径的建立。 4. 针对安全考虑，提供了关于PCEP连接的安全措施建议，如设置TE-PATH-BINDING TLV中的标识符（BSID）并限制其范围。 总的来说，这个新的标准文稿简化了现有技术架构，使得操作者能够独立地设置跨域路径，并且避免了需要跨域网络边界的信息交换，从而提高了网络的灵活性和安全性。


2. draft-ietf-pce-pcep-extension-pce-controller-sr-10

  • Title: PCE Communication Protocol (PCEP) Extensions for Using PCE as a Central Controller (PCECC) for Segment Routing (SR) MPLS Segment Identifier (SID) Allocation and Distribution.
  • Authors: Zhenbin Li(lizhenbin@huawei.com), Shuping Peng(pengshuping@huawei.com), Mahendra Singh Negi(mahend.ietf@gmail.com), Quintin Zhao(quintin.zhao@huawei.com), Chao Zhou(chaozhou_us@yahoo.com)
  • Summary: 本文主要讲述了在SDN架构下，如何使用软件定义网络（Software-Defined Networking, SDN）技术将路径计算功能从路由器移交给集中控制器（Central Controller, PCE）。通过引入PCECC（PCE Central Controller Control Plane），可以实现对路径进行优化配置、流量调度等功能。同时，该协议还支持在段路由（Segment Routing, SR）环境中，为SR节点分配和分发SID（Segment Identifier）。 文中详细介绍了PCECC的工作流程，包括状态机模型、新的路径操作功能、以及SR-SID的分配与分布等。此外，还讨论了PCECC的安全性和可管理性要求，并提出了相应的建议。 总的来说，本文提供了在SDN环境下，如何利用PCECC简化控制平面设计和提升控制能力的一种方法。它也指出了未来可能需要考虑的一些扩展方向，如标识空间管理和PCEP协议的进一步扩展。
  • Diff: 这篇新的英文标准文档对软件定义网络（SDN）下的边缘控制器（PCECC）进行了扩展，以简化分层控制平面的处理。与旧版不同的是： 1. 新增了支持PCECC-SR功能的协议扩展。 2. 定义了新的对象类型和TLV字段，用于承载SR-SID信息。 3. 支持节点/端点标签（SID）的集中分配和分发。 4. 提供了用于同步SR-SID分配的信息交换机制。 5. 在TCP会话期间使用不同的IP地址来避免与SR节点/端点标签映射相关的负面影响。 总的来说，新版标准文档提供了在SDN环境中的PCECC-SR架构下进行SR-MPLS配置、路径计算及标签分发的新方法。它消除了依赖于传统路由协议的问题，并为SR引入了一种新的治理方式。

teas

1. draft-ietf-teas-5g-ns-ip-mpls-14

  • Title: A Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies
  • Authors: Krzysztof Grzegorz Szarkowicz(kszarkowicz@gmail.com), Richard Roberts(rroberts@juniper.net), Julian Lucek(jlucek@juniper.net), Mohamed Boucadair(mohamed.boucadair@orange.com), Luis M. Contreras(luismiguel.contrerasmurillo@telefonica.com)
  • Summary: 本文主要介绍了在5G网络架构中，如何使用现有IP/MPLS技术实现运输网络中的切片。文中首先概述了运输网络在5G架构中的角色，以及5G切片和运输网络切片的区别。接着介绍了一个基于服务提供者网络（PN）和客户站点（CS）之间的管理协调来实现实现5G切片的方法。 该方法通过建立一个单个资源分区（NRP），并利用现有的技术和工具来控制运输网络中的切片连接服务级别协议（SLAs）。具体来说，本文描述了以下关键点： 1. 描述了运输网络的定义，包括物理层、传输层和服务层等。 2. 强调了5G切片与运输网络切片的概念区别，并讨论了两者之间可能存在的不同之处。 3. 提出了针对运输网络切片的一个参考设计模型，以明确其管理和组织的边界。 4. 简要介绍了实现5G切片的一些关键技术，如Layer 2虚拟私有网络（L2VPN）和Layer 3虚拟私有网络（L3VPN）服务实例等。 5. 描述了5G切片的分段逻辑，包括运营商网络和客户站点之间的协调机制。 总结起来，本文旨在为移动通信领域内如何充分利用现有技术实现运输网络中的切片提供了一种实用的技术解决方案。
  • Diff: 本文是关于将5G网络中的切片与运输网络（TN）结合在一起以实现网络服务的一种方法。主要内容包括： 1. 描述了5G网络中的切片融合在运输网络中的应用场景。 2. 对于5G切片而言，切片管理需要依赖于现有IP/MPLS技术来控制端到端的服务水平协议（SLA），以便满足5G切片的需求。为了做到这一点，本文描述了一个基于运输网络资源的切片实现实例模型。 3. 模型使用层2虚拟私有网络（L2VPN）和/或层3虚拟私有网络（L3VPN）服务实例进行逻辑隔离、精细的资源控制以及粗略的资源控制。此外，它还利用带宽规划/管理能力，如容量计划/管理。 4. 文档假设这些实施方法可以提供实用的实施方法，并且可以利用现成可用的技术，例如服务提供商网络中的现有的技术和组件，来实现网络切片。然而，文档并不试图定义必须遵守的机制来实现网络切片。 5. 实施该方案的主要区别在于：5G切片被看作是从3GPP移动网络中引入的概念，而运输网络（TN）则作为一个非3GPP管理系统被视为一个独立的部分。 6. 由于该文档重点放在5G切片的实现上，因此不讨论如何从3GPP移动网络中的切片出发来实现运输网络切片。 总的来说，本文提出了一种将运输网络中的切片与5G切片相结合的方法，从而实现了服务级别协议的要求。但是，它没有详细说明如何从3GPP移动网络切片中创建运输网络切片。

SEC

lamps

1. draft-ietf-lamps-header-protection-25

  • Title: Header Protection for Cryptographically Protected E-mail
  • Authors: Daniel Kahn Gillmor(dkg@fifthhorseman.net), Bernie Hoeneisen(bernie@ietf.hoeneisen.ch), Alexey Melnikov(alexey.melnikov@isode.com)
  • Summary: 本文主要讨论了电子邮件加密保护机制，包括如何提供邮件头部的加密保护。本文更新了S/MIME 3.1版本中的头部保护机制，并提供了新的加密保护方案，以减少头部保护对传统邮件用户代理（MUA）的影响。此外，还给出了发送、接收和回复头部保护的消息样例以及建议的安全措施。 具体来说，本文首先介绍了RFC8551头部保护机制及其缺点，如无法与一些旧版MUA兼容，导致头部保护效果不佳；无法保证消息的有效性和安全性。然后，它提出了一种新的头部保护机制，该机制使用直接将头部字段复制到加密数据中而不使用中间消息/RFC822 MIME对象来保护头部字段。这种新机制提供了更好的用户体验和安全性能，减少了旧版MUA处理问题的可能性。 另外，文稿还指出了其他可以用来保护电子邮件头部字段的协议，例如DKIM+DMARC。但是，这些协议通常应用于MTP客户端，而本文档专注于S/MIME保护方式，因此没有明确考虑与其他头保护机制的关系。 总的来说，本文提供了一个可扩展的、可定制化的头部保护机制，以满足现代邮件系统的需求，同时保持了旧版MUA的兼容性。这有助于确保头部字段的安全性和隐私性，同时也为未来的头部保护协议预留了空间。
  • Diff: 新的RFC 8551更新版文档对加密邮件中的头部保护做了以下关键改进： 1. 直接在密文消息的密钥包（Cryptographic Payload）中复制所有头部字段，不再需要中间的message/rfc822 MIME对象。 2. 在加密消息中，某些头部字段可以被屏蔽以提供额外的隐私和安全性。 3. 定义了如何确保发送者明确地表示他们希望提供头部保护，并且接收方能够检测到任何可能已经修改头部信息的情况。 4. 提供了更多关于如何使用这个机制来生成、处理和回复加密邮件的指导性建议。 5. 为发送和接收的MUA提供了更好的兼容性。 总的来说，新的RFC 8551更新版简化了头部保护的实现方式，使得大多数Legacy MUA都能正常处理并理解这种加密消息格式，从而提高了其可操作性和互操作性。

oauth

1. draft-ietf-oauth-cross-device-security-09

  • Title: Cross-Device Flows: Security Best Current Practice
  • Authors: Pieter Kasselman(prkasselman@gmail.com), Daniel Fett(mail@danielfett.de), Filip Skokan(panva.ip@gmail.com)
  • Summary: 本文主要讨论了对跨设备流攻击的安全保护措施。首先，介绍了威胁以及相应的防护措施，包括实际分析结果和最佳实践建议。其次，详细讨论了各种可能的攻击方式，例如用户传输会话数据模式、回传会话模式、用户传输授权数据模式等，并给出了具体的防御策略。最后，总结了协议选择指南，提出了如何在使用受攻击的协议时保持安全的最佳方法。
  • Diff: 本文档详细介绍了跨设备授权和跨设备会话转移威胁及其防护措施。主要内容包括： 1. 强调实施者需要评估风险，并在实施跨设备流之前进行风险评估。 2. 推荐使用跨设备流时避免使用易受攻击的协议。 3. 提供了基于现有分析结果的安全策略建议，这些分析涉及潜在的漏洞。 与旧版本相比，新版本的主要区别在于： 1. 增加了对当前安全状况的理解：提供了更全面的威胁分析、解决方案和最佳实践指南。 2. 强化了对于特定威胁类型（如Cross-Device Consent Phishing和Cross-Device Session Phishing）的理解和应对策略。 3. 提供了更多关于协议选择的信息，以便实施者可以有效地利用已知的可用信息来设计并构建保护系统。 4. 在引入新的概念和技术方面，本文档更新了现有的参考文献列表，以反映最新的研究进展。

sshm

1. draft-ietf-sshm-chacha20-poly1305-00

  • Title: Secure Shell (SSH) authenticated encryption cipher: chacha20-poly1305
  • Authors: Damien Miller(djm@djm.net.au), Simon Josefsson(simon@josefsson.org)
  • Summary: 本文描述了SSH协议中的一个新加密算法，名为chacha20-poly1305。该算法由两个部分组成：ChaCha20和Poly1305。 首先，ChaCha20是一个基于流密码的设计，它将固定位（128位）、128或256位密钥、64位非空序列号和64位计数器转换为输出，用于生成一个用于加密数据的流式密钥。然后，Poly1305是一个单次Carter-Wegman消息认证码，使用一个256位秘密密钥计算一个128位完整性标签。 chacha20-poly1305将这两个组件组合成一种验证加密模式。这种组合方式利用了ChaCha20和Poly1305的安全性，并且在关键处理上避免了作为解密Oracle的潜在漏洞。该算法提供了一种独立的密钥实例来加密长度字段，这样可以保护数据输入而不破坏对包payload的解密能力。 最后，chacha20-poly1305要求每个包都必须先被解密以获取长度，然后通过两个独立的密钥实例来计算MAC。如果接收方能够预先解密并使用长度字段进行解密，则此攻击者可以通过预测MAC值而获得包内部信息，包括其完整性和内容。为了防止这种情况发生，应该确保每次发送包时都要加密整个包，而不是仅解密长度字段。此外，在解密过程中应检查MAC，以防第三方尝试破解密钥或重放攻击。 总的来说，chacha20-poly1305提供了更安全的数据传输机制，特别是在保证数据完整性的同时，还允许数据包长度不公开的情况下传输。然而，由于其独立的密钥实例，因此在实际应用中需要谨慎考虑如何实现最佳安全性。

WIT

ccwg

1. draft-miao-ccwg-hpcc-03

  • Title: HPCC++: Enhanced High Precision Congestion Control
  • Authors: Rui Miao(rmiao@meta.com), Surendra Anubolu(surendra.anubolu@broadcom.com), Rong Pan(ropan@cisco.com), Jeongkeun Lee(leejk@google.com), Barak Gafni(gbarak@nvidia.com), Jeff Tantsura(jefftant.ietf@gmail.com), Allister Alemania(allister.alemania@intel.com), Yuval Shpigelman(yuvals@nvidia.com)
  • Summary: 本文主要介绍了高精度拥堵控制（HPCC）的概念、设计、实现以及应用。HPCC是一种新的高带宽网络中的流量控制机制，它利用在链路侧通过带外指标收集的信息来精确地计算流速率更新，并且可以快速收敛到合理消耗的带宽以避免拥挤和维持接近零的队列，从而满足低延迟、高带宽和稳定性的要求。HPCC还支持灵活的传输协议栈适应方案，如使用探针包从端点获取带外信息进行反馈等。 总的来说，HPCC通过精确的带外信息采集实现了对网络负载的有效监控和精准的流量调整，为超高速网络提供了高效稳定的解决方案。
  • Diff: 该文档描述了一种新的高带宽网络中的高精度拥堵控制机制，名为HPCC++（High Precision Congestion Control）。与传统的软件堆栈相比，它利用了来自链路旁侧的精确载荷信息来计算准确的流量更新，并且能够快速收敛到充分利用带宽和避免拥挤的状态。 它的设计改进包括在端口处添加边界的填充、使用通知消息从网络获取网络拥塞信息以及对发送窗口进行调整等。此外，它还支持在多队列环境中工作。 总的来说，这个新版本的新功能更强大，性能更好，更加易于硬件部署，适合应用于高速网络。


2. draft-miao-ccwg-hpcc-info-04

  • Title: Inband Telemetry for HPCC++
  • Authors: Rui Miao(rmiao@meta.com), Surendra Anubolu(surendra.anubolu@broadcom.com), Rong Pan(ropan@cisco.com), Jeongkeun Lee(leejk@google.com), Barak Gafni(gbarak@nvidia.com), Jeff Tantsura(jefftant.ietf@gmail.com), Allister Alemania(allister.alemania@intel.com), Yuval Shpigelman(yuvals@nvidia.com)
  • Summary: 本文介绍了高精度拥塞控制（HPCC）的概念及其实现，这是一种新的网络拥塞控制机制。它利用了在带内流量监测中收集到的信息来计算准确的流速率更新，从而解决了现有拥塞控制机制的一些限制。HPCC++支持多种协议标准，并且具有很高的性能和效率。它使用精确的信息来自交换机，因此无需复杂的迭代过程就可以快速收敛，避免拥堵并保持极低的网络队列以实现超低延迟。 本文总结了以下几点： 1. HPCC++是一种新的网络拥塞控制机制，旨在同时满足三个关键要求：低延迟、高带宽和网络稳定性。 2. 它利用带内流量监测信息计算准确的流速率更新，而不是依赖大量迭代过程。 3. HPCC++通过精准的带内信息获取方法，能够迅速收敛以充分利用所有可用带宽，防止队列建立以及保持接近零的网络延迟。 4. 它还实现了硬件友好性，可以在普通NIC和交换机上实施，不需要昂贵的专用硬件。 总的来说，HPCC++是解决高性能网络拥塞控制问题的一种有效解决方案。它的设计简化了实现，使得实现起来更加容易，同时也为未来网络的发展提供了更多的可能性。
  • Diff: 摘要 本文提出了一种新的高精度拥塞控制机制，名为HPCC++（High Precision Congestion Control），该机制可以同时实现三个关键目标：达到低延迟、高带宽和网络稳定。传统软件栈在主机上无法满足这些要求，因此需要将网络堆栈移至硬件平台。 与现有高速拥塞控制方案相比，HPCC++的优势在于其可以利用链路负载信息中的精确链接负荷数据来计算准确的流量更新率，从而解决当前拥塞控制方案面临的局限性。首先，HPCC++发送者可以在高峰期迅速增加流量速率以避免拥堵，并在避免拥挤时快速调整流量速率，保持每个端口的输出速率略低于端口容量，防止队列的建立以及保持高的端口利用率。其次，由于发送速率基于直接测量的端口开关，因此不需要大量的迭代即可收敛到充分利用所有可用带宽，同时避免拥挤。最后，由于发送速率是根据端口开关上的直接测量得出的，因此仅需使用三个独立参数来调优公平性和效率。 与现有的IFAM、IOAM和P4.org INT等协议相比，HPCC++提供了一个架构变更，支持在网络中引入用于监测链路负载的实时数据传输，提高处理网络拥塞的能力。通过在链路边缘节点记录完整的链路负荷估计，实现了对链路负载信息的有效收集和存储，从而提高了系统性能并减少了设计开销。此外，HPCC++还提供了公平性和效率的可配置参数，使得它易于部署和实施，适合硬件实现。 总的来说，HPCC++不仅改进了现有拥塞控制解决方案，而且为实现超低延迟、高带宽和网络稳定性提供了全新的思路。它具有高效的数据交换特性，便于硬件实现，并且易于扩展和维护。

Unknown

Unknown

1. draft-white-linklocal-capability-04

  • Title: Link-Local Next Hop Capability for BGP
  • Authors: Russ White(russ@riw.us), Jeff Tantsura(jefftant.ietf@gmail.com), Donatas Abraitis(donatas.abraitis@gmail.com)
  • Summary: 是一个关于使用IPv6的本地地址作为下一跳地址能力的新标准。该标准允许BGP路由器在点到点链路上使用仅限于本地网络的IPv6地址作为下一跳地址。这样可以简化BGP配置，从而有助于零接触部署（ZTP）。然而，由于IPv6本地地址不支持全局唯一性，因此需要确保它们严格关联到特定接口。 如果两个或更多的实施者都可以使用IPv6本地地址和一个全球IPv6地址来计算路由信息，则可以实现未编号接口的解决方案。这个新能力使不同类型的BGP邻居可以在没有额外配置的情况下相互兼容，并且现有实施者可以无需进行重大变更即可改变其行为，从而简化了配置管理和协调。 此外，IPv6本地地址的使用还可以支持数据中心中的多路径可达性，因为它们提供了一种通过直接连接到同一子网的路由器或通过多个路由步骤到达目的地的方法。然而，在某些情况下，全局IPv6地址可能不是必需的，因为它可以导致ZTP失败。 总的来说，这个新的BGP特性将使得BGP能够与IPv6本地地址一起工作，而不会影响到支持全局IPv6的能力，同时简化了BGP配置管理，从而改善了用户体验。
  • Diff: 新的英文标准文稿（链接本地下一站能力）是对BGP协议的一个改进，主要是将IPv6的下一个跳地址范围限制在点对点链路上，从而简化了BGP邻居配置和配置管理。新的能力允许BGP路由器只使用IPv6的点到点链路作为下一个跳地址，并且可以与这个属性一起使用其他类型的下一个跳地址，如全球IPv6地址。此外，该文档还提出了一个错误处理机制，用于处理不正确的IPv6链接本地地址更新。 相较于旧版标准文稿，《Link-Local Next Hop Capability for BGP》的主要区别在于： 1. 新的特性使BGP能够仅使用IPv6的点对点链路作为下一个跳地址，而不需要全局IPv6地址。 2. 使用了一个新的错误码来标识无法访问的IPv6链接本地地址。 3. 提供了选项让BGP邻居可以选择使用哪种下一个跳地址。 4. 提出了一个检测并报告IPv6链接本地地址无效的方法。 5. 更改了错误信息编码以更好地描述错误情况。 6. 对于内部BGP邻居，不再自动反射已知的下一个跳地址。


2. draft-bortzmeyer-more-edes-02

  • Title: Addition of Extended DNS Errors codes
  • Authors: Stéphane Bortzmeyer(bortzmeyer+ietf@nic.fr)
  • Summary: 本文是关于新增三个EDE（Extended DNS Errors）编码标准，以解决客户端IP地址作为响应定制、最小化响应和本地根服务器的问题。这三个新编码分别代表了从客户端实际IP地址查询（负载均衡）、故意最小化的响应以及来自本地根服务器的响应。这些编码由IANA注册，并可能在响应发送给客户端时复制到其上。 此外，本文还讨论了针对这些新编码的安全考虑，指出它们无需签名，并应谨慎使用。最后，它列出了实施者对这些新的扩展DNS错误代码开放的问题列表，以便收集有关这些新编码的信息。
  • Diff: 新的文档提出了三个新的EDE（扩展DNS错误）代码：一种用于根据客户端IP地址进行定制的响应；一种表示该响应是故意最小化的；另一种表示响应来自本地根服务器。此外，还引入了对这些EDE的管理考虑和安全考虑。对于实现者来说，需要关注的是如何处理这些新的EDE。总的来说，新的文档提供了更详细的信息，并且增加了更多的安全性方面的考虑。