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.