Markdown Version | Session Recording | Session Materials

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.

Related Documents

draft-gont-v6ops-ipv6-multihoming, draft-ietf-v6ops-464xlat-clat, draft-ietf-v6ops-dns64-prefix, draft-ietf-v6ops-nat64-traceroute, draft-zhang-v6ops-ipv6-only-framework