6MAN Working Group - London IETF Meeting Monday, 19 March 2018, 13:30-15:30, 1W Viscount Chairs: Bob Hinden, Ole Troan Minute taker: Jordi Palet, Eric Vyncke Jabber Scribe: Mikael Abrahamsson Jabber Room: 6man@jabber.ietf.org Meetecho: https://www.meetecho.com/ietf101/6man ----------------------------------------------------------------------- ----------------------------------------------------------------------- Agenda Introduction, Agenda Bashing, Document Status, Chairs, 10 min. Working Group Drafts IPv6 Node Requirements, draft-ietf-6man-rfc6434-bis , Tim Chown, Tim Winters, 20 min. IPv6 Segment Routing Header (SRH) draft-ietf-6man-segment-routing-header , Darren Dukes, 20 min. Multi-Vendor Interoperability Testing Results Update, Carsten Rossenhövel, 5 min. Active Individual Drafts ICMPv6 errors for discarding packets due to processing limits, draft-herbert-6man-icmp-limits , Tom Herbert, 20 min. IPv6 Router Advertisement IPv4 Unavailable Flag, draft-hinden-ipv4flag , Bob Hinden, 20 min. New Individual Drafts IPv6 Performance Measurement with Alternate Marking Method, draft-fioccola-v6ops-ipv6-alt-mark , Giuseppe Fioccola, 10 min. Recommendation on Temporary IPv6 Interface Identifiers, draft-gont-6man-non-stable-iids , Fernando Gont, 5 min. Privacy Extensions for Stateless Address Autoconfiguration in IPv6, draft-gont-6man-rfc4941bis , Fernando Gont, 5 min. Unified Identifier in IPv6 Segment Routing Networks, draft-mirsky-6man-unified-id-sr , Greg Mirsky, 5 min. ----------------------------------------------------------------------- ----------------------------------------------------------------------- Introduction, Agenda Bashing, Document Status, Chairs, 10 min. -------------------------------------------------------------- Since last meeting RFC8319 has been published Several documents of interest in other WGs Eric Vyncke -> there is one more document in the Internet Area about IPv6 provisioning domains (PvD) Suresh Krishnan -> another document in IPWAVE draft-ietf-ipwave-ipv6-over-80211ocb IPv6 Node Requirements, draft-ietf-6man-rfc6434-bis , Tim Chown, Tim Winters, 20 min. --------------------------------------------------------------------- Tim Chown presenting. Is a 6-7 years old document that need a refresh. 1 slide summary of changes since IETF100. If everybody is happy with the actual status, we can ask if we can advance it. Ole Trøan. Any observations considering this morning presentation at v6ops about router requirements. One difference being the router MUST support DHCPv6 while node SHOULD support DHCPv6 and Tim Chown is happy with this difference. Tim Winters confirms the reference was removed so only informally mention. [Note: reference was still in current version.] Barbara Stark confirms she likes the updates done. ACTION: Chairs will advance the document to IESG. IPv6 Segment Routing Header (SRH) draft-ietf-6man-segment-routing-header , Darren Dukes, 20 min. ------------------------------------------------------------------------ Darren Dukes presenting. Ron Bonica: this draft has been stable for a few years. There is another draft (about network programming) which is still moving and includes some shocking issues for this WG such as two RH in one packet. Either merge both drafts or last call them together. Ron and Darren disagree on the fact that SID could play a similar role to L3VPN. Suresh Krishnan: Do you have a plan to update the other document (on header insertion)? I don't want to hold this for ever, so I really want that to progress. Zafar Ali: drafts will be reviewed anyway in other WG Suresh Krishnan: That's what I've said. Ron Bonica: Question about issues with implementations? Presenter: if you're implementing now, let's have that discussion. Zhenbin Li from Huawei: we are also implementing SRv6. Suresh Krishnan: You can add a section about specific implementation details. Bob Hinden: There are no normative references in the document, they are all informational, that should be fixed and Darren agrees to fix this issue quickly. Darren what are the next steps. Bob is comfortable with starting the WGLC. ACTION: Chairs will start working group last call. Multi-Vendor Interoperability Testing Results Update, Carsten Rossenhövel, 5 min. ------------------------------------------------------------------------ Nobody available to present on this, so skipped. ICMPv6 errors for discarding packets due to processing limits, draft-herbert-6man-icmp-limits , Tom Herbert, 20 min. ------------------------------------------------------------------------ Tom Herbert presenting about having a new ICMP error code to indicate that the middle box cannot handle the EH chain (too long, too many headers, ...). Darren Dukes: what to do when using ASIC because I cannot move the pointer to the next extension header which is beyond the ASIC visibility. I will send an email about this. Tom Herbert: We should point to something after that. The point is taken. Suresh Krishnan: Push that to the slow path. Bob Hinden: Skeptical that hosts to make any use of this. You've not convinced me about that. Tom Herbert: Extension headers aren't reliable, anything we do improves the situation. Feedback is part of that, instead of alternatives such as probing. I'm looking for flexibility using extension headers. Ole Trøan: What granularity do we want? What are the hosts doing with those ICMP codes? Is parameter error sufficient? The ecosystem to use this is quite big. Mikael Abrahamsson: Is there a way to tell the hosts to filter a specific extension header? Suresh Krishnan: Is that a parameter problem? Lorenzo Coliti: if you write code yes, but nobody wrote it yet. Mikael Abrahamsson: I'm not talking about this. If I've a firewall that want to filter something, do I've a way to signal that I'm going to filter that? Michael Ackermann: We don't have network management for that. Ron Bonica: could be useful to detect issue in tunnels Chairs do a hum to get a sense for adopting this document as a WG item. Excellent, seems room in favor of vote for adoption and will confirm in mailing list. ACTION: Chairs will confirm adoption on the mailing list. IPv6 Router Advertisement IPv4 Unavailable Flag, draft-hinden-ipv4flag, Bob Hinden, 20 min. ------------------------------------------------------------------------ Bob Hinden presenting. The I-D could prevent a dual-stack host to use IPv4 even in the absence of IPv4 (could limit the amount of broadcast and the waste of battery, ...). Just a 4 flag in RA, default value 0 means that IPv4 is present. Mikael Abrahamsson: You said "flag set administratively and not automagically"? If the upstream is PPPoE only (so the CPE does not know before PPPoE whether IPv4 is present)? Juliusz Chroboczek: Why is a flag and not an option? I see 3 values. Bob Hinden: What do you expect the host do to differently in that case? Juliusz Chroboczek: In the future when networks don't have IPv4 anymore, should we really still use a 'useless' flag? Bob Hinden: Is good to remember history ... We could probably reclaims the flag. It is a very small problem, is not so bad. Lorenzo Coliti: We need to stop to disagree in the problem to find the right solution. We don't have a clear definition of what it means. Suresh Krishnan: I don't want to have sunset4 again. Let't other people talk ... Peter Stevens: what if there is IPv4 but only local in the LAN w/o IPv4 router? Lee Howard: Flat set: I'm not the default gateway for IPv4. There is a useful clarification to be made in the document. Jen Linkova: We need to state if it means public IPv4 or also link-local. Bob Hinden: The goal is no IPv4 addresses at all. Barbara Stark: I think is useful and doesn't harm. David Schinazi: what kind of network would use this? Home network? Enterprise? IETF Network? I want to be able to still use the old IPv4-only printer over IPv4 link-local, use Bonjour ... Bob Hinden: Then you don't set the bit. Veronika McKillop: about to deploy IPv6-only network within Microsoft IT, so this I-D is a good idea and she wants this. Jen Linkova: I see the case for enterprise ... Suresh Krishnan: I personally support his work, but we need to see how to progress. Sunset4 is ideal but not many people left there ... Happy to keep doing it here. Friso Feenstra: what is someone is sending this RA with this flag on a fully functioning IPv4 network. Suresh Krishnan: Is a different draft, note that this work is only specifying: "I'm not an IPv4 router". Suresh Krishnan: why not removing all behaviour from the I-D? Up to the host to decide what to do Fernando Gont remotely: Jen Linkova: Is a good thing that you can completely turn off IPv4, is a security issue. The chair did a hum, there was majority for adoption, with a significant minority against. To be confirmed on the mailing list. ACTION: Chair will confim adoption on the mailing list. IPv6 Performance Measurement with Alternate Marking Method, draft-fioccola-v6ops-ipv6-alt-mark , Giuseppe Fioccola, 10 min. ------------------------------------------------------------------------ IPv6 Performance Measurement with Alternate Marking Method, draft-fioccola-v6ops-ipv6-alt-mark , Giuseppe Fioccola Giuseppe Fioccola presenting: using 1 or 2 bits in every packet (same marking for one period of time) within one managed network and checking at the end of the path. Of course, 2 bits need to be found IPv6 packets (dest address, in HbH or Destination Options, flow label, ...). Ole Trøan: Clarification question. Are you talking only about traversing packets in your network or also originated in your network. Do you talk also about header injection? Giuseppe Fioccola: Is an open question, but in principle both cases. We are experimenting only, we know there are some issues, we want to get some inputs. Lorenzo Coliti: I wonder if we should use the flow label that nobody is using anyway. Suresh Krishnan: The main issue is that somebody is using those bits for hashing in load balancing. Tim Chown: We have updated the flow label behavior and a node cannot change the flow label if is not 0... but some systems may set it. Suresh Krishnan: The problem is that the flow label need to be delivered as initially set. Lorenzo Coliti: Use TCP/UDP, so use the checksum. Giuseppe Fioccola: but is not IP and may be the SLA is on IP. Recommendation on Temporary IPv6 Interface Identifiers, draft-gont-6man-non-stable-iids , Fernando Gont, 5 min. ------------------------------------------------------------------------ Ole Trøan: No comments from the room at the time being, so continue with the next document, as they are related. Privacy Extensions for Stateless Address Autoconfiguration in IPv6, draft-gont-6man-rfc4941bis , Fernando Gont, 5 min. ------------------------------------------------------------------------ Dave ?: Needs to specify "unprobably" Fernando Gont: I don't expect you remember the previous values. Tim Chown: You need to define the property of those addresses. Not predictable? Lorenzo Coliti: Base it in the algorithm from the previous RFC is a bad idea because it is predictable once the secret is known. It should be randomized so it is useful for privacy. Bob Hinden: Looking at the diff is very messy to find the changes. It would have been better if a -00 draft has been a base line from the original RFC. Then -01 can have the changes. Suresh Krishnan: The issue are the RFC editor edits, this draft was based on Suresh's XML, not the final output from the RFC Editor. The RFC Editor and AUTH48 changes were lost. Lorenzo Coliti: Let's delete the text for algorithms and just say it should be random. [After the session, the chairs request that the author start with a new filename using the RFC Editor XML to create a new baseline.] Unified Identifier in IPv6 Segment Routing Networks, draft-mirsky-6man-unified-id-sr , Greg Mirsky, 5 min. ------------------------------------------------------------------------ Ole Trøan: We have time for one question. Have you presented in SPRING? Greg Mirsky: They have a too tight agenda. Agree they should be aware of it. Darren Dukes: I do not see this I-D being applicable to any SPRING use-case. ------------------------------------------------------------------------ Meeting Adjourned ------------------------------------------------------------------------