* 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 —  
Chairs
 
 


IETF-102 6man minutes

Session 2018-07-16 0930-1200: Laurier - Audio stream - 6man chatroom

Minutes

minutes-102-6man-00 minute



          6MAN Working Group - Montreal IETF Meeting
          Monday, 16 July 2018, 09:30-12:00, Laurier
          Chairs: Bob Hinden, Ole Trøan
          
          Minute taker: Barbara Stark
          Jabber Scribe: Tal Mizrahi
          
          Jabber Room: 6man@jabber.ietf.org
          Meetecho: https://www.meetecho.com/ietf102/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, 40 min.
          
              IPv6 Router Advertisement IPv6-Only Flag,
              draft-ietf-6man-ipv6only-flag, Brian Carpenter, 15 min.
          
              Privacy Extensions for Stateless Address Autoconfiguration in IPv6,
              draft-ietf-6man-rfc4941bis, Fernando Gont, 30 min.
          
            Active Individual Drafts
          
              none
          
            New Individual Drafts
          
              The IPv6 Virtual Private Network (VPN) Context Information Option,
              draft-bonica-6man-vpn-dest-opt, Ron Bonica, 9 min.
          
              Destination Originates Internet Control Message Protocol (ICMP)
              Packet Too Big (PTB) Messages, draft-leddy-6man-truncate, Ron Bonica,
              9 min.
          
              The IPv6 Unrecognized Option, draft-bonica-6man-unrecognized-opt, Ron
              Bonica, 9 min.
          
              Zero valid lifetimes on point-to-point links,
              draft-zerorafolks-6man-ra-zero-lifetime, Lorenzo Colitti, 9 min.
          
              IPv6 Neighbor Discovery Extensions for Prefix Delegation,
              draft-templin-6man-dhcpv6-ndopt, Fred Templin, 9 min.
          
              OAM in Segment Routing Networks with IPv6 Data plane,
              draft-ali-spring-srv6-oam, Zafar Ali, 9 min.
          
              Router Advertisement Extensions for On-Demand Mobility,
              draft-feng-dmm-ra-prefixtype, Wu-chi Feng, 1 min.
          
          ------------------------------------------------------------------
          ------------------------------------------------------------------
          
          Introduction, Agenda Bashing, Document Status, Chairs, 10 min
          ------------------------------------------------------------------
          
          slides: "Introduction and Document Status"
          (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-introduction-and-document-status-01)
          
          
          Bob Hinden: Went over first few slides. This meeting will focus time on
          WG drafts.
          
          Ole Trøan: Went over the Document Status slides.
          
          Tim Winters: Mentioned last remaining issue for rfc6434-bis. No-one feels
          strongly about the issue other than Transport people. So requirement will
          remain as SHOULD.  No objections from the w.g.
          
          Tim published new draft  after the
          session reflecting this and resolution to other IESG issues.
          
          IPv6 Segment Routing Header (SRH),
          draft-ietf-6man-segment-routing-header, Darren Dukes, 40 min
          ------------------------------------------------------------------
          
          slides: "IPv6 Segment Routing Header (SRH)"
          (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-ipv6-segment-routing-header-srh-03)
          
          
              Darren Dukes stepped through the slides
          
              Slide 28 Open issues
          
              Bob: We should discuss each issue as you present it rather than
              waiting till the end.
          
              Darren: Edge filtering issues
          
              Ron Bonica: We need to understand what HMAC does and doesn't cover
              and properly describe the issue
          
              Darren: Agreed. Will do; and I think discussion on list says how
          
              Darren: Tag issues
          
              Mohamed Boucadair: Expressed opinion on way forward.
          
              Darren: Need to define to an acceptable degree what the tag is
          
              Zhenbin Li: Talked about interoperability testing.
          
              Darren: People interested in interoperability testing need to be
              identified and brought together.
          
              Darren: TLV issues
          
              Ron: Discussion on why TLVs are not implemented. We should document
              that.
          
              Zafar Ali: There are many TLVs that still need to be defined. Use
              cases need to define them.
          
              Darren: As other work progresses there needs to be discussion.
          
              Darren: Next steps slide.
          
              Joel Halpern: There are a number of issues on the list that don't
              seem to have been captured. One example is when we're required to
              encapsulate, etc. It may be in there, but as reader, I can't find
              them.
          
              Darren: OK. I'll look into that.
          
              Zhenbin Li:
          
              Darren: We need to be sure to follow up on those.
          
              Zafar:
          
              Darren: We need full definition of how and when to create TLVs.
          
              Ron: Question for Bob and Ole: When other WG defines new bit they
              have to come here for approval?
          
              Darren: Yes.
          
              Bob: Yes. How to coordinate needs to be clear. When updates on this
              doc are done, we will undergo WG last call again.  There have been
              many changes over a long period of time.
          
          IPv6 Router Advertisement IPv6-Only Flag, draft-ietf-6man-ipv6only-flag,
          Brian Carpenter, 15 min
          ------------------------------------------------------------------
          
          slides: "IPv6 Router Advertisement IPv6-Only Flag"
          (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-ipv6-router-advertisement-ipv6-only-flag-00)
          
          
              Brian Carpenter stepped through the slides.
          
              George Michaelson: There are many attack vectors. Why do we need this
              bit? I don't get it. But I don't want to say don't do this. I'm
              trying to think of the model.
          
              Brian:
          
              Lorenzo Colitti: I think you should clarify what it means.
          
              Brian:
          
              Lee Howard: Trying to get drivers installed for protocols was
              challenging. This is changing default behaviors.
          
              Jen Linkova: I think it could prevent some attack vectors.
          
              Brian:
          
              Lorenzo: There is no way to make this secure. We can never turn off
              DHCPv4 to the end of time.
          
              Brian: Ask other chair what he thinks.
          
              Ole: I don't mind having this discussion as part of WG LC.
          
              Brian: The authors will collect comments for another week or two and
              put up another draft.
          
              Ole will start w.g. last call when new draft is published.
          
          Privacy Extensions for Stateless Address Autoconfiguration in IPv6,
          draft-ietf-6man-rfc4941bis, Fernando Gont, 30 min
          ------------------------------------------------------------------
          
          slides: "Privacy Extensions for Stateless Address Autoconfiguration in
          IPv6 BIS"
          (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-privacy-extensions-for-stateless-address-autoconfiguration-in-ipv6-bis-00)
          
          
              Fernando Gont presented slides remotely.
          
              Bob: We will take questions now on this slide (labeled slide 5, but
              really slide 4 "Q: Algorithms")
          
              Lorenzo: We should remove 7217 algorithm. It can leak. That seems
              like an anti-goal.
          
              Fernando: I disagree
          
              Lorenzo: (on slide 'Q: "On by default"') RFC7528 seems unrelated.
          
              Fernando: It is RFC 7258. Sorry.
          
              Lorenzo: It's worth noting that 4941 provides no way to turn those
              off.
          
              Ole:
          
              Fernando: I agree with your concern. It should apply where it applies
              and not where it shouldn't.
          
              Brian: I think this is wrong. It makes assumption.
          
              on slide "Q: When to change IIDs"
          
              Fernando:
          
              Erik Nordmark: (on slide "Q: When to change IIDs"):
          
              Fernando:
          
              Bob: We will continue this on the list.
          
          The IPv6 Virtual Private Network (VPN) Context Information Option,
          draft-bonica-6man-vpn-dest-opt, Ron Bonica, 9 min
          ------------------------------------------------------------------
          
          slides: "The IPv6 Virtual Private Network (VPN) Context Information
          Option"
          (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-the-ipv6-virtual-private-network-vpn-context-information-option-00)
          
          
              Ron Bonica presented slides.
          
              Darren: How would your data plane find it?
          
              Ron: It could be anywhere in the destination option. I think it's a
              requirement to be able to walk the packet.
          
              Barak Gafni:
          
              Ron: You would use this to replace MPLS.
          
              Zafar: Why not use SRv6?
          
              Ron: SRv6 is still work in progress. And you might need to solve the
              problem in a network where you aren't running SRv6.
          
              Mark Townsley: Always is wrong
          
              Ron: For these VPNs it's always but I need to clarify.
          
              Mark: This is becoming yet another way of doing the same thing.
          
              Ron: Good question of whether this should be tied to SRv6.
          
              Satrou Matsushima: Why do we need to keep this info in the IPv6
              header?
          
              Ron: Instead of in a shim header? OK.
          
              Bob: There needs to be more justification and motivation before
              adoption can be considered.
          
          Destination Originates Internet Control Message Protocol (ICMP) Packet
          Too Big (PTB) Messages, draft-leddy-6man-truncate, Ron Bonica, 9 min
          ------------------------------------------------------------------
          
          slides: "Destination Originates Internet Control Message Protocol (ICMP)
          Packet Too Big (PTB) Messages"
          
          (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-destination-originates-internet-control-message-protocol-icmp-packet-too-big-ptb-messages-00)
          
          
              Ron Bonica presented slides.
          
              Slide 14
          
              Joel Jaeggli: The packet you truncated will no longer have a valid
              header?
          
              Ron: There is a rule that if truncation would cause invalid header
              you cannot truncate.
          
              Joel J: Requires stack change
          
              Richard Patterson: Requires on ICMP getting back to original source?
          
              Ron: But odds are better of getting back to source.
          
              Jen: I think you need to mention reason.
          
              Lee: It seems unlikely it would have all the needed info. This also
              seems like an opportunity to send misinformed messages.
          
              Fernando: This works because you don't need to get ICMP message?
          
              Ron: Yes
          
              Fernando: Destination options don't get through.
          
              Ron: Needs to be fixed in next draft.
          
              Lorenzo: Is there benefit to the source code to be able to use this?
              If not then this isn't needed. Also, if this doesn't work close to
              100% of time then it isn't needed.
          
              Bob: Take this to the list.
          
          The IPv6 Unrecognized Option, draft-bonica-6man-unrecognized-opt, Ron
          Bonica, 9 min
          ------------------------------------------------------------------
          
          slides: "The IPv6 Unrecognized Option"
          (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-the-ipv6-unrecognized-option-00)
          
          
              Ron Bonica presented slides.
          
              Joel Jaeggli: If you need to send flow label, then there is a hash
              issue
          
              Jen: Are you suggesting to keep this somewhere in destination option?
          
              Bob: Out of time.
          
          Zero valid lifetimes on point-to-point links,
          draft-zerorafolks-6man-ra-zero-lifetime, Lorenzo Colitti, 9 min
          ------------------------------------------------------------------
          
          slides: "Zero valid lifetimes on point-to-point links"
          (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-zero-valid-lifetimes-on-point-to-point-links-placeholder-01)
          
          
              Lorenzo Colitti presented slides.
          
              Danny Moses: This is too strict for 5G because 5G needs to support
              multihoming.
          
              Lorenzo: Is it actually an interface with 2 links or with 2 routers?
          
              Danny: Both cases exist.
          
              Lorenzo: Let's take this off-line.
          
              Richard Patterson: Would this work if you deleted the security text?
          
              Lorenzo: In a broadcast link it doesn't prevent from sending
              packets. If you delete all addresses then you have no addresses left.
          
              Jen: I think...
          
              Lorenzo:
          
              Bob: There are still issues to work out before w.g. adoption can be
              considered.
          
          IPv6 Neighbor Discovery Extensions for Prefix Delegation,
          draft-templin-6man-dhcpv6-ndopt, Fred Templin, 9 min
          ------------------------------------------------------------------
          
          slides: "IPv6 Neighbor Discovery Extensions for Prefix Delegation"
          (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-ipv6-neighbor-discovery-extensions-for-prefix-delegation-00)
          
          
              Fred Templin presented slides.
          
              Erik Kline:
          
              Lorenzo: I think this is very useful. But have comments. You don't
              save power after initial exchange.
          
              Fred: You don't necessarily have to continue receiving multicast RAs.
          
              Lorenzo: How do I get initial router?
          
              Fred: You send RS and get RA.
          
              Lorenzo: We need to be clear that we're turning RS/RA into a pull
              protocol.
          
              Bob: I'm not comfortable with adopting yet. I think it needs more
              work and use case needs to be clearer.
          
          OAM in Segment Routing Networks with IPv6 Data plane,
          draft-ali-spring-srv6-oam, Zafar Ali, 9 min
          ------------------------------------------------------------------
          
          slides: "OAM in Segment Routing Networks with IPv6 Data plane"
          (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-oam-in-segment-routing-networks-with-ipv6-data-plane-placeholder-01)
          
          
              Zafar Ali presented slides.
          
              Bob: We need to see more discussion of this on the list.
          
          Router Advertisement Extensions for On-Demand Mobility,
          draft-feng-dmm-ra-prefixtype, Wu-chi Feng, 1 min
          ------------------------------------------------------------------
          
          slides: "Router Advertisement Extensions for On-Demand Mobility"
          (https://datatracker.ietf.org/meeting/102/materials/slides-102-6man-router-advertisement-extensions-for-on-demand-mobility-00)
          
          
              Wu-chi Feng presented slides.
          
              Eric Vyncke: Are you aware of the other option?
          
              Wu-chi: Our understanding of it was
          
              Eric: So the big difference ere is that it is in the RA?
          
              Lorenzo: The prefixes are in the same PVD. They simply have different
              properties.
          
              Mark Townsley: Did you review the whole history of MIF (multi
              interface WG)?
          
              Wu-chi: No
          
              Mark: Please look at history so as not to repeat it.
          
              Danny Moses: 3GPP has required this for 5G. This was started about a
              year ago. We think this is the most optimized way of doing this. In
              the past 3GPP tried to use IETF technology for various things; but
              when IETF doesn't, 3GPP must create its own solution.
          
              Lorenzo: I think I might have a better explanation for why these are
              in the same PVD.
          
              Pierre Pfister: I think they may be different PVDs.
          
              Lorenzo: If they are different PVDs it means they are not on the same
              network.
          
              Eric V: you can use any address from the PVD. If it gets different
              results then it needs to be different PVD. I need to read the draft.
          
              Bob: Draft needs work. I encourage people to talk to people here at
              IETF. It's only Monday.  Applies to all documents discussed here.
          
          -----------------------------------------------------------------------------------
          
          Meeting Adjourned
          -----------------------------------------------------------------------------------
          
          



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