Markdown Version | Transcript | Session Recording | Session Materials

INTAREA

Summary

The INTAREA working group met at IETF 126 to discuss working group status, review active drafts, and evaluate several individual submissions. The session covered updates to the active YANG model for ARP extensions, proposals for IPv6-only environments supporting IPv4 clients, updates to legacy IANA registries, DHCP rate signaling, IP tunneling security requirements, ICMP authentication mechanisms, and guidance on packet reordering.

Key Discussion Points

1. WG Status and Administrative Updates

• Presentation: Agenda bashing, WG and document status updates
• WG Document Status:
  • draft-ietf-intarea-proxy-config is currently in the RFC Editor queue.
  • Two documents awaiting revision in the IESG evaluation pipeline are currently stalled. Jen Linkova took an action item to follow up with the author to help move them forward.
  • The multicast application port draft has completed working group last call (WGLC) and is awaiting final approval from AD Éric Vyncke.
  • The IP tunnels draft (draft-ietf-intarea-tunnels) has expired. The chairs sent an email requesting updates to address WGLC comments but received no response.
• Administrative Announcements:
  • Éric Vyncke announced he is stepping down as Internet Area AD in March 2025.
  • Tim Chown requested volunteers to join the Internet Directorate review team to assist ADs with cross-area draft reviews.

2. A YANG Data Model for ARP Extensions

• Presentation: A YANG Data Model for ARP Extensions
• Draft: draft-ietf-intarea-arp-yang-model
• Presenter: Fang Zhang
• Discussion:
  • Fang Zhang outlined changes implemented to address the YANG doctor review by Shigong.
  • Key updates included renaming the module prefix and document title to emphasize "ARP Extensions," removing the top-level global container for dynamic ARP learning, converting statistics counters from 32-bit to 64-bit, and validating and completing XML examples.
  • The authors requested WGLC. The chairs agreed to initiate WGLC following the meeting, emphasizing that the draft needs at least five active reviewers to provide feedback.

3. IPv6-Resolved IPv4 Gateway

• Presentation: IPv6-Resolved IPv4 Gateway
• Presenter: Remco van Mook
• Discussion:
  • Remco van Mook presented a proposal to allow IPv6-only segments to support dual-stack hosts by defining a specific sentinel IPv4 address from the IANA Special Purpose Registry (suggesting 192.0.0.11 as a placeholder) to represent the default gateway.
  • By placing this sentinel in DHCPv4 Option 3, hosts can route IPv4 traffic using the IPv6 neighbor cache instead of legacy ARP. The mechanism relies on the router replying to ARP queries for the sentinel to support unmodified legacy hosts.
  • Q&A:
    • Lorenzo Colitti: Asked if IPv4 hosts would still need subnet management. Remco explained that this allows a flat pool of IPv4 addresses without subnets, where lateral host-to-host traffic is routed through the default gateway. Lorenzo expressed concern that if host implementations only resolve the gateway once and fail to track IPv6 Routing Advertisements (RAs) and renumbering, it could break IPv4 connectivity.
    • Tobias Fiebig: Supported the draft, noting that it is a cleaner alternative to doing DHCPv4 over DHCPv6 and solves real operational issues when dividing small IPv4 blocks across multiple routers.
    • Ondřej Caletka (via chat/mic): Asked how return path routing functions. Remco noted that return routing is handled by existing router-to-router mechanisms defined in the "IPv4-via-IPv6" drafts.
    • Éric Vyncke (via chat): Noted that the draft should use "TBD" for the address allocation rather than assuming 192.0.0.11.
    • Maria Matějka (via chat): Supported a dedicated allocation, noting that it signals clear architectural intent across all layers and avoids operators squatting on addresses like 1.1.1.1.
    • Lorenzo Colitti: Suggested that while he supports working on the problem statement, the working group should not tie themselves exclusively to an IPv6 Next-Hop solution, as handing out /32 IPv4 addresses can already achieve similar results with legacy hosts.

