**Session Date/Time:** 19 Mar 2025 06:00

# v6ops

## Summary

The v6ops meeting covered several working group drafts and individual drafts. Key topics included CLAT source address selection, a framework for multi-homed IPv6-only networks, replacing DNS64 with RA-based prefix discovery, mitigating IPv6 NAT64 trace route issues, and improving IPv6 support for multi-interface/multi-router scenarios. There were also discussions around the use of LLMs to answer IPv6 questions, IPv6 deployment monitoring and analysis.

## Key Discussion Points

*   **IETF Process:** A reminder of the IETF process, policies, patent disclosure requirements, and expected respectful conduct.
*   **Working Group Status:** Concerns about declining attendance and milestones being slightly behind schedule. The need for more input and real-world experience on v6 mostly deployments was highlighted.
*   **LLM for IPv6:** Presentation on using LLMs to answer factual IPv6 questions with high accuracy. Concerns were raised regarding LLM's "creativity" potentially straining resources.
*   **CLAT (draft-ietf-v6ops-464xlat-clat):**
    *   Clarification on CLAT source address treatment and duplicate address detection.
    *   Discussion on multi-homing scenarios and guidelines for avoiding multiple CLAT instances.
    *   Debate regarding the practicality of implementing complex features like source address selection.
    *   Consideration of environments with only a single /128 address and whether to support them or reference BCP 7934 which recommends against giving general purpose hosts a single /128.
*   **Framework for Multi-homed IPv6-only Networks (draft-zhang-v6ops-ipv6-only-framework):**
    *   Presentation of a framework for building scalable IPv6-only backbone networks with IPv4 service support.
    *   Concern raised about overhead to routers specifically around 64 bit vs 128 bit lookup key.
    *   Discussion about how the P router can figure out how to send the packet to the next hop.
*   **Deprecating DNS64 (draft-ietf-v6ops-dns64-prefix):**
    *   Problems with RFC 7050 (DNS64) and potential improvements/alternatives.
    *   Recommendation to prioritize RA-based NAT64 prefix discovery (PREF64) over DNS64.
    *   Concern raised regarding mobile network operator adoption of PREF64.
    *   Discussion about where this draft should go, including the recommendation to talk about it in the 6man working group.
*   **Mitigating IPv6 NAT64 Trace Route Issues (draft-ietf-v6ops-nat64-traceroute):**
    *   Definition of how to translate untranslatable IPV6 addresses by using a IANA allocated IPv4 dummy address.
    *   Discussion of how to preserve the original V6 addresses and suggesting that we obsolete a previous work on this topic and proceed with this one.
*   **Improving IPv6 Support for Multi-Interface/Multi-Router Scenarios (draft-gont-v6ops-ipv6-multihoming):**
    *   Problem statement for improving IPv6 support in scenarios with multiple routers, interfaces, and prefixes.
    *   Proposed scenarios and recommendations for host-side improvements to address common failures.
    *   Discussion about prior work (RFC 7556, RFC 8801, Shim6).
    *   Clarifications on what's new.
*   **IPv6 Network Deployment Monitoring and Analysis Advancements:**
    *   System to drive the growth of IPV6 traffic including highlighting technical gaps in IPv6 before to IPV6 transition.
    *   Newly defined a complete set of key performance indicators including readiness indicators and operational metrics and quality metrics.

## Decisions and Action Items

*   **CLAT:**
    *   The authors to add a section referencing BCP 7934, recommending against single /128 address assignments.
    *   The authors to solicit complexity concerns on the mailing list and include explanation in the draft.
    *   Clarify that the recommendation and modification of the 6877 about the dedicated source prefix is on the host only.
    *   The document is going to proposed standard.
*   **Framework for Multi-homed IPv6-only Networks:**
    *   Authors to check mail and specify how the P router can figure out where to send the package to the next hop.
*   **Deprecating DNS64:**
    *   Discuss further within 6man about host requirements to implement pre-6-4 since this draft suggests a change in behavior of 87 implementation.
    *   Authors to add use case where you can use 70 50 without the ns 64 (e.g. synthesizing the code A only for IPV4 only that rpa).
*   **Mitigating IPv6 NAT64 Trace Route Issues**
    *   Chairs to follow up about adoption
*   **Improving IPv6 Support for Multi-Interface/Multi-Router Scenarios:**
    *   The authors to reference RFC 7556, RFC 8801, Shim6 to acknowledge prior work.
    *   Author to emphasize what's new.

## Next Steps

*   Continue discussion on the mailing lists for all drafts.
*   Authors to revise their drafts based on the feedback received during the meeting.
*   Working group chairs to consider adoption calls for appropriate drafts.