# IETF116 6MAN   {#ietf116-6man}

Wednesday, 29 March 2023, 09:30-11:30 GMT+9   
Minutes taker: Darren Dukes

## Agenda   {#agenda}

Introduction, Agenda Review, and Document Status , Chairs, 15 min.

### Working Group Drafts   {#working-group-drafts}

Carrying Virtual Transport Network (VTN) Information in IPv6 Extension
Header, [draft-ietf-6man-enhanced-vpn-vtn-id][1], Jie Dong, Robin Li, 15
min

Improving the Robustness of Stateless Address Autoconfiguration (SLAAC)
to Flash Renumbering Event, [draft-ietf-6man-slaac-renum][2], Fernando
Gont, 20 min.

Limits on Sending and Processing IPv6 Extension Headers,
[draft-ietf-6man-eh-limits][3] , Tom Herbert, 15 min.

IPv6 Hop-by-Hop Options Processing Procedures,
[draft-ietf-6man-hbh-processing][4] , Gorry Fairhurst, Bob Hinden, 15
min.

### Individual Drafts   {#individual-drafts}

Tracing process in IPv6 VPN Tunneling Networks,
[draft-peng-6man-tracing-option   
][5], Shuping Peng, 10 min.

Signalling DHCPv6 Prefix Delegation Availability to Hosts,
[draft-collink-6man-pio-pflag][6] , Lorenzo Colitti, Jen Linkova, 10
min.

### If Time Allows   {#if-time-allows}

Generalized IPv6 Tunnel, [draft-li-rtgwg-generalized-ipv6-tunnel][7] ,
[draft-li-rtgwg-gip6-protocol-ext-requirements][8] , Hongyi Huang,
Qiangzhou Gao, 5 min.

## Introduction, Agenda Review, and Document Status , Chairs, 15 min.   {#introduction-agenda-review-and-document-status--chairs-15-min}

### draft-ietf-6man0rfc6874bis-05   {#draft-ietf-6man0rfc6874bis-05}

*   Currently in the IESG, working to resolve two DISCUSSes.

### draft-ietf-6man-sids-02   {#draft-ietf-6man-sids-02}

*   Suresh: issues added to SPRING issue tracker
*   Bob: Normative reference to be added to this draft for the spring
    compression draft.

### Colaboration with other IETF working groups   {#colaboration-with-other-ietf-working-groups}

*   As the slide says 6man can start working after another working group
    has adopted and expressed interest.

## Working Group Drafts   {#working-group-drafts-1}

## Carrying Virtual Transport Network (VTN) Information in IPv6 Extension Header, draft-ietf-6man-enhanced-vpn-vtn-id, Jie Dong   {#carrying-virtual-transport-network-vtn-information-in-ipv6-extension-header-draft-ietf-6man-enhanced-vpn-vtn-id-jie-dong}

*   still work in progress
*   Warren Kumari: How does this relate to APN?
*   Jie: This doc solves the network slicing case in TEAS, not clear how
    it may relate to APN.
*   Adrian Farrel: Re Warren - difference with APN is the intent of
    information carried.
*   Tom Herbert: Why limit the topology to only nodes that process HBH
    options?
*   Jie: for nodes not implementing recent HBH process it may be good to
    avoid them.
*   Jen: Take the discussion to the list
*   Louis Chan: forwarding plane impact? do you have reports and real
    numbers??
*   Jie: kept format simple and length short, no reported numbers.
    continue on the list
*   Shuping: described difference with APN. APN is not trying to carry
    the information related with Applications but some information being
    held at the network edge devices such as VPN information and access
    interface information, which are lost when the packets enter into
    the network. APN is figuring out how to carry this information in a
    reasonable format to enable network continuously having such fine
    granularities to provide fine granular network services.

## Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Event, draft-ietf-6man-slaac-renum Fernando Gont   {#improving-the-robustness-of-stateless-address-autoconfiguration-slaac-to-flash-renumbering-event-draft-ietf-6man-slaac-renum-fernando-gont}

*   Erik Nordmark: what is the cause trigger? In a simple case, how will
    the algorithm work?
*   Lorenzo Colitti: This spec may be over specified specific examples 2
    hour rule. Consider how to fix this in the draft.
*   Lorenzo: This may break existing operational practices (reasons
    given). Suggested splitting this draft into multiple RFCs. Take the
    algorithm out. Keep it simple. Also, thinks suggested lifetimes
    won’t work well with higher packet loss. Plan for 66% packet loss in
    mobile.
*   Jen: What does configuration information in a host mean?
*   Tim Winters: Same concern about algorithm as Lorenzo. Changed a lot
    of lifeitmes.
*   Jen: move to the mailing list.
*   **ACTION**: Chairs will request authors to refine document to agreed
    features, once that is done will start w.g. last call.

## Limits on Sending and Processing IPv6 Extension Headers, draft-ietf-6man-eh-limits , Tom Herbert   {#limits-on-sending-and-processing-ipv6-extension-headers-draft-ietf-6man-eh-limits--tom-herbert}

*   Tom: Draft is stable, requesting WGLC
*   Erik Kline: Has the draft had a routing area review?
*   Jen: I'll request it.
*   Ana Custura: 108 bytes appears to be dropped in experiments.
*   Tom: There are good data there. HBH needs more bytes to be carried.
*   Fernando Gont: Is the minimum recommended value based on experience
    or where we want to get?
*   Tom: We don't have data yet. Guidance is needed on the minimum
    value.
*   Fernando Gont: A target is better to be set and people know about
    expectation.
