6MAN Working Group - Prague IETF Meeting Monday, 25 March 2019, 09:00-11:00, Congress Hall 2 Friday, 29 March 2019, 09:00-10:30, Congress Hall 1 Note takers: Barbara Stark, Massimiliano Stucchi Jabber: Éric Vyncke Jabber Room: 6man@jabber.ietf.org Meetecho: https://www.meetecho.com/ietf104/6man ------------------------------------------------------------------ ------------------------------------------------------------------ Agenda - 25 March 2019 Introduction, Agenda Bashing, Document Status, Chairs, 5 min. 6MAN use of Github Discussion, Chairs, 5 min. Working Group Drafts IPv6 Router Advertisement IPv6-Only Flag, draft-ietf-6man-ipv6only-flag , Bob Hinden, 15 min. Privacy Extensions for Stateless Address Autoconfiguration in IPv6, draft-ietf-6man-rfc4941bis , Fernando Gont, 30 min. Discovering PREF64 in Router Advertisements, draft-pref64folks-6man-ra-pref64 , Jen Linkova, 15 min. IPv6 Segment Routing Header (SRH), draft-ietf-6man-segment-routing-header , Darren Dukes, 30 min. Active Individual Drafts Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events, draft-gont-6man-slaac-renum , Fernando Gont, 20 min. Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6), draft-ali-spring-srv6-oam , Zafar Ali, 5 min. Agenda - 29 March 2019 Introduction, Agenda Bashing, Chairs, 5 min. Working Group Drafts IPv6 Segment Routing Header (SRH), draft-ietf-6man-segment-routing-header , Darren Dukes, 10 min. Active Individual Drafts The Universal IPv6 Router Advertisement Option (experiment), draft-troan-6man-universal-ra-option , Ole Trøan, 15 min. Path MTU Hop-by-Hop Option, draft-hinden-6man-mtu-option , Gorry Fairhurst / Bob Hinden, 15 min. New Individual Drafts The IPv6 Compressed Routing Header (CRH), draft-bonica-6man-comp-rtg-hdr , Ron Bonica, 5 min. The IPv6 Virtual Private Network (VPN) Context Information Option, draft-bonica-6man-vpn-dest-opt , Ron Bonica, 5min. OAM Capabilities for IPv6, draft-bonica-6man-oam , Ron Bonica, 5min. The IPv6 Segment Endpoint Option, draft-bonica-6man-seg-end-opt , Ron Bonica, 5min. In-situ OAM IPv6 Options, draft-ioametal-ippm-6man-ioam-ipv6-options , Frank Brockners, 5 min. Deployment Considerations for In-situ OAM with IPv6 Options, draft-ioametal-ippm-6man-ioam-ipv6-deployment , Frank Brockners, 5 min. -------------------------------------------------------------- Introduction, Agenda Bashing, Document Status, Chairs, 5 min. -------------------------------------------------------------- Chairs: Bob Hinden, Ole Trøan Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessa-introduction-agenda-bashing-00 No questions were asked. -------------------------------------------------------------- 6MAN use of Github Discussion, Chairs, 5 min. -------------------------------------------------------------- Eric Vyncke: Suresh is supportive of the approach, as long as participants are not blocked by not using github. Alissa Cooper: The tutorial materials are all available, and such is the recording. If people are interested, they can look at it. Ole: People should try it out. There were no more questions or comments. -------------------------------------------------------------- Working Group Drafts -------------------------------------------------------------- -------------------------------------------------------------- IPv6 Router Advertisement IPv6-Only Flag, draft-ietf-6man-ipv6only-flag, Bob Hinden, 15 min. -------------------------------------------------------------- Bob Hinden presents: https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessa-ipv6-ra-ipv6-only-flag-01 Jen Linkova: The document is nice and ready. Just one comment. I had the strange idea of using it in a dual-stacked network. There is a use case for this, moving IPv6-capable devices to use IPv6 only. Can we relax section 3 to a SHOULD ? Bob: I'm not sure. We tried to make it support different environments but need to see. Tim Chown: I would assume legacy devices wouldn't understand the flag anyway, so it should work. Bob: That's a good point. Jen Linkova: That's the whole idea. New devices will be moved to IPv6 only and old devices will keep IPv4. This is a suggestion so that they move to IPv6, and move to IPV6 as much as possible. Bob: That's not the way we were thinking about it, but I think it could be used for that. We could add some text. But it is an IPv6-only link and we want to turn off background chatter. There were no more questions nor comments. Ole: Thinking loudly. Do we want to do a further call for this to get it advanced ? Let's do a call on that. Hum: There were many hums in favor of advancing this document to the IESG. No humming was audible in opposition. Ole will confirm on the mailing list. -------------------------------------------------------------- Privacy Extensions for Stateless Address Autoconfiguration in IPv6, draft-ietf-6man-rfc4941bis, Fernando Gont, 30 min. -------------------------------------------------------------- Fernando Gont presents: https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessa-privacy-extensions-for-stateless-address-autoconfiguration-in-ipv6-bis-00 Christian Huitema: There is a problem in using time for randomisation because in practise you want your address to remain stable for some duration. This is something we saw in mac address randomisation where it's nice to go back to a network and keep the same address. What is the "stable time" you want ? It has to be part of what you're trying to do there. Fernando: We have that question, too. Let's say your just using a simple random number generator with no time parameters. What happens if you disconnect and then reconnect again? I think it's a broader issue than just the timer. Christian Huitema: I'm not advocating timer. The discussion of this issue and balancing the solution. WE could not use time at all ans we can assume the randomisation comes from timing. Fernando: I think that even if we use this time parameter from RFC7217 -- do we want more than one and recommend one? Or do we remove the rest? What does WG want to do? Ole: Do any implementers of RFC4941 care either way? Erik Kline: I think I have a preference for keeping a reference to pure randomness as a possible option. Let's leave it up to the Operating system to understand if they are connecting to the same network and want to keep a previous address. Fernando: So you think it should be up to the implementation as to what to do? Erik Kline: It's up to the host, if it's decides to do DNA. Management is separate from address generation. Fernando: Agreed. Erik: You can have as many algorithms as you want. Keep one as pure randomness. Fernando: So we keep the whole set and don't recommend any one. Erik: Fine for me. Dave Plonka: I am also in favor the simpler option of randomisation. I want to mention in maprg we have figured you can use privacy addresses to estimate the number of hosts in a network. You want to guarantee anonymity. If you use straight up randomisation you can reduce the chances of figuring out the number of hosts, so it has advantages. Fernando: You also want to keep the 2 algorithms? Dave: I like the first. Fernando: There are 2 separate questions. Do we want to remove the description of one of the operations? Do we want to recommend one? Eric suggested keeping both. Dave: I'm in favor of recommending the former for anonymisation counting feature. I think it's a nice feature. Ole: We could do a hum for each. We should ask people if ready to make choice or take to mailing list. How many have read this document recently? OK, we will take to mailing list. Fernando: Okay. Ole: We would like to have reviewers. Asking for volunteers. Christian and another volunteered. Ron ? Fernando: Another question I'd like to get input on is whether we should keep algorithm requirements in body or in an appendix? Ole: Anyone? Take to the list. Fernando [slide 5]: Thoughts? Erik Kline: I vote in favor for "on by default" Fernando: This could go as question to the list as well. Tim Chown: When you say requirements, are you meaning the requirements from the host point of view or from the management point of view ? Fernando: One of the issues with 4941 was when they switch to another link but keep same ID. So we recommend you should switch to new ID when certain things happen. Tim: Part of that is doing it predictably. Fernando: In a sense this is left to the implementation, I guess. There are a number of things changing from one implementation to another. Some OSes might want to generate a new temporary address for a specific application Tim: I want to maximise the privacy of the user, considering how much that would impact the management of the network. Fernando: I think it should be mostly up to the host implementation. But there is a trade-off. We have BCP about availability of addresses and that might include a recommendation. Tim: If the outcome is that the host can generate as many addresses as it wants, maybe we should have some paragraphs about it. It's an opportunity to move the tradeoffs one way or another. Fernando: Probably if we try to impose constraints it might benefit an endpoint, but we already have a BCP for that. Tim: Okay, thanks. Ole: Would you mind moving this doc to github? Fernando: Yes! Ole: Thanks! -------------------------------------------------------------- Discovering PREF64 in Router Advertisements, draft-pref64folks-6man-ra-pref64, Jen Linkova, 15 min. -------------------------------------------------------------- Jen Linkova presented: https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessa-discovering-pref64-in-router-advertisements-00 Mohamed Boucadair: I assume the info in slide 3. I don't think this is a good idea to justify having a new option in RA. Jen: SLAAC is designed to provide information to hosts for basic connectivity. I don't think a SIP Proxy (the example carried by Mohamed) is required for a host to have connectivity. In the future we see other use cases, we might consider other RA Options. Mohamed: That's OK. But other operators can decide, for example that you want to do it a different way. Maybe we don't worry about it because it's too esoteric. We have all of these options, and I wasn't against it at the time. But RFCs need to be updated to recommend all as a whole. There are some networks where you don't need to discover the NAT64 support. It's not needed for an IPv6 only network. Jen: May I ask you two questions ? Are you suggesting we should update other RFCs ? And second, we have other RA options. Should we stop using them because we have other ways to provide this information to the host ? Mohamed: We decided previously as a WG not to provide a way to configure NAT64 option. But at this point we need to decide to do things the right way. Suresh: there are options that should be there such as the nat64 prefix and route options. Others are not needed. Éric reading from jabber on behalf of Suresh: My view is that if the config information is fate sharing with the router it needs to be in the RA. If not it needs to be in DHCPv6. The DNS and NAT64 are border cases that could be argued that they are basic connectivity primitives. I don't think that will extend to SIP servers. Dave Thaler: On the topic of 7050, I don't think it should be absolute. They are different use cases. I don't know how many people have secure RAs deployed, but that RFC is for people who have a specific use case where they configure RAs in a network with a different management. My point is that it does not make sense to make it obsolete. Jen: I can guarantee that my host gets RAs only from my router with SeND. Dave T: IF you don't have SeND, how is it more secure than 7050 ? Jen: I cannot guarantee when DNS comes from outside. But I can guarantee RA security. Dave T: If you can prevent host-to-host, then you can prevent this use case from happening. Erik Kline: The RA option allows you to not have DNS64 at all. You can do it on the device and not have to talk to a DNS64 server. Jen: It is important not to deal with the primitives themselves. Erik: In fact that is part of service discovery does with DNS Jen: This should be configured on the router which is hard. We can allow all that information to share fate with routers. Mark Andrews: If we go down the variable RA I think we could do the same exact thing we do with length. You don't have to include the exclusion in the option itself. Jen: Yes, that does make sense. If we use approach number two and we expand it to have additional information. Martin Hunek: Is the option able to transfer to the CPE ? I have a similar draft, and I was wondering if it's possible to transfer through a router. Jen: I guess your suggestion is to include the option in RAs sent downstream. That's a good idea. There were no more questions nor comments. -------------------------------------------------------------- IPv6 Segment Routing Header (SRH), draft-ietf-6man-segment-routing-header, Darren Dukes, 30 min. -------------------------------------------------------------- Darren presented: https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessa-segment-routing-header-00 Erik Nordmark : do you know which subset of these does encapsulation compared to the previous ones ? Darren: All of these implementations are encapsulated. Tom Herbert: Why are TLVs required in the SR header as opposed to using . If you do have TLVs in the SR header, why are they different from hop-by-hop options and routing options ? I think the idea was that SR headers could be added and removed. Is this still the intention ? and in case, why would they be different from hop by hop and routing ? Darren: First question answer: As we add more TLVs, those nodes have to look further into header and have to do additional work to process header. With TLV in segment header, that's not a requirement. Second question: When you're defining the list, keeping the options in a single segment header combined with additional processing overhead is reason to keep them where they are. Joel Halpern: I don't see where the current docu draws distinction on kinds of segments. You might have non interoperable implementations.p Darren: This draft is designing the base for other parts to be built upon. Joel: This thing about processing or not TLVs seems to be strange. Darren: The current text says that it's left to local policy, which is open to clarification. Joel: It doesn't reach the optimization you're citing. Darren: I think I described the technical reasons. Saturo Matsushima: ? Eric Vyncke from Jabber (Mikael Abrahamsson): Please elaborate on the MTU handling/discovery you mentioned, and what to look for in the drafts to find this? Darren: I don't think I mentioned it. Chang Li: I think if we put TLVs inside the SRH, how are we handling processing ? Actually we have several implementations ready (Huawei) and we hope to address all the issues as soon as possible. Darren: Zafar Ali: Coming back to TLVs, I have a draft that ... You only need to look for the TLV in the header if you need to modify it in some cases. ? Tom Herbert: It's up to local policy to process TLVs. An implementation could decide to handle them whenever and wherever they want, and this seems to be too open. I would like to implement this without having to make assumptions about local policies. The definition of TLVs themselves is too open-ended and people could come up with their own implementations and claim they're still conformant. Zhenbin Li: Depends on the SRS. My suggestion is ... Darren: OK Ron Bonica: This discussion has been going on for a long time. Maybe a good thing to do would be to leave the door open to do it later when we better understand TLVs and requirements. Darren: OK. I would think defining it now and defining the base now but allowing for those options to be brought out would be valuable. Ron: We have an interest in getting this doc published quickly. The best we can do is to leave the controversial parts out and publish it. Zafar Ali: I don't understand this. I wish it would be spelled out in this draft. There is a point where we need to separate the political from the reality of the work. We seem to be stuck with this TLV. Ron: How many TLVs are defined today ? Zafar: Darren: If we were to use the same logic, destination options would not have been published. WE define things so we can build on them and build products on them. Definitions are buing built. Ron: You're asking to do the design part backwards. Darren: You do the best you can with the information you have now. You get closer to the right solution as you go. Zhenbin Li: I think the design of this is proper for the service. There is already an initiative to support. I think it is proper for SRS to behave as described in draft. Zafar Ali: Not all the cases could be defined. Ole: I'm not sure how to proceed. It seems TLVs are the biggest discussion topic, and it has been for quite some time. If I recall correctly, the groups did ask you to add HMAC. If you have ideas, please propose text and clarifications. We can't specify TLVs that don't exist, though. I don't think we have any way to close this now, so let's let the discussion continue during the week. We will have a friday session to summarise. Darren: Those people with open issues, please get back to me and get to work. -------------------------------------------------------------- Active Individual Drafts Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events, draft-gont-6man-slaac-renum, Fernando Gont, 20 min. -------------------------------------------------------------- Fernando presented: https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessa-slaacs-reaction-to-renumbering-events-00 Timothy Winters: It is allowed to invalidate lifetime under 2 hours. Some people from flash renumbering invalidate lifetime under 2 hours. This is to prevent dos attacks. Fernando: You say they don't allow? Timothy: If you set it to a day and then you reduce it 5 seconds, it will be adjusted to 2 hours. Fernando: That is a question for CE Router if what you say is so. Timothy: That's what you would have to put in there. Distinguish cases above and below 2 hours. Richard Patterson: Preferred lifetime can be reduced to less than two hours, and this solves the problem. The suggestion only solves the problem of having too many addresses in deprecated state bound to one interface. Fernando: There are 2 things. If you cannot keep the addresses, and ... Richard: Is that such a big problem ? Fernando: Not a big problem Andrew McGregor: On the reduced PIO lifetimes. I don't remember if there's anything in any RFC that says that you should set the lifetime on a router to half of the lifetime of the lease it got from its router, but I think it should. Fernando: I think only requirement that is out there is lifetime of PIO should never be undefined. Andrew: I think it should be done. Tim Chown: I want to echo what Richard said. I remember many years ago we had the issues of hosts forming 6to4 addresses. We had daemons send out RAs with 0 lifetime deprecating the addresses. The problem here is there are lots of things you could do that would be "hacky", but some of them are going to cause more harm than what they're trying to fix. Fernando: In the situation where CE Routers don't do that... it's unclear that this is the case. If we get a new PIO, first we change the preference of the other. But maybe first check whether prefix is still valid by sending packet to yourself. So if you want a more conservative reaction, that's fine. Tim: I think it would be good to document these heuristics. Fernando: What we have in the ID is we only unprefer or remove the address if it has been advertised by that same router. In this case we disassociate the prefix with the specific router. Jen: I also am concerned with the hacky workarounds for broken routers. IT's a solution that's too heavy. I think changing the default of preferred and valid lifetimes makes sense. We should have done it a long time ago. This would solve most of the problems. We definitely need to change defaults, it would help. Regarding the problem of not being able to talk to on-link prefixes, I don't think we need to tweak it. Shall we think about something like happy eyeballs for source addresses ? Erik Nordmark: Which devices do we think it makes sense tweaking ? Shall we write down a set of rules ? It's not clear about how much energy to put into this stuff and how much people should look at this implementation. We should look at the best approaches to look forward. Jinmei Takuya: In this particular model the router would just copy what it gets from prefix delegation. If we have to apply something, that would be the prefix delegation lifetime. Tim Chown: Maybe we could define 3 categories of things that need to be done. Implementations, things that can be done, and ? -------------------------------------------------------------- Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6), draft-ali-spring-srv6-oam, Zafar Ali, 5 min. -------------------------------------------------------------- Zafar presented: (no slides uploaded yet) Ole: We have discussed it, and we will hold off, then we'll make an adoption call on the list. Blue sheets did not make it to everyone. -------------------------------------------------------------- END of the first session -------------------------------------------------------------- -------------------------------------------------------------- BEGINNING of the second session -------------------------------------------------------------- -------------------------------------------------------------- Introduction, Agenda Bashing, Chairs, 5 min. -------------------------------------------------------------- Bob Hinden presented: https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-introduction-agenda-bashing-00 There were no questions nor comments -------------------------------------------------------------- IPv6 Segment Routing Header (SRH), draft-ietf-6man-segment-routing-header, Darren Dukes, 10 min. -------------------------------------------------------------- Darren Dukes presented: https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-segment-routing-followup-00 Ole: We'll consider this iteration of WGLC done and issue a new WGLC just to be sure there are no new comments, after you publish the new draft. Darren: We will have version -18 out very soon. Early next week. Ole: If there's anyone with an issue on this draft, please let us know now. Ole: OK I think we're done now. Darren: Thank you everyone. The chairs plan to start a new working group last call once a new draft is out that closes the open issues. -------------------------------------------------------------- The Universal IPv6 Router Advertisement Option (experiment), draft-troan-6man-universal-ra-option, Ole Trøan, 15 min. -------------------------------------------------------------- Ole Troan presented: https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-universal-ra-00 Jen Linkova: I like the idea because I can get support much faster on the router side. This would simplify specifying the option. But how do we define what the host is supposed todo? Ole: There's nothing here that prevents you from adding other information. Jen: What the host does with the option is not really open for discussion. Erik Kline: Text in this document says if you don't understand an option, ignore it. But yes, specifying host behavior is an issue. Ole: For that particular one I don't think the document helps either. It's down to the implementations. I would be happy with a single line of text. Jen: I'm talking about host doing unpredictable stuff when it does receive an option. Tommy Pauly: I'm one of the PVD authors. In general I think it's a good mechanism. I would love to see it used, especially if all you really need on the host is simple. In case of PVD specifically, it's a bit more complex, and it has an impact on host behaviour. I think one of the things you want to do with PVD is to have more options to extend behaviour there. I don't think switching PVD to one of these is something you want to do. Ole: I wouldn't expect PVDs not to have a stable reference. Mikael: One of the use cases for PVDs is for when you don't understand something. We would need to cover all of the cases. If I want to send a PIO, I would need to define a PIO here. Ole: That's already here. This is an experiment. You do whatever you like. Erik: I realize now we need an R flag. I support the extensibility of this. I do think if this is popular and successful. We need to fix some things, such as the data types. Ole: Yes. The reason is we decide where to put things. Erik:You already have something that could take from reading a server and turn it into a DHCP option. Ole: You need a little more parsing but it would be nice not to require implementation changes. It would be a little more than 50 lines of code. David Lamparter: We should consider that having something in here does not mean it's not adopted. We have to decide from here if we want to create a specific option and then go ahead with it. Ole: Éric Vyncke: I like the idea. Your option is interesting. You are really looking for something that will stand forever or you will get no implementation. Jen: Two comments: I'm trying to think about deployment scenarios. This means I have to duplicate everything between standard parts and this. Ole: I would expect it to be in a new option in a universal RA. Jen: I'm in favor of experiments. This looks a bit short. Getting something supported on router platform might take longer than what you are thinking. Ole: We have 2 implementations already. There was one done at the hackathon and another. Erik: I forgot to say that there are some conflicts between what is in RAs and somewhere. I will send a pull request with text. My perspective is that the things that need to use the network belong in RAs. An example from earlier this week is the SIP Proxy. Ole: We have an infinite namespace. The network operator should only do options that make sense for the network. Alex: I generally support the way it is presented. The way to address it seems appropriate. Is it intended to be router to host or could it be router to router ? Ole: The RA mechanism is by definition routed to the host. There is a question of whether we want to have some means for the host to send something back. It depends on what you mean by a router is a router. Alex: I will take this question to the list to explain router-to-router. With respect to judging success. Sometimes it comes from availability of platforms. We see JSON, we see CDDL, I think I saw ASN.1. IS the discussion on the format still open, or is it closed. Bob: I'd like to have us not discussing the format. If we decide to do this we can discuss the format. Tim Chown: I support this. My concern is that you might generate or need extra RAs, with the obvious consequences. There's a cliff in the document that you have left open. Ole: The second page of the slides shows the github URL. Tim: It would be nice to have an appendix with the list of RA options that did not make it. Ole: These are the ones that are on our schedule now. Tim: I think the point is that this is something that removes barriers. Ole: I don't know what else is out there. We have what is currently known. David Lamparter: I would be happy to implement this on FRR if I could find the libraries. Mikael: I'd like us to look into the interfaces when we talk about the MTU. Some of this is about Wi-Fi and multicast. If we think we will send more unsolicited RAs, I'd like us to think about that. Ole: I think that's also one reason I proposed it as an experiment. We can learn a lot from this. Mikael: If we think this might turn into several kB of info, it might be good to keep it out of the RA. Like DNS-SD. We should decide what goes here and what goes there. Ole: I could have a picture of my family sent on the local link. Darren Dukes: This looks like fun. Suresh Krishnan : How do you handle conflicts ? Some information could come from DHCP. I would like to see more text about sending information through different means and handling issues. Ole: Yes. Pull request welcome. OK... I'll take that as an order. Bob : I think this is going to be popular. There will be lots of new things. We need to be careful about what we specify. There's a lot to learn here, but when we get it going, we won't be able to stop it. There were no more questions nor comments. -------------------------------------------------------------- Path MTU Hop-by-Hop Option, draft-hinden-6man-mtu-option, Gorry Fairhurst/Bob Hinden, 15 min. -------------------------------------------------------------- Bob Hinden and Gorry Fairhurst jointly presented: https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-path-mtu-hop-by-hop-option-01 Jen: To get feedback you can have destination unreachable. I think this is quite cool. Gorry: I'm not that ambitious. Erik: I'm going to suggest some text. Getting this bubbled up to the app is good. Mikael: Fred Templin: RFC 1053 tried to do exactly the same thing. I think they were on the right track and I think you are too. It's good to have that history lesson. Gorry David Lamparter: I did a check of the Linux code and it doesn't look at some items. This may be hard to change. Bob: You are correct. That's the status quo today. If we can show that this is compelling, than it would encourage people to use it. David: Right but let me also make the argument that we need to make it as easy as possible for routers to implement and I'm not sure this is the way to do that. There may be other ways. Ole: I wanted to do performance tests during the hackathon. I'll try to get that work done and publish that. Shwetha Bhandari: It would be important to know if option changed. Gorry: Yes. We want to do stuff in this space. However, I think this is only a hint. Igor Lubashev: You said transport needs to be reliable and mentioned QUIC. Another transport in use is TCP. Wat do you think about opening it up and offering choice after handshake? Gorry: So you want to renegotiate MSS when you find something bigger ? Igor: This thing would be for asymmetric path. Gorry: You tell it how much space you have. I understand what you're saying. We could do it. Let's talk later. Tom Jones: Question on implementation. Some work at hackathon. This will not be horrific -- we can do this. Mikael: In my 20 years I've seen ICMP expired packets go from being handle by the cpu to going down to specific silicon. Have you thought about where this is going to be handled ? Bob: Not yet. Good question. Mikael: They can look 128bytes into the packet. If you can do this at higher speed, there are going to be high pps with hop-by-hop options to be treated Bob: And then there's another question of whether you put them occasionally or in all packets. Mikael: We want to make this silicon friendly. Magnus: I like that you're doing this. I'm very worried about where you want to do the processing. Erik: It could be that some devices can easily handle this and other devices won't. Something else is you may send this in parallel with others to the host. Bob provided hackathon readout. Feedback welcome. Ole: This is good work. Please provide feedback and experiment with implementation. -------------------------------------------------------------- The IPv6 Compressed Routing Header (CRH), draft-bonica-6man-comp-rtg-hdr, Ron Bonica, 5 min. -------------------------------------------------------------- Ron Bonica presented: https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-the-ipv6-compressed-routing-header-crh-01 There was no time for discussion. -------------------------------------------------------------- The IPv6 Virtual Private Network (VPN) Context Information Option, draft-bonica-6man-vpn-dest-opt, Ron Bonica, 5min. -------------------------------------------------------------- Rob Bonica presented: https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-the-ipv6-virtual-private-network-vpn-context-information-option-00 There was no time for discussion. -------------------------------------------------------------- OAM Capabilities for IPv6, draft-bonica-6man-oam, Ron Bonica, 5min. -------------------------------------------------------------- Ron Bonica presented: https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-operations-administration-and-maintenance-oam-in-segment-routing-networks-with-ipv6-data-plane-srv6-00 There was no time for discussion. -------------------------------------------------------------- The IPv6 Segment Endpoint Option, draft-bonica-6man-seg-end-opt, Ron Bonica, 5min. -------------------------------------------------------------- Ron Bonica presented: https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-the-ipv6-segment-endpoint-option-00 There was no time for discussion. Ole: We think we should take questions at the end of all the lightning talks for people to ask questions on all of the presented topics. But you [Ron} still get beer for doing your talk quickly. -------------------------------------------------------------- In-situ OAM IPv6 Options, draft-ioametal-ippm-6man-ioam-ipv6-options, Frank Brockners, 5 min. -------------------------------------------------------------- Franck Brockners presented: https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-in-situ-oam-ioam-in-ipv6-and-deployment-considerations-for-in-situ-oam-with-ipv6-options-00 Tommy Pauly: Yes, I think the question and feedback we'd like to get is what is the most appropriate way to do this work. What do we do here in 6man or in our group. We're ok doing this work in IPPM. But if 6man thinks it should be done here, that's ok. Let us know where. Franck: Thank you. Shuping Peng: I think we all agree. We are proposing to put the OAM data in the hop-by-hop option. If we look at EH, that's before the RH. The data along the path is going to become very large. That will damage the performance in the data plane. We also have done the same talks on the same topic. We didn't get the slot, but we're going to present in the next session in RTT. We would like to contribute more on this topic. Ole: We have 10 minutes left in this session. You can ask questions for Franck or Ron. Mikael: Go back to considerations. When I read this, I thought that none of this is true with the proposed approach. It violates all these 6. I think I misunderstand something. Franck: We're trying to mitigate these concerns. If there are other options to consider, we'd like to know. We want to deal with changes in most modest and operationally friendly way. Mikael: Are you going to continue this in v6ops ? Franck: Right now the core of the work is in ippm. There are lots of documents. Suresh: I think this should go in IPPM and 6man gets final say on whether it works. Mikael: If you want operational feedback, v6ops would be a better place. Mirja Kühlewind: We want feedback. Please give it to us. So either you make a decision that this is important to you and you want to work it, or give it to ippm. Ole : I think we're happy to have this in ippm. Mirja: Can we maybe find someone to do an in-depth review ? Igor: This is a document for all the OAM drafts. Please don't include options to send packets elsewhere. This could be a vector for reflected amplification attacks. Franck: There are things that are mixed up right now. Take and record or take something from packet and send it somewhere. Igor: Local node is fine. Franck: We should find a way to consolidate these things, and put them in a dedicated draft to address them. Igor: Internet is a dangerous place. Gorry: Some of the basic questions are the same Bob and I had. I am not sure how we can get the clue for both issues at the same place. We should work together, and learn from the same experience. Franck: We should make sure ippm and 6man are not scheduled att the same time. Ole: We will put that on the conflict list. -------------------------------------------------------------------- Meeting Adjourned --------------------------------------------------------------------