* 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: Benoit Claise, Warren Kumari | 2002-Aug-22 —  
Chairs
 
 
 


IETF-99 v6ops minutes

Session 2017-07-18 0930-1200: Congress Hall II - Audio stream - v6ops chatroom
Session 2017-07-20 1330-1530: Grand Ballroom - Audio stream - v6ops chatroom

Minutes

minutes-99-v6ops-01 minute



          9:30 v6ops starts.
          
          Chair intro/info space
            bash: chat about john browzowski's ietf proposal
            bash: jordi show should start, but will cover happy eyeballs
            monitoring.
                  happy-eyeballs monitoring after the HEB bis document discussion.
          
          John Browzowski - Dashboard.meeting.ietg.org presentation/discussion
            representing authors for  draft ()
            V6 only incremental deployment experiment, with v4 support as
            necessary.
            restarting the old v6 only experiment, using v4 help this time.
            conversation has been ongoing since Seoul meeting, the NOC has been
            helpful.
            production hardware and software updates to support v6 only with
            dns64/nat64
              on the main ietf SSID.
          
            Looks like ~5% of total use nat64 SSID today...
          
            Proposal: "Organize trial nat64/dns64/v6-only SSID for IETF meetings,
                       going forward."
          
            Community support is required/wanted here too.
          
            jimmartin: all of the SSID's are v6 enabled, there are v6 only.
              Putting middleboxes in, does seem against our goals though?
              With other options available, however, this shouldn't be 100%
              problematic.
          
            john: noting that this isn't "breaking" things, there are some bugs
            which
              will be found... and we SHOULD be able to do this still.
          
            jenlinkova: users sometimes make mistakes in their ssid selection...
              users CAN use nat64 SSID.
          
            warrenkumari: ietf/ietflegacy exist, people CAN just join the nat64
            if they
              want...
          
            john: but ietf is the default... so let's move that forward.
          
            jordi: i'm pro ipv6, the point though is what? detecting broken apps?
          
            john: to make the network 100% usable for all users, to remove barriers
            to
              deployment.
          
            jordi: Trying to find broken apps/etc, the only way forward is to force
              the hand, but to do that with some automation, not people.
              People won't report as often/reliably as we want, automation can
              though.
              Extra question, for jim: "how many reports on nat64 network?"
          
            jim: 2 tickets open... one from john, one from jordi.
              wiki page being opened, and feedback to a10 to fix problems as well.
          
            lorenzo: disagrees with jim - the only deployment model that's
            available
              is the nat64 and dns64. We should move forward, not backwards. We
              should
              make sure that the network is supportable and operable, finding
              systems
              problems and bugs SHOULD be a goal.
          
            jim: key here is: "what is the network objective?"
              1) facilitate work by users?
              2) ideology and vision?
              NOC goal is: "making the network work successfully, so people can
              do their
                jobs"
          
            john: this should be a community decision. don't want to strand folks,
            always
              keeping a fallback so users can rollback if required, if things are
              broken
              for them.
          
            jim: note that the legacy99 SSID shows people CHOOSE the legacy choice.
          
            dave@apple: in automating issue detection: "this would be good, but..."
              apple made some iphone v6 only (no xlat), and tried to build in
              automated
              alerting, such that the cell network could know: "send me v4, your
              v6 is
              busted" Trying to figure this out is ... hard. very hard.
          
            jordi: goal is not detecting the root-cause, but to take some initial
              packet dumps and use that to debug later.
          
            dave@apple: this isn't enough, and operationally this is still quite
            hard.
          
            <>: supportive of moving to this new world. question to jim: "what
            effort is
              it to turn off the ietf network in a particular WG session?"
          
            jim: This is possible, but this will require coordination (rebooting
            aps),
              and there should be note that APs bleed between rooms.
          
            : maybe change ietf instead of legacy99?
          
            jim: eliminating ietfssid could be the goal? rename to
              then make users choose... see what they choose?
          
            jenlinkova: probably folk are saying: "we are not ready to move"
              when will we be? what's the bar?
          
            warren: this room is a pretty biased group. Find the whole community
            instead?
          
            john: is IAB useful as the representation?
          
            joel: got upset about characterizations of changing here... we NEED
            to ask
              the community that's where the decision needs to come from.
          
            resolution - Fred moved to the nat64 network.
          
          Marcus Keane: Turning IPv4 off in an Enterprise network
            "be nice, this is my first time!" - is corp network engineer/architect -
            MS
          
            ipv6 only enterprise networking - why? status/plans? issues? major
            challenges?
          
            MS enterprise network is ~100 buildings, then three other regions,
            moving
            things into the clown NOT local DataCenters.
          
            Most remote networks - MPLS vpn served.
            800 or so locations, and 1.2m devices, so things move a bit slower at
            times.
          
            Dualstack is enabled everywhere already. Why v6 only?
          
            Exhaustion of v4 addresses, overlapping space (acquisitions, azure,
            etc)
            complexity of dual-stack... this is hard/expensive.
              2 igp, acls, firewals, etc :( sadness
              iot demands now coming around to get you as well.
          
            Testbed deployed, has guest/wired/wireless networks, is opt-in, but
            plan
              to make this default 'soon'.
          
            Automation of fault detection is rougher than we want. There are
            problems
            in dualstack as well.
          
            Guest-netowrk issues - on v6only guest .. things SHOULD be simple,
            they are
              not. there's also vpn, not just web/mail, bummer. vpns are the devil.
          
            Some device problems still exist: rdnss, wireless controller issues,
            etc.
          
            With new building configs, you may be abl eto deploy better/more
            network/telem
              etc. you still need better telem than we have, however.
          
            Multihoming is a bit more complex here as well. Making tail sites work
            out
              is harder. With 'internet first' corp goal, How do you multihome/etc
              with internal prefix and ISP prefix?
              Policy routing as a suggested path, however operationally very hard.
              Source selection is still problematic, still.
          
            Drawing slide about networks and displaying the branch office problem.
              note that hosts will choose the wrong address, at times, which
              stinks.
              what if the corp resource is in the AP prefix, not the NA prefix? on,
              ISP?
                wrong. :(
          
            options evaluated:
              nat66? hard, not supported yet everywhere.
              use isp space only - import to your internal network :(
              your ip space only - requires other resources (public as, ebgp, etc)
              :(
              using the mix seems correct.
          
            Looking at draft-ietf-rtwg-enterprise-pa-multihoming to help with this
            problem
            Also, conditional RA draft-linkova-v6ops-conditional-ras - may help?
          
            Really though, the clients must be more intelligent, they are
            not. (today).
          
            Provisioning Domains are required
              different administrative network domains reachable on the same
              segment.
              prefixes, sources and dns zones all would be part of the config here.
          
            Image of previous problem, now with 'provisioning domains'
              shows ra0/ra1 givng routing and dns data to the clients, with nexthop
                targets
          
            dualstack is hard, v6only has to be the goal long term.
            problems still exist in the v6only world, still need solutions to be
            found
            multihoming really has to be sorted out.
          
            note that there are v6 stck updates in win10-creator... you should
            check those
            out.
          
            Questions:
              ekline: will MS do provisioning domains?
              thaler: yes
              lorenzo: "slide with provisioning domains" - we should do this,
              a lot.
                multihoming wihtout scalability issues and nat ... are solved here.
                "What can we do to help?"
                "What else is missing?"
                "Are your designs/goals written up? we should do that if not"
              thaler: "making progress how?" - If you have enterprise networks
              with this
                problem - send mail to thaler.. .so more customers and more push
                behind
                the solution.
              jenlinkova: can you share experience with percentusers have to
              fallback to
                v4? Was there support problems?
              marcus: we enabled v6 only for particular product gruops and IT.
                we are more inclined to work through problems, other groups may
                not be?
              timchown: node-requirements doc should be including 5.5 support text.
                is this wrong? should we add something else?
              jenlinkova: dhcp can't do this, RAs are the only place to do this
              correctly
              lorenzo: no such methods from myth?
              thaler: maybe 5.5 should still be included ...
              lorenzo: not that 5.5 is a hack, but that relying on 5.5 for this
              is hacky.
          
          Vaibhac Bajpai: A Longitudinal View of Dual-stacked Websites: Failures,
          Latency and Happy Eyeballsk
            joint work with samknows folks
          
            There's less study on v6 performance, lots of study on adoption.
            since 2013 this study has run to try and show v6 performance.
              at start 1% (by google numbers) now ~15%!
            utilize samknows probes (about 100) from 66 origin asns.
            most measurement from residential networks
            Drift of v6 deployment is increasing, mostly on weekends though.
            teredo and relays usage is dropping.
          
            notes about blacklisting efforts for v6 nodes, some prefixes will not
            get
              v6 AAAA answers from (at least) google.
              largely in japan/malasyia, peru - btw.
          
            adoption at the server-side is increasing, notable events at:
              w6d, w6ld, cloudflare publishing v6. (last was HUGE - 10% of alexa1M)
          
            Failure types, sometimes failures are silent, because happy-eyeballs.
              will be useful for v6only netowrks.
          
            Results:
              complete failures - alexa1m graph looks the same as the adoption
              graph.
                40% in 2009, 3% today.
              alexa ranking for the 3% failures, are in the 100k rank... less
              popular
                sites tend to be more faliure prone.
              6 most popular, and less than 100 on rank, still fail,why?
              bing.com, detick.com, engadget.com, nifty.com, qq.com, sakura.ne.jp
                ... monitoring for aaaa, rquired as providers tend to add/remove
                aaaa
                over time.
              sites from w6ld have disappeared, maybe the site is just gone? (v4
              and v6
                broken) 1%
                8% v6 only.
              Partial failures:
                notes about even after w6ld, still sites which have aaaa have v6
                failures
                root-cause can be: not having aaaa in dns?
                  css, javascript, images .. often these come from in-domain other
                  sites
                  without AAAA.
                  these will be broken pages in v6 only networks.
                same-origin and cross-origin examples discussed.
                sometimes this is the CDN nothaving all AAAA for all parts of the
                sites.
          
            Latency:
              over time, v6/v4 have become equivalent, or closely so.
              initially missing CDN v6 support could have been the cause.
          
            Today's latency state:
              40% are v6-faster
              94% are ~1ms slower
              mostly large-cdn providers are v4/v6 enabled, showing these results.
          
            Happy Eyeballs numbers: (where HE timeout was a factor)
              many v6 prefer over v4.
              sometimes this is even when v6 is slower.
              pushing back into ietf a timer change for HE, move from 300ms to
              150ms.
          
            dave@apple - want input for 6557 bis update.
          
            jordi: 1) samknows no longer uses tplink, can the HE monitoring code
            still
                       work?
          
            presenter: yes, still works fine.
            jordi: 2) only 1% latency increase over 100ms?
            presenter: no bias, generally native only...
                       tunnelbroker stuff should be outliers...
            jordi: 3) only HE is being monitored?
            presenter: yes.
          
            stevenstros: measuring content on yahoo on v6 is mostly 'actual
            content'
              with ads slower... which is why failures for yahoo were shown this
              way.
          
            leehoward: previous experience shows that in fact with no v4 .. no ads.
              there was a 150ms proposal, this sounds like a point-in-time number.
              should this be something that is more responsive? or will it stay
              constant?
          
            presenter: the timer here is 'when we can disable v4' - when HE timer
            is 0,
              no v4 required.
          
            dave@apple: apple uses some other measure to do the timeout value...
              apple has been increasing the timer, not decreasing.
              because they want to prefer v6... over v4.
          
            presenter: questions about HE timers purpose.
            dave@apple: increasing forever is silly. but making it to ~500ms, that
              might be useful, still.
          
            lorenzo: 300ms was chosen because 250ms timer also existed.
              the intnetion was for the choice to prefer v6, but still make things
              work
              for users. setting the timer to 0 means 50% ipv4 usage...
          
           Lee howard: IPv6 Deployment Status
             'state of v6-only' ?
             Total adoption (to google perspective) == 20% ish.
             Pay attention to the weekend jump - enterprises are lagging.
          
             network operators deployments still doing well.
             interesting skew in numbers per country...
             sept 2019 we may have 50% coverage! woot!
             notes about US based deployment - showing some 90+% ... but with bad
               performance?
             noting some facts about v6 only asns? there may be parallel v6 as
             and v4 as?
             v6 only initiatives - many folk talking... there's still going to
             have to
               be translation services.
             reasons for v6 - simplicity, cost, etc.
             summary: enterprises lag :(
          
             jenlinkova: data for locale ...
             lorenzo: the weekend swing is .. hard to explain.
                      2018 could be the 50%?
             george: 2021 could be the 50%?
             jordi: predicts 2020 70% ...
             mikael: v6only networks aren't really v6 only.
          
          RussWhite: Requirements for IPv6 Routers
            draft-ietf-v6ops-ipv6rtr-reqs-00
          
            Outlines of changes...
            Lots of new text on ZTP.
              DHCPv6 required as well as SLAAC
            Needs data/support on DDoS requirements too.
            next-step: more comments/suggestions please.
          
            daveplonka: invite to thur meeting - about icmp limiting discussion.
            jameswoodyatt: doc should use more suggestions: "should this also talk
              about 7934? multiple-address support?"
            lorenzo: on dhcpv6 requirement - client ? server? this should be more
            clear...
          
          Dave Schinazi: Happy Eyeballs Version 2: Better Connectivity Using
          Concurrency
            Main differences to fix in new draft:
              asynchronous DNS problems.
                AAAA and A queries have to go out and get back before tcp starts.
          
              new doc: fire tcp as soon as dns returns, for each family
              individually.
              also include some limits on how long to wait for dns replies. (50ms)
              include some new rules as well for address-selection algorithm.
                prefer based on rtt as well?
          
            new section on nat64/dns64
              there are 3 issues to deal with here:
                1) ipv4 literals - synthesize v6 addr.
                2) hostnames with buxted AAAA - wait ~2s, then query A and move
                forward.
                3) vpn with dns tunneling - do the literals trick, basically.
                   (see doc/slids)
            limitations:
              PMTUD - HE can't know this, since it ends with syn/synack/ack.
              application-layer
              operational issues
          
            next steps:
              addressed/ing comments
              apple implementation deployed
              wglc question? (is there more feedback or?)
          
            jordi: tracking mss, is that a thing you should do? (for pmtud
            problems)
            lorenzo:
            mikael: pmtud discussion - was there feedback from content folk about
              how extra-load/etc HE caused?
            nabil: timer questions - 15ms is this based on some sciencey thing? or?
            dave@apple: we used empirical data from real devices in the
            field. science!
            thaler: this doc should be std track.
          
          13:30 Thursday 20 July 2017
          
          --
          
          Reporting of Happy Eyeballs v2 Failures
          2017-07-03,
          Jordi Palet Martinez
          
          Fred Baker: We don?t define protocols here. This belongs wherever syslog
          work belongs.
          
          Waren Kumari: Asking for a well-known anycast address is not really
          defining a protocol.
          
          Eric Vyncke: What is the incentive for anyone to implement and/or deploy
          this?
          
          Ondrej Caletka: This won?t work without NAT64 Jordi Palet Martinez:
          This does not need NAT64 or DNS64
          
          Ondrej Caletka: This will interact badly with lingering uses of 6to4
          Jordi Palet Martinez: But 6to4 is deprecated Waren Kumari: That doesn?t
          mean no one is still using it
          
          Waren Kumari: There?s a big DOS vulnerability here
          
          Jen Linkova: I see very limited use for this. Perhaps within an enterprize
          network.
          
          David Schinazi: Syslog messages of IPv6 failures may have serious privacy
          implications Private web browsing may not be private if your client
          device is logging failures into an unknown syslog server We should not
          try to integrate this into RFC6555bis; RFC6555bis document is almost done;
          this still has a long way to go
          
          Mikael Abrahamsson: The idea here sounds useful, but there are a lot of
          details to work out
          
          --
          
          Considerations For Using Unique Local Addresses
          2017-03-13 ,
          Bing Liu
          
          Merike Kaeo: Why are we even discussing ULAs?
          
          Fred Baker: A ULA is a firewall rule implemented in BGP I don?t understand
          the opposition to ULA
          
          Lorenzo Colitti: ULA can create a false sense of security If you?re on
          an adjacent network, just because I don?t advertise a route doesn?t mean
          you can?t send a packet to me
          
          Erik Kline: Good that the document states that ULA addresses are not
          RFC 1918 addresses
          
          Document needs to say ULA + NPTv6 is ?not recommended? or ?NOT
          RECOMMENDED?
          
          Tim Chown: Many people do seem to use ULA without trouble.
          
          Ronald Bonica: This document can be shortened to just a couple of pages.
          
          Victor Kuarsingh: I agree: Document needs to say ULA + NPTv6 is ?not
          recommended? or ?NOT RECOMMENDED?
          
          Lorenzo Colitti: Lots of existing walled gardens work fine using GUA
          global addresses
          
          Tim Chown: UK universities are creating ULAs manually, instead of
          including the random part
          
          Victor Kuarsingh: I agree with Lorenzo.
          
          Marcus Keane: We find it?s better to use GUA global addresses instead
          of ULAs
          
          --
          
          Using Conditional Router Advertisements for Enterprise Multihoming
          2017-06-14 ,
          Jen Linkova
          
          Fred Baker: I?m trying to work out how to implement this
          
          Timothy Winters: Why not use route information options?
          
          Jen Linkova: Not all platforms support RIO
          
          David Lamparter: I support this and plan to implement it Do the policy
          rules need to include more than just checking the routing table?
          
          Tim Chown: Could some external device monitor the network and send
          commands to the routers?
          
          Jen Linkova: It?s better if the routers do this detection for themselves
          
          Lorenzo Colitti: It is useful for us to document the current behaviors
          of today?s hosts which may have software from ten years ago.
          This is what operators need to know.
          
          Waren Kumari: Most implementations do VRRP tracking already, so this
          could be done in a similar way.
          
          Thaler: What if both uplinks are down? Leave both deprecated.
          Both addresses still exist; they?re just not preferred.
          
          Mikael Abrahamsson: There is prior art here.
          RFC 7084 talks about what to so when WAN link goes down.
          The Homenet code already does something like this.
          
          Timothy Winters: We should add RIO too, for future hosts that support
          RIO.
          
          Mikael Abrahamsson: I would like to see more work on the control plane
          
          Jen Linkova: This mechanism is independent of the control plane that
          controls it
          
          Darren Dukes: How fast is the propagation?
          
          Jen Linkova: That?s hard to say right now because of vendor bugs.
          
          Pierre Pfister: I support this. This work is compatible with RFC 7084
          and Homenet work.
          
          Lorenzo Colitti: Helping to get vendor bugs fixed is a good reason to
          publish this.
          
          David Schinazi: I like this work and support it.
          
          Fred Baker: Call for hum on adoption
          
          Reject outright? Silence
          Consider later?  Weak hum
          Adopt now?       Strong hum
          
          --
          
          Requirements for a Zero-Configuration IPv6 CPE 2017-06-17,
          Fred Baker
          
          Bob Hinden: The router I have is less of a horror story
          
          Timothy Winters: We should make having IPv6 enabled by default a
          requirement for using the ?IPv6ready? logo
          
          Barbara Stark: The only significant IPv6 success stories are when the
          ISP provides its own home gateway, already configured correctly
          
          Jordi Palet Martinez: Look at RFC 8026
          
          Lorenzo Colitti: The document is overly detailed.
          We want implementers reading and complying with RFC 7084.
          
          Hans Liu: D-Link is working to improve this issue
          
          Victor Kuarsingh: I have never seen a router that comes with IPv6 enabled
          
          John Jason Brzozowski: We should include a specification of what a router
          should do if it gets no IPv4 address.
          
          Joseph Abley: D-Link currently has a line of 31 different home gateway
          models, all with IPv6 enabled by default
          
          Barbara Stark: AT&T-supplied home gateways do IA PD.
          
          Mark Townsley: D-Link was involved with World IPv6 Launch in 2012.
          Initiatives like that are needed, not only more RFCs.
          
          Fred Baker: What are next steps? Sorten the document?
          
          No specific actionable conclusion was reached.
          
          --
          
          RFC 7984-bis in four parts
          Basic Requirements for IPv6 Customer Edge Routers
          2017-06-12 ,
          Transition Requirements for IPv6 Customer Edge Routers
          2017-06-12 ,
          Minimum Requirements for IPv6-only Customer Edge Routers
          2017-06-11 ,
          Basic Requirements for IPv6 Customer Edge Routers with HNCP
          2017-06-11 ,
          
          Jordi Palet Martinez
          
          Barbara Stark: We should be wary about updating RFC 7084 unless we really
          need to
          
          Timothy Winters: S-2 (ingress filtering) was a ?MUST? in RFC 6204,
          but got downgraded to ?SHOULD? in RFC 7084.
          We should revert that to ?MUST?
          
          Mikael Abrahamsson: I agree with Barbara Stark.
          We should not update RFC 7084. We should have a new RFC for transition
          mechanisms.
          
          



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