*   Jen: move to the list.
*   General question if this should be standards track or a BCP.
*   **ACTION**: Chairs will start w.g. last call after IETF meeting.
    Include question about Standards track or BCP.

## IPv6 Hop-by-Hop Options Processing Procedures, draft-ietf-6man-hbh-processing , Gorry Fairhurst, Bob Hinden   {#ipv6-hop-by-hop-options-processing-procedures-draft-ietf-6man-hbh-processing--gorry-fairhurst-bob-hinden}

*   Gorry Fairhurst presented
*   Ready for WGLC?
*   Fernando Gont: Any hints on the limitation of the value?
*   Gorry: Dont have. Fernando: Dont know either. Could be a trade-off?
    Better to give suggestions on the value. Gorry: not easy to get,
    depends upon a lot of things like hardware capabilities, etc. By
    putting a number will not help but may make it worse. Fernando: can
    we give a suggestion? Gorry: Dont want to constrain how it evolves
    in the future.
*   Timothy Winters: Only router or host as well? Better to be careful
    on the word used. Nodes or routers? Which word to use? "forward" is
    used in the sentece.
*   Bob: will go back and look.
*   Jen Linkova: wait for the new version.
*   **ACTION**: Chairs will start w.g. last call after new version is
    available.

## Individual Drafts   {#individual-drafts-1}

## Tracing process in IPv6 VPN Tunneling Networks, draft-peng-6man-tracing-option , Shuping Peng   {#tracing-process-in-ipv6-vpn-tunneling-networks-draft-peng-6man-tracing-option--shuping-peng}

*   Eric Vynke: if you do a traceroute and you receive all those ops
    being always coming from PE1, this would be quite confusing. And the
    other point, do you copy the TTL into the hop limit?
*   Shuping: Yes, but also changed based on the mode being configured at
    the source PE. For the uniform mode, the HL = TTL - 1, for the pipe
    mode, the HL is set as max.
*   Erik Kline: You referenced 4443, that's a MPLS tunneling document.
    For IPv6 tunneling you might want to look at RFC 2473.

## Signalling DHCPv6 Prefix Delegation Availability to Hosts, draft-collink-6man-pio-pflag , Lorenzo Colitti, Jen Linkova   {#signalling-dhcpv6-prefix-delegation-availability-to-hosts-draft-collink-6man-pio-pflag--lorenzo-colitti-jen-linkova}

*   Lorenzo Colitti presented.
*   Suresh Krishnan: The flag using is already taken.
*   Jen: will change.
*   Tomek Mrugalski: there's no need for normative langauge for REBIND,
    that's something that can be forced from the network policy by
    setting t1 equal to t2 and the clients will automatically send.
    Also, great the decade long RA vs DHCP debate coming to an end.
*   David Lamparter: if there multiple routers and multiple DHCP
    servers, would the client pick up one prefix only?
*   Tomek Mrugalski: no, the client doesn't require to select one prefix
    only, can use multiple prefixes.
*   Lorenzo Colitti: We will make it does work.
*   Fernando Gont: How does it coexist with IA\_NA? Dont want one more
    option for something already working. Also, we need to make sure the
    same prefix is assigned to the same client.
*   Lorenzo Colitti: Renumbering has been taken care of by using REBIND.
    Not sure that work belongs to 6man. if you do IA\_NA, what you would
    have to do, you have to start asking for PD, this is out of scope
    for this WG, Tim says a new draft would be needed.
*   Jen: This scenario should behave better in case of renumbering, as
    the host gets an explicit signal about renumbering.
*   Timothy Winters: Needs to take care of the L flag. Lorenzo: yes will
    do.
*   Timothy: A new draft might be needed or maybe RFC8415 already
    describes everything.
*   Suresh Krishnan: M and O bits are shot, meanings are fuzzy so a new
    bit is right way to go. Make sure the semantics are expected with
    this bit are clear.
*   Lorenzo: It is clear in the draft.

## If Time Allows   {#if-time-allows-1}

## Generalized IPv6 Tunnel, draft-li-rtgwg-generalized-ipv6-tunnel , draft-li-rtgwg-gip6-protocol-ext-requirements , Hongyi Huang, Qiangzhou Gao   {#generalized-ipv6-tunnel-draft-li-rtgwg-generalized-ipv6-tunnel--draft-li-rtgwg-gip6-protocol-ext-requirements--hongyi-huang-qiangzhou-gao}

*   Cong Li (China Telecom) presented.
*   Summary of the GIP6 side meeting
*   Jen: Ran out of time for discussion

## Meeting Adjourned   {#meeting-adjourned}

#### See everyone at IETF 117 in San Francisco.   {#see-everyone-at-ietf-117-in-san-francisco}



[1]: https://datatracker.ietf.org/doc/draft-ietf-6man-enhanced-vpn-vtn-id/
[2]: https://datatracker.ietf.org/doc/draft-ietf-6man-slaac-renum
[3]: https://datatracker.ietf.org/doc/draft-ietf-6man-eh-limits/
[4]: https://datatracker.ietf.org/doc/draft-ietf-6man-hbh-processing/
[5]: https://datatracker.ietf.org/doc/draft-peng-6man-tracing-option
[6]: https://datatracker.ietf.org/doc/draft-collink-6man-pio-pflag
[7]: https://datatracker.ietf.org/doc/draft-li-rtgwg-generalized-ipv6-tunnel
[8]: https://datatracker.ietf.org/doc/draft-li-rtgwg-gip6-protocol-ext-requirements