# 6MAN Working Group - IETF 115   {#6man-working-group---ietf-115}

Mon, 7 Nov 2022, 13:00-15:00 GMT  
Chairs: Bob Hinden, Jen Linkova, Ole Trøan

Minute taker: Michael Richardson  
Jabber Scribe: (none)

Jabber Room: 6man@jabber.ietf.org

Meetecho:
https://meetings.conf.meetecho.com/ietf115/?group=6man&short=&item=1  
Mon, 7 Nov 2022, 13:00-15:00 GMT  
Introduction and Document Status, Chairs, 10 min.

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

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

*   review of changes from -01 to -04: avoiding fastpath/slowpath term.
*   difficulties in balancing SHOULD/MUST.  
    DaveThaler: I find that the statements with "low", "reasonable"
    ambiguous and so do not use them in SHOULD/MUST.
    https://github.com/ietf-6man/hbh-processing/issues/22  
    RonBonica (RB): If we had done all of this stuff five years ago,
    when doing RFC8200, the sections on HbH and Extension Headers might
    be diferent. Would it be a good idea to merge these drafts, and then
    just update RFC8200? So synthesis will be done by authors rather
    than readers.  
    GF: Tom's document is still developing, but in the end, the two
    documents can live separately, and maybe the two documents have
    different readers. Clearly what you propose could also be done.  
    GF: should we do normative changes to RFC8200?  
    RB: PLMs from router computers need to read and implement both  
    SureshKrishna (SK): we had never treated HbH an EH as ordered, but
    now we are treating them as ordered, and so different options will
    jockey to be first.  
    GF: putting the option on every packet might not be something you
    should do, because it trumps other options that wanted to be first. 
    
    ChenLi(CL)???: proposes ... not sure.  
    GF: please send to the list.  
    \*\* Per-AS Travesal  
    \*\* We learned  
    \*\* WGLC? (no discussion/comments)

13:31!

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

GF: would be good to work with you for a coherent set of recommendations
for both drafts.  
TW: RFC8504 has text, and are you trying to update that text?   
TH: Yes, I think it does in fact update RFC8504, so we'll need to make
that change (ACTION)

### Segment Identifiers in SRv6 draft-ietf-6man-sids, Suresh Krishnan, 15 min   {#segment-identifiers-in-srv6-draft-ietf-6man-sids-suresh-krishnan-15-min}

no questions

### Carrying Virtual Transport Network (VTN) Information in IPv6 Extension Header, draft-ietf-6man-enhanced-vpn-vtn-id, Zhenbin Li, 10 min   {#carrying-virtual-transport-network-vtn-information-in-ipv6-extension-header-draft-ietf-6man-enhanced-vpn-vtn-id-zhenbin-li-10-min}

Éric Vyncke(EV): why do we keep getting this stuck to 32-bits ID? We
have reserved bits and we could generalize this to many other use cases?

ZL: the generalization needs to first identity the use cases. In the VTN
options we might need to retain the capability to extend the options to
new things

no time for more questions.

14:03

## Individual Drafts   {#individual-drafts}

### Carrying a Generic Identifier in IPv6 packets, draft-iurman-6man-generic-id, Justin Iurman, 10 min   {#carrying-a-generic-identifier-in-ipv6-packets-draft-iurman-6man-generic-id-justin-iurman-10-min}

Jie Dong: With the Flags field and the Reserved field, the VTN option
can provide the same capability for future extension. VTN also has the
generic semantic that it can be used to convey various network-wide
attributes. The suggestion is to start with a base document to meet the
existing use cases (e.g. network slicing), and future extensions can be
made when there is new use cases.

MCR: question at mic, 1) we should ask the hardware people if they can
actually match on this option context, 2) if we are really going to
consider all options to be "00" type, then do we in fact have more
options available? 3) we don't have that many 00 options defines today,
so many we are not out of options, and if we get more in the future,
maybe we do not need this.

