6MAN Working Group - Prague IETF Meeting Monday, 17 July 2017, 9:30-12:00, Grand Hilton Ballroom Chairs: Bob Hinden, Ole Troan Minute taker: Barbara Stark Jabber Scribe: Mikael Abrahamsson Jabber Room: 6man@jabber.ietf.org Meetecho: https://www.meetecho.com/ietf99/6man ----------------------------------------------------------------------- ----------------------------------------------------------------------- Agenda -------------------- Introduction, Agenda Bashing, Document Status, Chairs, 15 min. Working Group Drafts -------------------- IPv6 Specifications to Internet Standard Status, Ole Troan, 5 min. Update on rfc4291bis, draft-ietf-6man-rfc4291bis, Bob Hinden, 20 min. IPv6 Node Requirements, draft-ietf-6man-rfc6434-bis, Tim Chown, 20 min. Active Individual Drafts ------------------------ Route Information Options in Redirect Messages, draft-templin-6man-rio-redirect , Fred Templin, 15 min. IPv6 Address Usage Recommendations draft-gont-6man-address-usage-recommendations, Frenando Gont, 15 min. New Individual Drafts --------------------- Tweaking Default Address Selection, draft-linkova-6man-default-addr-selection-update, Jen Linkova, 10 min. Proposals to discover Provisioning Domains, draft-bruneau-intarea-provisioning-domains, Pierre Pfister, 10 min. The AERO Address, draft-templin-6man-aeroaddr, Fred Templin, 10 min. -------------------------------------------------------------- -------------------------------------------------------------- Introduction, Agenda Bashing, Document Status, Chairs, 15 min. -------------------------------------------------------------- Note well was noted. Reviewed status of w.g. documents and Charter milestones. IPv6 Specifications to Internet Standard Status, Ole Troan -------------------------------------------------------------- Ole walked through the chair slides: https://www.ietf.org/proceedings/99/slides/ slides-99-6man-introduction-agenda-bashing-document-status-01.pdf On document status (1 of 2) page: Suresh Krishnan: I sent 4291bis back because I'd really like the WG to solve the problems with 4291bis. I don't think they've been solved. Lee Howard: Noted error on slide where RFC numbers were swapped. Requested this slide (slide 9) should be the last thing discussed during meeting today. Ole: Yes Erik Kline: The documents do not have to all be done together. Update on rfc4291bis, draft-ietf-6man-rfc4291bis , Bob Hinden -------------------------------------------------------------- Presented slides: https://www.ietf.org/proceedings/99/slides/ slides-99-6man-rfc4291bis-to-internet-standard-00.pdf Paused on slide 4, asking for comments Randy Bush: Prefixes do not need to be restricted to 64 bits. SLAAC is not limited to 64 bits. Lee Howard: You are actively describing how the Internet is running now. Is the crux of the argument over the word "manually"? Lorenzo Colitti: This is close to what we've always had in standards. The value of the 64 bit number is to reserve for future use the definition of how to better use them. Job Snijders: I do see value in /64 but would hate for it to happen that implementations can't support other lengths. Perhaps remove /64 reference from the document. Everything that needs /64 can specify it in their own doc. Bob: There is text that routing should work with any prefix size. The fact that hardware should work with prefix of any length is handled in unicast section. Job: I would like to see this text removed. Jordi Palet Martinez: I support restricting to /64. Jen Linkova: Fernando Gont: Don't want code to break. James Woodyatt: Would like for there to be a compromise. Removing text may be a good compromise. In favor of taking it out. Bob: I don't think it does harm. James: It hasn't helped. Mikael: We should figure out a better word than "manual". Lorenzo: I really don't like that text. Toerless Eckert: Someone might read this and not read all other docs and that might not be good. Randy Bush: Classless IPv6 is a standards track doc. Lorenzo: Would we want Classless IPv6 without updating RFC 4291? Suresh: The point no-one talked about is what IID means, for example, for DHCPv6. I think we're having a lot of good discussions. But we need to make more progress to have everyone on same page when talking about IID. Christian Huitema: What I would like to see is maybe a problem statement? How do we do that? Bob: Will you write that? Christian: If I can get help? Bob: I will help you. Thank you. Erik: A problem statement might help. Randy: I have sympathy with Christian's expression of the problem. We need to avoid promoting NAT. We're trying to embed in the address architecture a way to tell operators how they should run their networks. We need to get operators to do what we want by up-selling on positive aspects of doing what we recommend. It's tragic tat it's getting more difficult to explain to people how to create an IPv6 network. Lorenzo: I think you're right, Bob. No matter what we do there will be an argument. But if we don't have a boundary, we will end up with /128 as the boundary. Lee Howard: Tal Mizrahi: Implementers need to know what to implement. The way I read this text is: the IID is not necessarily 64 bits long, but the implementation should be optimized for 64-bit IIDs. John Brzozowski: You need to be careful. Making the IID shorter could have ramifications. ? Add text to justify the decision Bob: We don't have consensus. Maybe if we write a doc about problem statement and get consensus on that we could eventually get consensus on this. Randy: I thought we did. Lorenzo: The question I have never seen answered is "What can we do with longer IPv6 prefixes that we can't do with /64 prefixes?" Barbara Stark: Where is the evidence that operators will use longer prefixes if we allow it? Lorenzo: They will. Job: I'm optimistic that companies will assign ample space if they are encouraged to do so. Christian: We need a problem statement. Jen: We do see evidence of operators doing things that are not recommended. Ole: I'm not quite sure what the path forward is going to be. Let's see if we can do more work around problem statements and figure out what problem we want to solve. Suresh: Maybe an interim would be useful. Maybe something more focused would help. Lorenzo: I agree. And we do have work ahead of us. IPv6 Node Requirements, draft-ietf-6man-rfc6434-bis , Tim Winters ----------------------------------------------------------------- Presented slides: https://www.ietf.org/proceedings/99/slides/ slides-99-6man-rfc6434-bis-ipv6-node-requirements-update-01.pdf Slide 10 (re jumbograms) Tim Chown: You're running off older slides. Brian's comment was there was no harm keeping as is. We changed to say we're thinking of keeping it. Mikael: I would like to keep it. Could we use other words? Joel Jaeggli: Large packets cause increased latency of other packets. James: I would like to see some consensus as to what it should say. What references to use. Like 4291. I would rather it say "Type A" than what it says now. Erik Kline: I would also like to see some sort of 4291 references. Tim Winters: We'll take a look at that. Slide 11 (3GPP) Suresh: Get with Med and talk about it. Lorenzo: Why are we publishing a new document that will trump other docs? Tim: We're saying read this other doc, if this is what you're doing. Suresh: That's just a snapshot. Tim W: Tim C: Lorenzo: Can't we just say if you support a link layer with broadcast, this is what you do. Tim W: Something we'll have to think about. Slide 13 Tim C: Lorenzo: There's a conflict between what we recommend in various places. We need to make up our minds. John Brzozowski: I think the MAY is good. Tim W: We can talk about the MAY. Nathalie Trenaman: Fernando: There is a BCP that says don't do DHCPv6? Lorenzo: It says don't do DHCPv6 only. Barbara: The BCP Lorenzo mentions applies to a specific use case and RFC 6434 is for all nodes. Suresh: If you get PIO with no A, then do DHCPv6. Now with AD hat on: Getting rid of DHCPv6 is not an option. Randy: Doesn't care if they like vanilla, chocolate, or strawberry. Wants to move them from unhealthy corn syrup to better ice cream. Ole: With that we end. Tim W.: Will update. Have some topics to discuss at next IETF. Route Information Options in Redirect Messages, draft-templin-6man-rio-redirect , Fred Templin ---------------------------------------------------------------- Presented slides: https://www.ietf.org/proceedings/99/slides/ slides-99-6man-route-information-options-in-neighbor-discovery-messages-00.pdf Ole (at mic, not as chair): Why isn't it sufficient that it sends RIO option in RA (in context of slide 6)? Fred: Eric Vyncke: It sends to destination address? Fred: No. Jen: How does it indicate it no longer has the prefix? Fred: Send NA without that route. And it sends Network Unreachable. Mikael: Fred: If it's a /112, then it sends a /112. Larger prefixes are ok. Bob: Clarifying question. This is confusing. It's a router, right? James: It might not be a router in 6man terms. No. Wait. It would have to be a router. Fred: It could just be a bluetooth device. Lorenzo: Expressed concerns about info being updated. Lorenzo and Fred discussed details. Jen: Can it send RA? Fred: RA response to RS is normally multicast but unicast is allowed. -- out of time -- IPv6 Address Usage Recommendations draft-gont-6man-address-usage-recommendations , Frenando Gont --------------------------------------------------------------------- Presented slides: https://www.ietf.org/proceedings/99/slides/ slides-99-6man-address-usage-recommendations-01.pdf At end of slides: Ole: Has anyone solved this? Fernando: Not that I know of. Erik Kline: Something that should be worked on. Eric Vyncke: Thomas Pauly: Philipp Tiesel: Ole: Unsure if this is for transport and above problem space. Need to talk to our AD and transport people. Dave Thaler: People wanting to do APIs and specific languages done by other SDOs should talk to me. Mikael: Useful for people to think about this problem space. No opinion on where to do it. We need a replacement to the open socket API that isn't proprietary. Dave: This org needs to abstract the API. The model is in scope for us, but not the actual API. Bob: What Dave recommends is a good path forward. Tweaking Default Address Selection, draft-linkova-6man-default-addr-selection-update , Jen Linkova -------------------------------------------------------------------- Presented slides: https://www.ietf.org/proceedings/99/slides/ slides-99-6man-making-default-address-selection-more-fool-proof-00.pdf Lorenzo: I think our Linux workstations are already doing this. But if they're already doing this and it's not helping, then it may not be the solution. This feels like a crutch. Jen: Some vendors have been asked to send RA every time. Lorenzo: Well maybe this will work. Suresh and Jen discussed having multiple routers. Tim W: My preference would be to just fix it with the preferred lifetime and base the decision on that. Jen: OK. Dave: Multiple comments. . -- out of time -- Proposals to discover Provisioning Domains, draft-bruneau-intarea-provisioning-domains , Pierre Pfister -------------------------------------------------------------------- Presented slides: https://www.ietf.org/proceedings/99/slides/ slides-99-6man-discovering-provisioning-domain-names-and-data-00.pdf Pierre would like feedback. Jen: Do you explain how to do... ? Pierre: The goal is to get the right source address. Dave: I understand this and think it works for regular hosts but not constrained hosts. Pierre agrees. The AERO Address, draft-templin-6man-aeroaddr , Fred Templin ------------------------------------------------------------ Presented slides: https://www.ietf.org/proceedings/99/slides/ slides-99-6man-the-aero-address-00.pdf There were no comments or questions at this time. ------------------ Ole: Thank you. Went back to slide 9 of chair slides. ----------------------------------------------------------------------- Meeting Adjourned -----------------------------------------------------------------------