Minutes IETF98: v6ops
minutes-98-v6ops-01

IPv6 Operations - IETF 98
Wednesday 2017-03-29, 13:00 US Central

Administrivia
    Note Well, minute takers, jabber scribe, agenda bashing,
review of WG docs and browbeating authors for promised revisions.
Charter discussion
    Should v6ops explicitly ask for discussion of IPv6-only networking?

Requirements for IPv6 Routers
    2017-02-18, <draft-ali-IPv6rtr-reqs>
Basic Requirements for IPv6 Customer Edge Routers
    2017-02-27, <draft-palet-v6ops-rfc7084-bis>
On the Dynamic/Automatic Configuration of IPv6 Hosts
    2017-02-27, <draft-gont-v6ops-host-configuration>

Possible talks given time:
An Update to Happy Eyeballs
    2017-03-08 , <draft-pauly-v6ops-happy-eyeballs-update>
Proposals to discover Provisioning Domains
    2017-03-13, <draft-bruneau-intarea-provisioning-domains>

Draft Status
    https://datatracker.ietf.org/wg/v6ops/.

Chair - Charter
Low attendance for previous IETF IPv6 working group
IPv6 only operations links (cites HE report of 360 v6-only ASN visible in BGP,
28,000 prefixes behind v6only operation) should we have IPv6 only operations
contributions (deployment case studies and experience) - companies using IPv6
network IP in 2017 is about enterprise networks, content provilders, datacenter
operations, residentials, IOT etc.; should we invite contributions from them?

    Calls for WG feedback hum
    Tim Chown - broadly supportive
     from UK academic context
    Joel Jaeggli - doesn't neccesserily mean all the work is associated with v6
    only networks. e.g., only v4 authoritatve NS although running dual-stack.
    So, things in mature environments which have to be done to get to v6only
    Prakash Suthar (cisco) - support this

Proposed charter is
https://www.ietf.org/proceedings/98/slides/slides-98-v6ops-proposed-charter-discussion-00.pdf
and the actual document with track changes is
https://www.ietf.org/proceedings/98/slides/slides-98-v6ops-proposed-charter-word-track-changes-00.pdf

Fred takes room "hum" as broad consensus to proceed with charter modification
as documented (see list) asks for market addition.

   Tim Chown - one sentence bullet, what would it be?
   Fred: list of markets as shown here. but discuss
   Jordi Palet - what is difference between market and scenarios, struggling.
   write down some text, then have a clear idea Fred: may be using different
   language for same thing. Eric Kline - is there text in charter precludes or
   ... Fred: want to be more explicit. RFC1812, various docs, proposed to be
   like that for -NG, were addressing hosts and ISP only
    more difficult discussion on mailing list: 'in my market, important to do
    <x>' somebody else 'in my market, that would be stupid' Wondering,
    questioning if can take the heat out of the discussion, by segmenting by
    market
   Eric  hard to avoid exhaustive list, etc.
   Warren Kumari - not precluded. v6 internet, if you look at it, implies more
   ISPs, changed the tone. no strong view on environments, markets &c John
   Brozowski (comcast) - had a conversation with Lee about this from RTGAREA,
   projects in this space, transcend different segments. 'marketizing' is
   overkill, they are uniforn problems how to configure a router, measure it.
   basic blocking and tackling things which need to be tackled, should be
   focussed on. bucketizing it more elongates the process. things to look at
   out there. James Woodyatt. (google) don't see any particular need to do
   this. floating out there always deal with always have. Mark Townsley -
   careful, if change one, in IPv6 networks, then have to change IPv4
   (wordsmithing) and some nits on -network-ing not network-s
Fred: sending this charter revision text.

Router Requirements
John Brozowski. Draft is https://tools.ietf.org/html/draft-ali-IPv6rtr-reqs
Deck is
https://www.ietf.org/proceedings/98/slides/slides-98-v6ops-requirements-for-IPv6-routers-00.pdf
    Idea of changes in the network architecture. suggestions from providers to
    implementers, around IPv6 support. explores jumbo MTU/large packets seeking
    WG adoption, feedback and questions

   Tim Chown - rfc6434 node requirements update to keep in sync. only one
   section significant difference is good news. Section 3.3: SLAAC is a SHOULD
   not a MUST. Definitely? John I think should be MUST will talk to Russ. Tim-
   another is a SHOULD be enabled, same thing? Fred: Xing Li, doesn't wnt SLAAC
   on his network, so poses what this means. Tim: Link-local or global? nothing
   said about global addresses?
    <unknown> that was my question.
   John take this to email on the ML to SLAAC, on by default is supported, A=0
   bit turns it off, so still controlled. the meta statement should be 'on by
   default' Tim overall doc good. like. Second part of Q. things to think
   about. comments about MLDv2. MUST required. RDNSS options in RA. nice to
   encourage. John with hat on, we require that to be on is a MUST. To DNS,
   well known FQDNs. moving from pull to push. contemplated router coming on
   line with SLAAC, DNSSD, search list phones home for configuration.foo,
   generic URL to fetch a config. Fits with provisioning domains in (mumbled;
   CASM?) Tim Winters. in favour. MLDv2 in lab has issues, DNS, put in there.
   John: Thank Russ, he did all the work. Ron Bonica, Juniper. support draft,
   good work easy reasing.
    some requirements are v6 specific, that's clear
    some not so specific, apply to v4 and v6. want to go there? things like ssh
    access or telnet, this is kind of scope creep. next issue. MTU and
    jumbogram. enables but doesnt mention jumbo. so we should talk: nobody does
    jumbograms. time to start the funeral
   John-or not. make it work.
    <confused mumble for bunch of people not at mic doing this offline>
   John I will confer with Russ and mailing list to fix
   James Woodyatt google.
    confused by doc at first, gen purpose routing requirements. lot of focus on
    managed routers by professional operations. not all routers are like that.
    so suggest something to clarify this is about managed, scale routers, so it
    doesn't confuse 'sole traders'
   John differentiate from HOMENET?
   James not the only ones unmanaged, zero-touch provisioning, implications of
   autonomous. John will ask for help to craft text here.
    secondly, ACLS in routers. like a firewall to do packet drop. should the
    ACL be subject to port control protocol. requirement named to have PCP
    servers if have ACL and have proxies.
   John see overlap with zero touch. maybe PCP is one of the post-zero config
   state tools. James blocking all inbound flows, eg residential gw, should
   have PCP for hosts waiting for incomings to register. If not a requirement,
   then like to see text   John will get back to you Dave Thaler be more clear
   if applies to CPE routers. not even referencing the existing 6204. is that
   out of scope, or what? John Fair point will reflect. Fred: requests WG
   adoption hum. strong consensus in favor

Jordi's session
slides at
https://www.ietf.org/proceedings/98/slides/slides-98-v6ops-basic-requirements-for-IPv6-edge-routers-00.pdf
    explores the lack of requirements in IETF to motivate CPE router vendors to
    code IPv6 transition mechanisms. lack is caausing small ISPS not to explore
    dualstack (only mention 6rd and DS-lite) advocates for the other transition
    technologies, code share, implementation cost, shared development elements.
    vendors won't target <100,000 unit sales to add features so precludes small
    to medium CPE sells to ISPs. Models categories, markets, 6 different
    scenarios many similarities in requirements. decides its all the same thing
    for the small router segment. Explores transition mechanism choices. revert
    to v6 only, as per RFC7064. or, downgrade RFC7084 to be IPv6 only router
    doc, and do a new transition IPv4 support document Open Q regarding FW 'on
    by default' or point to RFC6092 and just leave alone?
   Barbara Stark.
    support of 6092 is only a SHOULD and should remain a SHOULD. reason is,
    AT&T ship routers fully expect customers to put own router beyond, and
    specifically do not have any support in the box, valid use case. next
    steps: editorial corrections. memory cost for transition mechanisms.
    Adoption?
   Mukom Tamet from AfriNIC.
    consider, provision for transition mechanisms to fail or turn off
    gracefully when no longer needed. legacy protocol left on.
   Jordi: handled by ISP,
   Lee: 'turn off when IPv6' then you dont have a transition
   Hans Liu from D-LINK.
    small ISPS dont have bargaining power. dont see how going to benefit,
    promote v6 by adding transition features. Jordi small ISPs don't do
    tenders. Fred I dont see RFQ. Jordi I dispute
   Fernando Gont (remote)
     disable transition tech, should be a way, if you don't even if not using
     they increase attack surface, need option to disable, if expect v6 only
     traffic do not want this code on.
   Erik Kline: didn't see changes from 7084 section in document.
   Jordi can add.
   Erik:  Secondly all the transitions looks like SHOULD so I will cherrypick
   Jordi said this on mailing list, but heard NO on the list to MUST
   Erik: stop IPv6 inside IPv4. remove 6rd, remove the things which are not
   needed. Jordi: suggested, got pushback James Woodyatt
    support Eric, right to stop saying should implement for 6 inside 4, first
    mile links. maybe may. adopt revision to 7084. PCP language could be
    tweeked, like to see this draft do it. interested to see if anyione objects
    to adding HNCP.
   Jordi: it's in
   Jen Linkova
    also looking for CPE. cannot see mention of NAT64.
   Jordi in the CPE? would love to see.
   Jordi, see as service provided by ISP not CPE.
   Erik because requires delivery of v4 to the CPE.
   Ole Troan
    with this shopping list, unless make it have expiry list, make it hard to
    build v6 only routers in the future. long shopping list of v4 reqts
   Virgil
    working for large op, we use this even though its for small ISPs so is
    useful for big ISPs. off by default has to be in there 2086 interworking
    several to support.
   Jordi: included
    Fred take to list. clearly some interest. Take as WG draft? hum strong
    consensus; taken to list

Fernando Gont, On the dynamic/Automatic configuration of IPv6 host
slides at
https://www.ietf.org/proceedings/98/slides/slides-98-v6ops-on-the-dynamicautomatic-configuration-of-IPv6-hosts-00.pdf
     - two ways to config DNS (DHCPv6 and RDNSS)
     avoiding reliance of IPv4 based services like DHCP
    formalizing need for SLAAC and DHCPv6 in hosts.
    formalizing need for SLAAC and RDNSS in routers.
   Tim Chown - Southampton
    moving in 6man to a MUST which obsoletes this if 6434bis becomes more than
    informational. also John in router requirements so, this may be OBE. still
    support.
   Tim Winters
    DNS in the RA, for enterprise routers is not widely deployed. there is a
    gap. 7084, requirements as written, all rtr will support DNS in RA, but not
    all stateless either or statefull. clarity point change
   Fred - if only 3 in 10 routers support rdnss is this document stating a
   direction the other 7 should do? Tim: good question, not widely deployed.
   Home gateways do. Fred: do we want this in the enterprise <floor> yes. Dave
   Thaler
    similar comment about 7084. basically, seems OBE (overtaken by events).
    Mandated as MUST ok document. v6ops discuss some time ago, because both
    mandatory, no incentive get hosts to do this. want to change older hosts.
    need interop path,. router do both hosts can chose
   John Brzowzowski: drafts earlier, tried to touch on enterprise. this is
   generic. James Woodyatt, Google: DNS search list echo John B.
    as said on list, not all exciting to make dhcpv6 client mandatory. if
    cannot be dropped, want to insist we get smart in documents about when both
    available, use RA/RDNSS to the exclusion of dhcpv6 client unless nothing.
   Lorenzo Colitti, Google: would you standardize the opposite.
   James: I think I would object.
   Lorenzo: too late...
   Jen Linkova, Google:
    disagree with problerm statement.  lot of routers do, but operating systems
    can't get dns info from (thats not a problem statement heckle from Dave
    Thaler) make all hosts routers support rdnss
   Marcus Keen: post from MS on v6 only. exact problem convey info in rdns
   option router deployed had no support so why included in problem statement.
   Juliusz Chroboczek
    having rdnss if already sending is 7 lines of C with error handling, its so
    easy.
   Lorenzo Colitti google
    MUST already have RA processing or doesnt work to get off link. not
    useful,. so have to have code to send or receive RA so miught as well add
    rdnss. stateful dhcp is not as capable, minimum 10 minute time min lifetime
    stateless dhcp request so cannot change more often. but in the home.. if we
    do then can this stateless DNS and do rdnss in ra code Deprecation path
   Fernando: Lorenzo understood but [inaudible]
   Lee Howard
    not all hosts are created equal, so have different needs. want qualified
    language about specific types of devices with generic access not purpose
    specific nodes doing very local things avoiud costs which don't fit need to
    think about multiple version support.
   Jinmei  Tatsuya
    following discussion, read draft. agreed it's an important problem.
    opinions differing. unrealistic to set specific requirements yet. best way
    foreward is just to be a problem statement let market decide
   Dave Thaler
    suspect may be right. comes up time and again, not just about dns server,
    well known arguments on both sides. ageing out hosts dont upgrade. so we
    should address new hosts issues, but consider interoperability.
   John Brzowzowski
    To problem statement. unique prefix per host thing, identified some of the
    problems here. new network philadelphia, v6only, seeing convergeance here,
    hosts and routers, supporting rdnss properly
   Fred:  time for discussion on the ML, adopt call for hum (silence)
   Tim Chown. if we update 6434, put host requirements there, do we need this?
   Fred: ok. then open to discuss on ML and progress in future if needed.

