Minutes IETF99: v6ops

Meeting Minutes IPv6 Operations (v6ops) WG
Title Minutes IETF99: v6ops
State Active
Other versions plain text
Last updated 2017-07-25

Meeting Minutes

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

  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

  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

  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

  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

    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.

    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.

    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

  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
   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

  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)
    PMTUD - HE can't know this, since it ends with syn/synack/ack.
    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)
  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
Jordi Palet Martinez

Fred Baker: We don?t define protocols here. This belongs wherever syslog work

Waren Kumari: Asking for a well-known anycast address is not really defining a

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

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

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

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

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

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