Introduction and Document Status, Chairs, 10 min

no comments on agenda/status

Working Group Drafts

Segment Identifiers in SRv6, draft-ietf-6man-sids, Suresh Krishnan, 15 min

• Erik Kline: (proxying Andrew) how about the /16 being a "MUST NOT"?
• Suresh Krishnan: open to discussion
• Erik Kline: suggest to put in communication with spring

IPv6 Hop-by-Hop Options Processing Procedures, draft-ietf-6man-hbh-processing, Gorry Fairhurst, Bob Hinden, 20 min

• Fernando Gont: offering to review

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

• Tommaso Pecorella: what if information keeps being sent and lost?
  maximum time limit before giving up?
• Fernando Gont: this is assumed to be configurable, could default to
  3, and at some point SLAAC just breaks
• Tim Winters: Multicast RA before getting rid?
• Fernando Gont: no, because per router basis
• Jen Linkova: send All-Routers RS instead of unicast? e.g. router
  changes address
• Fernando Gont: expect that router multicasts RA after address change
• Jen Linkova: removal - on invalid or deprecated?
• Fernando Gont: would just be gone when the last router disappears
• Jen Linkova: breaks connectivity for remaining hosts?
• Fernando Gont: (missed on notes)
• Jen Linkova: does "no response" include "response not including PIO"
• Fernando Gont: would include the latter
• Bob Hinden: never seen router splitting information, is it useful?
• Fernando Gont: not seen, algorithm is just robust against it
• Erik Kline: TBD section 4.5 - state machine or narrative? preference
  for state machine
• Fernando Gont: mostly ready to send out to look at

Carrying Virtual Transport Network (VTN) Information in IPv6 Extension Header, draft-ietf-6man-enhanced-vpn-vtn-id, Jie Dong, 10 min

• Éric Vyncke: repeat of previous comment - fixed length option for
  single use case is a waste, would prefer varying length for multiple
  use cases
• Jie Dong: The rule in hbh-processing draft suggests using fixed
  length options, which may need to be considered. We've introduced
  new fields to improve extensibility
• Joel Halpern: intention/wording is confusing, hoping for resource ID
  to identify allocation, but not clear. and relation to teas NRP ID
  header should be clarified.
• Jie Dong: yes, intended to be resource ID. While further discussion
  on semantics generalization may have impact to this.

Individual Drafts

ICMPv6 Extensions for IOAM Capabilities Discovery, draft-xiao-6man-icmpv6-ioam-conf-state, Xiao Min, 10 min

• (chat comment missed)
• Éric Vyncke: annoyed by using echo request/reply for this, would
  prefer e.g. Node query
• Xiao Min: (? / not understood)
• continuing on list

SRv6 Upper-Layer Checksum, draft-xiao-6man-srv6-checksum, Xiao Min, 5 min

• Darren Dukes: SR source knows destination, compressed does not
  matter, and by the time packet reaches dest, address will be
  replaced - no need for this draft, works as is
• Xiao Min: have problem statement in draft
• Darren Dukes: disagree with problem statement
• continuing on list

Neighbor Discovery support for Multi-home Multi-prefix, draft-vv-6man-nd-support-mhmp, Paolo Volpato, 10 min

• David Lamparter: anything achievable by changing selection order can
  also be achieved with additional LL address as nexthops
• Paolo Volpato: open to discussion
• Erik Kline: ACKing 8801 per-PVD link local addresses solve this,
  it's done, issues with that?
• Fernando Gont: overlap with other WG & v6ops documents, need to do
  this in that context; document also tries to address operational
  concerns, that should go to v6ops; how about noting down the
  remaining problems/gaps first?; also lots of very specific cases in
  current doc rather than holistic approach
• Eduard Vasilenko: tried to delete everything that overlaps, trying
  to solve specific case, will take feedback into consideration
• Eduard Vasilenko: believe 8801 to not be enough, planning to discuss
  offline
• Jen Linkova: seconding PVD comment, topic started in 2016, if PVD
  does not solve this that needs to be clarified
• Eduard Vasilenko: PVD only good enough after source address was
  chosen, not enough on its own. but yes PVD is applicable.
