* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

6man Status Pages

IPv6 Maintenance (Active WG)
Int Area: Suresh Krishnan, Terry Manderson | 2007-Sep-25 —  

IETF-99 6man minutes

Session 2017-07-17 0930-1200: Grand Ballroom - Audio stream - 6man chatroom


minutes-99-6man-00 minute

          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
          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:
          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:
          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
          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
          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
          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:
          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/
          Ole (at mic, not as chair): Why isn't it sufficient that it sends RIO
          option in RA (in context of slide 6)?
          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.
          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:
          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:
          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:
          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:
          There were no comments or questions at this time.
          Ole: Thank you.
          Went back to slide 9 of chair slides.
          Meeting Adjourned

Generated from PyHt script /wg/6man/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -