【每日文稿】2024-12-20
今日共有12篇文稿更新，涉及5个area里的11个WG
INT
6man
- Title: Limits on Sending and Processing IPv6 Extension Headers
- Authors: Tom Herbert(tom@herbertland.com)
- Summary: 本文主要讨论了IPv6协议中的扩展头(Extension Header)的限制问题。文中首先介绍了相关工作和要求，然后详细定义了发送、接收和处理扩展头的各种限制。这些限制分为两部分：对发送方的限制和对接收方和中间节点的限制。对发送方的限制包括长度、选项数量等；对接收方和中间节点的限制则包括长度、选项数量、以及是否允许连续选项等。 本文还指出了设置限制的原因，例如避免拒绝服务攻击（Denial of Service Attack）、保护路由器控制平面安全等，并给出了相应的默认值或推荐值。最后，本文总结了限制的作用和意义，强调了限制可以提高部署支持率，增加协议的可移植性。
- Diff: 以上新版本的英文标准文稿（草案编号draft-ietf-6man-eh-limits-18）的主要区别在于： 1. 更严格的限制条件：相较于旧版草案《Limits on Sending and Processing IPv6 Extension Headers》（草案编号draft-ietf-6man-eh-limits-17），新版草案增加了更多细节和更严格的要求。 2. 支持扩展性更强：新版草案定义了更多的接收、发送以及处理IPv6扩展头部的限制条件，并允许这些限制可以被定制以更好地匹配合理的使用场景。 3. 定义了默认值：新版草案提供了默认值来限定一些限制条件的数值范围，例如选项数量、包长度等，以此作为支持适度部署的基本底线。 4. 强调了安全性和安全性：新版草案详细讨论了如何应对包括过度Hop-by-Hop选项在内的多种威胁，并通过实例说明了在实际网络中的情况。
- Title: IPv6 Parcels and Advanced Jumbos (AJs)
- Authors: Fred Templin(fltemplin@acm.org)
- Summary: 本文讨论了在互联网架构中的使用IPv6包裹和附加大型包（AJ）来改进网络性能、效率和完整性。包裹是包含多个数据段的“封装单元”，允许一个包裹携带多个数据段，从而实现多路复用。附加大型包（AJ）提供了一个服务模型，使得单个大小范围从很小到很大的所有段都可以通过传输，而无需应用任何规则。 文稿还介绍了延迟容忍网络（DTN）模型，以支持如移动性这样的空中、陆地、海洋和太空通信场景下的高延时和中断耐受性。这些服务可以激励未来创新的应用、运输协议、操作系统、网络设备和数据链接，以最大化互联网络性能。
- Diff: 新的IPv6 Parcels和Advanced Jumbos（AJ）是为了解决当前IPv6网络中的性能瓶颈而提出的。这两个概念分别提供了一种包装多段传输服务的方法，使得运输层协议能够使用更长的端到端数据包大小。 相较于旧版的标准化文档，新版本的主要区别在于： 1. IPv6 Parcels将多个连续的运输层协议分组封装在一个“包裹”中，并且允许这些包裹包含多个段作为“多段包裹”。这意味着用户可以一次发送大量不同长度的段而不必一次性发送所有它们。 2. Advanced Jumbos（AJ）是一种基于基本IPv6 jumbograms的新型扩展，其端到端数据包长度从单个传输层协议段扩大到多达2^32个8位字节的端到端数据包，这远远超过了传统路径最大MTU限制。 3. 这些附加功能提供了改进的网络性能、效率和完整性，并鼓励更大的最大传输单元（MTU），同时通过延迟容忍网络（DTN）模型支持延迟和中断容忍性。 总的来说，这些新技术旨在解决现有IPv6网络中存在的性能瓶颈问题，并促进网络设备技术的发展。
dhc
- Title: DHCPv4-over-DHCPv6 (DHCP 4o6) with Relay Agent Support
- Authors: Claudio Porfiri(claudio.porfiri@ericsson.com), Suresh Krishnan(suresh.krishnan@gmail.com), Jari Arkko(jari.arkko@ericsson.com), Mirja Kühlewind(ietf@kuehlewind.net)
- Summary: 本文档详细介绍了在IPv4网络中使用DHCPv6的解决方案，该方案允许通过DHCPv4-over-DHCPv6（DHCP 4o6）机制将IP地址和其它配置参数动态地从IPv6网络提供给IPv4主机。虽然RFC7341定义了IPv4主机可以向IPv6服务器申请IP地址的过程，但在没有IPv6服务的情况下，这个过程是不可行的。为此，本文提出了一个替代方案：在IPv4主机与IPv6路由器之间引入DHCPv4-over-DHCPv6代理节点（4o6RA），用于支持IPv4的DHCPv4-over-DHCPv6封装和解封装。 这种解决方案的核心思想是在网络边缘部署一个或多个DHCPv4-over-DHCPv6代理节点（4o6RA），这些节点负责将IPv4主机请求的IP地址转换为IPv4-over-DHCPv6格式，并将其转发到IPv6服务器以获取IPv6地址。这样，IPv4主机就可以通过DHCPv4-over-DHCPv6代理节点来访问IPv6服务，而无需改变其内部结构，从而保护了IPv4主机的安全性。 总之，本文提出了一种新的方法，在不更改IPv4主机内部结构的前提下，允许IPv4主机利用IPv6服务。这一方法消除了IPv4主机对IPv6服务的需求，同时保持了IPv4主机的安全性和可靠性。因此，这是一种既实用又安全的方法，可以在现有环境中实现IPv4主机访问IPv6服务的目标。
- Diff: 摘要 本文档描述了网络中支持IPv4的客户端使用基于DHCPv6的DHCPv4配置服务在DHCPv4代理上的机制。旧版文档只适用于客户端模式下使用DHCPv4消息传输IPv4地址等配置参数。本文提出一种基于[RFC7341]的方法，允许作为DHCPv4代理的DHCPv4-over-DHCPv6（DHCP 4o6）在中间节点如交换机或路由器上部署，而无需对客户端做出任何要求。没有新的协议或扩展需要，本文仅对[RFC7341]进行修改，以允许DHCPv4-over-DHCPv6的DHCP 4o6功能，并且不改变其他协议。 本文主要区别在于： 1. 文档从一个客户端向另一个DHCPv4服务器发送DHCPv4请求到DHCPv6服务器的场景转变。 2. 将DHCPv4-over-DHCPv6与DHCPv4代理相结合，在DHCPv6客户端和DHCPv6服务器之间建立连接。 3. 在DHCPv4-over-DHCPv6中实施DHCPv4-en/decapsulation。 4. 支持通过L2（轻量级DHCPv6代理）或LDRA（层2DHCPv6代理）发现网络拓扑信息。 5. 保持兼容性，使得DHCPv6和DHCPv4都遵循4o6协议。
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: 本文主要讨论了无线网络设备如Wi-Fi路由器和接入点在使用MAC地址作为身份标识时可能引发的安全问题。文稿指出，随着无线技术的发展，设备可以通过MAC地址建立持久的身份关联，从而造成隐私泄露。针对这个问题，一些厂商开始实施随机变化的MAC地址方案来限制这种关联，并防止MAC地址泄露。 然而，这种变化可能会对用户体验和网络效率产生影响。如果多个用户同时进行MAC地址的变化而不协调，可能会导致网络中断等问题。此外，某些服务依赖于设备发送特定的MAC地址，而这些服务又需要保持与该设备的持续连接，因此这些变化可能会破坏这些服务。 因此，文稿提出了维持网络服务质量、用户隐私保护以及减少网络故障风险的同时，还需要考虑用户的体验和网络效率的原则。作者认为，有必要探讨如何平衡这些因素以满足不同场景的需求。
- Diff: 该文档提出了对无线网络设备（如路由器、交换机和无线接入点）使用随机化MAC地址（Random and Changing MAC Address, RCM）进行身份验证（Identity Verification）的新方法。其目的是在不泄露用户隐私的前提下实现设备之间的唯一标识符（Unique Identifier），以保护用户个人信息免受攻击。 与旧版的不同之处在于： 1. 主要讨论了基于Wi-Fi的RRC技术，并且强调了这些技术如何影响用户的体验和网络操作效率。 2. 讨论了不同类型的网络服务可能受到RRC的影响，包括设备识别和相关问题、以及网络安全措施等。 3. 提出了维护用户隐私同时确保用户体验和网络效率的方法，包括现有的框架和未来的工作。 4. 强调了环境因素对于RRC实施效果的重要性，并分析了不同环境下的信任度。 总的来说，新版着重于解决RRC带来的隐私和用户体验问题，同时也为未来的网络设计提供了一定参考。
OPS
ippm
- Title: On-path Telemetry YANG Data Model
- Authors: Giuseppe Fioccola(giuseppe.fioccola@huawei.com), Tianran Zhou(zhoutianran@huawei.com)
- Summary: 本文主要介绍了在IP网络上使用的替代标记方法（Alternate-Marking Method, AltMark）和在线标操作、行政管理和维护（Operations, Administration, and Maintenance, IOAM）的数据模型。这些数据模型用于监测和报告网络性能，如流量延迟、丢包率等。它们被定义为可订阅的，以便通过特定的机制（如NETCONF或RESTCONF）进行监控和传输。 文中还讨论了如何使用这些数据模型来实现动态网络控制，并详细描述了每个组件的功能和相互关系。此外，还指出了使用这些数据模型时需要注意的安全性和认证问题。 总的来说，这篇文档提供了一个关于如何在IP网络上应用替代标记方法和在线标操作、行政管理和维护的信息框架。它旨在帮助用户更好地理解并利用这些技术来优化网络性能。
- Diff: 是关于网络性能监测的一个YANG数据模型提案。它定义了在基于标记方法（Alternate Marking Method）和即时操作、管理维护（In-Situ Operations, Administration, and Maintenance，IOAM）等混合测量方法上的行进式网络性能监控信息的数据模型。 与旧版相比，新版的主要区别在于： 1. 定义了新的流量计数器来跟踪流量：loss-counters（丢包计数）、pkts-timestamps（包时钟）和pkt-timestamp（包时钟）。 2. 增加了对于IPv6和SRH的支持。 3. 在协议类型上增加了对MPLS的支持。 4. 对于On-path Telemetry的特性进行了进一步的描述，如标识符过滤器(identity filter)，以及如何指定传输延迟、边到边数据等。 总的来说，新版提供了一个更完整的数据模型，以支持基于标记的方法和实时的网络性能监控，并且通过增加新的特性提高了其兼容性和实用性。
RTG
bess
- Title: BGP Usage for SD-WAN Overlay Networks
- Authors: Linda Dunbar(dunbar.ll@gmail.com), Ali Sajassi(sajassi@gmail.com), John Drake(jdrake@juniper.net), Basil Najem(basil.najem@bell.ca), Susan Hares(skh@ndzh.com)
- Summary: 本文主要讨论了在软件定义广域网络（SD-WAN）覆盖网络中的复杂性，以及如何使用BGP控制平面有效地管理这些网络。文稿介绍了各种SD-WAN场景，并探讨了BGP作为控制平面的优势，如简化边缘节点间身份验证过程、简化IPSec隧道管理、简化流量选择配置等。此外，文稿还讨论了BGP对实现流式分段的要求、安全考虑和IANA考虑。 总的来说，本文展示了如何利用BGP进行大规模SD-WAN覆盖网络的管理，以最小化手动干预，同时满足业务需求和网络安全要求。
- Diff: 上述新版本的英文标准文稿详细介绍了软件定义广域网络（Software Defined Wide Area Network）在大型SD-WAN（Software Defined Wide Area Network）Overlay网络中的使用场景和要求。它展示了BGP控制平面如何有效地管理这些大规模SD-WAN Overlay网络，同时尽量减少人工干预。 与旧版相比，新的文档着重强调了以下区别： 1. 比较详细地介绍了SD-WAN应用场景，并解释了它们对BGP控制平面的需求。 2. 提供了详细的客户服务提供模型、策略配置模型和IPSec相关参数配置模型。 3. 描述了BGP基于控制平面管理SD-WAN Overlay网络的优势：无需手动操作即可实现统一的网络管理和灵活的业务划分。 4. 强调了BGP作为SD-WAN Overlay网络控制平面的重要性。 5. 揭示了零触点部署（Zero Touch Provisioning，ZTP）的概念及其在远程SD-WAN边缘节点上的应用流程。 6. 阐述了受限传播SD-WAN边缘属性的考虑，确保仅授权的SD-WAN边缘节点可以与其他边缘节点通信。 总的来说，该文档整合了最佳实践，定义了指南，旨在使各类型网络能够高效实施标准化的SD-WAN Overlay网络架构，而不是提出全新的概念。
pce
- Title: Carrying SR-Algorithm Information in PCE-based Networks.
- Authors: Samuel Sidor(ssidor@cisco.com), Zoey Rose(atokar@cisco.com), Shaofu Peng(peng.shaofu@zte.com.cn), Shuping Peng(pengshuping@huawei.com), Andrew Stone(andrew.stone@nokia.com)
- Summary: 本文主要介绍了在点到端路径计算（PCEP）协议中，段路由（SR）算法信息如何通过拓扑学习传递给头端路由器。头端需要将从主PCE获取到的每条SR-TE路径计算结果都反馈给备份PCE，以确保高可用性（HA）。此外，本文还讨论了使用SR算法TLV来告知头端关于每个SID使用的SR算法的信息以及如何设置SR算法约束的方法。 总结而言，本文提出了一种方法来告知头端关于每个SID使用的SR算法信息，并且可以设置特定的SR算法作为约束条件，从而指导PCE进行更高效的路径计算。这有助于确保在多个（冗余）PCE的情况下，头端能够正确地报告完整的路径信息。
- Diff: 以上新版的文档主要对SR算法在PCEP协议中的使用进行了扩展和说明。主要内容包括： 1. 在SR路径计算中引入了新的SR算法TLV，用于标识支持的SR算法，并且定义了SR算法约束。 2. 扩展了SRERO和SRv6-ERO子对象，允许头部路由器将SR算法信息包含在内或设置为非空子对象。 3. 定义了新的METRIC类型，以支持基于SR算法的路径计算。这些新的metric类型可以映射到“最小链路延迟”、“最大链路延迟”和“用户自定义指标”。 4. 提供了一个新的LSPA对象，用来携带SR算法约束信息，只有当Path Setup Type为SR或SRv6时才被处理。 5. 对于基于Flexible Algorithm的路径计算，提供了相关的规则和逻辑来确保计算结果与给定的SR算法相匹配。 6. 提供了管理能力要求，如控制功能、政策以及信息和数据模型等。 总的来说，新增加的功能和特性使得基于SR算法的路径计算更加灵活和可控。同时，也考虑到了头端路由器需要获取更多关于SR算法的信息，以及网络运维过程中可能遇到的问题。因此，这些更新增加了文档的实用性和可操作性。
teas
- Title: A YANG Data Model for the RFC 9543 Network Slice Service
- Authors: Bo Wu(lana.wubo@huawei.com), Dhruv Dhody(dd@dhruvdhody.com), Reza Rokui(reza.rokui@gmail.com), Tarek Saad(tsaad.net@gmail.com), John Mullooly(jmullool@cisco.com)
- Summary: 这篇文稿定义了一个用于RFC 9543网络切片服务（Network Slice Service）的数据模型。这个模型可以用来在提供者和客户之间管理网络切片服务，也可以用来管理网络切片服务实例。网络切片服务包含一组服务分界点（SDP）、一组连接构造、以及一组服务水平要求（SLO）和期望（SLE）。通过NSSM，客户和服务提供商可以在网络层面上进行操作以满足需求。 NSSM分为两个主要数据结构："slo-sle-templates"和"slice-service"。前者包含了通用的网络切片服务模板，后者代表了网络切片服务的实际实体。NSSM允许客户管理和监控其网络切片服务生命周期，例如创建、修改或删除服务实例等。 NSSM使用协议如NETCONF来实现对网络切片服务的操作。此外，它还支持从不同角度获取性能信息和状态信息。总的来说，NSSM是一个面向客户的网络切片服务接口模型，提供了丰富的功能和灵活性，使得网络运营商能够高效地管理他们的网络切片服务。 总结： 本文定义了一个用于RFC 9543网络切片服务（Network Slice Service）的数据模型。这个模型可以用来在提供者和客户之间管理网络切片服务，并且支持多维度的监控和管理能力。NSSM提供了丰富的功能和灵活性，使得网络运营商能够高效地管理他们的网络切片服务。
- Diff: 该文档定义了用于RFC 9543网络切片服务的Yang数据模型（YANG）。它适用于在提供网络服务提供商和客户之间的接口之间管理网络切片服务，从而触发适当的网络操作，如实例化、修改或删除一个网络切片。这个模型可以作为网络切片服务接口被提供给客户的高层操作系统进行生命周期管理和监控。 与旧版本相比，新的Yang数据模型定义了两个主要的数据节点："slo-sle-templates"和"slice-service"。"slo-sle-templates"容器用来维护一组共享的网络切片服务模板，这些模板应用到一个或多个人工网络切片服务。而"slice-service"列表包含了一组维护为特定客户提供的一系列网络切片服务的网络切片服务。此外，文档还提供了对网络切片服务模板属性以及定制的服务水平要求和期望的详细描述。 总的来说，新的Yang数据模型简化了网络切片服务的实现过程，并允许更灵活地管理网络切片服务。
SEC
oauth
- Title: OAuth Status Assertions
- Authors: Giuseppe De Marco(gi.demarco@innovazione.gov.it), Orie Steele(orie@transmute.industries), Francesco Marino(fa.marino@ipzs.it), Marina Adomeit(marina@sunet.se)
- Summary: 本文主要讨论了OAuth Status Assertions，这是一种用于证明数字凭据状态的签发对象。这种签发对象被用作客户端请求认证和验证的凭证。它使用JSON Web Token（JWT）格式或CBOR Web Token（CWT）格式，并包含一个状态声明请求。用户可以通过将这些状态声明发送给可信实体来获取这些签名。通过这种方式，用户可以免于直接向第三方查询，以查看其数字凭据的状态。此外，它可以降低验证延迟并促进离线验证。 Status Assertion主要用于证明数字凭据的有效性状态，例如在证书撤销的情况下。它们提供了一种方式，使得依赖于有效凭据状态的实体能够验证凭据的有效性状态而无需直接访问第三方系统。此外，Status Assertion还允许验证实体独立工作，避免与第三方机构或其他验证实体之间的信息泄露。总之，Status Assertion是一种有效的技术，可为用户提供一种安全的方式来管理其数字凭据状态。
- Diff: 以上新版本的英文标准文稿是对《OAuth Status Assertions》旧版本的一个修订版。 主要内容上的区别包括： 1. 去掉了关于更新为RFC78和RFC79规范的注释，并且表示了新的版本将按照这些规范进行发布。 2. 简化了文档结构和标题命名，使得文稿更加清晰易读。 3. 引用了新的国际标准化组织（如IETF）的文件作为参考文献。 4. 表达了对某些条款的保留意见，比如允许使用数字签名等方法验证状态确认请求，而不是直接与第三方系统交互。 5. 将认证实体的定义从OpenID Connect Core修改为RFC6749。 总的来说，新版标准更注重简化、统一和规范化，同时也保留了一些具体实现细节，以满足不同的需求。
tls
- Title: TLS 1.2 is in Feature Freeze
- Authors: Rich Salz(rsalz@akamai.com), Nimrod Aviram(nimrod.aviram@gmail.com)
- Summary: 本文主要讨论了关于使用TLS 1.3和新的加密算法、安全特性等更新的可能性。作者指出，由于目前没有可供量子计算机攻击的可靠算法，因此不建议在TLS 1.2版本上进行任何修改或添加新功能。此外，还提到了一些国际组织正在努力制定用于处理量子计算的安全协议，并强调了这些协议对于支持未来的量子世界至关重要。 文稿最后总结道，虽然现有的加密算法可能无法满足未来量子计算机的要求，但应该考虑将这些算法与新的安全机制相结合以实现安全性的提升。同时，应加强对量子计算机威胁的研究，以便在未来有更多有效的防御措施。
- Diff: 该文档是关于使用TLS 1.3解决TLS 1.2的一些缺陷，并规定在非紧急情况下，不批准任何改动到TLS 1.2。同时，对于DTLS（任何DTLS版本），这个规则也不适用。 与旧版相比，主要区别在于： 1. 新增加了对后量子加密的支持，包括RSA、FFDH和ECC等现有密码技术可能受到的影响。 2. 后量子加密将改变加密方式，使得外部无法获取信息。 3. 对于后量子加密，需要等待NIST标准发布。 4. 因此，在非紧急的情况下，不批准任何改动到TLS 1.2。 总的来说，本文主要是为了明确指出当前支持的加密方式以及未来的加密需求。
WIT
httpapi
- Title: api-catalog: a well-known URI and link relation to help discovery of APIs
- Authors: Kevin Smith(kevin.smith@vodafone.com)
- Summary: 这篇文稿主要提出了一个名为"api-catalog"的新URI和关联关系，用于促进API发现和使用。API文档可以通过这个uri获取到最新的API目录，包含API的详细信息以及API使用的政策等。该uri的注册被登记在了well-known URI registry中，并支持多种格式如Linkset。此外，还提供了关于如何使用这个uri的一些操作指南，包括如何利用其他link relations，如何返回多层nesting的API catalog等。 总的来说，这篇文稿主要介绍了如何通过"api-catalog"来实现API的自动发现和使用，同时也指出了在实际使用过程中需要注意的问题。
- Diff: 本文是关于定义一个“api-catalog”标准命名空间和链接关系的文档。 相较于之前的版本，新的版本在以下方面进行了改进： 1. 引入了新的“api-catalog”标准命名空间和关联关系，用于发布API端点列表和元数据信息。 2. 提供了一个通用的URI（“.well-known/api-catalog”）来标识这个API资源。 3. 使用了新的“api-catalog”链接关系，该关系指向一个API目录文件，其中包含API端点及其元数据。 4. 规定了API目录格式为应用/链接集+JSON，包括对元数据进行映射到API目录结构的要求。 5. 在操作层面上，讨论了如何处理API分布到多个域的情况，以及如何使用不同格式来提供API目录。 6. 强调了安全性和隐私审查的重要性，并提供了相应的指南。 7. 注重了API管理框架与API目录的关系，建议在API管理流程中定期更新API目录。 总的来说，新的标准文稿更加注重API管理和自动化发现，强调了安全性、可维护性等方面的设计。它还提供了更详细的操作指南和技术细节。
httpbis
- Title: Cookies: HTTP State Management Mechanism
- Authors: Steven Bingler(bingler@google.com), Mike West(mkwst@google.com), John Wilander(wilander@apple.com)
- Summary: 本文是关于在HTTP协议中使用Cookie和Set-Cookie头字段来管理状态，例如存储和传输信息。这种机制可以用来提供一个客户端与服务器之间交互的接口，并允许用户代理保存和检索这些信息。 主要讨论了以下方面： 1. Cookie和Set-Cookie头字段的定义：这两个字段用于在客户端和服务器之间传递信息，如用户标识符、日期等。 2. Cookie生产和消费：生产者应该选择Section 4（生成并发送给客户端）；消费者应该选择Section 5（接收来自其他来源的信息）。两者都应遵循一定的规则和约定。 3. Cookie命名前缀：一些服务器可能不遵守某些特定的规则，因此开发者需要了解如何处理这些问题。 总的来说，这个文档旨在为开发人员提供一种标准的API来管理和通信数据，同时保持兼容性和安全性。
- Diff: 该文档定义了HTTP中的Cookie和Set-Cookie头字段，用于服务器向用户代理发送状态信息（称为cookies），以及用户代理从服务器接收这些状态信息后返回给服务器。相比于旧版标准文稿，其主要区别在于： 1. 新版文档详细描述了所有要求，包括生产者、消费者等不同角色的实施指南，使文档更加详尽。 2. 强调了兼容性问题，并提供了更宽泛的处理规则，以支持更多的用户代理。 3. 描述了对非标准行为的支持，如允许使用非标准语法，以提供更好的兼容性和灵活性。 4. 对一些已存在的软件差异进行了解释，强调在实现时应考虑这些因素。 综上所述，新版文档不仅提供了一个统一的、更全面的协议规范，也提供了对现有软件行为的包容性和灵活性，使得更多用户可以受益于这一协议。