6MAN Working Group - Montreal IETF Meeting Monday, 16 July 2018, 09:30-12:00, Laurier Chairs: Bob Hinden, Ole Trĝan Minute taker: Barbara Stark Jabber Scribe: Tal Mizrahi Jabber Room: 6man@jabber.ietf.org Meetecho: https://www.meetecho.com/ietf102/6man ------------------------------------------------------------------ ------------------------------------------------------------------ Agenda Introduction, Agenda Bashing, Document Status, Chairs, 10 min. Working Group Drafts IPv6 Segment Routing Header (SRH), draft-ietf-6man-segment-routing-header, Darren Dukes, 40 min. IPv6 Router Advertisement IPv6-Only Flag, draft-ietf-6man-ipv6only-flag, Brian Carpenter, 15 min. Privacy Extensions for Stateless Address Autoconfiguration in IPv6, draft-ietf-6man-rfc4941bis, Fernando Gont, 30 min. Active Individual Drafts none New Individual Drafts The IPv6 Virtual Private Network (VPN) Context Information Option, draft-bonica-6man-vpn-dest-opt, Ron Bonica, 9 min. Destination Originates Internet Control Message Protocol (ICMP) Packet Too Big (PTB) Messages, draft-leddy-6man-truncate, Ron Bonica, 9 min. The IPv6 Unrecognized Option, draft-bonica-6man-unrecognized-opt, Ron Bonica, 9 min. Zero valid lifetimes on point-to-point links, draft-zerorafolks-6man-ra-zero-lifetime, Lorenzo Colitti, 9 min. IPv6 Neighbor Discovery Extensions for Prefix Delegation, draft-templin-6man-dhcpv6-ndopt, Fred Templin, 9 min. OAM in Segment Routing Networks with IPv6 Data plane, draft-ali-spring-srv6-oam, Zafar Ali, 9 min. Router Advertisement Extensions for On-Demand Mobility, draft-feng-dmm-ra-prefixtype, Wu-chi Feng, 1 min. ------------------------------------------------------------------ ------------------------------------------------------------------ Introduction, Agenda Bashing, Document Status, Chairs, 10 min ------------------------------------------------------------------ slides: "Introduction and Document Status" (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-introduction-and-document-status-01) Bob Hinden: Went over first few slides. This meeting will focus time on WG drafts. Ole Trĝan: Went over the Document Status slides. Tim Winters: Mentioned last remaining issue for rfc6434-bis. No-one feels strongly about the issue other than Transport people. So requirement will remain as SHOULD. No objections from the w.g. Tim published new draft after the session reflecting this and resolution to other IESG issues. IPv6 Segment Routing Header (SRH), draft-ietf-6man-segment-routing-header, Darren Dukes, 40 min ------------------------------------------------------------------ slides: "IPv6 Segment Routing Header (SRH)" (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-ipv6-segment-routing-header-srh-03) Darren Dukes stepped through the slides Slide 28 Open issues Bob: We should discuss each issue as you present it rather than waiting till the end. Darren: Edge filtering issues Ron Bonica: We need to understand what HMAC does and doesn't cover and properly describe the issue Darren: Agreed. Will do; and I think discussion on list says how Darren: Tag issues Mohamed Boucadair: Expressed opinion on way forward. Darren: Need to define to an acceptable degree what the tag is Zhenbin Li: Talked about interoperability testing. Darren: People interested in interoperability testing need to be identified and brought together. Darren: TLV issues Ron: Discussion on why TLVs are not implemented. We should document that. Zafar Ali: There are many TLVs that still need to be defined. Use cases need to define them. Darren: As other work progresses there needs to be discussion. Darren: Next steps slide. Joel Halpern: There are a number of issues on the list that don't seem to have been captured. One example is when we're required to encapsulate, etc. It may be in there, but as reader, I can't find them. Darren: OK. I'll look into that. Zhenbin Li: Darren: We need to be sure to follow up on those. Zafar: Darren: We need full definition of how and when to create TLVs. Ron: Question for Bob and Ole: When other WG defines new bit they have to come here for approval? Darren: Yes. Bob: Yes. How to coordinate needs to be clear. When updates on this doc are done, we will undergo WG last call again. There have been many changes over a long period of time. IPv6 Router Advertisement IPv6-Only Flag, draft-ietf-6man-ipv6only-flag, Brian Carpenter, 15 min ------------------------------------------------------------------ slides: "IPv6 Router Advertisement IPv6-Only Flag" (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-ipv6-router-advertisement-ipv6-only-flag-00) Brian Carpenter stepped through the slides. George Michaelson: There are many attack vectors. Why do we need this bit? I don't get it. But I don't want to say don't do this. I'm trying to think of the model. Brian: We aren't talking about any specific attacks. It's just a reduction of the attack surface. Lorenzo Colitti: I think you should clarify what it means. Brian: Please send details of what isn't clear. Lee Howard: Trying to get drivers installed for protocols was challenging. This is changing default behaviors. Jen Linkova: I think it could prevent some attack vectors. Brian: We agree. Lorenzo: There is no way to make this secure. We can never turn off DHCPv4 to the end of time. Brian: Ask other chair what he thinks. Ole: I don't mind having this discussion as part of WG LC. Brian: The authors will collect comments for another week or two and put up another draft. Ole will start w.g. last call when new draft is published. Privacy Extensions for Stateless Address Autoconfiguration in IPv6, draft-ietf-6man-rfc4941bis, Fernando Gont, 30 min ------------------------------------------------------------------ slides: "Privacy Extensions for Stateless Address Autoconfiguration in IPv6 BIS" (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-privacy-extensions-for-stateless-address-autoconfiguration-in-ipv6-bis-00) Fernando Gont presented slides remotely. Bob: We will take questions now on this slide (labeled slide 5, but really slide 4 "Q: Algorithms") Lorenzo: We should remove 7217 algorithm. It can leak. That seems like an anti-goal. Fernando: I disagree Lorenzo: (on slide 'Q: "On by default"') RFC7528 seems unrelated. Fernando: It is RFC 7258. Sorry. Lorenzo: It's worth noting that 4941 provides no way to turn those off. Ole: Fernando: I agree with your concern. It should apply where it applies and not where it shouldn't. Brian: I think this is wrong. It makes assumption. on slide "Q: When to change IIDs" Fernando: Erik Nordmark: (on slide "Q: When to change IIDs"): Fernando: Bob: We will continue this on the list. The IPv6 Virtual Private Network (VPN) Context Information Option, draft-bonica-6man-vpn-dest-opt, Ron Bonica, 9 min ------------------------------------------------------------------ slides: "The IPv6 Virtual Private Network (VPN) Context Information Option" (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-the-ipv6-virtual-private-network-vpn-context-information-option-00) Ron Bonica presented slides. Darren: How would your data plane find it? Ron: It could be anywhere in the destination option. I think it's a requirement to be able to walk the packet. Barak Gafni: Ron: You would use this to replace MPLS. Zafar: Why not use SRv6? Ron: SRv6 is still work in progress. And you might need to solve the problem in a network where you aren't running SRv6. Mark Townsley: Always is wrong Ron: For these VPNs it's always but I need to clarify. Mark: This is becoming yet another way of doing the same thing. Ron: Good question of whether this should be tied to SRv6. Satrou Matsushima: Why do we need to keep this info in the IPv6 header? Ron: Instead of in a shim header? OK. Bob: There needs to be more justification and motivation before adoption can be considered. Destination Originates Internet Control Message Protocol (ICMP) Packet Too Big (PTB) Messages, draft-leddy-6man-truncate, Ron Bonica, 9 min ------------------------------------------------------------------ slides: "Destination Originates Internet Control Message Protocol (ICMP) Packet Too Big (PTB) Messages" (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-destination-originates-internet-control-message-protocol-icmp-packet-too-big-ptb-messages-00) Ron Bonica presented slides. Slide 14 Joel Jaeggli: The packet you truncated will no longer have a valid header? Ron: There is a rule that if truncation would cause invalid header you cannot truncate. Joel J: Requires stack change Richard Patterson: Requires on ICMP getting back to original source? Ron: But odds are better of getting back to source. Jen: I think you need to mention reason. Lee: It seems unlikely it would have all the needed info. This also seems like an opportunity to send misinformed messages. Fernando: This works because you don't need to get ICMP message? Ron: Yes Fernando: Destination options don't get through. Ron: Needs to be fixed in next draft. Lorenzo: Is there benefit to the source code to be able to use this? If not then this isn't needed. Also, if this doesn't work close to 100% of time then it isn't needed. Bob: Take this to the list. The IPv6 Unrecognized Option, draft-bonica-6man-unrecognized-opt, Ron Bonica, 9 min ------------------------------------------------------------------ slides: "The IPv6 Unrecognized Option" (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-the-ipv6-unrecognized-option-00) Ron Bonica presented slides. Joel Jaeggli: If you need to send flow label, then there is a hash issue Jen: Are you suggesting to keep this somewhere in destination option? Bob: Out of time. Zero valid lifetimes on point-to-point links, draft-zerorafolks-6man-ra-zero-lifetime, Lorenzo Colitti, 9 min ------------------------------------------------------------------ slides: "Zero valid lifetimes on point-to-point links" (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-zero-valid-lifetimes-on-point-to-point-links-placeholder-01) Lorenzo Colitti presented slides. Danny Moses: This is too strict for 5G because 5G needs to support multihoming. Lorenzo: Is it actually an interface with 2 links or with 2 routers? Danny: Both cases exist. Lorenzo: Let's take this off-line. Richard Patterson: Would this work if you deleted the security text? Lorenzo: In a broadcast link it doesn't prevent from sending packets. If you delete all addresses then you have no addresses left. Jen: I think... Lorenzo: Bob: There are still issues to work out before w.g. adoption can be considered. IPv6 Neighbor Discovery Extensions for Prefix Delegation, draft-templin-6man-dhcpv6-ndopt, Fred Templin, 9 min ------------------------------------------------------------------ slides: "IPv6 Neighbor Discovery Extensions for Prefix Delegation" (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-ipv6-neighbor-discovery-extensions-for-prefix-delegation-00) Fred Templin presented slides. Erik Kline: Lorenzo: I think this is very useful. But have comments. You don't save power after initial exchange. Fred: You don't necessarily have to continue receiving multicast RAs. Lorenzo: How do I get initial router? Fred: You send RS and get RA. Lorenzo: We need to be clear that we're turning RS/RA into a pull protocol. Bob: I'm not comfortable with adopting yet. I think it needs more work and use case needs to be clearer. OAM in Segment Routing Networks with IPv6 Data plane, draft-ali-spring-srv6-oam, Zafar Ali, 9 min ------------------------------------------------------------------ slides: "OAM in Segment Routing Networks with IPv6 Data plane" (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-oam-in-segment-routing-networks-with-ipv6-data-plane-placeholder-01) Zafar Ali presented slides. Bob: We need to see more discussion of this on the list. Router Advertisement Extensions for On-Demand Mobility, draft-feng-dmm-ra-prefixtype, Wu-chi Feng, 1 min ------------------------------------------------------------------ slides: "Router Advertisement Extensions for On-Demand Mobility" (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-router-advertisement-extensions-for-on-demand-mobility-00) Wu-chi Feng presented slides. Eric Vyncke: Are you aware of the other option? Wu-chi: Our understanding of it was Eric: So the big difference ere is that it is in the RA? Lorenzo: The prefixes are in the same PVD. They simply have different properties. Mark Townsley: Did you review the whole history of MIF (multi interface WG)? Wu-chi: No Mark: Please look at history so as not to repeat it. Danny Moses: 3GPP has required this for 5G. This was started about a year ago. We think this is the most optimized way of doing this. In the past 3GPP tried to use IETF technology for various things; but when IETF doesn't, 3GPP must create its own solution. Lorenzo: I think I might have a better explanation for why these are in the same PVD. Pierre Pfister: I think they may be different PVDs. Lorenzo: If they are different PVDs it means they are not on the same network. Eric V: you can use any address from the PVD. If it gets different results then it needs to be different PVD. I need to read the draft. Bob: Draft needs work. I encourage people to talk to people here at IETF. It's only Monday. Applies to all documents discussed here. ----------------------------------------------------------------------------------- Meeting Adjourned -----------------------------------------------------------------------------------