6MAN Working Group - Chicago IETF Meeting Thursday, 30 March 2017 9:00-12:30, Zurich D Chairs: Bob Hinden, Ole Troan Minute taker: George Michaelson Jabber Scribe: Tim Chown Jabber Room: 6man@jabber.ietf.org Meetecho: https://www.meetecho.com/ietf98/6man ----------------------------------------------------------------------- ----------------------------------------------------------------------- Agenda Introduction, Agenda Bashing, Document Status, Chairs, 15 min. Working Group Drafts -------------------- IPv6 Specifications to Internet Standard - IETF Last Call Summary, draft-ietf-6man-rfc2460bis , draft-ietf-6man-rfc1981bis , draft-ietf-6man-rfc4291bis , Suresh Krishnan / AD, 40 min. Active Individual Drafts -------------------- IPv6 Node Requirements, draft-clw-rfc6434-bis , Tim Chown, 15 min. IPv6 Router Advertisement Prefix Information Option, draft-pioxfolks-6man-pio-exclusive-bit , Erik Kline, 15 min. Route Information Options in Redirect Messages, draft-templin-6man-rio-redirect , Fred Templin, 10 min. New Individual Drafts -------------------- DoS signaling with Hop-By-Hop options, draft-francois-dots-ipv6-signal-option , Jerome Francois, 10 min. IPv6 Address Usage Recommendations, draft-gont-6man-address-usage-recommendations , Christian Huitema, 10 min. Recommendation on Temporary IPv6 Interface Identifiers, draft-gont-6man-non-stable-iids , Christian Huitema, 10 min. ----------------------------------------------------------------------- ----------------------------------------------------------------------- IPv6 Specifications to Internet Standard - IETF Last Call Summary, draft-ietf-6man-rfc2460bis , draft-ietf-6man-rfc1981bis , draft-ietf-6man-rfc4291bis , Suresh Krishnan / AD, 40 min. ----------------------------------------------------------------------- IETF Last Call Summary, https://www.ietf.org/proceedings/98/slides/slides-98-6man-ietf-last-call-summary- Suresh: All pretty contentious (alas) Five docs moving to Internet Standard, 3 updates, 2 elevation 'in place' (no changes) Animated discussion, lots of input, AD thanks. constructive. No real dissent to the ban on EH insertion. Looking for closure. Brian Carpenter: What people do in their own networks is their own business. Leave the door open to safe EH insertion inside a private domain. We should be practical and realistic. Have text. Propose extending introduction to make it apply internet-wide. The most basic protocol of all (IP) should state, will take to list. Robert: insertion is ok. in my own DC, or provider inside. based on this, clearly stated in doc, forbidden. doc is 20y old Suresh: cannot do things about private domains like a DC we're not the protocol police. this is about interoperability. If do insertion, somebody needs to explain whats going in. Robert: feel this is inconstant. Stephano: Always see this on ML "use encap" wrong to put encap in front, or in place of EH. Not only IETF for e2e also defines for control., bandwidth, intra-domain. here in the same situation. publishing something we may need to amend soon. Since updating 20yo document, knowing there have been changes, lets take the opportunity to fix things. Suresh: have examples, bring them to the document. Lorenzo Colitti: Disinterested comment, support the position 100% that this can (and should) be changed. Publish, if we make sensible changes, then change, standardize, done. we do this all the time. this is just a reflection of whats been done since 20y its state-of-the-art. Ahmad: 20y can wait 3-4 weeks Suresh: unless planning for 3mo develop, then thats impeding Lorenzo: write what you want, evaluate, use, and if not appropriate, scope it. Advance the document. Michael Richardson: Like Brians proposed statement. Some words badly chosen, impede progress of the document because of the applicability to gov and other agencies. If we do publish still have 2y tail of testing. Regularly write docs which are internet protocol: specs, not just global connectivity Internet documents. Applaud, support. Ahmad: push to 'do something' very quickly even though we know changes coming. Doesn't make sense to push 2 weeks early just because we don't want to wait. Suresh: whats coming? the draft which is coming? Bob Hinden: this is not just a 2 week new draft its been worked on for years. Mark Townsley: its not on the telechat agenda for a couple of weeks. Suresh: do not want delay. Mark: floor is open for discussion. John Leddy: don't understand the impact of the language, to summarize. Vendors can implement insertion, Operatiors can implement inside their domains. Any WG/STD considering insertion. Suresh: 2460 goes through, then.. some other group can document this. John: so the impact is internal IETF process about how people can document this, align with the STD. John: what do we think this language is going to achieve as impact? Suresh: document discussed today, the WG consensus was "rough" -more than rough. Not clear-cut in the WG, and then changed in 2weeks. this is contentious for some time. Rough consensus, yes, but not just out of the blue. Mark: exactly. moving from 20y deeply questionable, now hitting IETF last call, and changes made by you, wen't from kind of iffy to -very clear SHALL NOT. That was a big change just a few weeks ago. Suresh: the WG did it Mark: the WG left it ambiguous. Bob Hinden: this is why we do IETF last call. Suresh's conclusion from this, is: make it non-ambiguous. Mark: IETF last call designed to get wider input, get other WG awareness not to make substantive change. Bob: its the AD's call thats why we have this process. Mark: same people, same discussions on IETF list as 6man list I dont think we learned anything more. Bob: but looking at other non-WG participant input, I think it was different and I support what Suresh concluded. Mark: back to my original statement. STD is a big deal, and should reflect solid consensus. This is not very solid in the community even if it was original intent of the AUTHORS. 20 of EH? no. not really deployed. Just getting into serious deployment. Leading operators of V6 deployment say they want to do this not just inside their control domain, but need this to work globally. This stuff is coming. change text before IETF last call.. maybe we didn't need to Lorenzo: can't process it without understanding it. Suresh: requires clear production to do this. Mark: I am hearing 'easy to update this document' Don't have confidence won't hear 'can't do that its STD' Suresh: bad argument, if I abandon, the same people are going to still say 'cant do this' no matter what. Goal is to remove ambiguity. This is my call. I am overriding the people who are in the rough. I unhappy take it into Appeal. I see clear consensus but its open to appeal. Lorenzo: post to list said send comments: this is it, if you don't like it, there is an appeal? Suresh: not hearing arguments to change my mind. Ole: need to move on. Mark: my reasons are on the ML Tim: I see the same consensus, I like Brians wordings, they open the door to another document in early draft, clarify why not doing encap, and how to do safely. It wont pass in weeks, will take years. my view is publish as described with Brians rev, come into WG and work through. Quite likely if worried 'cast in stone' there will be another change. Suresh: will not use text on here to block things in the future. If documented breakage emerges we will take that in hand. we do updates all the time. Find argument not productive Lorenzo: earlier point good, have useful things relying on header insertion. What we say here, is baseline for entire internet need higher bar. SR for instance, clarifying the specs, doesn't mean we cant do SR tomorrow. address interoperability issues, in the control led domain, evaluate risks, mitigate, as opposed to leaving the door open to use in the wide, break in the wide. Don't understand the problem with the text. Cannot insert EH without processing it. write things up. John Brozowski: not here to argue with it, even division of views, Q, directed at AD. overwrote using your own words, so on what information? Suresh: nobody complained about underlying issue, clarifying text on that basis, for intent always there. WG consensus was iffy but the survey, Ole/Bob did, people were ok with it, ranking different, but nobody objected strongly? Adding won't break anything. This is how I see consensus happening. I am listening for why the consensus is wrong because breaks, concrete thing, sustainable from 2460 but not this -bis, then I know my technical decision is wrong. John: My view of your responsibly is big decision, controversial, so your job is "do homework" and "talk to people" need to be seen to talk, not happening, thats a problem. as operator, where is the conversation? spoken to them? Suresh: no, not yet. Christian Huitema: listening to the debate disappointed. See purity/practicality debate (channeling RB) reason its not deployed is not 'lack of purity' I don't care personally, but the process, needs to respect operational views. Nalini: push back on a couple of things Lorenzo said, but agree on others. People in the room, lot in the room not deployed. Talk to large enterprise fortune 500 and others, every day, and they have not, not deployed IPv6, not explored, may be doing edge translation, tell me IPv6 is deployed, to extend we like? no. Personal opinion EH are wonderful, biggest reasons to deploy IPv6, capability to do extensions, to do things, whats keeping it alive, reason to deploy for many of them. Sure, ISPs have it, wonderful, but enterprise banks insurance, to deploy, hasn't happened. Huge number of cycles in this argument can't keep up. lot of repeating. Lets move on. go ahead, revise. living document. Jinmei: like to add, argument to who is deploying EH. should also be careful about reliance on EH interpretation DNS servers assume IPv6 packet min MTU will not be blocked. in this case we don't use an EH but rely on the widely believed restriction that EH is not inserted in the middle of the network. Think this point is equally important. Support addition, Brian Carpenter clarification. Ron Bonica: Observation: reason arguing because half people in the room afraid if standardized, then impossible to do SRV6 draft because constrained. may be justified. Proposal. perhaps thing to do, go into room, with Stephano and come out with text to add to SRV6 to make legal even if this text standardized, then issue goes away. Willing to try? Jen Linkova: lot of routers in internet, already violate EH and process in ACL border router, what are we going to do. Suresh: very clear we can't constrain, Mark: this standard should reflect reality, the reality is ACLs process, spirit of text codify original wishes of 2460 authors, not enough of communication to operators. hearing this 'we are processing' then how can it be in a document if reality on the wire is violating it. Fernando Gont: don't understand why having it again. IETF LC in WG, outcome of conversation. still discussing, something we decided. dont understand why. even in the context of document published 2-3 days ago for last call finished while ago dont understand Suresh: got lots of operation text suggestions. two sides so far apart, cannot get text to satisfy the whole. Do not see consensus to move forward sending back to WG. Lorenzo: think process serves us well here, because if we can't do it, then have to do this. Agree strong divide. two camps. Should take a step back, in WG think about what we lose by having this fixed boundary. Look at arguments applying to V6 specifically, not learned from V4. dynamics of addressing are clear. 64 bits to 24 bits are huge, not just the apparent 40 bit gap. lets come up with something more encompassing, find out what we want to change. Have to do in the WG. Word smithing this text is trying to change implementation not re-design. but we have to re-design. Look to use cases. Tried to push what we cannot do with 64 which we can do with 128. Once we have those in mind know what to change. wont get that from word smithing on this document. Randy Bush: 64 is a magic number from IEEE MAC and worked until privacy. we don't need any boundaries. To clear misconception, use SLAAC all the time, think its fine. I wanted 56 but 64 is fine. RA is fine on SLAAC_RA side. DHCPv6 is fine, with router option, want to make it so customer has choice can do what they want to do. MUST language to run network doesn't help V6 but it helps NAT/CGN Pierre Pfister : text not in agreement, reason is because brought up in v6ops yesterday depends on use cases. way out, explicitly say the differences between different deployments Matt Mathis: this issue, previous issue is about tussle/paradigm gap. precedent, lays out both ideas, terminology, but need of MUST and MUST NOT for each side, both exist in the internet doesn't matter, decided in the marketplace. document both correct answers and have decision made in deployment Lorenzo: dont think we should think about this here, write use cases as Pierre said. Good outcome, time to consider the use cases. Randy has a point, Customers do what they want but we are responsible for what happens 20 year off. we're going to live with this for 3-4 decades, design for the long term. have to think about what happens in the future. Take the time. use cases. James Woodyatt: Google draft of subnet and on-net prefixes, commend the draft. distinction is important, existing draft not making the improvement I'd like to see the confusion between subnet prefix and on-net prefix. to repeat, important. on-link are a routing proto discovery. can use link or have to ask. subnet is address alloc for a host. think set at 64 because SLAAC rather not think about hosts doing other things, bound to SLAAC but people on other side, no doesn't matter what host addr config is done, 64bit IID is separate on-link prefix send to router or use ND. thats the basic confusion. still see present in current draft, long draft liberal/conservative to upgrade text. some bits the same for both options could be added, could improve I would support. Michael: echo James. all use tenbase2? use real switches? I dont think so. there IS a switch in the middle. has discovery and trace. the on-link stuff should die, layer 3 router is it. lets be clear, the layer 2 thing. networks break. thats not being on-link on-link is important. Bob: good topic to discuss. Lots of time to talk about it. Suresh: ongoing looking for text to revise, not break existing Implementors. haven't made a call yet. looking promising, yet to be seen. Bob: text coming, waiting to hear from reviewers will elicit draft. I think big improvement, old versions, TCP stuff, does it without changing proto. have to decide if IS or proposed standard. Suresh: thats the issue Francis Dupont: Suresh: next steps: telechat will put up, still open to hear from people. if wrong explain WHY: feel free to talk. Other two docs had no discussion, going to telechat. IPv6 Node Requirements, draft-clw-rfc6434-bis , Tim Chown, 15 min. ------------------------------------------------------------------- https://www.ietf.org/proceedings/98/slides/slides-98-6man-rfc6434-bis-ipv6-node-requirements-update-00.pdf Tim Winters: Node requirements update. some question for the working group. Calls for uplift of SHOULD to MUST fior DNS resolver carriage. NO OBJECTS FROM THE FLOOR, one +1: MLDv1 MUST and MLDv2 SHOULD. Dave Thaler: use case for constrained devices conformance, avoid implement cost in memory of MUST for not-needed. can argue some fixed function device to get job done must use MLD then ok, but if not, then NO not normative needed. Tim: bad implications things done to network, logic is dont do ND right in trouble Tim Chown: pit into document, general nodes, constrained nodes, can do weasel words to consider in device but doc is general node devices doc. Brian: been sending ff02::114 want them to arrive. some nets they don't arrive, because MLDv2 not supported. want MUST because I think new multicast solutions demand it Dave: fine explain put in doc. don't remember how normative in doc. Tim: there is MLDv2 lightweight, addresses this (not multicast) Dave: to scale to IoT. Ali?: wrt list of items proto removed, mobile IPv6 removed based on comments. Tim: asked if impl, not general. saw comment. not a whole lot of interest. if deployed will put back in, Ali: open source impl has been taken up to be maintained, 1y dead but now taken over and active. worth being aware., Tim: take to list Tim Chown: back in another doc ???: Also want Tim: will put back in Path-MTU. PLPMTUD support. put SHOULD Language. 1981 fall off the plate. Matt??: not sure supported in constrained implementations. Frag in constraint is dicey. Tim: can cover in doc Brian: difficulty 1) 1981 does work on many many paths, do not think should downgrade 2) 4821 is underspecified document. nonspecific language. not sure why on STDs track. needs update. SHOULD is ok but its meaningless no guidance what to do. 1981 remain mandatory until 4821 accurate Ole: think this is valid Francis: keep 1981 as SHOULD Dave: this not internet requirements this is node requirements. across LAN, switches can send stuff. backwards compatible &c need 1981 as SHOULD, requirements so can not do the SHOULD, pref is add 4821 as SHOULD keep 1981 as SHOULD for this iteration. Tim: need parts of 1981 Bob: repeats 1981 language referring to minimal impl. DHCP-PD for hosts. Francis: two comments, ppl who dont read reference RFC. uncommon term of art confused with DHC WG. session today details to change, because of new use of Prefix Delegation. some impl, strictly enforce 64 limit. maybe needs to be relaxed Lorenzo: we considered implementing, asked operators 'going to support' but the answer was .. not really. not aware of any. can't typically connect device which supports PD. typically has DSL or coax, not host friendly. do PD by default on a home network. 12 devices doing PD run out of /60. so not sure how practical. few nets support, ones which do can do damage. premature. want to support PD, ask carrier mobiles and tether, they say no. Ole: agree Lorenzo, it is premature. Have three different mechanisms if PD must be a router. So seems not host aligned. Alexander: consider yes, bit more time. distinction between host/router is a fine distinction difficult to make. Tim: say node requirements to try and stay away from that. Eric: not a WG item so can't second Q to Chairs: how much time Because Q about doc but not related to slides Ole: fit at end Fred: use PD inside corp net for airplanes and related systems. Dave: doc should NOT talk about PD. in favor of PD, but not in NODE requirements documents. wrong document. MIBS update to YANG. No major requirements keep aligned to Router Req doc Privacy Addressing. Add SHOULD to 7844 privacy profiles Dave: support for MUST if support privacy addresses. if impl. Bernie: profiles issue. maybe point to it, say IF device may be mobile, privacy is considered strongly Lorenzo: think say devies which identify Users, mobile devices, pervasive monitoring suggests should be doing but dont know if consensus MUST can we do that? on by default? hearing Dave: yes cant do it constrained Tim: add section to doc Lorenzo: gen purpose device? Tim: take back to list Lorenzo: 7844 discourages stageful DHCPv6. Cary: text should be configurable to privacy drafts. might want to get into fine detail or point to other document Tim: agree not in this draft point and say read Dave Apple: MUST be configurable explain Tim: must be able to turn off and on in original draft. Answer may be not to say anything James: MUST be configurable by WHOM? Tim: read draft James: text not clear does it satisfy requirements for Manufacturer choses on or off, owner does not? Tim: let me take a look. DHCP vs RA for host config.. "here be dragons" Eric: 8028 mh behavior on list (Brian) tim: yes next version to include text Inform or BCP? Lorenzo: have to remove dragons if BCP. either deal or go silent. Lorenzo: speculative Tim: good feedback. Tim Chown: if/when adopted, discuss BCP status Ole: Hum for adoption strong in-room to adopt. Chairs will confirm on the mailing list. IPv6 Router Advertisement Prefix Information Option, draft-pioxfolks-6man-pio-exclusive-bit , Erik Kline, 15 min. ----------------------------------------------------------------------------------------------------------------- https://www.ietf.org/proceedings/98/slides/slides-98-6man-pio-exclusive-flag-00.pdf Eric Kline: Apologies for -02 during meeting. some unfixed items from Seoul. Motivations, every host gets /64, separated layer2 domains. being talked in V6ops. nice as client to know. understood in 3GPP arch, nice to know explicitly. simple bitflag to signal own the net. If unrecognized hosts do DAD and are fine. Simplified from seoul was too clever, became 'brittle'. updated flag location to avoid flag bit collision added text because r flag mutually exclusive. Continues with slides from Seoul so jump to end. interest in WG Eric: would the X flag be useful on 3GPP? don't think harmful but not useful if node knows on that model. intervening device, one hop away, bridge, then useful yes. ???: assumption node knows link model based on Eric: 7066 does the same thing, link model not implicitly segmented/L2 separated Alexander: related to earlier discussion creating new dragon? helps or not helps PD? Eric: perhaps. but, useful. Alexander: backwards compatible.. Eric: not mutually exclusive. no way to say eg attach to /64 find out f PD possible, then do link number afterward. can be unnumbered, numbered without PD, or numbered without PD. (unnumbered links) Ole: have use cases. draft enforce Alexander: earlier drafts proposed to do PD by router advs. there are two drafts doing same functionality. Eric: draft in archive? expired? Alexander: can resurrect? Eric: discuss with ops. can point. alexander: will send again Lorenzo: support. links where device gets RA, knows from technology exclusive use, but nice to signal, avoid baking to link layer. useful to signal in v6. definitely useful in other link layers take this model. To Alex's point using PD have to provision separate networks. need R bit on for anything to work at all so now have to configure two things. with X bit can benefit from it, if understand. Dave (Apple): like this. one bit gets all the info. love. want discussed in WG. Fernando: concern duplicating functionality in DHCPv6 in RA and vice-versa not surprised if we wind up in scenario where support this option but not in PD and this is a bad call. duplicate everything not good. have to do both in both impl. take step back figure out whats best option to do. Looks similar to stuff we already have. Eric: not mutually exclusive. this is not about PD. being informed its yours. Jeffry Handal: To understand. client isolation, could permit battery conservation, energy efficiency because know don't do stuff. Mark: say 'way to get single prefix' maybe rather than Ole: take to list. Fred: router has to know host is authorized. Route Information Options in Redirect Messages, draft-templin-6man-rio-redirect , Fred Templin, 10 min. --------------------------------------------------------------------------------- https://www.ietf.org/proceedings/98/slides/slides-98-6man-route-information -options-in-redirect-messages-02.pdf Fred Templin: adding new host type to existing 3 types from 4191. type 'D' like C but process redirects Eric: could the target send its own RA with lifetime zero, RIO in this scenario? Fred: wont accept unless first hop from prefix (router) second thing, RA-guard on link would discard. Dave: similar confusion. wonder attack possibilities, target is authoritative router. secure RA, but thing labelled router is not authoritative, so misled. Lorenzo: I am the router, I have PD from upstream, delegate the /64 to target, know not routable how delete? Fred: target gets delegation lifetime valid. Lorenzo: renumber, has implications. has to be communicated. unsolicited lifetime zero upstream, how to inform child. no way to tell. James: in this draft say type D can process redirects. does not mean they stop processing RA. eg RIO lifetime zero entire prefix. Lorenzo: semantics of RIO somebody else can claim immediately (lie) and you've been hacked. Bob: out of time Pierre: interested. disabled in Linux by default is security. think wrong argument, but thats what linux decided. maybe addressed in this. so interested. second avoids too much stuff in the RA. put in document redirect only for src address in packet 'D' host is not the right way to do it. don't need to be type C host to be type D host. Eric Vyncke: target sending RA w/RIO ignored by src what would RIO in redirect be accepted Fred: send these rate limited not every message Erik: but why ever process/send? Jeffry Handal Cisco:* context changing, interesting ad-hoc networks, router and host at the same time, figure out how to do it. like v6 to be part of it. Fred: no, multicasting scenario eg like sat links Lorenzo: turning on RIO in android Alexander: answer to earlier not target sending RA, target is mobile dev do not send. dont do this James: concern to join draft, support. if not passed home gateways may do redirects per host address. 1000 behind target, home gateway may have to do this fill cache with individ. DoS signaling with Hop-By-Hop options, draft-francois-dots-ipv6-signal-option , Jerome Francois, 10 min. ----------------------------------------------------------------- https://www.ietf.org/proceedings/98/slides/slides-98-6man-ipv6-dots-signal-option-00.pdf Jerome Francois: presented in DOTS WG (see pack) Chris Morrow: google - please don't do this. many bad dimensions Jinmei: terminology is confusing. didn't understand "embed" actually means "insert". whether insertion is good or bad, need to be more clear about terminology. IPv6 Address Usage Recommendations, draft-gont-6man-address-usage-recommendations , Christian Huitema, 10 min. ------------------------------------------------------------------------- https://www.ietf.org/proceedings/98/slides/slides-98-6man-address-usage-recommendations-00.pdf Christian Huitema: Implications of the socket bind() on INADDR_ANY and leakage of temporary addresses, seen and reachable. can do enumerated bind, but its a pain. don't do that. requires update on change Francis: UDP has some specific bind requirements in some applications/protocols stable vs temporary addresses Dave: useful to document the issues on the alternatives slide, three categories, generalize one bind India. sockets. Stack layer sockets methods, firewall does it worth documenting techniques available, future work PS Michael Richardson: whats the alternatives to bind() is this what you are thinking about. something different to :: in there? scoping? flags? not :: but something else? is that it? Christian: one possibility yes Michael: so API critical change Very supportive. useful. Eric: reuse addresses, use cases are interesting. follow DNM work to get on-demand addresses and prefixes with different qualities. availability of types of addresses and prefixes. ability to bind to the prefix. ???: DNM is not here. mobility and non-mobility. Chris Morrow: problem exists in v4 basic security problem. maybe need language in draft. Christian: practice of scope is much more a v6 thing Chris: lots of machines with v4 many addresses Fernando: considering SOCKOPT to allow app programmer to specify properties, stable, local or whatever. comment chris made think theory in v4, but in v6 have the scopes problem ore evident. Ted: good work important problem API suggestion is good document defaults app developers will be flummoxed Jinmei: bind socket to ANY, even with filtering, packet delivered to the node, transport layer may reach TCP reset state or ICMP port unreachable some issues may still remain. easy to address. Christian: send text Recommendation on Temporary IPv6 Interface Identifiers, draft-gont-6man-non-stable-iids , Christian Huitema, 10 min. -------------------------------------------------------------------- https://www.ietf.org/proceedings/98/slides/slides-98-6man-temporary-ipv6-interface-iid-00.pdf Christian Huitema: More complex than original IID work. cookies, structure, avoiding correlations, lifetime binding to privacy events ???:* can cover in one document Ole: we're out of time, See you in Prague. ------------------------------------------------------------------------- Meeting Adjourned -------------------------------------------------------------------------