Skip to main content

Minutes IETF102: v6ops
minutes-102-v6ops-00

Meeting Minutes IPv6 Operations (v6ops) WG
Title Minutes IETF102: v6ops
State Active
Other versions plain text
Last updated 2018-07-26

minutes-102-v6ops-00
IPv6 Operations - IETF 102

Chairs: Ron Bonica, Fred Baker
Jabber: None (David Schinazi did some minimalistic jabbering)
Minutes: Barbara Stark (Thursday minutes from Meetecho recording)

Agenda
            Thursday 13:30
World IPv6 Trends George Michaelson, APNIC
Requirements for IPv6 Routers 2018-05-26 , <draft-ietf-v6ops-ipv6rtr-reqs>
Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity
as-a-Service 2018-06-25, <draft-ietf-v6ops-transition-ipv4aas> NAT64/464XLAT
Deployment Guidelines in Operator and Enterprise Networks 2018-07-02 ,
<draft-ietf-v6ops-nat64-deployment>

            Friday 9:30
Multi-Addressing Considerations for IPv6 Prefix Delegation 2018-06-14 ,
<draft-templin-v6ops-pdhost>

Time permitting, the following will be presented (Thursday or Friday):
Discovering PREF64 in Router Advertisements 2018-07-19,
<draft-pref64folks-6man-ra-pref64> IP over Ethernet (IPoE) Session Checking
2018-07-02 , <draft-patterson-intarea-ipoe-health> Discovering Provisioning
Domain Names and Data 2018-06-04, <draft-ietf-intarea-provisioning-domains>

Draft Status
The status of v6ops drafts, both working group drafts (draft-ietf-v6ops-*) and
individual submissions to the working group (draft-<author>-v6ops-*), may be
determined from https://datatracker.ietf.org/wg/v6ops

====================================================
Minutes for Thursday 13:30 (transcribed from Meetecho recording; incomplete due
to power outage) ==================================================== Chairs
displayed Note Well. Then displayed agenda and asked for agenda bashing. There
was no bashing. Jen Linkova: Conditional RAs is now in telechat.
[draft-ietf-v6ops-conditional-ras-05]

-----------------------------------------------------
Fred Baker showed web pages of per-country IPv6 usage (from
www.vyncke.org/ipv6status/compare.php ). Fred: These stats are only for the
case where edge provider and all networks in-between run IPv6. George has been
looking at implications of this with other sampling methods and statistical
analysis.

World IPv6 Trends George Michaelson, APNIC
slides:
https://datatracker.ietf.org/meeting/102/materials/slides-102-v6ops-sessa-world-ipv6-trends-00

Lorenzo Colitti: Asked for clarification on slides 7-14 statistics.
George: Percentages are based on ad placement technology.
Warren Kumari: Weighted by price of ads?
George: Yes.

Shane Kerr: From advertising technology?
George: Doubleclick does not necessarily get blocked. They prevent content from
google.com domain but not necessarily Google ASN. Lorenzo Colitti: If you take
similar traffic sources, you end up with US in first and Japan in second.
George: Our numbers are GDP as percent of population. Lorenzo: It appears the
numbers here go from 44% to 5% George: I think there's a reason you're seeing
that. Tommy Pauly: Demographics of people making connections makes a difference.

Jared Mauch: <on slide 27> Regarding Comcast, there are people who don't get v6
because they're using old CE routers that don't do v6. There are also still
some cable modems that don't do v6.

Erik Kline: <on slide 28> The Brazil line is lower than other carve outs?
George: Carve outs don't reflect market share. Not about percentage
contribution.

<power outage occurred at 24:25 into Meetecho recording>

----------------------------------------------------------
Requirements for IPv6 Routers 2018-05-26 , <draft-ietf-v6ops-ipv6rtr-reqs>
slides:
https://datatracker.ietf.org/meeting/102/materials/slides-102-v6ops-requirements-for-ipv6-routers-00
Russ White presented; per jabber, he started around 44:30 into Meetecho
recording.

----------------------------------------------------------
Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity
as-a-Service 2018-06-25, <draft-ietf-v6ops-transition-ipv4aas>

slides:
https://datatracker.ietf.org/meeting/102/materials/slides-102-v6ops-sessa-requirements-for-ipv6-customer-edge-routers-to-support-ipv4-connectivity-as-a-service-00
Jordi Palet Martinez presented.

<video restored and these slides started at 49:34 and audio restored at 51:35
into Meetecho recording>

