Minutes IETF104: v6ops
minutes-104-v6ops-00

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? <hands were raised> About 14
Question from someone: How do you define operator?
Fred: Ask Jen. <laughter ensued>
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.
<presentation resumed>
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.
<presentation resumed>

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? <question directed at
Fred>
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,
<draft-palet-v6ops-464xlat-opt-cdn-caches>
################################
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.

<presentation resumed with Approach 2>

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. <not at mic>
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,
<draft-lmhp-v6ops-transition-comparison>
################################
Richard Patterson presented:
https://datatracker.ietf.org/meeting/104/materials/slides-104-v6ops-comparison-of-ipv6-transition-technologies-for-ipv4aas-00

Richard: <to Fred> 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, <draft-gont-6man-slaac-renum>
################################

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...
<discussion was cut>
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,
<draft-ietf-v6ops-nat64-srv>
################################

Martin Hunek presented:
https://datatracker.ietf.org/meeting/104/materials/slides-104-v6ops-nat64dns64-detection-via-srv-records-00

<slide 6>
Jen Linkova: In it's current version it says /96, we will present an
option to have different values in the future.
<presentation resumed>
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.
<presentation resumed>

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