4. ILNP Clarifications and Compatibility with IPv6 Applications

• Presentation: ILNP clarifications and compatibility with IPv6 applications
• Presenter: Salim
• Discussion:
  • Salim presented updates on the Identifier-Locator Network Protocol (ILNP), an experimental addressing architecture that splits the traditional IP address into an identifier (for transport state) and a locator (for network routing).
  • Four individual drafts were introduced to improve ILNP compatibility with standard IPv6 networks:
    1. Preferences draft: Defines DNS preference ordering for locators and identifiers.
    2. Textual representations draft: Proposes a clear notation to distinguish identifier-locator vectors from standard IPv6 addresses.
    3. Nonce draft: Tightens security by specifying the inclusion of a bidirectional, randomly generated session nonce in every ILNP packet.
    4. IPv6 apps draft: Outlines how standard unmodified IPv6 applications (such as iPerf3) can run transparently over ILNP.
  • The presenter requested that these documents be progressed as Experimental RFCs to match the status of the base ILNP specifications.

5. Updates to Legacy IANA Registries

• Presentation: Updates to Legacy IANA Registries
• Presenter: Éric Vyncke
• Discussion:
  • Éric Vyncke outlined an effort to clean up old, unmaintained IANA registries that lack designated registration or modification procedures.
  • The draft proposes:
    • Closing the unused IPv4 Time To Live (TTL) registry.
    • Closing the NetWare Option registry (DHCPv4).
    • Setting "Terminal Names" and "Terminal Type" registries (historically used for Telnet) to "First Come First Served."
    • Modifying the IPv4 Options registry to require "IESG Approval" rather than closing it, allowing for potential limited-domain experimental allocations.
  • Q&A:
    • Thierry: Expressed concern that locking down or deprecating IPv4 options would block future innovations, particularly in limited domains or network monitoring. He welcomed the compromise of using "IESG Approval."
    • Tom Hill: Requested that any deleted or deprecated registry information be archived for historical and hardware-preservation purposes. Éric confirmed that IANA does not delete historical registry entries, but simply marks them as closed.

6. DHCP Explicit Rate Signaling

• Presentation: DHCP Explicit Rate Signaling
• Presenter: Richard Patterson
• Discussion:
  • Richard Patterson presented a draft addressing situations where a CPE router's physical interface speed (e.g., 1 Gbps, 2.5 Gbps) exceeds the contracted service speed (e.g., 400 Mbps). This mismatch prevents effective configuration of Active Queue Management (AQM) or L4S.
  • The draft introduces new DHCPv4 and DHCPv6 options to signal upstream and downstream contracted rates to the CPE.
  • Q&A:
    • Stuart Cheshire: Argued that explicit signaling is unnecessary because transport protocols naturally detect bottlenecks. He suggested that policing and ECN marking (e.g., using "SRM" - ECN-based policing) should be performed at the BNG. Stuart recommended that this work belongs in the transport area (TSVWG) rather than Internet Area.
    • Tim Winters (DHC WG Chair): Noted that while the DHC working group can assist with formatting and reviewing DHCP options, they prefer not to own the design of new functional options. He suggested the work should reside in INTAREA or TSVWG.
    • Éric Vyncke: Supported hosting the work in INTAREA, noting that it acts as the default home for general IP-layer mechanisms and that signaling this rate to the CPE helps prevent congestion on shared upstream access links.

7. Security Requirements for IP Tunnel Nodes