Lorenzo: Why do you say it must comply with RFC7608?
Jordi: If router wants to do something different in LAN, that's ok.
Lorenzo: What are you trying to achieve with this?
Jordi: I need to look into this.
Jared: Users should be able to configure this if they want to and not be stuck
with /64. Lorenzo: Then that's what you should say. That users should be able
to configure other than /64. And then we discuss that. Jordi: Need to just
provide reference to do that says this. Lorenzo: That's not what RFC7608 says.
It's about forwarding packets. Fred: If it comes into you in routing you want
to be able to honor that. Lorenzo: We have requirements in homenet that we must
be able to at least delegate /64. Fred: You are having conversation you want to
have in 6man. Lorenzo: No, I'm asking if this is requirement we want to impose
on vendors. I propose we remove this. Jen: If you think we should have this,
then you need to better describe use case. I don't understand "MUST". Jordi:
Important if DHCP provides something other than /64. Jen: I think we need to
remove.

Fred: Do you want to go to WGLC on this? Please hum. In that case, let's not
take it to WGLC. We'll have discussion on list. Fred: I'd like to get 2
volunteers to review this draft. <there were volunteers -- who they were was
not clear from Meetecho>

Fred: Can I get 2 people to volunteer to review Russ's draft?
<draft-ietf-v6ops-ipv6rtr-reqs> <there were volunteers -- who they were was not
clear from Meetecho>

Lorenzo: I recall Barbara's position on requiring CE router manufacturers to
implement 5 different mechanisms increased cost too much. I wanted to see if
that issue was resolved. Jordi: CE router manufacturers have determined it is
not too much cost and have already implemented. Lorenzo: Were they low-end or
high-end CE router vendors? Were they only ones that sell to ISPs? Barbara: My
view on how this document gets used is there are 2 uses. As ISP, I'm happy to
pick and choose without requiring full compliance. Run-of-the-mill CE router
vendors can do some and not claim full spec compliance. Others can do
everything and claim full compliance. Hans Liu: I don't know if Jordi is
referring to my implementation. But I can use this to guide my OEM vendors.

------------------------------------------------------------
NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks
2018-07-02 , <draft-ietf-v6ops-nat64-deployment> Jordi presented. slides:
https://datatracker.ietf.org/meeting/102/materials/slides-102-v6ops-sessa-nat64464xlat-depoloyment-guidelines-in-operator-and-enterprise-networks-01

Fred: <on slide 8> I want to report on conversation from dinner last night. If
you have host that is configured to use Google or Cloudflare DNS, and ISP DNS,
and RR differs -- I think you should comment on this scenario. Jordi: I think I
have described this scenario. In total I think I have 12 different scenarios.
Some include what I think you are describing. Lorenzo: I assume you meant AAAA
should be different but A are the same? Fred: Yes. AAAA give different
properties. Lorenzo: Or there are none.

Fred: No-one at mic. We will have discussion on list. I'd like 2 volunteers to
review draft. <there were volunteers -- who they were was not clear from
Meetecho>

--------------------------------------------------------------
Discovering PREF64 in Router Advertisements 2018-07-19,
<draft-pref64folks-6man-ra-pref64> slides:
https:datatracker.ietf.org/meeting/102/materials/slides-102-v6ops-sessa-discovering-pref64-in-router-advertisements-00
Jen Linkova presented.

Fred: <slide on open questions> I can answer your question on /96. There is a
network that is running other than /96. I think for your scenario, /96 is the
way to go. Jen: Yes, we want to keep things from being too complicated. David
Schinazi: We support other than /96, but haven't tested and don't know of
anyone who has deployed. I think fixing to /96 makes sense. Lorenzo: Android
doesn't support anything other than /96. Jordi: I like draft. Does RFC 7050
apply? Jen: RFC 7050 is about DNS prefixes other than /96. Jordi: Maybe we can
say this part of that doc is not in use and deprecate? Jen: Maybe someone is
using that but also wants to get this option in RA. Jordi: I was reading RFC
7051 which has analysis of different options for discovery. They were comparing
RA with DHCPv6 option. I will send comments later if I find something I think
is important to include. Jen: This was just -00 draft and there are errors.
Brian Carpenter: It seems to me that RA option has a length field. Why can't
you use length field? <answer away from mic> Brian: OK. That puts a limit on my
method. Mark Andrews: There are cases where you want to ignore AAAA records. If
you're running a different v4 network you don't want to translate your internal
v4 addresses to AAAA. Jen: My understanding is that there are rules for DNS64.
We want to follow rules. Mark: DNS translation is more than just translation.
There is other stuff we need to get to host. David Schinazi: As author of
"Happy Eyeballs", today, those networks do not have mechanism to communicate
that other info. I don't think that's something we need to solve. Lorenzo: Only
other method we have deployed is 7050. I believe the solution is if you are
running v4 only locally, then if I'm at edge, and am v6 only, it has to be
translated. Mark: You also need to consider case where you want it to work
locally. Lorenzo: Consider case where I have no v4 address. Do you need
something more? Mark: If you've only got v6 and no v4, yes. When you have
internal network and want to get back to host, you need more than just this.
Lorenzo: What you are describing is network that has v6 and v4. <fuzzy
discussion among many people near but not at mic> Lorenzo: We could say you
only use this when you have no v4 in the network. And if v4 appears we turn
this off. Fred: Make sure it's in the draft. David: Agree with Lorenzo. I
support this draft. ? <native French speaker -- maybe Eric Vyncke?>: I'm
probably looking at this wrong, but how does this impact routing? Jen:
<complicated description using lots of prefixes> ?: Need to make sure NAT64
works. There are many RFCs. Lorenzo: How does that differ from routing more
specific on your network? You want to reach different v4 destinations for
NAT64? ?: Fred: Lorenzo, what you just suggested was an odd length prefix. ?:
Which prefix should I use so I get to the right IPv4 address behind the NAT64?
Lorenzo: Just get to the NAT64 box. ?: Trying to make sure we are talking about
same problem. Lorenzo: The network can take care of that. ?: No Lorenzo: We
will take this off-line.

