Markdown Version | Session Recording

Session Date/Time: 04 Nov 2025 19:30

V6OPS

Summary

The V6OPS session covered updates on several working group drafts and introduced new individual submissions. Key discussions revolved around refining IPv6 Customer Edge router requirements, deployment considerations for IPv6-mostly networks, advancing the NAT64 family of RFCs, and new work on IPv6 application testing, point-to-point link assignments, 5G IPv6-only deployment, and IPv6 network monitoring. A significant technical discussion focused on the "must not" rule in RFC 6052 regarding translation of RFC 1918 addresses, with a strong sentiment for relaxing it due to operational realities and non-compliance in implementations. The chairs indicated that interest calls for adoption will be made on the mailing list for new drafts.

Key Discussion Points

• IPv6 Customer Edge Router Requirements (draft-ietf-v6ops-ipv6-cpe-router)
  • Incorporated all requirements from RFC 9818 (prefix delegation on LAN side).
  • Adjusted RA advertisement interval to min 2 mins, max 3 mins, with a proposal to align with SlackRenum.
  • Mandated that RA Guard should not be on by default on CE routers, requiring user/operator intervention.
  • M&O flags behavior: Proposed adding text to prevent DHCPv6 servers on home gateways from turning off if M/O flags change, addressing issues with existing open-source implementations. There was general agreement on this.
• IPv6 Mostly Deployment Considerations (draft-ietf-v6ops-v6only-deployment-cons)
  • Added explicit considerations for NAT64 pool selection, recommending sharing pools between NAT44 and NAT64 and ensuring NAT64 stickiness for consistent client external IPv4 addresses.
  • Addressed issues with atomic fragments and UDPv4 packets with zero checksums.
  • The document emphasizes that many observed issues are not specific to IPv6-mostly networks but are exposed when IPv4 is removed.
• YANG Data Model for IPv6 Neighbor Discovery (draft-ietf-v6ops-ipv6-nd-yang)
  • Moved from RTGWG to V6OPS to solicit more operational feedback.
  • Updated to include enhanced DAD and removed SND/SND proxy references.
• NAT64 Family of Documents (various drafts by Lorenzo Colitti)
  • Reviewed status of drafts (6146bis, 67915bis, 7757bis, 7755bis) aimed at advancing RFCs.
  • For RFCs with errata, the path involves WG adoption and WG last call. For those without errata (status change from informational to standard), a consensus call will be run on the mailing list.
  • A significant concern was raised by Lorenzo Colitti and supported by Ted Lemon regarding RFC 67915bis: the document describes a stateful translation mode but does not specify how it works, making assertions of interoperable implementations problematic for advancement to full standard.
• Applications for IPv6 Support (draft-tiesel-v6ops-ipv6-application-support)
  • New work motivated by the US government mandate 2107, highlighting a need for IETF guidance on proper IPv6 application testing in IPv6-only environments.
  • The draft redefines "support IPv6" as applications functioning regardless of the underlying IP environment (IPv4-only, dual-stack, IPv6-only with/without NAT64, true IPv6-only).
  • Proposed deriving IPv6 testing from existing functional integration test suites rather than creating special IPv6-specific tests.
  • Feedback suggested diversifying the justification beyond the US mandate and considering specific "True IPv6 only" scenarios (e.g., with/without DHCPv6 for apps needing NTP/certs).
