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.