• Presentation: Security Requirements for IP Tunnel Nodes
• Presenter: Yushan Yang
• Discussion:
  • The presenter discussed security risks associated with open, publicly reachable IP tunneling endpoints, which can be exploited for source-address spoofing, traffic redirection, and security policy bypass.
  • The draft outlines a security framework for tunnel endpoints, detailing:
    • Secure default configurations (disabled by default).
    • Source Address Validation (SAV) for outer and inner headers.
    • Restricting recursive encapsulation to a maximum depth of three.
    • Restricting IPv6 extension headers on tunneled traffic.
  • Q&A:
    • Éric Vyncke (via chat/mic): Questioned whether recursive encapsulation limits (depth of 3) and specific IPv6 extension header limitations are strictly security issues. He recommended reviewing RFC 6169 (Security Concerns with IP Tunneling) to identify overlaps.
    • Thierry: Warned that dropping packets containing extension headers degrades the usability of the IPv6 extension header framework and should be avoided.
    • Carlos Bernardos (via chat): Noted that existing tunneling protocols like Mobile IPv6 (RFC 6275) already mandate validation mechanisms for tunnel headers.

8. Problem Statement for Cross-Layer Vulnerabilities due to Forged ICMP Errors

• Presentation: Problem Statement for Cross-Layer Vulnerabilities due to Forged ICMP Errors & Enhancing ICMP/ICMPv6 Error Message Authentication Using Challenge-Confirm Mechanism
• Presenter: Yushan Yang
• Discussion:
  • Yushan Yang presented research on vulnerabilities where off-path attackers spoof ICMP/ICMPv6 error messages (e.g., Packet Too Big) to trigger malicious cross-layer actions, such as TCP sequence number leakage, state desynchronization, and path MTU desynchronization.
  • To resolve this for protocols lacking embedded secrets (like stateless UDP), the draft proposes a challenge-confirm mechanism. When a host receives an ICMP error, it generates a stateless cryptographic token (nonce) and embeds it in the option field of the next outgoing packet of the affected flow. A legitimate on-path router will see and return this nonce, validating the error path.
  • Q&A:
    • Tim Winters: Noted that standard implementations should check the originating packet payload inside the ICMP message as described in RFC 4443. He offered to discuss the specific scenarios where this check fails off-list.
    • Éric Vyncke: Asked for clarification on how the challenge is sent. Yushan confirmed it does not use a new ICMP message but instead piggybacks on the application's next outgoing data packet.

9. Reordering Guidance Draft

• Presentation: Reordering Guidance Draft
• Presenter: Greg White
• Discussion:
  • Greg White discussed how Layer 2 links (such as Wi-Fi, 5G, and DOCSIS) introduce significant latency when attempting to perform resequencing (in-order delivery) for packets that are lost or delayed. Because Layer 2 is unaware of upper-layer contexts, it often delays independent packets.
  • The draft aims to provide guidance to Layer 2 standards bodies (such as IEEE 802.11 for Wi-Fi 9 and 3GPP for 6G) on when they should and should not enforce in-order packet delivery.
  • Q&A:
    • Lorenzo Colitti: Recommended moving the draft to TSVWG, as transport protocols are the direct sufferers of this behavior. He also suggested avoiding the word "reordering" in the title, as it can be confusing.
    • Greg White: Agreed that definitions are tricky, but clarified that the draft explicitly distinguishes "reordering" (the act of packets getting out of order) from "resequencing" (the act of buffering to put them back in order).

Decisions and Action Items

• draft-ietf-intarea-arp-yang-model: The chairs will initiate Working Group Last Call (WGLC).
• draft-ietf-intarea-tunnels: Jen Linkova will follow up with the authors regarding the expired document and outstanding WGLC comments.
• draft-van-mook-intarea-v4viav6-gateway and Legacy IANA Registries draft: The chairs will initiate a call for adoption on the mailing list.

Next Steps

• The working group will continue discussions on the mailing list regarding:
  • The appropriate home (INTAREA vs. TSVWG) for the DHCP Explicit Rate Signaling draft and the Reordering Guidance draft.
  • Security concerns and potential updates to the Security Requirements for IP Tunnel Nodes draft based on overlaps with RFC 6169.

Related Documents

draft-00, draft-ietf-intarea-arp-yang-model, draft-ietf-intarea-proxy-config, draft-ietf-intarea-tunnels, draft-van-mook-intarea-v4viav6-gateway