* 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-102 v6ops minutes

Session 2018-07-19 1330-1530: Laurier - Audio stream - v6ops chatroom
Session 2018-07-20 0930-1130: Place du Canada - Audio stream - v6ops chatroom

Minutes

minutes-102-v6ops-00 minutes



          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.
          
          



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