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

V6ops Status Pages

IPv6 Operations (Active WG)
Ops Area: Ignas Bagdonas, Warren Kumari | 2002-Aug-22 —  
Chairs
 
 


IETF-104 v6ops minutes

Session 2019-03-28 1350-1550: Athens/Barcelona - Audio stream - v6ops chatroom

Minutes

minutes-104-v6ops-00 minute



          IPv6 Operations - IETF 104
          2019-03-28 13:50
          
          Chairs: Fred Baker, Ron Bonica (not present)
          Notes: Barbara Stark, Massimiliano Stucchi
          Jabber: Mikael Abrahamsson, Kitimbo Ben Kyemba
          
          ################################
          Choosing the Agenda
          ################################
          Fred explained how he and Ron decide on a meeting agenda.
          Then proceeded with chair slides.
          https://datatracker.ietf.org/meeting/104/materials/agenda-104-v6ops-00
          
          Jordi Palet asked for last call on the NAT64 deployment draft.
          Hum: Yes.  Working group last call will be sent out.
          
          Fred explained that Jen Linkova is wanting more data on how many
          operators attend.
          How many operators are in the room?  About 14
          Question from someone: How do you define operator?
          Fred: Ask Jen.
          Jared Mauch (speaking on behalf of Akamai): If people are looking for
          data, we should be quantifying it. People should identify what
          information they want, and we would be happy to publish more of it.
          
          ################################
          IPv6 Networking with an IPv4aas Overlay: Deutsche Telekom TeraStream,
          Mikael Abrahamsson
          ################################
          
          Mikael Abrahamsson presented:
          https://datatracker.ietf.org/meeting/104/materials/slides-104-v6ops-deutsche-telekom-terastream-00
          
          one slide 3
          Bernie Volz: What's the technology using from the home to the relay, the
          cable environment has done a good job defining everything.
          Mikael: There is 1 VLAN. Untagged. 1 sub-interface per customer "here"
          (pointing at R1 router with DHCPv6 relay box)
          Bernie: Okay.
          
          on slide 4
          Jen Linkova: Can you use ULAs for this ?
          Mikael: For what ?
          Jen:  For prefixes that are not supposed to be on the internet
          Mikael: We are not currently using ULAs.
          
          Jen Linkova: Thank you very much,.  This is awesome, I agree, and I
          think you're doing an unusual thing.  This is some interesting work that
          many haven't done yet.  We need to provide a gap analysis and document
          how to make the protocol more robust.  This might need to be in v6ops.
          We should check what we can do without having to change neighbor
          discovery too much.
          Mikael: There is one more thing avout the PVD. Different VPNs aren't
          recognized. Could be solved with PVDs.
          Jen: I totally agree about the stories of hosts having more addresses is
          not solved reliably.
          Mikael: Not only addresses. Also resolvers. The whole space.
          Jordi Palet Martinez: I agree with Jen.  We had this conversation
          yesterday.  Maybe it's not just deployment guidelines, but also
          implementation guidelines, and I'm not sure this is the scope of the WG
          and/or we need to recharter.
          Mikael: Would parameter settings also be in scope?
          Fred: If we have something that tells us that a parameter needs to be
          changed, then we should look at it carefully, and that would be a
          deployment guideline.
          Mikael: For existing parameters, how to set them.
          Fred: Yes, that would be in scope of v6op.
          Jordi:  OpenWRT does all of this correctly and maybe qwe should document
          it.  If you don't explain it to people, they won't learn to implement it
          correctly.
          Fred: So... Please implement correctly. That would be within our
          operational charter.
          Erik Kline:  We should make it bug-ree at last. PVD is needed.
          Mikael: I agree.
          Fred: The PVD is the only way to solve this problem.  Have you checked
          the latest version of the universal RA I-D ?
          Mikael: I haven't.  I would like to be able to define MTUs over my
          systems, and that would help a lot.
          
          Erik: I'm not sure if that's expressed in current state of universal RA
          draft. Are you saying you're using a Linux Box?
          Mikael: It is a linux Box, yes.
          Erik:  Do you monitor the link for changes in the network state ?  You
          could put it in the probes and observe failures.
          Mikael: We need to come up with best current practices.
          Erik: A long time ago this was an issue we were discovering in the
          resiliency issues.  We never finished that work.
          Mikael: Work to be done there. Might not be here; might be 6man. It is a
          gap.
          Martin Hunek: You mentioned DHCP relay does not always put a route in
          the routing table.  We have the same issue with our server.  We have
          seen operators solving this through hooks.  Sometimes devices use LL
          addresses not generated using EUI-64.
          Mikael: Agreed. I've had that happen to me. OpenWRT has many bindings.
          If you just download a DHCPv6 server, it has none of these things.
          Martin: I know this implementation does not always work, because of
          these LL addresses and other minor issues.
          Mikael: That's not actually a problem. It's the implicications of what
          it's doing that's not happenin.
          Martin: Yes.
          
          There were no other questions nor comments.
          
          ################################
          464XLAT Optimization for CDNs/Caches 2019-03-06,
          
          ################################
          Jordi Palet Martinez presented:
          https://datatracker.ietf.org/meeting/104/materials/slides-104-v6ops-464xlat-optimization-for-cdns-and-caches-00
          
          After presenting "Approach 1", Jordi paused for comments on slide 9.
          Mikael Abrahamsson:  Chromecast has been known to use 8.8.8.8.8 even if
          it gets something else via DHCP.
          Jordi: No problem.  This would still work
          Freed:  There is a problem actually, and it's configuration.
          Mikael:  It's not usingf your local resolver.  It's talking to something
          on the internet to resolve.
          Jordi: That would be translated twice. I'm not breaking it. It's not
          optiomized but it still works.
          Mikael: It's not going to be optimised.
          Jared Mauch:  There's lots of work happening to move this from host
          control and move it into applicatino control.  This approach workls for
          host level control.  I've started to wonder if it would be time to
          update some of the host behaviour RFC to include the application layer.
          The chromecast is a unified device, but there might be other people
          applications that might interfere with this.
          Jordi: But if that's the case, we're still not breaking anything. It's
          not optimized.
          Fred: This means you're not breaking anything, right ?
          Jordi:  No we're not.
          Jared: The work at the IETF is moving in that direction, and people
          should keep that in mind.
          Jordi:  We need to keep an eye on that.
          
          Dave Plonka: You want the recursive server to make a determination if
          the connection is v4 only ?
          Jordi: Yes. It's going to do that by... if you are a dual stack client
          it will ask for the A record.
          Dave:  If I ask for the A, how long do you wait for me to ask for AAAA ?
          I don't think you can tell the client on your lan is v4 only.
          Jordi: I think you can. You are asking for a single name.
          Dave: If I'm dual-stack I could just ask for the A record.
          Jordi: If that happens, we will still work because we will provide the
          real AAAA record.
          Mikael: You can probably create heuristics and figure out how to do it.
          The downside is that you lose optimisation.  The worst case is what we
          do today.  There's little downside to be wrong.
          Jordi: Yes.
          Geoff Huston: Two consecutive queries will invariably go to same
          resolver agrent. This idea that somehow memory of query A can be
          remembered for query B no longer applies.
          Jordi: But this is exactly the same thing Happy Eyeballs is doing.
          Geoff Huston:  Happy eyeballs asks for A and AAAA from different
          resolver engines.
          Jordi:  Okay. In this case if it's a v4 only device it does not have a
          fallback.
          Jen Linkova: I think the only way you can solve the problem is to make
          sure CPE Router is your resolver. But if IPv4 is broken, I don't mind.
          Jordi: I am not sure if I missed to explicitely say that what I'm trying
          to make is the CPE having a DNS resolver/proxy to bring that
          information.  If the proxy is the clat itself, it is able to know if
          there's an IPv4 device or an application that can do only ipv4.
          Mark Andrews: You're wrong.
          Mikael Abrahamsson: So, what about doing traffic statistics ?  If you're
          talking to an IPv 4 address a lot, you might be talking to a few places
          and look into correlating it into the IP layer.
          Jordi: Instead of using DNS correlation.
          Mikael:  Let's test it with some devices and see if and how it works
          Jordi: I've already experimented in OpenWRT and it worked.
          Jen Linkova: All this static mappings have corner cases if DNS responses
          change, right ?
          Jordi: It was in the slides, I didn't mention.  What's missing today is
          the TTL.  You create an entry in the EMT table and it misses that data.
          Jen: What are you going to do when you have more than one AAAA?
          Jordi: I didn't look into that.  Maybe it takes only the first one.  I
          need to look into that.
          Jared Mauch:  We give out multiple answers when you ask for A and AAAA.
          Look out for that case.
          Jordi: OK. Thank you. Alejandro D'Egidio (co-author) said he may also
          try it out.
          
          Jordi asked for input on the list about
          
          Fred:  I think changing the title would make sense.
          Jordi: Yes. We are open to other possibilities.
          Fred:  Just make it be NAT64.  I'll open up a discussion for a week.  In
          that timeframe, please do a writeup of the prototype and your results.
          Jordi: Yes.
          
          There were no more questions nor comments.
          
          ################################
          Pros and Cons of IPv6 Transition Technologies for IPv4aaS 2019-01-24,
          
          ################################
          Richard Patterson presented:
          https://datatracker.ietf.org/meeting/104/materials/slides-104-v6ops-comparison-of-ipv6-transition-technologies-for-ipv4aas-00
          
          Richard:  I think the idea came from you?
          Fred: It came out of a discussion. Not sure I started it. What do you
          want next for draft and what do you want from the WG?
          Richard: The original goal was to provide a single reference point for
          an operator.  I tried to do the analysis myself.  Had I had this
          document two yearsd ago, it would have helped me a lot.  I want to make
          sure we catch as much as we can, and I would like to see discussion on
          this.  What do the operators in the room think ?
          Fred: It seems like, if I'm just some random person, how do I decide
          which to pick? If everything is in the data center, it all works. If
          you're doing translation or not local it might not work. So what are
          trade-offs to selecting? Is there guidance to give?
          Richard: There's also a lot of subjective things here.
          Mikael Abrahamsson: Some of the decisions to take have to do with
          platform support.  You have to capture these.  I think it's a very
          useful document.  I get this question every few months and I woul dlove
          to point people to this document.  I want to have an overview of what
          the community is doing.  I don't know if we can capture what's mostly
          deployed.  What's in there right now is useful and we should continue
          with this work.
          Jordi: Speaking as an author... I had many of the same questions for
          some of my customers. So I decided to compile info and put it into a
          table. I think if we don't have this document, then any operator who
          wants to choose a transition mechanism will have to read all
          documentation on all mechanisms. I think this is useful. I've gotten
          many people telling me this is nice. I'm not sure how much we can or
          should say in this doc. Maybe some things like security belong in
          another doc. Those would take a long time and people need this now.
          Mohamed Boucadair: I think this is a useful document to some degree.  I
          think that someone starting work should read all the documents, so this
          should provide only a first view of the alternatives, but if you need to
          pick your own, you should be more aware.  People should not be surprised
          when they open the document.  The material is useful and it's nice
          to have.
          Richard: Many operators are not going to spend the time reading all
          these RFCs. They'll just do what their vendor says.
          Mohamed: But initially there were recommendations.
          Richard: That was removed. It's more like operators need to convey their
          experiences.
          Mukom Tamon: I think I would like to see this become a WG draft. It's an
          important decision-making document. Zero of operators I've dealt with
          were willing to read RFCs.
          Ian Farrer:  We are trying to remove anything around subjective things.
          We are trying to keep a comparison between things and just consider what
          you need to know.
          Jen Linkova: I would like to disagree with the statement that operators
          should read all the rfcs.  When I started with the IETF I tried reading
          everything, and it wasn't the best way to go.  If we can indicate what
          technology to use, they would not have to spend time understanding it.
          This could provide a beginning point.
          Kaname Nishizuka: As an operator, I find this work useful. RFC 6888 has
          common requirements for CGN. I would like to see this referred to.
          Richard: Yes.
          Jan Zorz: I think this is interesting work, and I would suggest to come
          to the next RIPE Meeting to discuss at the BCOP Task force where we have
          more operators than in this room.  It would be nice this draft could be
          discussed in more fora.
          Fred: We have a doc that is title Guidelines for Using IPv6 Transition
          Technologies. Should this draft be considered to obsolete that draft? If
          so, this draft should consider issues raised in that draft. If so, I'll
          send to list an email to see if we should just replace that. Any more
          comments?
          
          ################################
          Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering
          Events 2019-02-18,
          ################################
          
          Fernando Gont presented:
          https://datatracker.ietf.org/meeting/104/materials/slides-104-v6ops-slaacs-reaction-to-renumbering-events-00
          
          on slide 7
          Mikael Abrahamsson: We discussed it before, and OpenWRT caps the router
          lifetime to the life of the PD.
          Fernando: What lifetime?
          Mikael:  The Prefix Delegation lifetime.
          Fernando: That is already stated in the standard.
          Mikael: Is that in 7084 ?  I think this is less of a problem.  It's an
          implementation problem if the device doesn't do it.  Your 30 minurtes
          could be a problem.  It's worthwhile to do some tests.  I was under the
          impression thatt he address with the highest lifetime was preferred.
          Fernando: There are many things being done in CPE Routers. It's not
          surprising to find implementations that have some sort of mitigation to
          these problems.
          Jen Linkova: Source address selection algorithm checks the longest
          prefix match, and you avoid using it if you have other means.  So hosts
          can do it.  Fernando, I sent a long email this morning.  I totally agree
          we have a problem, I disagree with the proposed solution.  Why do you
          think it's only a SLAAC problem ?
          Fernando: Nobody uses DHCPv6.
          Jenm:  I'm still confused with the statement that stable prefix have
          privacy implications.
          Fernando: I'm not saying that. I'm saying there are people who have
          concerns.
          Jen:  Some people having concerns is not the same as privacy implications.
          Fernando:  There are.
          Jen:  If I'm getting the same prefix over a month...
          
          Fernando: The purpose of the presentation was to get feedback.  I do
          think that the solutions belong in 6man for the most part.
          Documentation of the problem ight be here or in 6man.
          Richard Patterson: I agree with the problem. I disagree with that last
          comment. We have widgets and things that are already defined that can
          mitigate the problem. Documenting the proposed recommendations and best
          practices would be good. But I don't think it's worth creating a new
          solution.
          Fernando: There are cenrtainly mitiigations that are operationals and
          other that are not.
          Richard: I disagree with some of the proposed solutions.
          Bob Hinden:  Somewhat skeptical of the basics problem.  ISPs should
          remember the prefix they hand out.  Having the additional state of the
          prefix associated to a customer seems trivial.  I don't see why they
          can't remember that.  This is not a renumbering document.  It's a
          well-known big problem, but not a renumbering solution.  This is trying
          to address a specific problem, so let's not use specific words in the
          document.  People are not convinced the solution is protocol changes.
          Maybe we shiuld use tools we have already, but I don't have a specific
          list.
          Bob Hinden: The other issueis that you should be careful the line
          between customer and ISP, when it goes down, the prefixes should be
          fine.  I am concerned that the mechanism here should cause issues to
          happen.  I think there's some work that needs to be done carefully.
          Fernando: We proposed several alternatives to help mitigate the problem.
          When it comes to the particular solution you describe, this was for the
          scenario when the CPE Router dies. There is no refresh for the timers.
          Bob: I need to look at the document again.
          Tim Chown: I suspect this problem is hidden by happy eyeballs at the
          moment.  Has anyone done any real tests with OSes and routers to see
          what happens?
          Fernando: I can't answer that.
          Tim Chown:  I did some tests some years ago.
          Fernando;  We agreed yesterday to do some tests.
          Tim Chown:  We should discuss guidelines for operators and guidelines
          for implementors.  I think I would like to see this presented as a
          recommendation.
          
          ################################
          NAT64/DNS64 detection via SRV Records 2019-03-11,
          
          ################################
          
          Martin Hunek presented:
          https://datatracker.ietf.org/meeting/104/materials/slides-104-v6ops-nat64dns64-detection-via-srv-records-00
          
          Jen Linkova: In it's current version it says /96, we will present an
          option to have different values in the future.
          
          Mikael Abrahamsson: Could you repeat what you said about the levels
          change ?
          Martin: You would have to change the implementation of whatever is doing
          the RA.
          Mikael:  A lot of people think this is done in the kernel, but it's no
          longer done there.  It's done in the connection manager.
          Martin: Yes.
          
          Fred:  I will have to ask to bring discussion to the mailing list.  We
          are overtime.
          Fred: There is a discussion happening in opsec.  Second group last call
          for draft-ietf-opsec-v6 and they are looking for reviewers.
          
          --
          
          Massimiliano Stucchi
          MS16801-RIPE
          
          



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