V6ops Meeting Notes - IETF94 Yokohama Chairs: Fred Baker, Lee Howard https://datatracker.ietf.org/meeting/94/materials.html http://tools.ietf.org/wg/v6ops/agenda?item=agenda-94-v6ops.html Jabber: Mikael Abrahamsson Minutes: Victor Kuarsingh 9:01 AM - Agenda Bashing (Baker) - Two major topics: Addressing (how many addresses to a host) - Part of the discussion is around discussion in NVO3 - Ask any change to agenda? No comments. Agenda set Speaker: Tom Herbert Identifier Locator Addressing with IPv6 draft-herbert-nvo3-ila Link to Document: https://tools.ietf.org/html/draft-herbert-nvo3-ila-01 Link to Slides: https://www.ietf.org/proceedings/94/slides/slides-94-v6ops-3.pdf Why IPv6 in the data center? Each task gets its own address, rather than different port number. Simpler task scheduling, service lookup ILA splits address into identifier and location, a lot like ILNP If task migrates between hosts, locator changes but identifier does not Locator: 64 bits Type: n bits Identifier: 64 bit logic endpoint of virtual node, routable to a translator (NVE) Could embed VNID in address Need to map identifiers to locators. Same problem as mapping virtual address to physical address. Need to assign unique identifiers without needing tons of DAD. Maybe timestamp. - Slide: Why IP in the DC - Slide: Forward looking benefits - Slide: Deployment @Facebook - Slide: Motivations for ILA - Slide: Solution Question [Fred Baker]: Is this a process?, One unique entity - Slide: Address Split - Slide: Network virtualization use cases - Slide: Details - Q, Dave Thaler: VNID correlate to location? Make sure it's not location based - A: Identifies a tenant - Slide: Architecture - Slide: Flow Example - Slide: Status Questions: - Q, Mark Townsley: When you mentioned you put ILA addresses in DNS?, was that for internal operation or to users (Internet) A: There are modes where users can use these as addresses (not sure how this works with Anycast, or solve those problems).Ê Addresses getting from DNS is transport as to if they are getting mapped.Ê Use Case, VMs to talk to each other.Ê Also, User sees IPv4, but running IPv4 - Q Martin Hoffmann,Ê A: The only thing that goes into DNS is a name and an address.Ê Q: Where do you place your DNS servers so they are reachable?Ê A: There are two lookups.Ê One is just DNS, second is mapping.Ê Q: DNS is not mobile, when you have these networks (place DNS instance in virtual network). A: DNS is reachable from all Virtual networks.Ê Need address to be reachable - Q, Brian Haberman: Go back to diagram slide (flow example).Ê Speaking as Int ID, this looks like Mobile IPv6, would that apply here? A: Are they encapsulated.Ê Once thing we would like to do is extension headers.Ê Any solution with extension headers needs hardware support - most NICs offload when extension headers are present. Q: ThereÕs lots of security stuff we baked into that, which you should look at because youÕll have to recreate it in your solution. Q, Dave Thaler: Security related to dash line. Mobile IP solutions related to redirect. A: Try to leverage Q, Eric Kline: You don't need to be restricted to that control plane on the Internet. Draft: Host address availability recommendation Link to Document: https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability Speaker: Lorenzo Collitti Draft: - Q, Fred, comments that Lee and I have been holding off on, is this only DC, or also residential A: So Owens commnent is /64 excessive? In 7421, you can't sub-divide a /64 as it may not work.Ê in DC you can use non-64 since you control the ecosystem (but not for general hosts and applications).Ê For other concern related to 'weak', but the authors feel it's justified - Q, Suresh Krishnan: There is text to be used inÊ - Q, Fred Templin: if you get addresses from SLAAC vs. PD, you may not need to do DAD, I would like to see draft to discuss that.Ê A: do you want sentence that says this?Ê Is there anything technical. - Q, John Brzozowski, I support this, we have similar deployment in homes today. A: Draft is to be agnostic to deployment models (if you have /64 per host, fine, if you want SLACC, that's fine).Ê Only one case in draft where there is a recommendation.Ê We are trying to avoid networks where the host ask for address space, but not getting them (avoid NAT66). - Q, Stephen Barth: In PD, nobody implements certain feature:Ê A: tried to avoid statements of "use this or that".Ê Comment: Hosts should be able to renumber. A: Function of hosts ability (make provisions to networks - Q, Mark Townsley: you are trying to say avoid NAT66, that's good.Ê Not fair to say what hosts do. A: not making a recommendation. - Comment: Eric Kline: Renumbering with DHCP.Ê If we want to renumber, do we use shorter leases.Ê (Stephen) If you do PD, then please make it a SHOULD requirement if you need renumbering.Ê A: if you chose to use PD, you need to word it correctly.Ê Made suggestion for new text.Ê What about hosts that donÕt support renumbering. Comments:Ê If host supports fast renumbering, network should do - Q, XX: at the time draft is written, implications to operator based on hosts capabilities. A: do you feel making a statement for a document that says you should allow multiple addresses should make such a statement. Response: yes if the document is informational on what options there are. - Q, Bernie Volz: How many hosts support PD, A: not manyÊ - Q, John Brzozowski, for Cable Networks, is not the target. Lowered lease times is used in cable networks, done on occasion. - Q, Bill Manning: How do you chose between a hostile and valid request?Ê NO way to determined type of request? A: If you don't have securityÊ - Q, Fred Templin: Host can act like a requesting router : A: valid - Q, Mikael Abrahamsson: keep certain detail out of the document which is operational. Fred: Is draft in sight of completion, Hum if it's close or flawed. Hum: good (lots of hums), Flawed (low hum) What we want to do next week, for those who came to mike on changes, please respond on the list.Ê What you want changed and the argument Lorenzo: Don't want to get to dead lock argument.Ê Draft: draft-jjmb-v6ops-unique-ipv6-prefix-per-host Speaker: John Brzozowski Link to Document: https://tools.ietf.org/html/draft-jjmb-v6ops-unique-ipv6-prefix-per-host Q, Mikael Abrahamsson: If you are bridging, everything behind the device looks like one device?Ê If I have a WiFi that can also be a client, but can connect a physical port.Ê A: If you have a Airport, if you bridge from front to back, each device behind it would get a /64.Ê A: The GRE tunnel is from operator equipment.Ê Q:Ê This needs to be clarified.Ê A: What happens if someone connects to the bridge (not operator device) will get /64 Q, Fred Templin: Need more detail on use case.Ê Is mobility of a concern, SSID, and others:Ê A: We can share more details.Ê Made it so no new software needs to be loaded on host/endpoint.Ê We can talk about stuff on the mailing list (like route optimization). ÊÊÊÊÊÊÊ - AD: Joel Jaeggli, what he is describing a case study.Ê The mechanics of this like the Ò30 APs in my buildingÓ donÕt belong in the draft.Ê Fred Templin: Separate document describing the details of the use case. Q, Lorenzo Collitti: I think this is great.Ê This should be a full case study (a model how to do IPv6 on WiFi) and want this as BCP.Ê We do have a problem with IPv6 on WiFi - like SLACC and related issues.Ê Lots of work to manage issues on WiFi.Ê A /64 is really good. A: We did promote this as BCP, asked to share information.ÊÊ Q, Ole Troan: In 6man, we had work on energy efficient ND. Q, Fred Templin: with the A/O bit values (non exclusive access to prefix) Q, Lorenzo: put more text around the advantages you get A: donÕt want to state assertions. Steven Barth: Need to say something about roaming. Switching between multiple APs in range. MTCP and QUIC arenÕt rolled out yet. JJB: We talked about it on list. We have unlimited roaming off, because APs are L2 bridges. Sometimes you do get Roaming on, connections may break for L3.Ê A: Fred had exchange on this matter on mailing list. Chair: Fred, two possible futures.Ê We have several calls for WG for whatÕs a good way to do WiFi Networks.Ê Do folks want this draft to be a WG draft.Ê One hum for no, some for yes.Ê John would you be willing to take this as a guidance draft. Draft: Observations on Dropping of packers with IPv6 extension headers in the real worldÊ Speaker: Fernando Gott Link to Slides: https://www.ietf.org/proceedings/94/slides/slides-94-v6ops-6.pdf Link to document: https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-in-real-world Q, Jen Linkova, On this document, a grey area if you are filtering header 0, if itÕs intention or unintentional drop.Ê How should this be phrased (i.e. HW limitation) A: given options, itÕs intentional.Ê Not that it was meant to filter, but it describes the occurrence. Jen: intention is if you want to specifically deny a certain filter action, but not if itÕs due to HWÊ Q, Jen Linkova: I am not clear about the message. A: the recommendation is that it should be improved.Ê Jen, I donÕt have issue with packets going to slow path, as long as itÕs not impacting control plane IS-IS, BGP, etc. Q, Lee, jabber room comments regarding intent Q, Bob Hinden: you paint this with a broad brush, not sure what the goal of the draft is. A: didÊ Q, Warren Kumari: There are a lot of people who drop packets based on not expecting it (ESP).Ê Fred: is that intent or collateral damage. Warren, thatÕs intent. Q, Jen Linkova: There are two things here.Ê First is based on what I expect (i.e. middle box, or firewall).Ê If I am intermediate ISP, if I drop this, it should only be based on if customer wants this behaviour (drop EH) to occur. A: this is not stated the way Jen described it. Q, Tom Herbert: There is alternative to use Flow Labels.Ê Would it be wroth while to mention this? Yes.ÊÊ Chair, Lee, I canÕt tell if this is something the WG wants to work on.Ê Is this something we should work on (hum - a few).Ê not work on this (no hums).Ê Keep working on this Fernando. Comments: Bob Hindon, related discussion in 6man, related to Extension Header use. Comments: Fred, as author of draft mentioned by bob, please comment. Draft: IPv6 Design ChoicesÊ Speaker: Philip MatthewsÊ Link to Slides: https://www.ietf.org/proceedings/94/slides/slides-94-v6ops-7.pdf Link to document: https://tools.ietf.org/html/draft-ietf-v6ops-design-choices ÊÊÊÊÊÊÊ Q, Lorenzo Collitti: You missed the only option that works, source/dest routing.Ê A: is that available today?Ê Q: not all these work.Ê #1 does not work (for everyone).Ê #2 works (renumber at night), #3 does not work for app breakage.Ê We do not have solution for this problem for some deployments.Ê A: summarizes that an enterprise cannot deploy IPv6,Ê Lorenzo: all deployments will have some challenges. We should work on real solution (all these options are not viable).ÊÊ ÊÊÊÊÊÊÊ Fred: you said that src/dest needs to work.Ê related documents have not been adopted.Ê push back that dest is sufficient.Ê Should we make note to AD in that area. ÊÊÊÊÊÊÊ Fred: hum on statement for WG to send the note:Ê hum for yes, send note - many hums.Ê NO hums for no ÊÊÊÊ Q, Jen Linkova: We need another design option, if we are enterprise and do IPv6 today, what are my choices. A: you want to get PA for one provider, but advertise by the other provider? A: what can people can do today, not about 5 years for now. ÊÊÊÊ Q, David Lamparter: This is missing on how those addresses are being deployed.Ê Assume Enterprises deploy statically. ÊÊÊÊÊÊÊ Q, Dave Thaler, wants to support position on documenting what can and cannot be done today.Ê Here is the problem statement, A: just documentÊ ÊÊÊÊÊÊÊ Q, James Woodyatt: I donÕt like choice number 3. There are not places #3 is better then #2. A: only a small number of PA host changes. James: Multihoming is not that difficult.Ê Issue with embedded nature of PA space being embedded.Ê Con for similar to IPv4.Ê ÊÊÊÊÊÊÊ Q, Igor Gashinsky: I have an issue what we have today, and not documenting that its bad. A: everyone should do #1, or wait?Ê #2 works fine until you use ULA then it gets murky.ÊÊ ÊÊÊÊÊÊÊ Q, Jen Linkova: I agree when we publish this as RFC, people will read it for a long time.Ê Make sure we document that some options are not a good idea. Clarification on PA/PI options.ÊÊ ÊÊÊÊÊÊÊ Joel: what you are dealing with local Regional assignment policy.Ê Attachment cost should be low if you are small.ÊÊ ÊÊÊÊÊÊÊ Q, Erik Kline: I wanted to make observation, the routers of the Internet today, are not ones of 10 years ago.Ê Should we thinking about changing address dissemination. A: router table sizes. ÊÊÊÊÊÊÊ Joel: we canÕt solve this problem today ÊÊÊÊÊÊÊ Q, Lorenzo C: Use #1 until src/des is ready. A: agreed ÊÊÊÊÊÊÊ Q, Christian Franke: draft should make it apparent that #2/3 is inferior to #1. ÊÊÊÊÊÊÊ Q, Lorenzo C: remove #3 from the document. A: document is to show what the options are.Ê Lorenzo, make guidance that NPT is a bad idea (option #3) ÊÊÊÊÊÊÊ Fred: there are enterprises who are looking at NPT66 ÊÊÊÊÊÊÊ Q, Mikel A: recommendation use PI, or PA and renumber.ÊÊ ÊÊÊÊÊÊÊ Q, George Michelson: There are implications generating a table about these options (with moderate language).Ê Language should say ÒdonÕt do thisÓ.Ê A: we should say these are the choices, today with mention of future options. ÊÊÊÊÊÊÊÊ Q, Wes George: We are arguing something that is not related to this draft.Ê People regard NPT66/NAT66 is a bad idea.Ê Solution to that is declare those techs are historic. ÊÊÊÊÊÊÊ Q, Shin Miyazawa: there are other options not shown here.Ê Difference between NAPT66 vs. NPT66.Ê There are already implementations, do we tell those companies not to do that?Ê We should have opinion neutral table. ÊÊÊÊÊÊÊ Q, Lorenzo Collitti:Ê NAT44 had a different commercial reason - ISPs charging for IPs. A: we will present this table like ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ Chair: what is the guidance for authors. ÊÊÊÊÊÊÊ Q, Dave Thaler.Ê Of the three options.Ê we should show #3, but say itÕs a bad idea.Ê Also can put a table that NAT66 is a bad idea and like technologies ÊÊÊÊÊÊÊ Q, Shin Miyazawa:Ê support for LorenzoÕs draft.Ê We should not charge for IP addresses. ÊÊÊÊÊÊÊ Q, Bob Hinden: need clarity for enterprise types. Slide: Change #3 Survey (1of2) Slide: Change #3 Survey (2of2) ÊÊÊÊÊÊÊ Q, John Brzozowski: was this a progression, or a point in time - define the trend. Slide: Change #4Ó ÒPrivateÓ addresses --- Afternoon session --- Draft "Design Choices"Ê ... presentation continued from the morning session Note: Slides updated for the afternoon session Slide "Update after morning discussion" Slide "Moving forward" Based on morning discussion, authors will rewrite section and remove references to IPv4 and private addresses. Will include comments on NAT66/NPT66 and ULA. Jan and Tim have done reviews. Will ask reviewers and critics to review next revision before requesting WGLC. Agreement reached on proposal Ê Draft: draft-bao-v6ops-rfc6145bis Speaker:Ê Link to Document: https://tools.ietf.org/html/draft-bao-v6ops-rfc6145bis Link to Slides: https://www.ietf.org/proceedings/94/slides/slides-94-v6ops-8.pdf Q, Xing Li : One of changes proposed, if there is a EH after fragment - should the translator drop packet?Ê Whats the problem? A: IPv4 cannot support any extension header. Q: if I want to support translation, do we need to use those mappings (re: algorithm)? A: this is for stateless translator - is this confusing? Q, Fred: There is an update in order regarding Extension headers. A: agreed. Q, Lee: do we LC non-working group document? A Joel: we can adopt and LC it at the same time. Q, Fred: do you want to adopt as WG draft.Ê no-hums for either option. Q, Phil Matthews: why here?Ê A Fred: no where else to do it AD Joel: we should do maintenance where ever it makes the most sense. Draft: Temporal and Spatial Classification of Active IPv6 AddressesÊ Speaker: David PlonkaÊ Link to Document: http://conferences2.sigcomm.org/imc/2015/papers/p509.pdf Link to Slides: https://www.ietf.org/proceedings/94/slides/slides-94-v6ops-0.pdf Slide: WWW Client Characteristics: Daily (Table 1a) ÊÊÊÊÊÊÊ Q, : updated happy eyeballs data, doubling of IPv6 trafficÊ A: interesting, will look at that data Speaker did a live demo on tool. Q, Erik Nordmark: compare to what it is like vs. IPv4 space. A: we were going to look at this.Ê *** Chairs to talk about status ** Lee: discuss how we prepare for meetings.Ê Discussing documents which have not had any updates recently.Ê Do we want to abandon the drafts. 1. Global Divide profile / good 2. ULA Recommendation drafts - no room participants, will take to list 3. DHCP v6 SLACC problem.Ê No conversation on a while.Ê No room participants. will take to the listÊ Ê Ê