(Did not get Zhenbin Li's comments)

PascalThubert(PT): RPL has defined an option RH3/RPI that defines a
VTN-like thing, so maybe you could reuse that option rather than define
a new one.

### Neighbor Discovery support for Multi-home Multi-prefix , draft-vv-6man-nd-support-mhmp, Paolo Volpato, 10 min   {#neighbor-discovery-support-for-multi-home-multi-prefix--draft-vv-6man-nd-support-mhmp-paolo-volpato-10-min}

SK: the goal was to scope this down, to the minimum viable scope. Go to
INTAREA? One of the things that made MIF less successful was whether or
not the end-hosts are willing to implement.  
PoaloVolpato: not the goal to extend the scope of this document.  
LorenzoColleto(LC): selecting the address before one does the routing
lookup does not allow you to do certain things, and prevents a straight
line algorithm. Should applications use bind(2), and I would not advise
not to do this, because applications can't do it. Source address
selection is just too hard, and that's why Android decided not to make
applications do this, and let the stack decide on the source address.

time: 14:12

### ICMPv6 Extensions for IOAM Capabilities Discovery, draft-xiao-6man-icmpv6-ioam-conf-state, Xiao Min, 10 min   {#icmpv6-extensions-for-ioam-capabilities-discovery-draft-xiao-6man-icmpv6-ioam-conf-state-xiao-min-10-min}

time: 14:26

### CGA light, draft-ev-6man-cga-light, Eduard Vasilenko (remote), 10 min   {#cga-light-draft-ev-6man-cga-light-eduard-vasilenko-remote-10-min}

EV: the problem isn't encryption/but key management.  
no discussion.

### IPv6 Neighbor Discovery on Wireless Networks, draft-thubert-6man-ipv6-over-wireless, Pascal Thubert, 10 min   {#ipv6-neighbor-discovery-on-wireless-networks-draft-thubert-6man-ipv6-over-wireless-pascal-thubert-10-min}

DavidLamparter(DL): in that mesh network scenario, what is the benefit
of considering that a subnet? If one looks at RFC7404 what is the
advantage of considering it a subnet, vs having a /128 router?  
PT: this is exactly what we do!   
DL: so what problem are you solving?  
PT: The piece that we are discussing here is how the host tells the
router where they are.   
DL: so you are trying to increase mobility?   
PT: Yes, exactly.  
LC: you really don't want to use ND for this, it doesn't have updates!
We have this concept of subnets which is stuck in IPv4, but really it's
not even IPv4, it's what's local. How do the hosts communicate with
routers?  
PT: the router doesn't have a clear idea of where the hosts are...   
TAKEN TO THE LIST.

### Stub Router Flag in ICMPv6 Router Advertisement Messages, draft-hui-stub-router-ra-flag, Ted Lemon/Jonathan Hui, 10 min   {#stub-router-flag-in-icmpv6-router-advertisement-messages-draft-hui-stub-router-ra-flag-ted-lemonjonathan-hui-10-min}

LC: I think that this is useful. But why is it the router itself, vs the
PIOs and the routes that it advertises that should be marked?  
TedMelon: stub routers are going to send this, and going to consume it. 

LC: Why not apply this to the PIO itself rather than the RA?  
TM: I'd like to see this WG adopt it, or instructed to adopt it
elsewhere.  
EV: this looks like a small piece of a big solution, so it can not judge
the solution without the whole solution.  
BobHinden: in order to do this, SNAC needs to ask for this? SNAC should
decide that it wants this and ask to adopt it.  
SK: there aren't 6 bits left, there are 6 bits taken, and 2 bits left.
So, this needs to go into the option. And so SNAC can do the work, and
do it in the option. Put it in the RA flags rather than in the PIO.  
EricVyncke(EV): int area ADs discussion here... we are not able to in
the charter of SNAC to process any flags, so we have to come to 6man for
the flag.

## Meeting Adjourned   {#meeting-adjourned}

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

### IP Payload Compression excluding transport layer, draft-ls-6man-ipcomp-exclude-transport-layer, Hang Shi, 5 min   {#ip-payload-compression-excluding-transport-layer-draft-ls-6man-ipcomp-exclude-transport-layer-hang-shi-5-min}

### Encoding Network Slice Identification for SRv6, draft-cheng-spring-srv6-encoding-network-sliceid, Liyan Gong, 5 min   {#encoding-network-slice-identification-for-srv6-draft-cheng-spring-srv6-encoding-network-sliceid-liyan-gong-5-min}