(Backup presentations if time permits)
David Schinazi, Apple: update to Happy Eyeballs
slides at
https://www.ietf.org/proceedings/98/slides/slides-98-v6ops-an-update-to-happy-eyeballs-00.pdf
    looking to see if worth reworking HE document based on experience in apple,
    large scale experiment high cost to synchronous DNS. delay, and basic
    roadblock to HE. calling for asynchronous API to be adopted for use (getdns
    api) or, use of multiple threads. packet count of the cost of doing the DNS
    fetch, incurred retransmission cost as delay. Looking into why v6
    resolution worse than v4 application of custom rules to the address
    preference/sorting function. (ensuring a v4 fallback is a quick choice)
    using stack based model of RTT estimation to make time choice of when to
    kick off the next connection waiting to find one which works
   Jen Linkova
    limit on how many DNS servers to use, eg 3 want to also provide guidance on
    implications to pick eg 3 out of 8, or balance or ...
   David we don't have that limit but yes, we should. can add to document.
   Geoff Huston
    Call it "esotropia," which means 'crossed' eyeballs.
    haven't changed TCP syn timeout. if fail exponential backof with SYNS. this
    is a high count. eg 75-3min depending on OS. 12 addresses, is long time. if
    alter the way in which, intensity of connection tasting, should be more
    aggressive about cuttong down TCP earlier, instead of state persistance.
    two dont work well for user. shorten lifetime and move on.
   David re-use the same picture, kernel stack but we dont have the backoff.
   balance timeout, dont wait less than 100ms and don't wait more than 1sec
   Jinmei Tatsuya
    long lived queries not currently documented in current version. relates to
    dynamic nature of the answers
   Lorenzo
    use getaddrinfo or be fast, cant do both.
    good for internet access,  but windows has special case hooks everywhere
    and chrome finds issues. A/AAAA fallback with search paths. leads to
    getaddrinfo()
   David modern operating systems have async dns calls.
    if not like chrome, then we need guidance. maybe punt. call the OS or say
    OS has to do this right next steps: dont like HE name. associated to
    fallback to v4. standards track depends on detail. It's just the Apple
    implementation, so may get blockage. informational is easier. if can
    genericize, can standardize.
   Fred: make document simpler by moving away to applications space
   Tommy Pauly, Co-author. want more than Apple's Happy Eyeballs doc. dont want
   to compromise on asynch dns, other things, things to do different, change
   and adopt in draft. flexible on some things. Lorenzo bar is very high. can
   die on a single issue. final MTU? hard to do in current HE. main problem.
   David feel out of scope. Lorenzo then say it's out of scope. John Brzozowksi
    Good work. as v4 properties change, things which make it work have to
    change too. happy to review. with change to v4 come changes to DNS. recurse
    properly over v6, through to authoritative. wants to see first option
    there; standards track because becomes predictable.
   Jordi Palet
    Happy eyeball is bad in general. Users don't report to ISP about what is
    failed because they don't see the failure. (John B.: that is not true).
    Stop this doc going to standards track. User should be able to tell if
    something is wrong. happy eyeball hide if IPv4 is broken.
   James Woodyatt, Google.
    interested in imporving the document. Principal value of this draft is
    better response quickly to fetch content. 15 ms timer is not different. How
    about write algorightms 15ms+additional grace timeout. Make it minimum 50ms
    as default (generally acceptable). Call it concurrent
   Dave Thaler
    Various API's. API's used are from standarda dcoument and they might not be
    latest. Austin group of 2020 ISO (??). if there is any liason. Dave can
    help out with liason. People can send API to mailing list. RFC6555 provide
    compliance to RFC (??). if there is additional general requirements for
    algorithms
   Igor Lubashev (Akamai): Good work and generally support this.
    Do not continue to use an IP that is no loger returned by DNS indefinately,
    even if you have an open socket to that IP already. The IP may had been
    withdrawn for a good reason.
   Eric Nygren
    One--this worth considering. Is v6ops the right working group? Should we
    coordinate with dnsop to see different failure scenarios for DNS?

https://www.ietf.org/proceedings/98/slides/slides-98-v6ops-provisioning-domains-00.pdf

SUMMARY OF OUTCOMES
Discuss charter on mailing list.
ADOPT draft-ali-ipv6rtr-reqs (as draft-ietf-v6ops-ipv6rtr-reqs)
ADOPT draft-palet-v6ops-rfc7084-bis (as draft-ietf-v6ops-rfc7084-bis)
ADOPT draft-pauly-v6ops-happy-eyeballs-update (as
draft-ietf-v6ops-happy-eyeballs-update) Confirm adoption of above items on
mailing list.