• IPv6 Point-to-Point Links and Customer Prefix Assignment (draft-carrasco-v6ops-point-to-point-unnumbered)
  • New BCP-aimed work combining existing best practices (e.g., RIPE-690).
  • Recommendations include /48 prefix assignment to end-sites, avoiding prefixes longer than /56, and persistent prefix assignment.
  • WAN Link Numbering: Proposed using a /64 for WAN point-to-point links (optionally the first /64 from the customer's assigned prefix), but this generated significant discussion. Concerns were raised about the lack of CPE support for prefix exclusion, the impact on existing "unnumbered" or link-local deployments (especially in PON/FTTx), and whether "must" should be used given operator contractual and operational complexities.
  • Prefix Persistency: While beneficial for operations, "must" for persistency was opposed due to privacy concerns and operator flexibility for renumbering.
• Gradual IPv6-Only Deployment in 5G Mobile Networks (draft-chenho-v6ops-5g-v6only-deployment)
  • New work describing 464XLAT-based IPv6-only deployment in 5G, proposing RA options for Pref64 and DNS64 addresses.
  • The primary motivation is to allow IPv6-only and dual-stack users to coexist on the same network while ensuring IPv6-only users get DNS64.
  • Discussion questioned the need for a new DNS64 RA option, suggesting standard RDNSS is sufficient and mobile networks can achieve separation via PDP contexts.
• IPv6 Network Deployment Monitoring and Analysis (draft-zhao-v6ops-ipv6-deployment-monitoring)
  • New work proposing an end-to-end monitoring and analysis architecture for IPv6 deployment, addressing issues like fragmented coverage, single-dimension assessment, lack of correlation, and limited prediction.
  • Proposed Key Performance Indicators (readiness, operational, quality metrics).
  • Feedback included aligning with Happy Eyeballs WG discussions on IPv6 brokenness and also focusing on "residual IPv4" to identify offload targets. The chairs reminded the authors to focus on methodologies rather than "scoring" regional deployment status.
• Relaxing the "must not" for translating RFC 1918 addresses (draft-linkova-v6ops-wkp-1918)
  • New work proposing to relax the "must not" clause in RFC 6052, Section 3.1, which prohibits translators from using the well-known prefix for RFC 1918 addresses and mandates dropping such packets.
  • Problem: This rule hinders IPv6-mostly enterprise deployments using public DNS64 when accessing private IPv4 addresses. Operational reality shows widespread non-compliance and breakage if enforced.
  • Historical context: The rule was likely intended to prevent ambiguous DNS64 translations for overlapping private IPv4 address spaces in certain mobile deployments.
  • Proposed Solution: Change "must not" to "may" for prefix usage and "should translate, must not drop" for translators, unless configured otherwise.
  • Discussion: There was strong support for relaxing the rule due to its impracticality and current disregard by implementations. Implementers confirmed they are blocked by this RFC requirement. Concerns were raised about security implications of changing the default, but it was noted that current reliance on this for security is misguided. Debate on the precise normative language ("should" vs. "must") for the updated text.

Decisions and Action Items

• IPv6 CE Router Requirements (draft-ietf-v6ops-ipv6-cpe-router)
  • ACTION: Tim Winters to review the SlackRenum RFC and align the RA advertisement interval values in the CE Router draft.
  • DECISION: Text will be added to the draft to specify that DHCPv6 servers on home gateways should not turn off due to M/O flag changes.
  • ACTION: Chairs to initiate a Working Group Last Call for this document.
• NAT64 Family of Documents (various drafts by Lorenzo Colitti)
  • DECISION: For documents with errata, the process will be WG adoption followed by WG Last Call and then IESG review.
  • DECISION: For documents without errata (informational to standard status change), a consensus call will be run on the mailing list for promotion directly to IESG.
  • ACTION: Lorenzo Colitti, in coordination with the chairs, will conduct a detailed review of RFC 7915 regarding its stateful translation mode and the implications for advancement to full standard.
• Relaxing "must not" for translating RFC 1918 addresses (draft-linkova-v6ops-wkp-1918)
  • ACTION: Jen Linkova to revise the draft's proposed text based on discussion regarding normative language ("should translate," "must not drop," and default behaviors).

Next Steps

• For all new individual drafts presented (Applications for IPv6 Support, IPv6 Point-to-Point Links and Customer Prefix Assignment, Gradual IPv6-Only Deployment in 5G Mobile Networks, IPv6 Network Deployment Monitoring and Analysis, Relaxing "must not" for translating RFC 1918 addresses): The V6OPS chairs will initiate an "adoption call" on the mailing list to gauge working group interest in taking on these documents as working group items.
• IPv6 Point-to-Point Links and Customer Prefix Assignment (draft-carrasco-v6ops-point-to-point-unnumbered): The author will send specific questions on the draft's recommendations (prefix exclude, persistency, WAN link sizing) to the mailing list to gather focused feedback.
• Gradual IPv6-Only Deployment in 5G Mobile Networks (draft-chenho-v6ops-5g-v6only-deployment): The author is encouraged to engage in offline discussions with other participants and experts to gather more information and refine the document, particularly regarding the necessity of a new DNS option.
• All further discussions and comments on the presented drafts should be brought to the V6OPS mailing list.