# 6MAN Working Group - IETF 111 Tuesday, July 27, 2021 12:00-14:00 PDT (19:00-21:00 UTC) Chairs: Bob Hinden, Ole Trøan Minute taker: Barbara Stark, Peng Shuping Jabber Scribe: None Jabber Room: 6man@jabber.ietf.org ###Meetecho: Tuesday Session: [Meetecho Link](https://meetings.conf.meetecho.com/ietf111/?group=6man&short=&item=1) Tuesday, July 27, 2021 12:00-14:00 PDT (19:00-21:00 UTC) ## Agenda - Introduction and Document Status, Chairs, 10 min. - Working Group Drafts - IPv6 Minimum Path MTU Hop-by-Hop Option, draft-ietf-6man-mtu-option , Gorry Fairhurst, Bob Hinden, 15 min. - Active Individual Drafts - IPv6 Hop-by-Hop Options Processing Procedures, draft-hinden-6man-hbh-processing , Gorry Fairhurst, Bob Hinden, 25 min. - Limits on Sending and Processing IPv6 Extension Headers, draft-herbert-6man-eh-limits , Tom Herbert, 25 min. - Universal Configuration Information Option, draft-troan-6man-universal-ra-option , Tim Winters, Ole Trøan, 10 min. - Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers, draft-carpenter-6man-rfc6874bis , Brian Carpenter, 15 min. - New Internet Drafts and Drafts without Apparent W.G. Support - ND Prefix Robustness Improvements, draft-vv-6man-nd-prefix-robustness , Vasilenko Eduard, 10 min. - Carrying VTN Identifier in IPv6 Extension Header, draft-dong-6man-enhanced-vpn-vtn-id Jie Dong, 10 min. ## Minutes ### Introduction, Agenda Bashing [Slides](https://datatracker.ietf.org/meeting/111/materials/slides-111-6man-introduction-agenda-bashing-02) Ole and Bob presented. There was no bashing of the agenda. ### IPv6 Minimum Path MTU Hop-by-Hop Option * draft-ietf-6man-mtu-option * Gorry Fairhurst, Bob Hinden, 15 min. [Slides](https://datatracker.ietf.org/meeting/111/materials/slides-111-6man-ipv6-minimum-path-mtu-hop-by-hop-option-01) Toerless Eckert: Very nice. Any experience from ECN experimental? Gorry Fairhurst: ECN is standards. Second generation of ECN. Unable to help. Gorry Fairhurst: Original is currently proposed standards. Toerless Eckert: I think we could be consistent on that. You made it experimental because you don't want to explore some things? Gorry Fairhurst: Original ECN appears to be more unexperimental. We can do whatever 6man wants us to. Geoff Huston: Not everybody can do it overnight. It effects every router along the path. The real question is that how partial deployment will impact. Bob Hinden: Agreed, we expect there will be mixed implementations for a while. Gorry do you want to say more? Gorry Fairhurst: Not replace the PMTU discovery. If you have some routers that can discover, then this is a way to probe. Provides a first guess of what to probe for. This will be faster. Toerless Eckert: Routers even don't understand. The router will punt them to the slow path. Some thoughts are to test about the impact on the latency about the punting. Gorry Fairhurst: The draft suggests you probe the path occasionally. You would not add to every packet. You should add to sacrificial packets. Maybe a few to start the flow and a few now and then. Toerless: What percentage of the packets are punt? Ole Trøan: More presentations and drafts on that the routers should not punt. Jen Linkova: Why does draft say it is supposed to be used in data center and closed environment; and how does application know what environment it is in? How does the host know which connection to use? Maybe the draft could say more about how it should be used in various environments? Bob Hinden: Good comment for last call. The first version was the controlled environment. We can address. Ole Trøan: The next step would be to last call of this draft. It is probably the first HBH option to be tested in the wide Internet and we wait to see the test result. Any objections to do the last call after this meeting? Erik Kline: last call as experimental? Ole Trøan: Yes, or IESG can change it later? Erik Kline: Changing later would mean another IETF LC. Bob Hinden: It is not a problem to keep it as experimental. Someone once referred IPv6 as a "science experiment" intended as a criticism, I took it as a compliment. Ole Trøan: Excellent. Thanks. ### IPv6 Hop-by-Hop Options Processing Procedures * draft-hinden-6man-hbh-processing * Gorry Fairhurst, Bob Hinden, 25 min. [Slides](https://datatracker.ietf.org/meeting/111/materials/slides-111-6man-ipv6-hop-by-hop-options-processing-procedures-01) Tom Herbert: Some discussions on the list, a lot of questions on the second point, that is, the HBH option MUST be processed (slide 7) whether it is practical because a lot of deployed routers may just ignore the HBH options. Bob: Let's wait to answer this when we get to the slides on issues. Bob continues with slides Dave Thaler: Slide 8, the first HBH option is special. What happens if everyone wants to put this one has to be the first in two specs. Gorry: One of the approaches might be that you send separate packets. It depends on what you're going to use the option for. Sending two packets may be the right way. Dave Thaler: Is it written in the document? Bob: It will be in the issue slide. If the HBH options don't need per packet it works well. If it has to be in every packet, we are there is an issue. Dave: I think as long as you do that in the draft it may not be a showstopper. Expect it would be an issue. But you need to include the discussion of that in the document. Need to provide guidance. It is what we need. Bob: Completely agree. Suresh: Will get back in line when audio is better. Toreless Eckert: The must-be processed HBH option, how about NEW HBH option? Changing the exiting behaviour would be difficult, but the new options would be easier. Bob: Yes, I agree. There is some discussions about criteria for new options in the document. This can go there. Warren Kumari: Reminder. Capacity and cost stopped people from doing so. You need to know how to handle the HBH option in the fast path. You will need to design the ASIC and hardware. Gorry: Maybe you could have a configuration that says which one you want to support. You can only deal with one of them. Match against a table. Bob: RFC8200 and this draft discuss per option configuration on whether they are supported and what to do if they are not. The options that are long and complicated are not going to be widely supported. HBH options that will be useful will need to have a a compelling use. Suresh: I like what Dave said about first option thing. And this isn't really a new issue. Not having it in every packet will be useful. Please refer to RFC7037. Bob: The important thing is that the current number is now effectively zero. We want to change it to one. Kireeti Kompella: Similar to MPLS work where we are thinking about where to put the labels after the stack before the payload. Need to take into account that we have more processing power today and it's very different on what we can do today. If multiple HBH or E2E things in the stack, how much of it should/must process or may be processed. If you could not process what you need to do. Ron and I have talked about HBH options in IPv6 and I see that is in parallel with this even the terminologies. We have a DT in MPLS WG. There are some information there that you could refer to. Bob: Thank you. Eduard Vasilenko: Clarification. An example say there are six options that one in slow path but 5 in fast path. If the vendor could not support one option processing as a MUST. Does it mean the vendor does not support IPv6 properly? What would be consequence if a vendor can only support a small number of HBH options on the slow path? Bob: We continue the notion that a router will have a config table for which options it does in fast path. Obviously you can set that to state you don't support any, which will be compliant. This does not change 8200. You can claim compliance to 8200 and not support any options. Eduard: Slide says must support. There is difference between must disclose support and must support. It should not be should or must. That is a requirement to disclose. Bob: The draft is clear on the configurations on each option. Please look at what the draft says and not just the slide. The presentation is a summary. Eduard: There is a difference between Must support and Must disclose support. Bob: What does the disclose support mean? Gorry: We do want the right terminology. It does change the IPv6 core spec in addition. We hope it will work. We love to get feedback on the wording. Adrian Farrel: RFC6398 recommends against the Router Alert especially in new protocols. Gorry: Yes, I can reiterate that one. It's for doing Router Alert (RA) different. Toerless: Also read it. Better to support Route Alert we should have a new HBH header code point for it. Don't touch the existing stuff. Ron Bonica: He said there are few protocols that use RA option. Actually there is exactly one. Since we have an RFC recommending against using, maybe we should deprecate it? Bob: makes sense to me. I don't think deprecating Router Alert is something we want to do it in this draft. Ron: Agreed not in this document. Probably a different one. Kireeti Kompella: Don't try to make RA work to ruin what you really want to do here. Fix the RA elsewhere and just focus on making the HBH work. Bob: OK. Toerless Eckert: In multi path we had 2 protocols we were using and we were able to make it work. In RSVP we had better hardware and were able to make it work. Maybe we are obsoleting all the old uses of RA and can obsolete it now. Bob continues with slides. Slide 11. Comments on Slide 12? Kireeti: Dealing with legacy routers. I like the second way of putting this "If a node is configured to process HBH options, Node MUST examine...". Slide 12. Bob: Yes, I think that is the common factor. Kireeti: Would keep slow path processing. Dont know what will come up in the future. It may be useful. Bob: OK. Toerless: Why not specify in this doc specifically whether an option is slow path or fast path? Tom Herbert: Clearly know which options are slow and which ones are fast. Bob: We agree with that. Ole: 8 minutes over time. Bob: Let's go through the rest of the slides. Ole: Next step will be to do call for adoption on the mailing list. ### Limits on Sending and Processing IPv6 Extension Headers * draft-herbert-6man-eh-limits * Tom Herbert, 25 min. [Slides](https://datatracker.ietf.org/meeting/111/materials/slides-111-6man-limits-on-sending-and-processing-ipv6-extensions-headers-00) Jen Linkova: The draft says that host must not send unless it got the knowledge of the limitation. In the future, with the probe mechanisms, the host might sense this information. Tom: Can we defer that? I do have some comments about that on another slide. Tom continues presenting. Toerless: I think it's 50/50. I think it's a great analogy for people trying to define extension headers. But putting analogies in MUST and SHOULD statements is dangerous. As Jen was saying -- if we do have a control thing that can figure out and orchestrate what a path is doing, why do we need some of this? Your control plane must be able to provide you with what you need. Tom Herbert: Agree with that. Careful on putting requirements. A node can ignore them based on RFC8200. It is not 100% for something to be supported in Internet. In public Internet, we need to get a baseline a minimal set. If you have knowledge on the path, so you can use the capabilities. Dave Thaler: 2 related questions: 1) You talked about how primary problem you wanted to solve was how to build a transport header. Do you consider IPsec a transport header? Are there problems with hosts have destination options encrypted inside E2E IPsec? Tom Herbert: interesting. Dave: Is the only problem you're trying to solve for routers or do you also care about end hosts? Tom: I dont know about the first question. A question to 6man. Dave: It would be easier to discuss if this said it was only for stuff that appears before the IPsec header. Tom: That would be fine. I don't think IPsec is that prevalent on the Internet. We do want to have some limits even in the host side. Dave: We should be judicious with anything that impacts node requirements. 2nd question: It's not encrypted but you can't trust packets are handled in the regular way. Tom: This is the discussion we had in v6ops. Not every packet has a tranport layer that is parsable. In a real world that is an issue. Dave: Yes, I'm just considering if there is a case where IPsec is working, you shouldn't break it. Tom: In this model, that could be an issue in the host. Haoyu Song: I agree that there should be some limit on header size. We cannot foresee what future hardware can actually support. I wonder if there will be some mechanism to advertise capability to routers so the host can decide how many headers to use? Tom：The host could send a packet with a large extension header to test. The potential trend is that the capability is getting stronger. Erik Kline: If we do decide to say something sensible about HBH processing should this also say something about limits? Does it make sense to have one doc without the other or do they need to go together? Tom: I think they are related. One is the subset of the other. Bob: We don't specify sizes in the HBH Processing draft. There are some relationship between this two drafts. Tom: I think primary difference is that at least one HBH must be processed. Toerless: I think if we can better provide guidance, it will be useful. Tom: That is the biggest thing that is missing for the hardware developper. Hard to make experiments without guidance. Ole: the next step will be to continue the discussions in the mailing list. ### Universal Configuration Information Option * draft-troan-6man-universal-ra-option * Tim Winters, Ole Trøan, 10 min. [Slides](https://datatracker.ietf.org/meeting/111/materials/slides-111-6man-universal-configuration-information-option-01) Jen Linkova: Not sure whether we have discussed before about the configuration error. Ole: This is a point Suresh also brought up last time we presented. We had added text to the draft for that. We didn't mind saying that's a config error. The same thing applies to DHCP. We left that up to the implementation to deal with. Fred Templin: Is the intention for having a universal option so all future protocols would use this or can other protocols use their own option? Ole: it is not meant to stop. My intention was not to do it. Dave Thaler: I agree that it would be a configuration error if you had a conflict. You should already have created conflict resolution to solve RDNSS and DNS from DHCP. I would support adoption of this one. To Fred, it will be useful for this draft to have some text. We need some guidance. I like the draft answer it. Ole: We will add it for sure. Erik Kline: There are some things I mentioned on the list. Maybe this cn be a way to head off redundancy. There is value in sometimes not having things standardized. This could force networks to support certain options. There might be a Pandora's Box aspect. Ole: Indeed this would let us out of the bag. Ted Lemon: It's probably not a good idea to abandon this. It's a bad idea to have 2 ways to do things. Please take doing RAs out of this, so there aren't 2 ways to do what's already there. If you open it wide up you will have a train wreck and not get interoperability. I would prefer to see this not happen. Ole: A very good point. Thinking about the same thing. It may be a argument on whether it should be experimental. Bob: over time. Erik Kline: Encoding in IETF is sort of problem. Ted Lemon: That would make me happier, but I'd still be a little concern. If open up the door and close it later wont help much. You could consider the experimental. The problem is the process not the spec. Toerless: There is no reason why we must have just one way to encode things. You already have that a lot. This is a perfect experiment. I'd encourage this as experimental. Bob: I think there is enough interest to do an adoption call on the mailing list. If you object to adoption, you can say it then. ### Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers * draft-carpenter-6man-rfc6874bis * Brian Carpenter, 15 min. [Slides](https://datatracker.ietf.org/meeting/111/materials/slides-111-6man-representing-ipv6-zone-identifiers-in-uniform-resource-identifiers-00) Stuart Cheshire: I wanted to reiterate what Brian is saying. I cannot find any browser that lets me connect to a device I have that puts a zone ID in with its IP address. Brian: Do you want to be a contributor to this project? Stuart: Yes. Brian continues with slides. Stuart: For everybody else, not to do any escaping. No need to escape it. One down side, you cannot copy and repaste to the web. It comes to a lot of pain. Interesting to see how many other people would like to use it. Brian: It has been pointed out that... Dave Thaler: A lot of URI in the world. Prevent cut and paste. I can Brian: Edge... Dave Thaler: Edge has switched to using Chromium as a base. Brian: We really want to get some feedback. Toerless: Any character. It is going to be long time. Brian: The problem is RFC was written a long time ago. Toerless: You dont have to always replace it. Brian: It is hard to get something changed in URI. Bob: Chair hat on. Out of time. There appears to be interest in doing this, it needs additional discussion and socializations in other groups. We should continue in the mailing list. ### ND Prefix Robustness Improvements * draft-vv-6man-nd-prefix-robustness * Paolo Volpato, Eduard Vasilenko, 10 min. [Slides](https://datatracker.ietf.org/meeting/111/materials/slides-111-6man-nd-prefix-robustness-improvements-00) Bob: Thank you, please bring this to the mailing list. ### Carrying VTN Identifier in IPv6 Extension Header * draft-dong-6man-enhanced-vpn-vtn-id * Jie Dong, 10 min. [Slides](https://datatracker.ietf.org/meeting/111/materials/slides-111-6man-carrying-vtn-id-in-ipv6-extension-header-00) Bob: Thank you, please discuss this to the mailing list. ### Meeting Adjourned Bob: Very constructive session. Thank you all!