6MAN Working Group - Bangkok IETF Meeting Tuesday, 6 November 2018, 13:50-15:50, Chitlada 3 Chairs: Bob Hinden, Ole Trøan Minute taker: Barbara Stark, Max Stucchi Jabber Scribe: Mikael Abrahamsson Jabber Room: 6man@jabber.ietf.org Meetecho: https://www.meetecho.com/ietf103/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, 15 min. IPv6 Router Advertisement IPv6-Only Flag, draft-ietf-6man-ipv6only-flag, Brian Carpenter, 15 min. Active Individual Drafts Discovering PREF64 in Router Advertisements, draft-pref64folks-6man-ra-pref64, Jen Linkova, 15 min. Making IPv6 options an option, draft-herbert-ipv6-update-opts, draft-herbert-6man-icmp-limits, Tom Herbert, 20 minutes. Path MTU Solution Space, draft-troan-6man-pmtu-solution-space, Ole Trøan, 10 min. Path MTU Hop-by-Hop Option, draft-hinden-6man-mtu-option, Bob Hinden / Gorry Fairhurst, 15 min. Destination Originates Internet Control Message Protocol (ICMP) Packet Too Big (PTB) Messages, draft-leddy-6man-truncate, Ron Bonica, 15 min. New Individual Drafts In-situ OAM IPv6 Options, draft-ioametal-ippm-6man-ioam-ipv6-options-01, Frank Brockners, 5 min. OAM in Segment Routing Networks with IPv6 Data plane, draft-ali-spring-srv6-oam, Zafar Ali, 5 min. ========================================== Introduction, Agenda Bashing, Document Status, Chairs, 10 min. ========================================== Bob and Ole went through Introduction and Document status slides https://datatracker.ietf.org/meeting/103/materials/slides-103-6man-introduction-and-document-status-01 Note well. No changes to the agenda. Suresh Krishnan: draft-ietf-ipwave-ipv6-over-80211ocb-30 will be sent back to 6man to look over once it has completed other reviews. Zafar Ali: Will discuss comments to draft-ali-spring-srv6-oam-01 on the mailing list. ========================================== IPv6 Segment Routing Header (SRH) draft-ietf-6man-segment-routing-header ========================================== Darren Dukes presented the slides https://datatracker.ietf.org/meeting/103/materials/slides-103-6man-ipv6-segment-routing-header-srh-00 Darren: Goal is to close all of the issues by the end of December. Joel Halpern: Thanks for work. We've agreed on need for using encapsulation mode and I agree on clarification. But why don't we use that mode all the time? It would make everything so much simpler. Darren: Joel: If it uses the encapsulation mode, it works fine. There are no special cases. Much cleaner. Darren: Maybe we need to continue as separate thread on the list. Joel: It seems the appropriate thing to do. Ron Bonica: Thank you. Many good changes over last 6 months. Ole: Thank you. Suresh: Will you do another WG last call? Ole: It will go into last call when all the issues are resolved. =========================================== IPv6 Router Advertisement IPv6-Only Flag draft-ietf-6man-ipv6only-flag =========================================== Bob Hinden presented slides https://datatracker.ietf.org/meeting/103/materials/slides-103-6man-ipv6-ra-ipv6-only-flag-00 Lorenzo Colitti: I have no problems with this. I have some nits. Bob: OK. Send them to us. Lorenzo: The nature of IPv6 provisioning is always slower than IPv4 at the moment. You can avoid turning IPv4 off if you notice it's already working, and I suggest not looking at this flag in this case to avoid lots of attacks. Bob: OK. Suggest some text. Eric Vyncke: There is a point in the introduction where you discuss lots of benefits. There is a sentence that it's true, but I would remove it. Bob: I would agree to removing it. There was discussion on the list about it and I remember it. Suresh: AD hat on: I don't want you to go down the same path as ?. Are we trying to cram 3 values into 1 bit? We need to be careful. Bob: I'm not sure what I should take based on your suggestions. Suresh: Try to be clearer on expected behavior. More description on what does and doesn't happen. How things actually work isn't clear. Bob: There could be reasons for keeping this as suggested behaviour. MUST may not be the right word or approach. Mikael Abrahamsson: I think this SHOULD is perfect and we can leave it to the system to decide how to handle this. Let people find out what works and what doesn't, and then we'll work on a new document. Bob: v6ops will get to work on this in three years. Suresh: Mikael, do you want the host behaviour removed ? Mikael: I'm fine with it as SHOULD. We can have a BCP in 2-3 years. Suresh: That's where people are rat-holing on. Lorenzo Colitti: The M and O bits were controversial because they arose from a big fight. That's why they are controversial. As an implementer, I'm fine with current recommendations. We are not going to have a one-size fits all solution. Bob: When we ran the IPv6 only network some meetings ago, that's when we realized we needed this. Jen Linkova: I like this draft, and as a network operator, I think the host behaviour section is clear enough on what I expect hosts to behave. I like Lorenzo's comment on ignoring expiring routers' lifetime. I think overall it's quite good. Ole: I'm not sure what I hear here is representative of the mailing list. Suresh: I don't think it is. We have fairly significant support for the text as of now. I'm not sure it's holding the mailing list. There are people there feeling otherwise. Let's post it there and see how it goes. Ole: My problem is that there's no consensus on the list. Suresh: Yes, this is a problem I have with current state. Bob: It seems a lot of email discussion was just about the email discussion and not focused on the text. Commenting on the text might be simpler. Suresh: Like the one that started it all that said "I'm really against it" Mikael: Relaying Bjoern Zeeb: The -04 draft says MAY and not SHOULD. If v6 worked why turn on v4 again ? Ole: We could do some consensus calls. We could ask about the flag being prescriptive or not, making it just a hint. Given what's going on in the ML, we can try this call in the meeting room and then we'll see how it goes on the list. Mikael: I talked to one of the large host implementors and I got the feeling they wanted the hint. The feedback was similar to what Lorenzo said. Ole: It is already quite prescriptive. Mikael: We're not the protocol police. It should be SHOULD. Ole: As an implementor, how would you know what to do ? Lorenzo: Your life as an implementor is not knowing what to do. We're overstating the level of requirements that a SHOULD imposes. We're here to make sure implementations are interoperable. Mikael: What Lorenzo said, that's my take on it. It would happen anyway, even if we put a SHOULD. I think this document is fine as it is. Ole: Thank you. Should we ask questions? Mikael: I think if we point out that the SHOULD leaves space to implementors, we can have consensus. Lorenzo: Who is arguing for MUST ? Mikael: I've seen people on the list asking for it. I could be misinterpreting it, though. Bob: The text in the document is not prescriptive, but it is unless you have a reason to do otherwise. Mikael: For me that's fine and it gives implementors leeway to do their thing. Lorenzo: I think if you change the text to really mean a hint, then you could get consensus. That could be a possible way forward, together with security concerns. Ole: At some point the flag will have little value. Lorenzo: It's a useful statement of intent. It's easier to see it and then take action. Bob: It's a signal from the administrator. Mikael: Also on the security section: If you don't have first hop security, you have problems anyways. I'm pretty tired of repeating the same concepts. Ole: I wonder if I should sit with Mikael and Lorenzo and write the short paragraph and send to list. Suresh: Can you get Bob to do it with Lorenzo and Mikael ? Ole: Yes, I will do that. =========================================== Discovering PREF64 in Router Advertisements draft-pref64folks-6man-ra-pref64 =========================================== Jen Linkova presented slides. https://datatracker.ietf.org/meeting/103/materials/slides-103-6man-discovering-pref64-in-router-advertisements-00 Fred Baker: I support adoption of the document. I have an issue, though. You don't want to translate private addresses into an IPv6 prefix. That creates a problem. In a case I witnessed, where they would like to run NAT64, they would have to get a public address for every location. Jen: It's well-known prefix. It's not us. Private address space must not be translated using well-known prefix. Other translation is ok. Translation RFC (will get reference during break) says this is the rule. Fred: That needs to be in the draft. We need to be able to put private addresses. Jordi Palet: Fred, I don't think that's a problem. support the document. I sent comments to list. For selection of prefix I think the order is the same as what we have. See my draft of 464xlat-05. Ole: Jordi, please let's take this to the list. Mark Andrews: This is an IPv6 only network. We are going to have lots of networks with DNS64 from the ISP and dual-stack internal. We need to cover this scenario. We need to know which local addresses are excluded from the process. We can do it relatively easily by pointing at a DNS Entry. Jen: I think it would be tricky to do it with DNS. Mark: I can have the entire ACL in DNS signed (?) Jen: I actually think you can just use well-known prefix. Mark: We're dictating how network operators number their space here. Jen: Kind of. Mark: The option is not flexible enough for real life scenarios. Lorenzo: Not true. No other mechanism has support for this as of now. Ole: Mark, Are you able to propose text? Mark: I suggested to add a DNS name that points to a record/option. That's already on the list. Jen: Then let's take it on the list. Xing Li: I support this document. Please don't limit it to a /96. Make it variable length. We've seen the need for this in our implementation. Jen: Should we consider 2 options, one of flexible variable length so you can minimize size when possible? Suresh: It says the DNS type is an ADNS option type. DO you mean that ? Jen: It might be a typo. I'll correct it. Suresh: Lifetime is unspecified. Jen: It makes it easy to change the prefix. Suresh: Then you need 2 lifetimes? Jen: No Suresh: I think we need better specification on the lifetime. Let's take it to the list. Lorenzo: I don't object on things I'm not going to implement anyway. I leave it to the WG. We should think about putting things we're not going to use and will stay with us for a long time. Erik Kline: If the option is 8 bytes long, there should be a length field in there somewhere. Ole: Can we take comments back to mailing list and summarize? I think there is support for the draft. Chairs will do adoption call on the IPv6 list. =========================================== Making IPv6 options an option draft-herbert-ipv6-update-opts draft-herbert-6man-icmp-limits =========================================== Tom Herbert presented slides remotely. https://datatracker.ietf.org/meeting/103/materials/slides-103-6man-making-ipv6-options-an-option-00 Ron Bonica: I think this draft maybe premature. You bring one rule mentioning destination option. The one in 8200 contradicts you. Who's right ? Lacking the operational experience, do we want to make the rule now or do we want to wait until we can use this option ? Tom: So this was motivated by segment routing. Using destination option before routing header was to satisfy requirement that segment routing header TLVs have. Ron: Is it possible that someone might want to use the destination option before another EH ? Tom: We don't want case where nodes are ignoring these. Ron: A better approach might be to say that if a packet has a SRH, maybe t's better to have the option before that. Tom: The TLVs in the SR header are redundant to the DO Eric Vyncke: Regarding the ICMP message to be sent when router hits its processing limit (of extension headers), I support it but it is expired: do you intent to write a rev ? Tom: Yes, I can updated. Please comment on list. Bob: This needs more discussion on list. The 2 drafts need to be considered separately. ============================================ Path MTU Solution Space draft-troan-6man-pmtu-solution-space ============================================ Ole Troan presented the slides https://datatracker.ietf.org/meeting/103/materials/slides-103-6man-pmtu-solution-space-00 Mikael: If I say all of the above proposed solutions could be a way to go ? We're going to need everybody to do a little of everything. Some of the ideas are nice, but what did the hardware people say about truncation ? In summary. We should work on this. I can help, we have to figure out what we want to do. Ole: So we need multiple solutions. Mikael: Yes, I want all of them. ============================================ Path MTU Hop-by-Hop Option draft-hinden-6man-mtu-option ============================================ Bob Hinden and Gorry Fairhurst tag-teamed presenting slides. https://datatracker.ietf.org/meeting/103/materials/slides-103-6man-ipv6-minimum-path-mtu-hop-by-hop-option-00 Mikael: I think this draft didn't specify which MTU. Is it whatever packet type MTU you want back ? I also made a point about which MTU needs to be chosen when dealing with more interfaces. If the MRU is smaller than the MTU, what happens ? Bob: You only do it to the out-going interface and don't send it in big packets. You only update the number if it's smaller than the previous number. Mikael: I think there should be text on this. Gorry: I think I understand what you're saying. Suresh: I don't understand the feedback mechanism. What happens to the socket ? Gorry: We were hoping that the packet too big from the destination would be dropped. Jen: I want to get you some data taken from RIPE Atlas. I have a question: I couldn't find it on the draft. Are you sure that routers are not doing load balancing, so the packets are going through a different path ? Bob: It's a good question. Jen: You have to ask the vendors how they do it. Lorenzo: You know it's not going to work at all ? Gorry: Talk to us and tell us what you need. Mikael channeling Peter Van Dijk: For the specific case of DNS, where a resolver sends a query to an auth, the auth sends a response; the resolver might issue the PTB and then throw the packet away. However, it is the resolver that wants to know this number because it can communicate it as EDNS bufsize. So, for both this proposal and the next one, it would be wonderful if we could expose this number *on the receiving end* to the application layer. ============================================== Destination Originates Internet Control Message Protocol (ICMP) Packet Too Big (PTB) Messages draft-leddy-6man-truncate ============================================== Ron Bonica presented slides https://datatracker.ietf.org/meeting/103/materials/slides-103-6man-ipv6-packet-truncation-00 Ole: you have -2 minutes. Take one comment. Igor Lubashev: It is calculated all the time in middle boxes now. Ron: I tend to agree with that. Bob: I reserved a room on Friday with the goal of discussing between 6MAN and TSVWG. It would be useful to continue this discussion there, and later on the list. The meeting location and time will be announced on both mailing lists. ============================================== Meeting Adjourned ==============================================