------------------------------------------------------------
Fred Baker: Fred Templin, do you want to do your talk now or in the morning.
You have 15 minutes. Fred Templin: Now.

Multi-Addressing Considerations for IPv6 Prefix Delegation 2018-06-14 ,
<draft-templin-v6ops-pdhost> slides:
https://datatracker.ietf.org/meeting/102/materials/slides-102-v6ops-multi-addressing-considerations-for-ipv6-prefix-delegation-00
Fred Templin presented.

Eric Vyncke: Just use case and no changes to protocols?
Fred T: Just use cases.
Ron Bonica: No proposal to change anything?
Fred T: Correct. Though assignment of address may not be well-documented.

Ron: How many have read draft? If you think useful and should be adopted, hum.
<some hums> Hum if you think dangerous -- wrong question. Hum if you think it
should not be a WG item. <some hums> Fred B: We will take it to the list. There
was some support for adoption.

========================================================================
Friday 9:30
========================================================================
IP over Ethernet (IPoE) Session Health Checking 2018-07-02 ,
<draft-patterson-intarea-ipoe-health>
https://datatracker.ietf.org/meeting/102/materials/slides-102-v6ops-sessa-ip-over-ethernet-ipoe-session-health-checking-00
Richard Patterson presented.

Stuart Cheshire: Questions and observations. It seems rather odd that we are
doing this now. We've been running IPoE for a long time. It's known if you
don't have a connection you can't get to the Internet. You've talked about
cases where devices use ARP for discovery. There's a reason the DHCP spec is
out there. Stuart: Which clients do you put this on? Richard: CE routers.
Stuart: Not for inside-the-home network? Richard: No. This is for the broadband
link. Barbara Stark: Whatare you trying to do that TR-146 doesn't give you?
Richard: TR-146 only has the health check and doesn't have the DHCP behavior.
Lorenzo Colitti: Write this up as a bug. Richard: There are some different
behaviors that need to be defined. The DHCP spec is ok. Lorenzo: If you REBIND
it means they failed? Richard: Yes. Lorenzo: Why at the client? Richard: That's
the thing that can discover the connection is down. Barbara: He's taking the
right approach.

------------------------------------------------------------------
Discovering Provisioning Domain Names and Data 2018-06-04,
<draft-ietf-intarea-provisioning-domains>
https://datatracker.ietf.org/meeting/102/materials/slides-102-v6ops-sessa-discovering-provisioning-domain-01
Eric Vyncke presented.

We use the PvD information. This information is powerful to use. This is a path
forward. Erik Nygren: DNS Discovery was being discussed elsewhere. There may be
privacy implications if there is exepected to be blind trust of this. Erik
Kline: What does it say about key words? In the Introduction? Eric V: We want
IANA to create a registry. It's in the IANA Considerations. Erik Kline: There
needs to be a recommendation on how to add a new option. Every new option needs
to be documented and not just registered. Jen Linkova: The main issue I see is
related to DNS. You start to incorporate DNS and everything breaks. Warren
Kumari: It's also what can you do with one of those options. Eric V: OK

------------------------------------------------------------------
Other Business (Open mic)

Brian Carpenter: I want to give implementation report on IPv6+++.
Fred Baker: I want to give report on implementation of IPv6-only draft. I sent
not to 6man chairs this morning. I expect updates to the draft. Warren: I think
a number of people think RFC 7050 is flawed. I'd love to hear if people think
this is dangerous. Stuart: We should either say don't do it or say how to do it
to make it work. Warren: I don't think we can deprecate it because it is widely
deployed. Jen: Just uploaded -01 version. Let us know if new version is better.
We probably need to make it clear if you're talking about discovering the
prefix or something else. Mohamed Boucadair: We have put in multiple options
and ways to discover. Lorenzo: There is no guarantee that this draft will do
something better. We're trying to do the right thing. But by all means, fix RFC
7050.

Fred: We're done.