**Session Date/Time:** 27 Jul 2022 19:00

# 6man Session Minutes

## Summary

The 6man working group session included discussions on four working group documents and seven individual drafts. Key updates were provided for segment identifiers, hop-by-hop option processing, and stateless address autoconfiguration. Several individual drafts proposed new IPv6 extension headers for capabilities discovery, upper layer checksums, multi-homing, security (CGA-Light), SRv6 visibility, topology identification, and generalized tunnels. Discussions highlighted the need for clarity, re-evaluation of proposed solutions against existing mechanisms, and the potential for consolidating efforts across different identification schemes.

## Key Discussion Points

*   **Working Group Documents:**
    *   **Segment Identifiers (Suresh Krishnan):** The draft's -01 version addresses IANA and segment endpoint clarifications. A key point of discussion was the definition of `/16` "must not" in operational guidelines, which is deferred to Spring WG.
    *   **Hop-by-Hop Processing Procedures (Gori):** Updates in -01 included refining the document's scope, clarifying option support, and changing a "must not" to "should not" for flexibility. Extensive discussion occurred around 9 open issues, particularly the replacement of "slow path/fast path" terminology with "processing at full forwarding speed." Input on RFC status (BCP/Informational) and ASIC implementation experience was requested.
    *   **Stateless Address Autoconfiguration (Fernando Gont):** A new, more robust algorithm for deprecating stale information was presented. The algorithm relies on unicast Router Solicitations to verify missing information. Discussion points included configurable retries for probes and the potential overlap with existing 6man work on stale prefixes.
    *   **Carrying VTN Information in IPv6 Extension Headers (Hongyi):** A fixed-length Hop-by-Hop option for Virtualized Trust Network (VTN) information was proposed, with a "Strict Match" flag for forwarding behavior. Comments suggested making the option more generic and clarifying its relationship with Network Resource Partitions (NRP) and 5G network slicing.

*   **Individual Documents:**
    *   **ICMPv6 Extensions for IoM Discovering (Xiaoyong):** Proposed ICMPv6 Echo Request/Reply extensions for In-situ OAM (IoM) capabilities discovery. Concerns were raised about using Echo messages for information queries, with suggestions to explore Node Information Query or new ICMP types.
    *   **IPv6 Upper Layer Checksum (Xiaoyong):** Addressed an issue with RFC 8200's upper layer checksum calculation when SRv6 uses compressed SIDs. Proposed inserting a 128-bit final destination address into the last SID with a new SRH flag. Discussion questioned the premise of the problem statement, suggesting current mechanisms might already handle this.
    *   **Neighbor Discovery for Multi-homing Multi-prefix Networks (Paolo Volpato):** Explored ND's role in multi-homing, focusing on "non-equal prefixes" scenarios like walled gardens. The draft proposed prioritizing source address selection before next-hop selection. Critiques included the simplicity of using per-PVD link-local addresses (RFC 8801) and potential overlap with other working group efforts.
    *   **CGA-Light (Eduard Vinogradov):** Proposed a simplified Cryptographically Generated Addresses (CGA) mechanism to bind MAC addresses to IP addresses, aiming to prevent IP address impersonation without complex Public Key Infrastructure (PKI). Discussion revolved around potential privacy concerns, the effectiveness against various attacks, and the reliance on Layer 2 security.
    *   **Export of SRv6 Information in IPFIX (Thomas Graf):** Presented an approach to export SRv6 forwarding plane information via IPFIX, enhancing data plane visibility during SRv6 deployments and migrations. No changes to RFC 8754 (SRH) are proposed, but changes to RFC 1711 (IPFIX) are.
    *   **Topology Identifiers in Extension Header (Liu):** Proposed a new Hop-by-Hop option to carry "Topology Identifiers" for Multi-Topology/Flex-Algo to share IP addresses. Strong opposition was raised, arguing that existing Flex-Algo designs avoid in-packet data requirements and that IPv6's address space makes such sharing unnecessary, potentially reintroducing problems seen with MTRs. The need for a generic identifier for slicing/APN was also noted.
    *   **Generalized IPv6 Tunnel (Jiamin):** Briefly outlined a proposal for a generalized IPv6 tunnel header to consolidate new feature encapsulations (e.g., slicing, APN, IoM) into IPv6 extension headers, aiming to reduce standardization work and improve consistency across tunnel types.

## Decisions and Action Items

*   **Segment Identifiers (Suresh Krishnan):**
    *   **Decision:** Chairs will issue a Working Group Last Call (WGLC) for the document, likely early next week.
    *   **Action Item:** Chairs will craft and send an official message to the Spring Working Group regarding this document's completion and subsequent actions for them.
*   **Hop-by-Hop Processing Procedures (Gori):**
    *   **Action Item:** Working group members are requested to review the document, provide feedback (especially on the "processing at full forwarding rate" language), and suggest text for outstanding issues.
    *   **Action Item:** Fernando Gont volunteered to conduct a review.
*   **Improvement to Stateless Address Autoconfiguration (Fernando Gont):**
    *   **Action Item:** Fernando Gont will send the updated draft text for the algorithm (specifically the TBD section 4.5) to the mailing list for review, with a preference for a state machine description.
*   **ICMPv6 Extensions for IoM Discovering (Xiaoyong):**
    *   **Action Item:** Discussion on the appropriateness of using ICMPv6 Echo Request/Reply for IoM capabilities discovery will continue on the mailing list, exploring alternatives like Node Information Query.
*   **IPv6 Upper Layer Checksum (Xiaoyong):**
    *   **Action Item:** Discussion on the problem statement and proposed solutions will continue on the mailing list.
*   **Neighbor Discovery for Multi-homing Multi-prefix Networks (Paolo Volpato):**
    *   **Action Item:** The authors will consider feedback, especially regarding the explicit problem statement for why per-PVD link-local addresses (RFC 8801) are not sufficient and the removal of the ULA discussion.
    *   **Action Item:** Further discussion on the proposed source address selection order will occur on the mailing list.
*   **CGA-Light (Eduard Vinogradov):**
    *   **Action Item:** The authors will consider adding a mention of dynamic MAC address changes (e.g., Windows 10 randomization) and their implications for CGA-Light.
    *   **Action Item:** Discussion on the draft's security model, attack prevention, and relation to existing L2 security mechanisms will continue on the mailing list.
*   **Topology Identifiers in Extension Header (Liu):**
    *   **Action Item:** Discussion will continue on the mailing list, specifically addressing the rationale for the proposal in light of existing Flex-Algo mechanisms and the broader need for a generic network slicing/APN identifier.
    *   **Action Item:** It was suggested that 6man could send a liaison statement to the TEAS Working Group chairs to inquire about the status of network slice documents and the consolidation of various identifier proposals.

## Next Steps

*   Working group members are encouraged to read the presented drafts and provide constructive feedback on the mailing list.
*   Authors should revise their drafts based on the discussions and comments received.
*   Chairs will follow up on the planned WGLC and inter-WG communications.
*   General discussion on consolidating various network identifier proposals (for slicing, APN, VTN, etc.) may be pursued through cross-WG liaison.