* 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: Éric Vyncke, Suresh Krishnan | 2007-Sep-25 —  

IETF-104 6man minutes

Session 2019-03-25 0900-1100: Congress Hall 2 - Audio stream - 6man chatroom
Session 2019-03-29 0900-1030: Congress Hall 1 - Audio stream - 6man chatroom


minutes-104-6man-02 minute

          6MAN Working Group  - Prague IETF Meeting
          Monday, 25 March 2019, 09:00-11:00, Congress Hall 2
          Friday, 29 March 2019, 09:00-10:30, Congress Hall 1
          Note takers: Barbara Stark, Massimiliano Stucchi
          Jabber: Éric Vyncke
          Jabber Room: 6man@jabber.ietf.org
          Meetecho: https://www.meetecho.com/ietf104/6man
          Agenda - 25 March 2019
          Introduction, Agenda Bashing, Document Status, Chairs, 5 min.
          6MAN use of Github Discussion, Chairs, 5 min.
          Working Group Drafts
             IPv6 Router Advertisement IPv6-Only Flag, draft-ietf-6man-ipv6only-flag
             Bob Hinden, 15 min.
             Privacy Extensions for Stateless Address Autoconfiguration in IPv6,
             draft-ietf-6man-rfc4941bis , Fernando Gont, 30 min.
             Discovering PREF64 in Router Advertisements,
             draft-pref64folks-6man-ra-pref64 , Jen Linkova, 15 min.
             IPv6 Segment Routing Header (SRH),
             draft-ietf-6man-segment-routing-header , Darren Dukes, 30 min.
          Active Individual Drafts
             Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering
             Events, draft-gont-6man-slaac-renum , Fernando Gont, 20 min.
             Operations, Administration, and Maintenance (OAM) in Segment Routing
             Networks with IPv6 Data plane (SRv6), draft-ali-spring-srv6-oam ,
             Zafar Ali, 5 min.
          Agenda - 29 March 2019
             Introduction, Agenda Bashing, Chairs, 5 min.
          Working Group Drafts
             IPv6 Segment Routing Header (SRH),
             draft-ietf-6man-segment-routing-header , Darren Dukes, 10 min.
          Active Individual Drafts
            The Universal IPv6 Router Advertisement Option (experiment),
            draft-troan-6man-universal-ra-option , Ole Trøan, 15 min.
            Path MTU Hop-by-Hop Option, draft-hinden-6man-mtu-option , Gorry
            Fairhurst / Bob Hinden, 15 min.
          New Individual Drafts
             The IPv6 Compressed Routing Header (CRH),
             draft-bonica-6man-comp-rtg-hdr , Ron Bonica, 5 min.
             The IPv6 Virtual Private Network (VPN) Context Information Option,
             draft-bonica-6man-vpn-dest-opt , Ron Bonica, 5min.
             OAM Capabilities for IPv6, draft-bonica-6man-oam , Ron Bonica, 5min.
             The IPv6 Segment Endpoint Option, draft-bonica-6man-seg-end-opt , Ron
             Bonica, 5min.
             In-situ OAM IPv6 Options, draft-ioametal-ippm-6man-ioam-ipv6-options ,
             Frank Brockners, 5 min.
             Deployment Considerations for In-situ OAM with IPv6 Options,
             draft-ioametal-ippm-6man-ioam-ipv6-deployment , Frank Brockners, 5
          Introduction, Agenda Bashing, Document Status, Chairs, 5 min.
          Chairs: Bob Hinden, Ole Trøan
          No questions were asked.
          6MAN use of Github Discussion, Chairs, 5 min.
          Eric Vyncke: Suresh is supportive of the approach, as long as
          participants are not blocked by not using github.
          Alissa Cooper: The tutorial materials are all available, and such is the
          recording.  If people are interested, they can look at it.
          Ole: People should try it out.
          There were no more questions or comments.
          Working Group Drafts
          IPv6 Router Advertisement IPv6-Only Flag,  draft-ietf-6man-ipv6only-flag,
          Bob Hinden, 15 min.
          Bob Hinden presents:
          Jen Linkova: The document is nice and ready.  Just one comment.  I had
          the strange idea of using it in a dual-stacked network.  There is a use
          case for this, moving IPv6-capable devices to use IPv6 only.  Can we
          relax section 3 to a SHOULD ?
          Bob: I'm not sure. We tried to make it support different environments but
          need to see.
          Tim Chown: I would assume legacy devices wouldn't understand the flag
          anyway, so it should work.
          Bob: That's a good point.
          Jen Linkova:  That's the whole idea.  New devices will be moved to IPv6
          only and old devices will keep IPv4.  This is a suggestion so that they
          move to IPv6, and move to IPV6 as much as possible.
          Bob: That's not the way we were thinking about it, but I think it could
          be used for that. We could add some text. But it is an IPv6-only link and
          we want to turn off background chatter.
          There were no more questions nor comments.
          Ole: Thinking loudly. Do we want to do a further call for this to get it
          advanced ?  Let's do a call on that.
          Hum: There were many hums in favor of advancing this document to the
          IESG.   No humming was audible in opposition.   Ole will confirm on the
          mailing list.
          Privacy Extensions for Stateless Address Autoconfiguration in IPv6,
          draft-ietf-6man-rfc4941bis, Fernando Gont, 30 min.
          Fernando Gont presents:
          Christian Huitema:  There is a problem in using time for randomisation
          because in practise you want your address to remain stable for some
          duration.  This is something we saw in mac address randomisation where
          it's nice to go back to a network and keep the same address.  What is the
          "stable time" you want ?  It has to be part of what you're trying to do
          Fernando: We have that question, too. Let's say your just using a simple
          random number generator with no time parameters. What happens if you
          disconnect and then reconnect again? I think it's a broader issue than
          just the timer.
          Christian Huitema: I'm not advocating timer.  The discussion of this
          issue and balancing the solution.  WE could not use time at all ans we
          can assume the randomisation comes from timing.
          Fernando: I think that even if we use this time parameter from RFC7217 --
          do we want more than one and recommend one? Or do we remove the rest?
          What does WG want to do?
          Ole: Do any implementers of RFC4941 care either way?
          Erik Kline: I think I have a preference for keeping a reference to pure
          randomness as a possible option.  Let's leave it up to the Operating
          system to understand if they are connecting to the same network and want
          to keep a previous address.
          Fernando: So you think it should be up to the implementation as to what
          to do?
          Erik Kline: It's up to the host, if it's decides to do DNA. Management is
          separate from address generation.
          Fernando: Agreed.
          Erik: You can have as many algorithms as you want.  Keep one as pure
          Fernando: So we keep the whole set and don't recommend any one.
          Erik: Fine for me.
          Dave Plonka: I am also in favor the simpler option of randomisation.  I
          want to mention in maprg we have figured you can use privacy addresses to
          estimate the number of hosts in a network.  You want to guarantee
          anonymity.  If you use straight up randomisation you can reduce the
          chances of figuring out the number of hosts, so it has advantages.
          Fernando: You also want to keep the 2 algorithms?
          Dave: I like the first.
          Fernando: There are 2 separate questions. Do we want to remove the
          description of one of the operations? Do we want to recommend one? Eric
          suggested keeping both.
          Dave: I'm in favor of recommending the former for anonymisation counting
          feature.  I think it's a nice feature.
          Ole: We could do a hum for each. We should ask people if ready to make
          choice or take to mailing list. How many have read this document
          recently?  OK, we will take to mailing list.
          Fernando: Okay.
          Ole:  We would like to have reviewers.  Asking for volunteers. Christian
          and another volunteered. Ron ?
          Fernando: Another question I'd like to get input on is whether we should
          keep algorithm requirements in body or in an appendix?
          Ole: Anyone?  Take to the list.
          Fernando [slide 5]: Thoughts?
          Erik Kline: I vote in favor for "on by default"
          Fernando: This could go as question to the list as well.
          Tim Chown: When you say requirements, are you meaning the requirements
          from the host point of view or from the management point of view ?
          Fernando: One of the issues with 4941 was when they switch to another
          link but keep same ID. So we recommend you should switch to new ID when
          certain things happen.
          Tim: Part of that is doing it predictably.
          Fernando:  In a sense this is left to the implementation, I guess.  There
          are a number of things changing from one implementation to another.  Some
          OSes might want to generate a new temporary address for a specific
          Tim:  I want to maximise the privacy of the user, considering how much
          that would impact the management of the network.
          Fernando: I think it should be mostly up to the host implementation. But
          there is a trade-off. We have BCP about availability of addresses and
          that might include a recommendation.
          Tim: If the outcome is that the host can generate as many addresses as it
          wants, maybe we should have some paragraphs about it.  It's an
          opportunity to move the tradeoffs one way or another.
          Fernando: Probably if we try to impose constraints it might benefit an
          endpoint, but we already have a BCP for that.
          Tim: Okay, thanks.
          Ole: Would you mind moving this doc to github?
          Fernando: Yes!
          Ole: Thanks!
          Discovering PREF64 in Router Advertisements,
          draft-pref64folks-6man-ra-pref64, Jen Linkova, 15 min.
          Jen Linkova presented:
          Mohamed Boucadair: I assume the info in slide 3. I don't think this is a
          good idea to justify having a new option in RA.
          Jen:  SLAAC is designed to provide information to hosts for basic
          connectivity.  I don't think a SIP Proxy (the example carried by Mohamed)
          is required for a host to have connectivity.  In the future we see other
          use cases, we might consider other RA Options.
          Mohamed: That's OK. But other operators can decide, for example that you
          want to do it a different way. Maybe we don't worry about it because it's
          too esoteric. We have all of these options, and I wasn't against it at
          the time. But RFCs need to be updated to recommend all as a whole. There
          are some networks where you don't need to discover the NAT64
          support. It's not needed for an IPv6 only network.
          Jen: May I ask you two questions ?  Are you suggesting we should update
          other RFCs ?  And second, we have other RA options.  Should we stop using
          them because we have other ways to provide this information to the host ?
          Mohamed: We decided previously as a WG not to provide a way to configure
          NAT64 option. But at this point we need to decide to do things the right
          Suresh: there are options that should be there such as the nat64 prefix
          and route options.  Others are not needed.
          Éric reading from jabber on behalf of Suresh: My view is that if the
          config information is fate sharing with the router it needs to be in the
          RA. If not it needs to be in DHCPv6. The DNS and NAT64 are border cases
          that could be argued that they are basic connectivity primitives. I don't
          think that will extend to SIP servers.
          Dave Thaler: On the topic of 7050, I don't think it should be absolute.
          They are different use cases.  I don't know how many people have secure
          RAs deployed, but that RFC is for people who have a specific use case
          where they configure RAs in a network with a different management.  My
          point is that it does not make sense to make it obsolete.
          Jen: I can guarantee that my host gets RAs only from my router with SeND.
          Dave T:  IF you don't have SeND, how is it more secure than 7050 ?
          Jen: I cannot guarantee when DNS comes from outside. But I can guarantee
          RA security.
          Dave T: If you can prevent host-to-host, then you can prevent this use
          case from happening.
          Erik Kline:  The RA option allows you to not have DNS64 at all.  You can
          do it on the device and not have to talk to a DNS64 server.
          Jen: It is important not to deal with the primitives themselves.
          Erik: In fact that is part of service discovery does with DNS
          Jen:  This should be configured on the router which is hard.  We can
          allow all that information to share fate with routers.
          Mark Andrews: If we go down the variable RA I think we could do the same
          exact thing we do with length. You don't have to include the exclusion in
          the option itself.
          Jen: Yes, that does make sense.  If we use approach number two and we
          expand it to have additional information.
          Martin Hunek: Is the option able to transfer to the CPE ?  I have a
          similar draft, and I was wondering if it's possible to transfer through a
          Jen:  I guess your suggestion is to include the option in RAs sent
          downstream.  That's a good idea.
          There were no more questions nor comments.
          IPv6 Segment Routing Header (SRH),
          draft-ietf-6man-segment-routing-header, Darren Dukes, 30 min.
          Darren presented:
          Erik Nordmark : do you know which subset of these does encapsulation
          compared to the previous ones ?
          Darren: All of these implementations are encapsulated.
          Tom Herbert:  Why are TLVs required in the SR header as opposed to using
          .  If you do have TLVs in the SR header, why are they different from
          hop-by-hop options and routing options ?  I think the idea was that SR
          headers could be added and removed.  Is this still the intention ?  and
          in case, why would they be different from hop by hop and routing ?
          Darren: First question answer: As we add more TLVs, those nodes have to
          look further into header and have to do additional work to process
          header. With TLV in segment header, that's not a requirement. Second
          question: When you're defining the list, keeping the options in a single
          segment header combined with additional processing overhead is reason to
          keep them where they are.
          Joel Halpern: I don't see where the current docu draws distinction on
          kinds of segments.  You might have non interoperable implementations.p
          Darren:  This draft is designing the base for other parts to be built
          Joel:  This thing about processing or not TLVs seems to be strange.
          Darren: The current text says that it's left to local policy, which is
          open to clarification.
          Joel: It doesn't reach the optimization you're citing.
          Darren: I think I described the technical reasons.
          Saturo Matsushima: ?
          Eric Vyncke from Jabber (Mikael Abrahamsson): Please elaborate on the MTU
          handling/discovery you mentioned, and what to look for in the drafts to
          find this?
          Darren: I don't think I mentioned it.
          Chang Li: I think if we put TLVs inside the SRH, how are we handling
          processing ?  Actually we have several implementations ready (Huawei) and
          we hope to address all the issues as soon as possible.
          Zafar Ali: Coming back to TLVs, I have a draft that ...  You only need to
          look for the TLV in the header if you need to modify it in some cases. ?
          Tom Herbert: It's up to local policy to process TLVs.  An implementation
          could decide to handle them whenever and wherever they want, and this
          seems to be too open.  I would like to implement this without having to
          make assumptions about local policies.  The definition of TLVs themselves
          is too open-ended and people could come up with their own implementations
          and claim they're still conformant.
          Zhenbin Li: Depends on the SRS. My suggestion is ...
          Darren: OK
          Ron Bonica:  This discussion has been going on for a long time.  Maybe a
          good thing to do would be to leave the door open to do it later when we
          better understand TLVs and requirements.
          Darren: OK. I would think defining it now and defining the base now but
          allowing for those options to be brought out would be valuable.
          Ron:  We have an interest in getting this doc published quickly.  The
          best we can do is to leave the controversial parts out and publish it.
          Zafar Ali: I don't understand this. I wish it would be spelled out in
          this draft. There is a point where we need to separate the political from
          the reality of the work. We seem to be stuck with this TLV.
          Ron: How many TLVs are defined today ?
          Darren: If we were to use the same logic, destination options would not
          have been published.  WE define things so we can build on them and build
          products on them.  Definitions are buing built.
          Ron: You're asking to do the design part backwards.
          Darren: You do the best you can with the information you have now.  You
          get closer to the right solution as you go.
          Zhenbin Li: I think the design of this is proper for the service. There
          is already an initiative to support. I think it is proper for SRS to
          behave as described in draft.
          Zafar Ali: Not all the cases could be defined.
          Ole: I'm not sure how to proceed.  It seems TLVs are the biggest
          discussion topic, and it has been for quite some time.  If I recall
          correctly, the groups did ask you to add HMAC.  If you have ideas, please
          propose text and clarifications.  We can't specify TLVs that don't exist,
          though.  I don't think we have any way to close this now, so let's let
          the discussion continue during the week.  We will have a friday session
          to summarise.
          Darren:  Those people with open issues, please get back to me and get to
          Active Individual Drafts  Reaction of Stateless Address Autoconfiguration
          (SLAAC) to Renumbering Events,  draft-gont-6man-slaac-renum, Fernando
          Gont, 20 min.
          Fernando presented:
          Timothy Winters: It is allowed to invalidate lifetime under 2 hours.
          Some people from flash renumbering invalidate lifetime under 2 hours.
          This is to prevent dos attacks.
          Fernando: You say they don't allow?
          Timothy: If you set it to a day and then you reduce it 5 seconds, it will
          be adjusted to 2 hours.
          Fernando: That is a question for CE Router if what you say is so.
          Timothy: That's what you would have to put in there.  Distinguish cases
          above and below 2 hours.
          Richard Patterson: Preferred lifetime can be reduced to less than two
          hours, and this solves the problem.  The suggestion only solves the
          problem of having too many addresses in deprecated state bound to one
          Fernando: There are 2 things. If you cannot keep the addresses, and ...
          Richard:  Is that such a big problem ?
          Fernando: Not a big problem
          Andrew McGregor: On the reduced PIO lifetimes.  I don't remember if
          there's anything in any RFC that says that you should set the lifetime on
          a router to half of the lifetime of the lease it got from its router, but
          I think it should.
          Fernando: I think only requirement that is out there is lifetime of PIO
          should never be undefined.
          Andrew: I think it should be done.
          Tim Chown: I want to echo what Richard said.  I remember many years ago
          we had the issues of hosts forming 6to4 addresses.  We had daemons send
          out RAs with 0 lifetime deprecating the addresses. The problem here is
          there are lots of things you could do that would be "hacky", but some of
          them are going to cause more harm than what they're trying to fix.
          Fernando: In the situation where CE Routers don't do that... it's unclear
          that this is the case. If we get a new PIO, first we change the
          preference of the other. But maybe first check whether prefix is still
          valid by sending packet to yourself. So if you want a more conservative
          reaction, that's fine.
          Tim: I think it would be good to document these heuristics.
          Fernando: What we have in the ID is we only unprefer or remove the
          address if it has been advertised by that same router.  In this case we
          disassociate the prefix with the specific router.
          Jen: I also am concerned with the hacky workarounds for broken routers.
          IT's a solution that's too heavy.  I think changing the default of
          preferred and valid lifetimes makes sense.  We should have done it a long
          time ago. This would solve most of the problems.  We definitely need to
          change defaults, it would help.  Regarding the problem of not being able
          to talk to on-link prefixes, I don't think we need to tweak it.  Shall we
          think about something like happy eyeballs for source addresses ?
          Erik Nordmark: Which devices do we think it makes sense tweaking ?  Shall
          we write down a set of rules ?  It's not clear about how much energy to
          put into this stuff and how much people should look at this
          implementation.  We should look at the best approaches to look forward.
          Jinmei Takuya: In this particular model the router would just copy what
          it gets from prefix delegation.  If we have to apply something, that
          would be the prefix delegation lifetime.
          Tim Chown: Maybe we could define 3 categories of things that need to be
          done. Implementations, things that can be done, and  ?
          Operations, Administration, and Maintenance (OAM) in Segment Routing
          Networks with IPv6 Data plane (SRv6), draft-ali-spring-srv6-oam, Zafar
          Ali, 5 min.
          Zafar presented: (no slides uploaded yet)
          Ole: We have discussed it, and we will hold off, then we'll make an
          adoption call on the list.
          Blue sheets did not make it to everyone.
          END of the first session
          BEGINNING of the second session
          Introduction, Agenda Bashing, Chairs, 5 min.
          Bob Hinden presented:
          There were no questions nor comments
          IPv6 Segment Routing Header (SRH),
          draft-ietf-6man-segment-routing-header, Darren Dukes, 10 min.
          Darren Dukes presented:
          Ole: We'll consider this iteration of WGLC done and issue a new WGLC just
          to be sure there are no new comments, after you publish the new draft.
          Darren:  We will have version -18 out very soon.  Early next week.
          Ole: If there's anyone with an issue on this draft, please let us know
          Ole:  OK I think we're done now.
          Darren: Thank you everyone.
          The chairs plan to start a new working group last call once a new draft
          is out that closes the open issues.
          The Universal IPv6 Router Advertisement Option (experiment),
          draft-troan-6man-universal-ra-option, Ole Trøan, 15 min.
          Ole Troan presented:
          Jen Linkova: I like the idea because I can get support much faster on the
          router side. This would simplify specifying the option. But how do we
          define what the host is supposed todo?
          Ole: There's nothing here that prevents you from adding other
          Jen: What the host does with the option is not really open for
          Erik Kline: Text in this document says if you don't understand an option,
          ignore it. But yes, specifying host behavior is an issue.
          Ole: For that particular one I don't think the document helps either.
          It's down to the implementations.  I would be happy with a single line of
          Jen: I'm talking about host doing unpredictable stuff when it does
          receive an option.
          Tommy Pauly: I'm one of the PVD authors.  In general I think it's a good
          mechanism. I would love to see it used, especially if all you really need
          on the host is simple.  In case of PVD specifically, it's a bit more
          complex, and it has an impact on host behaviour.  I think one of the
          things you want to do with PVD is to have more options to extend
          behaviour there.  I don't think switching PVD to one of these is
          something you want to do.
          Ole: I wouldn't expect PVDs not to have a stable reference.
          Mikael: One of the use cases for PVDs is for when you don't understand
          something.  We would need to cover all of the cases.  If I want to send a
          PIO, I would need to define a PIO here.
          Ole: That's already here. This is an experiment. You do whatever you
          Erik: I realize now we need an R flag.  I support the extensibility of
          this.  I do think if this is popular and successful.  We need to fix some
          things, such as the data types.
          Ole: Yes. The reason is we decide where to put things.
          Erik:You already have something that could take from reading a server and
          turn it into a DHCP option.
          Ole: You need a little more parsing but it would be nice not to require
          implementation changes. It would be a little more than 50 lines of code.
          David Lamparter: We should consider that having something in here does
          not mean it's not adopted.  We have to decide from here if we want to
          create a specific option and then go ahead with it.
          Éric Vyncke: I like the idea. Your option is interesting. You are really
          looking for something that will stand forever or you will get no
          Jen: Two comments: I'm trying to think about deployment scenarios.  This
          means I have to duplicate everything between standard parts and this.
          Ole: I would expect it to be in a new option in a universal RA.  Jen: I'm
          in favor of experiments.  This looks a bit short.  Getting something
          supported on router platform might take longer than what you are
          Ole: We have 2 implementations already. There was one done at the
          hackathon and another.
          Erik: I forgot to say that there are some conflicts between what is in
          RAs and somewhere.  I will send a pull request with text.  My perspective
          is that the things that need to use the network belong in RAs.  An
          example from earlier this week is the SIP Proxy.
          Ole: We have an infinite namespace. The network operator should only do
          options that make sense for the network.
          Alex: I generally support the way it is presented.  The way to address
          it seems appropriate.  Is it intended to be router to host or could it be
          router to router ?
          Ole: The RA mechanism is by definition routed to the host. There is a
          question of whether we want to have some means for the host to send
          something back. It depends on what you mean by a router is a router.
          Alex: I will take this question to the list to explain router-to-router.
          With respect to judging success.  Sometimes it comes from availability of
          platforms.  We see JSON, we see CDDL, I think I saw ASN.1.  IS the
          discussion on the format still open, or is it closed.
          Bob: I'd like to have us not discussing the format. If we decide
          to do this we can discuss the format.
          Tim Chown: I support this.  My concern is that you might generate or need
          extra RAs, with the obvious consequences.  There's a cliff in the
          document that you have left open.
          Ole: The second page of the slides shows the github URL.
          Tim: It would be nice to have an appendix with the list of RA options
          that did not make it.
          Ole: These are the ones that are on our schedule now.
          Tim: I think the point is that this is something that removes barriers.
          Ole: I don't know what else is out there. We have what is currently
          David Lamparter: I would be happy to implement this on FRR if I could
          find the libraries.
          Mikael: I'd like us to look into the interfaces when we talk about the
          MTU. Some of this is about Wi-Fi and multicast. If we think we will send
          more unsolicited RAs, I'd like us to think about that.
          Ole: I think that's also one reason I proposed it as an experiment.  We
          can learn a lot from this.
          Mikael: If we think this might turn into several kB of info, it might be
          good to keep it out of the RA. Like DNS-SD. We should decide what goes
          here and what goes there.
          Ole: I could have a picture of my family sent on the local link.
          Darren Dukes:  This looks like fun.
          Suresh Krishnan : How do you handle conflicts ?  Some
          information could come from DHCP.  I would like to see more text about
          sending information through different means and handling issues.
          Ole: Yes. Pull request welcome.
          OK... I'll take that as an order.
          Bob : I think this is going to be popular.  There will be lots of
          new things.  We need to be careful about what we specify.  There's a lot
          to learn here, but when we get it going, we won't be able to stop it.
          There were no more questions nor comments.
          Path MTU Hop-by-Hop Option,  draft-hinden-6man-mtu-option, Gorry
          Fairhurst/Bob Hinden, 15 min.
          Bob Hinden and Gorry Fairhurst jointly presented:
          Jen: To get feedback you can have destination unreachable. I think this
          is quite cool.
          Gorry: I'm not that ambitious.
          Erik: I'm going to suggest some text. Getting this bubbled up to the app
          is good.
          Fred Templin: RFC 1053 tried to do exactly the same thing. I think they
          were on the right track and I think you are too. It's good to have that
          history lesson.
          David Lamparter: I did a check of the Linux code and it doesn't look at
          some items. This may be hard to change.
          Bob: You are correct.  That's the status quo today.  If we can show that
          this is compelling, than it would encourage people to use it.
          David: Right but let me also make the argument that we need to make it as
          easy as possible for routers to implement and I'm not sure this is the
          way to do that. There may be other ways.
          Ole: I wanted to do performance tests during the hackathon.  I'll try to
          get that work done and publish that.
          Shwetha Bhandari: It would be important to know if option changed.
          Gorry: Yes.  We want to do stuff in this space.  However, I think this is
          only a hint.
          Igor Lubashev: You said transport needs to be reliable and mentioned
          QUIC. Another transport in use is TCP. Wat do you think about opening it
          up and offering choice after handshake?
          Gorry:  So you want to renegotiate MSS when you find something bigger ?
          Igor: This thing would be for asymmetric path.
          Gorry:  You tell it how much space you have.  I understand what you're
          saying.  We could do it.  Let's talk later.
          Tom Jones: Question on implementation. Some work at hackathon. This will
          not be horrific -- we can do this.
          Mikael:  In my 20 years I've seen ICMP expired packets go from being
          handle by the cpu to going down to specific silicon.  Have you thought
          about where this is going to be handled ?
          Bob: Not yet. Good question.
          Mikael:   They can look 128bytes into the packet.  If you can do this at
          higher speed, there are going to be high pps with hop-by-hop options to
          be treated
          Bob: And then there's another question of whether you put them
          occasionally or in all packets.
          Mikael:  We want to make this silicon friendly.
          Magnus: I like that you're doing this.  I'm very worried about where you
          want to do the processing.
          Erik: It could be that some devices can easily handle this and other
          devices won't. Something else is you may send this in parallel with
          others to the host.
          Bob provided hackathon readout. Feedback welcome.
          Ole: This is good work. Please provide feedback and experiment with
          The IPv6 Compressed Routing Header (CRH), draft-bonica-6man-comp-rtg-hdr,
          Ron Bonica, 5 min.
          Ron Bonica presented:
          There was no time for discussion.
          The IPv6 Virtual Private Network (VPN) Context Information Option,
          draft-bonica-6man-vpn-dest-opt, Ron Bonica, 5min.
          Rob Bonica presented:
          There was no time for discussion.
          OAM Capabilities for IPv6,  draft-bonica-6man-oam, Ron Bonica, 5min.
          Ron Bonica presented:
          There was no time for discussion.
          The IPv6 Segment Endpoint Option,  draft-bonica-6man-seg-end-opt, Ron
          Bonica, 5min.
          Ron Bonica presented:
          There was no time for discussion.
          Ole: We think we should take questions at the end of all the lightning
          talks for people to ask questions on all of the presented topics. But you
          [Ron} still get beer for doing your talk quickly.
          In-situ OAM IPv6 Options,  draft-ioametal-ippm-6man-ioam-ipv6-options,
          Frank Brockners, 5 min.
          Franck Brockners presented:
          Tommy Pauly: Yes, I think the question and feedback we'd like to get is
          what is the most appropriate way to do this work. What do we do here in
          6man or in our group. We're ok doing this work in IPPM. But if 6man
          thinks it should be done here, that's ok. Let us know where.
          Franck: Thank you.
          Shuping Peng:  I think we all agree.  We are proposing to put the OAM
          data in the hop-by-hop option.  If we look at EH, that's before the RH.
          The data along the path is going to become very large.  That will damage
          the performance in the data plane.  We also have done the same talks on
          the same topic.  We didn't get the slot, but we're going to present in
          the next session in RTT.  We would like to contribute more on this
          Ole: We have 10 minutes left in this session. You can ask questions for
          Franck or Ron.
          Mikael: Go back to considerations.  When I read this, I thought that none
          of this is true with the proposed approach.  It violates all these 6.  I
          think I misunderstand something.
          Franck: We're trying to mitigate these concerns. If there are other
          options to consider, we'd like to know. We want to deal with changes in
          most modest and operationally friendly way.
          Mikael: Are you going to continue this in v6ops ?
          Franck:  Right now the core of the work is in ippm. There are lots of
          Suresh: I think this should go in IPPM and 6man gets final say on whether
          it works.
          Mikael:  If you want operational feedback, v6ops would be a better
          Mirja Kühlewind: We want feedback. Please give it to us. So either you
          make a decision that this is important to you and you want to work it, or
          give it to ippm.
          Ole : I think we're happy to have this in ippm.
          Mirja: Can we maybe find someone to do an in-depth review ?
          Igor: This is a document for all the OAM drafts.  Please don't include
          options to send packets elsewhere.  This could be a vector for reflected
          amplification attacks.
          Franck: There are things that are mixed up right now. Take and record or
          take something from packet and send it somewhere.
          Igor: Local node is fine.
          Franck:  We should find a way to consolidate these things, and put them
          in a dedicated draft to address them.
          Igor: Internet is a dangerous place.
          Gorry: Some of the basic questions are the same Bob and I had.  I am not
          sure how we can get the clue for both issues at the same place.  We
          should work together, and learn from the same experience.
          Franck: We should make sure ippm and 6man are not scheduled att the
          same time.
          Ole:  We will put that on the conflict list.
          Meeting Adjourned

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