6MAN Working Group - Berlin IETF Meeting Monday, 1510-1720, July 29, 2013, Belluvue Chairs: Bob Hinden, Ole Troan Minute taker: Fernando Gont Jabber Room: 6man@jabber.ietf.org Meetecho: http://www.meetecho.com/ietf87/6man Slides can be found at: http://www.ietf.org/proceedings/87/6man.html ================================================== Agenda -------- Introduction, Agenda Bashing, Document Status, Chairs, 5 min. Charter Update, Chairs, 10 min. Privacy & IPv6 Addresses Privacy Considerations for IPv6 Address Generation Mechanisms, draft-cooper-6man-ipv6-address-generation-privacy , Alissa Cooper, 20 min. A method for Generating Stable Privacy-Enhanced Addresses with IPv6, draft-ietf-6man-stable-privacy-addresses , Fernando Gont, 10 min. Router Advertisement based privacy extension in IPv6 autoconfiguration, draft-rafiee-6man-ra-privacy , Hoshieh Rafiee, 10 min. IPv6 Fragment Header Deprecated, draft-bonica-6man-frag-deprecate , Ron Bonica, 15 min. Operational Issues Associated With Long IPv6 Extension Header Chains, draft-wkumari-long-headers , Warren Kumari, 10 min. IPv6 Performance and Diagnostic Metrics Destination Option, draft-elkins-6man-ipv6-pdm-dest-option , Nalini Elkins, 10 min. IPv6 Multicast Address Scopes, draft-droms-6man-multicast-scopes , Ralph Droms, 10 min. Updates to the IPv6 Multicast Addressing Architecture, draft-boucadair-6man-multicast-addr-arch-update , Stig Venaas, 10 min. Efficiency aware IPv6 Neighbor Discovery Optimizations, draft-chakrabarti-nordmark-6man-efficient-nd , Samita Chakrabarti, 10 min. Presentations if time permits IPv6 RA Options for Next Hop Routes draft-sarikaya-6man-rfc4191bis , Behcet Sarikaya, 5 min. SSAS: A Simple Secure Addressing Generation Scheme for IPv6 AutoConfiguration, draft-rafiee-6man-ssas , Hosnieh Rafiee, 5 min. IPv6 Prefix Properties, draft-korhonen-6man-prefix-properties , Jouni Korhonen, 5 min. IPv6 Prefix Meta-data and Usage, draft-lepape-6man-prefix-metadata , Shwetha Bhandari, 5 min. ============================= Introduction, Agenda Bashing, Document Status, Chairs, 5 min. Bob opens the meeting. Full agenda. Some requests couldn't be accommodated. We'll have a charter update discussion, and a session on IPv6 addressing privacy issues, and a session about fragmentation and extension headers, and other additional items. Ole describes the state of wg documents, and notes that we're trying to improve the quality that go out from the WG, so the chairs are looking for volunteers for doing detailed review of document, in addition to the chair's detailed reviews. Brian Haberman: IESG view is to have the working groups resolve the issues with the documents, rather than having several Area Directors (ADs) deal with them ----------------------------- Charter Update, Chairs, 10 min. Bob describes changes to the 6man wg charter. ----------------------------- Privacy Considerations for IPv6 Address Generation Mechanisms, draft-cooper-6man-ipv6-address-generation-privacy , Alissa Cooper, 20 min. Alisa presents draft-cooper-6man-ipv6-address-generation-policy Alissa notes that the I-D was published in response to apparent confusion on the 6man mailing-list regarding the privacy implications of different Interface-ID generation methods. Alissa discusses the properties of different Interface ID types, and comments on the lifetime of RFC4941. Dave Thaler clarifies that temporary addresses are deprecated after one day, and removed after seven days. Alissa continues with her presentation Erik Nordmark: There's additional level detail. You might be able to track nodes if you have local access to the network. For example, in CGA there no requirement to change the public key when you move. SO if you see a NS/NA exchange, you might see that it's the same public key. -- I don't know if you want to get into that level of detail. Alissa: We could incorporate that. The advice I got is that CGAs are expensive, so it's unlikely that you will regenerate the public key. Alissa continues with her presentation, and notes that problems arise when you configure more than one address. E.g., if you use temp addr but also configure IEEE-based, you might loose many of the privacy properties of temp addr. (XXXX 27:26): Idea is very useful. In case temp addr, they are useful for clients, but not for servers. So this criteria should be added to the draft. (XXXX 27:26) I have an idea that is called "ephemeral address". I will drop you an email about it. Warren Kumari: I'm confused about the privacy issue. What's the difference from v4? I mean, other than IEEE-based identifiers.. why wasn't this a problem with v4? Fernando: The Interface-ID space is much larger than in the v4 case. So in v4 it is unlikely that you will use a unique ID. Erik Nordmark: The document talks about privacy properties. Distinguishing between security and privacy issues is interesting. Alissa: exploits and address scans are security issues. Erik Nordmark: Should add something about probable ownership of addresses. Tim Chown: It would be good to state the goal of the document. Deprecate IEEE-based Interface IDs? Encourage people to generate addresses on a per-application basis? It's a nice summary, but would be interesting to note what's next. Alissa: I'd love to deprecate IEEE identifiers. Keith Moore: There's an implicit notion that a host is a client or a server. It is difficult to tell in advance which role a host will have. The net is evolving towards a state where things are not unambiguously clients or servers. You can talk about client or server interactions, but not assume a node is a client or a server. Alissa: Agreed. Keith: You will use different types of addresses in different contexts. You won't be able to say "you only need this type of address". You may get rid of IEEE identifiers. But you will still need stable identifiers, and you'll still have most of the associated threats associated with them. When giving people choices beware that they may not understand. Andrew: I want to follow up to what Tim said. If I'm coding an application, I may want to select desired properties for an address, such as "best privacy properties", etc. Do you envision an API for that? Alissa: That's a good question to think about. [XXX, 34:05] How much of this will be valid when you have link-layer encryption? When you encrypt link-layer packets, you don't see the addresses. Alissa: That doesn't address the addressing problems. Dan York: Useful draft. Relaying from Jabber:Should discuss RFC4941 in replacement vs in addition to IEEE IIDs. If they are in addition, you still have e.g. the scanning problem. Barbara Stark(?): Given that the recommendation is that prefixes don't change for a person or home, does this matter? Alissa: This is not addressed in the I-D. Suresh: There's some text about this in RFC4941. For example, there's some 3GP recommendation to assign a /64 per mobile device.. so changing the IID won't help. Also: there's an socket API extension that allows you to specify stable vs. temporary -- and defaults to temporary. Bob Hinden: Like it, but should be put in context: e.g. web cookies, etc. We need to have an overall view of these issues. Keith Moore: There's an assumption that everyone has a web browser. (xxxx, 38:05) Another mechanism besides cookies that is becoming popular is synthetic subdomains. Hosts will always come back to those domains, so they will remain identifiable. Ole asks to hum about wg adoption. Strong hum to adopt the document This will be confirm on the mailing-list. ------------------------- A method for Generating Stable Privacy-Enhanced Addresses with IPv6, draft-ietf-6man-stable-privacy-addresses , Fernando Gont, 10 min. Fernando goes through his slideware, and provides a summary of issues raised during IETF LC. Dave: Third issue was mine, and I'm happy with the way it has been resolved. Second issue: We should probably remove Appendix B and move it to Alissa's document, and revise, and redo the WGLC. Ole: Next step is to redo the working group last call. ------------------------- Router Advertisement based privacy extension in IPv6 autoconfiguration, draft-rafiee-6man-ra-privacy , Hoshieh Rafiee, 10 min. Hosnieh goes through her slideware. Fernando: Not sure if I got it right: is your recommendation that you'd use a new IPv6 address for each web site that you visit? Hosnieh: If you consider it a new application, yes. Because it is application-based. If you open a new application, you create a new address. BUt if there's already an IID with a high lifetime, the application could be assigned that IID. Fernando: So if you have a thousand connections, you should have a thousand addresses? Hosnieh: Whenever a new application arrives, and there's an IID with a valid lifetime, you assign that application to that IID. Keith Moore: some apps could cope with using a different ip with each different connection, some could not (e.g., some applications might need more stable addresses). I don't understand the bullet that says "it should not use stable addresses". It looks like a gross exaggeration. Hosnieh: If you really care about privacy, you shouldn't. Keith: If you use IPv6, all addresses should be public for any application you're using. Hosnieh: I don't mean global address, I mean having a DNS records. Keith: If that's what you mean by public, that's a bizarre way to define it. Your text needs more precision. Dave Thaler: When the temporary addresses specification was define, there where different proposals regarding which addresses should or should not be used. A reason for which that is not in the spec is that when you start having lots of addresses because you have lots outgoing connections, you end up needing to have your NIC in promiscuous mode to listen to NSs. That's the reason for which that approach doesn't scale. Two things: All in favor of deprecating the temporary addresses I-D, but would do it in a document that is not specific to temporary addresses RFC. Last thing: Go back to slide 5 "store new generated..". The only things that are in use are addresses, and you already have a list of addresses. Hosnieh: There's a wording issue. We just want to improve it. And we want to control the number of addresses. Andrew Yourtchenko: This proposal would increase the number of addresses per node dramatically. If we implement this we should also specify what happens when it's not possible for the network to accommodate that, and for the network to notify the network to notify the node it can accommodate that. Ole: There's a cost to the network when it comes to the number of addresses in use, and the number of addresses is usually limited to two digits rather than a thousand. Warren: You mention changing addresses to avoid tracking e.g. in the presene of cookies... but the whole point of cookies is to keep track of the node even if the address changes. Bob notes that there's no time to respond to this.. we should just keep track of the comments. Erik Kline: You mention that all these privacy parameters would be conveyed in RA messages... is that a secure thing to do? I wouldn't be in favor of accepting this kind of policy from the network. Complying with whatever the operator tells you is not going to work. Chairs: Too early to consider adoption. ------------------------- IPv6 Fragment Header Deprecated, draft-bonica-6man-frag-deprecate , Ron Bonica, 15 min. Ron goes through his slideware Lorenzo Colitti: What is PLPMTUD? Ron: It's specified in RFC4821 Francis Dupont: DNSsec doesn't rely on fragmentation. Ron: Okay, I can remove it from the list. Lorenzo: I haven't read the draft or RFC4821, but PLPMTUD for UDP is like "just run traceroute and see if you get any unreachables" - that's not going to work. If we're going to do this, I'd separate the question of deprecating fragmentation and PMTUD not working. PMTUD *has* to work. PLPMTUD could be seen as additional burden on them that should in fact be dealt with at a lower layer. Ron: Two ways to tackle this: 19 say that RFC4821 is good enough, or do a better job for RFC4821 for UDP. Ole: What does PMTUD has to do with this? It wouldn't have helped you here if PMTUD was reliable. Ron: We wouldn't need PLPMTUD if PMTUD was reliable. Lorenzo: You wouldn't have fragmented if it worked. Ole: The reason for doing PMTUD is that it's an hindrance to make fragmentation work correctly The requirement out of this is that you need transport protocols that can do segmentation. Ron: Yes. That's a better way to say it. Keith: There's several things conflated in this I-D, but should better be treated separately. There's a lot of good input here. Always good idea to give input of what works in the current network. BUt we should be careful in making architecture decisions based on the behavior of current networks. Keith Moore: The word deprecate is a strong word that is prone to misunderstanding. Better to explain what you want to do without using that word. Ron: Sounds reasonable. Warren: Erik asked to relay this. He wanted to know if the document wants to deprecate PMTUD, because it was not clear to him. Ron: Definitely not. Andrew Yourtchenko: In IPv6 there is no reliable do ACLs in stateless devices. If we put arbitrary limits on the number of headers you can stick in the first fragment, we might eventually be able to do ACLs on stateless devices. Erik Nordmark: We should definitely discourage the use of fragmentation. The less of it, the better. There's a class of apps you haven't talked about: tunnels. Those packets are going to be larger than 1280 bytes -- since there's no way to tell the application "send 900-byte packets" (or the like). Fred Baker: the word "deprecate" was carefully defined by the SNMP group in the early '90s. In SNMP we went from one version of the MIB from another version of the MIB. A deprecated object has to be implemented, bu in a next version for the MIB it might magically disappear. Do you mean that if we were to rewrite RFC2460 in the future, we'd remove the the fragmentation part? Ron: I don't know if we're going to re-write RFC2460 anytime soon. Fred Baker: Given that you don't know that, if we decide to go forward, I'd like you to spell out what you mean. You need to get rid of the word "deprecate". Lorenzo: To echo Keith's point, we want to transport protocol developers stop using this and use something that actually works, but meanwhile we will keep this. Packetization will always be better than fragmentation. We should tell applications "don't use fragmentation unless you're not using a transport protocol". Dave Thaler: What you mean probably is "any application protocol spec writer should not use fragmentation"? Ron: Yes! Keith: There's an architectural problem here about making fragmentation co-exist with things like firewall. And we should probably put it in a list, since we do a very poor job with dealing with architectural problems in this community, such that eventually someone comes up with a way of doing fragmentation that is firewall-friendly. The second thing is that it is very difficult to tell when it is appropriate to use fragments. I would discourage that. There's a list of things you said this document does not say. I think this document should say existing protocols that rely on fragmentation will not be forced to change. Vendors should not remove the fragmentation function from their products, and ISPs must not drop fragment. There's no responsibility for operators to make the network be more hostile to applications. We should move away from that line of reasoning. Chairs: Too early to consider adoption, needs more discussion. ------------------------- Operational Issues Associated With Long IPv6 Extension Header Chains, draft-wkumari-long-headers, Warren Kumari, 10 min. Ron Bonica gave the presentation. Mark Townsley: I have a problem with the tone of this. Your passing the problem to the operator. If it's a problem with equipment being unable to handle this, let's explicitly say that Lorenzo: Replace ISPs SHOULD NOT with vendor MUST! Another thing to add is that if a vendor allows filtering on the header chain, it should be able to look up to (and including) this value. If you don't write it down... Don't know about the trade-off between 128 and 256...128 looks a bit too small. Right now the unlimited length is not going to work. Mikael Abrahamsson: Agree with Lorenzo. Dropping IPv6 fragments is the default behavior of a very common box. Suresh: Some questions: what do you do when you receive one of these messages. Rate limit? Send ICMPv6 errors? Ron: It's in the I-D: you send an ICMPv6 parameter problem, and all ICMP messages are rate limited. Suresh: The other thing is figure out the packet size. We should get some measurements and see what's in the wild. Lorenzo notes that Google drops fragments and extension headers. Suresh: 128 seems too small. Eric Vyncke: 256 seems too long. Mark Townsley: Looking ahead, and thinking about protocols that have not defined, we shouldn't use the least common denominator. We should look at the specs, and see what we want to do, and make an engineering decision too. Erik Nordmark: We need to pick a number. But in order to pick a number we need to find a definition of what an IPv6 header chain is. w.g. Is GRE covered? Ron points to the example in the slideware, and the rules that define what's consider part of the header chain and what not. (???, 23:32) Whats the status of the Hop by Hops header? Is that the only header that my forwarding device (other than the IPv6 header) that my forwarding device should care about? Why should I care about ESP r anything above it? Ron: The forwarding device may make forwarding decisions of what's in the TCP header. Joel Jaeggli: You don't need to make much empirical testing because the people who make the ASICs and integrate those ASICs in the routers know what those limits are -- they are not mysterious. The other part is that the reason there are variations in length is because people do handle encapsulations. e.g. in L2VPN we did penultimate hop popping so we didn't have to pass the packet through a forwarding engine twice in order to look up the next hop. There are devices out there that can handle multiple encapsulations, and that affects the header length they can parse because they may look e.g. at the second IP header in order to decap the packet and forward it in one pass. Chairs: Too early to consider adoption, needs more discussion. ------------------------- IPv6 Performance and Diagnostic Metrics Destination Option, draft-elkins-6man-ipv6-pdm-dest-option , Nalini Elkins, 10 min. [XXX, 32:38]: My org handles or the traces that run in the financial market triage is very important and means a lot of money. Also, the costs of agents can be very expensive. In many scenarios this can mean big savings. (XXX?) It's very difficult to synchronize clocks over a network to get a precision that is useful. M. Ackermann: Absolutely. Don't try this without NTP. (XX?) Not good enough even with NTP. M. Ackermann: With NTP you should get the precision you need. A. Yourtchenko: First, you assume this header will be untouched when others won't. Second, this reduces will reduce the effective length of the header chain (below 128 bytes). Third, I should remind you of TCP time stamps that are already there. Lorenzo: Is this meant for the general Internet or for your own deployment? If it is meant for the general Internet, it won't work, because packets with extension headers will be dropped. If it is for your own deployment, it doesn't need to be standardized by the IETF. Chairs did a call for working group interest in adopting as a 6man working group document. Very little support to adopt. ------------------------- IPv6 Multicast Address Scopes, draft-droms-6man-multicast-scopes , Ralph Droms, 10 min. Dave: Go to the definitions slide. Reading this, I don't know what network-specific is. You might want to change "network". Second half of it. Scope 4 is the smaller scope that is configurable. Scope 3 is smaller scope that is automatically configured. If you say "largest scope that can be computed automatically... " (??? 42:20) is an easy way around this and you don't have to figure out what that word should be Ralph: I like that. Ole: Clarification: The IANA registry your asking about is the registry of applications using this scope? Ralph: No, the list of 16 values. Ole asked the wg to hum if people are in adoption of the document. There was support. This will be confirmed on the mailing-list. ------------------------- Updates to the IPv6 Multicast Addressing Architecture, draft-boucadair-6man-multicast-addr-arch-update , Stig Venaas, 10 min. Stig: We'll figure out what the multicast community wants to do, and finish the document. Ole: Do you expect the answer to come from the multicast working group? Stig: I'm sure there's people in this wg with thoughts on this.. so probably the answer will come from both working groups. Bob: Will you resubmit so that it looks like wg item (draft-ietf)? Stig: Yes Chairs: No action now, need to find a few reviewers. ------------------------- Efficiency aware IPv6 Neighbor Discovery Optimizations, draft-chakrabarti-nordmark-6man-efficient-nd , Samita Chakrabarti, 10 min. Lorenzo: I was looking at the mixed mode, and there's a lot of stuff that you need to do there. Why not just say that you can carve a different subnet and call it "IPv6 over some other mechanism" and stop pretending is interoperable? Why don't you just have the real routers as gatekeeper, and have everything register with it. Samita: The model is that we want to move to efficient ND Lorenzo: I don't want this on a wired network. If router loses state, my NCE is gone. For nodes that are not hardware constrained, what we have now is superior. Samite: By the way the last feature of sending NS/NA between routers is optional. Jouni: The I-D says you must have have a slla option -- how about links that do not have link-layer addresses? Samita: This is still not addressed in the I-D. Erik: If there's a better way to handle the transition, we could figure that out. Simple is better. Pascal Thubert: We've been through a lot of hassle screening the protocol so that we could cancel some of these multicast that we do today. -------------- No time for "Presentations if time permits" presentations. ========================= Meeting adjourned =========================