• Jen Linkova: section in beginning of document to explain this

CGA light, draft-ev-6man-cga-light, Eduard Vasilenko (remote), 10 min

comments on slide 4

• Éric Vyncke: again binding IID to MAC - back to EUI-64 problem and
  lack of privacy?
• Eduard Vasilenko: no, enough information fed into hash; will chose
  different inputs
• Éric Vyncke: madinas WG about randomizing and changing MAC address,
  being deployed, how does it affect this?
• Eduard Vasilenko: generating new identifier should still work with
  this
• Éric Vyncke: should be mentioned in draft

comments at end

• Fernando Gont: goal is to prevent IP address impersonation?
• Eduard Vasilenko: yes, nobody else can claim address
• Fernando Gont: what are the attacks you have in mind?
• Eduard Vasilenko: slide 2, poisoning caches of other nodes, MITM
• Fernando Gont: tying identifiers has generally proven to bring
  problems, move away from EUI-64 similar, and if you need RA-guard
  anyway why not ND inspection to fix this?
• Eduard Vasilenko: not enough support for ND inspection in switches,
  RA guard simpler & supported everywhere. CGA/SeND connecting public
  key to IP, this is connecting MAC to IP instead. Avoid need for cert
  infrastructure.
• Jen Linkova: not clear why only disconnected node could be attacked
• Eduard Vasilenko: partially true, assuming L2 infra would flap when
  same L2 address is reused
• Jen Linkova: relying on monitoring for this, not prevented?
• Eduard Vasilenko: yes, assuming flapping, noticeable issues
• Jen Linkova: address conflicts could be detected too. / Separately,
  if hosts are not trusted, why not deploy L2 isolation?
• Eduard Vasilenko: L2 isolation not typical in targeted situations,
  generally rare
• continuing on list

Export of Segment Routing IPv6 Information in IP Flow Information Export, draft-tgraf-opsawg-ipfix-srv6-srh, Thomas Graf, 5 min

• Erik Kline: to be clear, no changes to 8754?
• Thomas Graf: ACK, only IPFIX changes

Topology Identifier in IPv6 Extension Header, draft-li-6man-topology-id, Zhibo Hu, 5 min

• Peter Psenak: when flexalgo was designed, requirement was not to
  have any specific date in the packet, working on label or address.
  what's presented here is completely opposite to that. tried and
  failed due to classification at every hop.
• Éric Vyncke: same comment as on previous draft, VPN ID marking is
  interesting, but make it generic
• Suresh Krishnan: is the host adding this information? who is putting
  it in?
• Zhibo Hu: ingress router doing the encap adds it
• Suresh Krishnan: security & related properties are scary, needs more
  consideration & discussion
• Zhenbin Li: design of flex algo consumes more IP addresses, trying
  to avoid that with alternate signaling. also active discussion in
  teas WG about identifiers
• Joel Halpern: does not add up; needing IP addresses is a benefit,
  not drawback, enough addrs in IPv6. new extension header to take
  into account is a very complicated solution to a non-existing
  problem. please don't.
• Tommaso Pecorella: missed something but extension header cannot be
  added by router?
• Zhenbin Li: router is adding encapsulation header, can add extension
  headers as part of that
• Jen Linkova: ACK with Éric, lots of different drafts for this
  slicing/identifying type of thing, should be merged?
• Erik Kline: mailed teas AD re. status of network slicing documents

If Time Allows

Generalized IPv6 Tunnel (GIP6), draft-li-rtgwg-generalized-ipv6-tunnel, Zhenbin Li (Robin) / Shuanglong Chen, 5 min

draft presented but insufficient time for comments

Encoding Network Slice Identification for SRv6, draft-cheng-spring-srv6-encoding-network-sliceid, Weiqiang Cheng, 5 min

no time left to present this draft

Stateless Best Effort Multicast Using MRH, draft-chen-pim-be-mrh, Huaimo Chen, 5 mins

no time left to present this draft

Stateless Traffic Engineering Multicast using MRH, draft-chen-pim-mrh6, Huaimo Chen, 5 mins

no time left to present this draft