6MAN Working Group - Prague IETF Meeting Monday, 1300-1500, 20 July 2015, Congress Hall III Chairs: Bob Hinden, Ole Troan Minute taker: Lee Howard, Suresh Krishnan Jabber Scribe: Andrew Yourtchenko, Loganaden Velvindron Jabber Room: 6man@jabber.ietf.org Meetecho: http://www.meetecho.com/ietf93/6man Slides can be found at: https://www.ietf.org/proceedings/93/6man.html The full recording (synchronized video, audio, slides and jabber room) of the 6MAN WG session at IETF 93 is available at https://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#6MAN ----------------------------------------------------------------- Agenda ----------------------------------------------------------------- Introduction, Agenda Bashing, Document Status, Chairs, 10 min. Working Group Drafts None. Active Individual Drafts Republishing the IPV6-MIBs as obsolete draft-fenner-ipv6-mibs-obsolete, Bill Fenner, 10 min. Source Address Dependent Routing for IPv6 hosts analysis, Brian Carpenter, 20 min. IPv6 Hop-by-Hop Header Handling draft-baker-6man-hbh-header-handling, Fred Baker, 15 min. IPv6 Segment Routing Header (SRH) draft-previdi-6man-segment-routing-header, Stefano Previdi, 10 min. Implications of Randomized Link Layers Addresses for IPv6 Address Assignment draft-huitema-6man-random-addresses, Christian Huitema, 10 min. IPv6 specifications to Internet Standard, Chairs, 20 min. New Individual Drafts RA power measurements, Lorenzo Collitti, 5 min. Guidelines for New Router Advertisement Options draft-sarikaya-6man-ra-guidelines, Dan Ludtke / Behcet Sarikaya, 5 min. CGA SEC Option for Secure Neighbor Discovery Protocol draft-jiang-6man-cga-sec-option, Sheng Jiang, 5 min. Transmission and Processing of IPv6 Options draft-gont-6man-ipv6-opt-transmit, Fernando Gont, 5 min. DNS Name Autoconfiguration for Internet of Things Devices draft-jeong-homenet-device-name-autoconf, Jaehoon Paul Jeong, 5 min. ----------------------------------------------------------------- ----------------------------------------------------------------- Introduction, Agenda Bashing, Document Status, Chairs, 10 min. ----------------------------------------------------------------- Meeting started promptly at 1300. Chairs requested comments on DAD improvements, on the mailing list. Remote question from Ted Lemon: Would chairs entertain a question about DHCPv6-Shield and IPv6 Extension Headers? The chairs didn't understand the context, and asked Ted to raise the issue on the mailing list. Republishing the IPV6-MIBs as obsolete draft-fenner-ipv6-mibs-obsolete, Bill Fenner, 10 min. ----------------------------------------------------------------- Old MIBs are obsolete, but the descriptions don’t actually say that. So this draft changes that. Two thumbs up from the AD. Adopt as a WG doc? Loud hum in favor, no opposition. Chairs will confirm on the mailing list. Republish as a 6man doc. Dave Thaler: Are there any open issues, or can it go to WGLC? Bill: I have no open issues, but please review. Dave Thaler: I will review. Source Address Dependent Routing for IPv6 hosts analysis, Brian Carpenter, 20 min. ----------------------------------------------------------------- Should 6man do something about source-address dependent routing? Recommend reading draft-baker-rtgwg-src-dst-routing-use-cases and draft-sarikaya-6man-sadr-overview Problem: a host with more than one GUA wants to send packets to a host with more than one GUA, and at least one upstream network implements BCP38. Lorenzo: if it’s one routing cloud, how can this happen? Fred: You wind up getting to a different egress router, evenwhen your first hop is the same physical interface Lorenzo: How can they be separate if it’s the same interface? Fred: There would be one overlapping device. Bob: e.g., cable and DSL, where both exist but don’t route between each other. Sub-optimal routing or performance is not a failure mode. Dave Thaler: selection of address pair is done sometimes by app and sometimes by stack Fred Baker: what does “sub-optimal” mean in this context? Mikhail Abramsson: What do you mean you don’t care? Brian: It doesn’t need fixing. Mikhal: I disagree. In some use cases, an extra hop is a problem. Pfister: It is a failure. I have two routers on my WiFi and we don’t want each packer to be retransmitted twice. Phil: Routers can just figure it out, we still have redirects. If we have two routers than never talk, that’s a problem. Fred: I thought routing was off the table. In Use Cases, one question was whether all routers in the system understand what was being discussed. But saying “I’m going to select the right number of hops” you can redirect to the wrong egress. Therefore, getting to the right egress is a functional requirement. [missed name]: Let’s identify blockers now, and do optimization later. Erik Kline: Would you consider it a failure if you were only supposed to have one failure on the link, but somebody showed up with another router and started sending RAs? Brian: If there’s an ingress filter, it would be a failure. Pfister: Reply to David. At least you agree that we have a fix to a problem, and later we have a fix to the fix. Julius Chrobocek: Aren’t you going to have route flapping,with each router sending redirect to the other? Description of scenarios. Philip Homberg: So we're tying address to routing, which wouldn't occur if you tied address to DHCP? Brian: Right, you need to process RAs, whether you're doing SLAAC or not. Philip: RAs don't say anything about address. Brian: Except PIO. Fred: Recommendation that all routers support SADR; don't send to Routing Area, send to Ops Area. Routing Area doesn't tell you how to route, it owns the protocols. Mikail Abramsson: It's not just that you select source address and get routing; we need to tie them together. This doesn't do that. Ole: Yes, requiring stacks to remember which next-hops advertised which prefix and enabling source-address selection rule 5.5 does this. Mikhal: But I want to be able to use both source addresses to reach a single remote host. Lorenzo: That already works. Jacques Pfister: Homenet WG. I support fixing observed problems. We're using SADR in Homenet, but have no drafts defining it. This looks like a solution. I disagree with this. You're using PIO for routing, redirect, I don't know how that will work with RIO. Lorenzo Colitti: Require that RAs are sent. Say you're a lonely /128, do you send a PIO for yourself? If everything is off-link, ow? Brian: If there's only one, no problem. Get address from DHCP, get RA with PIO from router. Fernando Gont: Does the fact that a router sends a PIO mean you have to send packets to that router? Brian: Not currently defined, but seems like that's what you have to do to make it work. Ole: Assumes if you send PIO, you should expect to route. Brian: 5.5 only applied to those who understand the prefix and route it. Marcus Steinburg: I applaud work in this space, but not this solution. Funny: Routing Area doesn't choose for you, except in Homenet they are. Hunter (?) does any of this imply host installs two default routes, each with source prefix? audience: Yes, no, yes. Brian: Default it a weird thing, Steven Barth (?): I've been doing something like that on CPE for a while now. We do on an interface basis. For every PIO and PD, we're making the router source-specific. Works well, not sure how to do in host stacks, especially constrained devices. Bob: Is there interest in the WG in working on this along the lines of Brian's conclusion? strong hum Lorenzo: Does that preclude working on other stuff at the same time. Mark Townsley: The hum should be for the first slide (should we work on this problem?), not the last slide (Brian's conclusions). Moderate hum to work on this. Fred volunteers to co-author with somebody. Brian might help. Brian: Let's remember what Pierre said, that sub-optimal can be a real penalty, not just an annoyance. Lorenzo: Want more discussion of alternatives. Fred: I think we can do this without getting into a routing protocol. IPv6 Hop-by-Hop Header Handling draft-baker-6man-hbh-header-handling, Fred Baker, 15 min. ----------------------------------------------------------------- HBH punts to software, which is an attack vector. Either fix it or deprecate it. Cisco looking at some OAM questions which could overlap. Recommend: presence of HBH SHOULD NOT slow forwarding rate. If HBH can be skipped, it MUST be skipped. Change in place supported by rfc2460, but what if host is unaware? Might be okay. Unless it's in ESP and checksum no longer matches. Thus, header must be restored to original before final delivery. This OAM might only work among consenting networks; interop is a concern. So, either deprecate all extension headers. Bob: You mean all HBH? Fred: No, all EH break this way, but I'll limit discussion to HBH. And I think that's a bad idea. Jen Linkova: Don't deprecate. But why say to skip if you don't know what to do? There's guidance about what to do. Fred: I thought I did say that. Jen: If HBH not implemented, then skip. Fred: I'll work on wording. Christian Huitema: Look in ippm WG, options to measure traversal times. I think that work should be synchronized here; similar use case. Fernando Gont: Agree with processing of HBH. SHOULD/MUST. But other EH also have problems. Improving this doesn't fix everthing. Suresh Krishnan: I support this work. Consider MTU if you're going to add headers on the fly. Fred: I think I mentioned in security considerations. Suresh: How does last hop know what headers were added in the middle? Fred: I think that's in the option, whatever it is. Suresh: But if it's the whole header? Also there's no ordering of options, so same header could be repeated multiple times, which could be a DOS vector. Boro Nis? Good work, maybe four years late. Erik Kline: HBH with router-layer options like MLD are not in scope? Fred: Um. It's a packet with an option, I don't know about what's in it. Ron Bonica: I agree with you, but we need to do some soul-searching. Agree that HBH isn't useful because implementations filter or punt. So, fix. But do we have a good use for HBH options that makes the work worthwhile? IPv4 equivalent is unused. Different in IPv6? Probably, but we should be explicit about it. Ole: Too soon to adopt. Please keep working. Fred: I have an offer to co-author. IPv6 Segment Routing Header (SRH) draft-previdi-6man-segment-routing-header, Stefano Previdi, 10 min. ----------------------------------------------------------------- Fernando Gont: rfc2460 EH means [missed comment] Brian Carpenter: no, segment router header means you are controlling where the packet goes, so you can assume it will leave network at a point where it will remove the weed you've planted. But I'm still nervous about inserting headers; Steve Deering and Bob Hinden never conceived of this. I'm sure it works in your lab, because it's a lab. Do not adopt as Standards Track--Experimental at most. Stefano: Valid concern. Same as when we added headers to a packet in an MPLS network. What if we defined the domain to make sure it exited the domain exactly the same? Not sure this concern pushes back the whole thing. Erik Vyncke: No problem on the Internet, because you don't do it on the Internet. We've been trying it, and getting 5-10% drop rate. John Brzozowski: I disagree with Brian. We need to continue examining, but maybe 6man and v6ops aren't the right place. We see this as necessary evolution. Lorenzo Colitti: I don't share Brian's concerns. Always true: if the network touches the packet, the packet is at the mercy of later routers. I can see how adding headers could open opportunities for undesirable or even malicious behavior, but maybe we can limit the opportunities for mischief. Alex Petrescu: What kind of services will this network offer using segment routing? Stefano: See the use cases draft. Jean-Michel: I sent a message about security, no reply. Ole: There are questions about security. Stefano: I would say there are questions. Bob: We deprecated the earlier document. Stefano: That's why we wrote the segment-routing-security draft. Ole: People who read security draft, any issues, knowing who we deprecatedRH0? Jean-Michel: The security considerations section, or the segment-routing-header draft? Christian: Please make it one document. Stefano: We separated based on a suggestion already. Bob: Please combine, and we'll do a call for adoption. Stefano: If I submit tonight, do we get a call this week? Bob: Next week. Implications of Randomized Link Layers Addresses for IPv6 Address Assignment draft-huitema-6man-random-addresses, Christian Huitema, 10 min. ----------------------------------------------------------------- Don't assume MAC address is constant. Use IEEE rules to set U/G bits, to show it's a random adress. rfc7217 recommends stable identifiers. Lorenzo: Are you assuming there are other addresses too, e.g. privacy addresses? Fernando: 7217 doesn't require you to use an interface identifier. Propose to update 7217 Do we adopt this draft, or revise draft-ietf-6man-default-iids Philip Homburg: We have language that;s one-size-fits-all: mobile devices, large platforms, small things. Update this to say, "If you use randomized MAC addresses, do this; if you're a stable server, stay constant." But I think we need to work on this. Michel Combes: Interaction with SAVI. Erik Vyncke: I understand your goal, but I'd like to keep rfc7217 stable, because enterprises are easily confused. Christian: We solve that now by not doing MAC randomization on enterprise networks. But it's still a risk since a neighbor can do MAC sniffing on WiFi. The intersection of enterprise and privacy is not well understood yet. Bob: Being on the inside is not safe. Erik: Okay, keep MAC address random, but keep 7217 intact, randomize MAC but not IP address. Christian: That in-between case is harder to test. Lorenzo: I like this work. Broader questions, not just SAVI, but there's a lot of infrastructure e.g., captive portals, based on stable MAC address. Even 802.1x on wireless expects it. I think we'll find out that the important this is that the MAC address remain stable for a particular period of time, but changes quickly after. Christian: I've gotten that feedback several times. Doing a presentation in INTAREA. Not sure IETF is the right place to do a thorough examination of MAC address randomization. Alex Petrescu: Yes, MAC randomization is needed for privacy. If we try to identify what breaks when we do this. Like DHCPv6 (Lorenzo cheers). A ULA generation tool will fail. Jen Linkova: People don't want do deploy IPv6 with SLAAC because they don't have a way to correlate user with IP address. Would this further inhibit? Lorenzo: That's the IEEE's fault. Dave Thaler: All this does it make IPv6 as bad as IPv4. Ole: Not sure whether to combine with -default-iids, continue discussion on mailing list. IPv6 specifications to Internet Standard, Chairs, 20 min. ----------------------------------------------------------------- We have several documents at Draft Standard (a status now deprecated), which after two years without interest should drop to Proposed Standard. Propose to reclassify as Internet Standard any documents requiring no changes. Start work on those that require updates. Then look at Proposed Standard documents. Dave Thaler: Is there another requirement that all normative references be at the same or higher level when advancing to IS? Ole: Exceptions are allowed, but try to keep it rare. Has to go through exception approval process. option 1: Reclassify to IS unchanged (same RFC#) option 2: Revise and re- classify (rfc6410) option 3: don't advance Recommendation for several documents. RFC2460 IPv6: 9 updates, 2 errata. Revise, re-classify as IS. Bob: it's not clear that all of these meet the requirements Ole: Incorporate the "updated-by" text, but not always clear whether the updates are all qualified for IS Brian Carpenter: rfc2460bis should be much shorter, with references to the updating docs He is not concerned about the down refs Lee Howard: Including by reference is the better way. He believes that some of the referenced documents may also need updating Bob Hinden: The 2 track standards doc does not talk about updates. Only about errata. He thinks there is no precedent and we need to create precedent Fred Baker: Wants the IESG to reclassify the updating documents en masse to Standard along with 2460bis. Brian Haberman, AD: I like Fred's idea to move as a cluster. We have this problem in other places, where groups of docs need to be moved together. Will discuss with other ADs. RFC4291: IPv6 Addressing Architecture. If someone wants to take this on, please volunteer. Wes George: It's often really hard to follow the chain of documents. If you're going to touch it, make it a bis that includes the current status. instead of letting people guessing the right thing to do by combining 15 references and the newly minted Internet Standard Lee Howard: Strongly agrees with Wes. We should not shy away from hard work. We need a document that describes the standard, which is not the document we have. Bob H. Wanted to know if creating a new Standard would create any confusion in the marketplace Lorenzo: Agreed with Lee and Wes Ron Bonica: When we look at any of these, we may get frightened as we find ambiguity as we try to collapse. If that frightens us, we should be frightened now. Bob: In the future when we update documents, we need to make sure the update is explicitly clear. Sounds like we'll do a -bis of at least 2460 and 4291 Address Architecture. I'll take a cut at 2460. New Individual Drafts ----------------------------------------------------------------- Did not have time to do the presentations on the new individual drafts. Chair encouraged authors to bring to the mailing list. RA power measurements, Lorenzo Collitti, 5 min. Guidelines for New Router Advertisement Options draft-sarikaya-6man-ra-guidelines, Dan Ludtke / Behcet Sarikaya, 5 min. CGA SEC Option for Secure Neighbor Discovery Protocol draft-jiang-6man-cga-sec-option, Sheng Jiang, 5 min. Transmission and Processing of IPv6 Options draft-gont-6man-ipv6-opt-transmit, Fernando Gont, 5 min. DNS Name Autoconfiguration for Internet of Things Devices draft-jeong-homenet-device-name-autoconf, Jaehoon Paul Jeong, 5 min. ----------------------------------------------------------------- Meeting Adjourned -----------------------------------------------------------------