6MAN Working Group - Vancouver IETF Meeting Monday, 0900-1130, 4 November, 2013, Regency D Chairs: Bob Hinden, Ole Troan (remote from Norway) Minute taker: Fernando Gont Jabber scribe: Michael Richardson Jabber Room: 6man@jabber.ietf.org Meetecho: http://www.meetecho.com/ietf88/6man Slides can be found at: http://www.ietf.org/proceedings/88/6man.html ----------------------------------------------------------------------- Agenda ----------------------------------------------------------------------- Introduction, Agenda Bashing, Document Status, New Charter, Chairs, 15 min. Updates to the IPv6 Multicast Addressing Architecture, draft-ietf-6man-multicast-addr-arch-update , Stig Venaas, 15 min. Efficiency aware IPv6 Neighbor Discovery Optimizations, draft-chakrabarti-nordmark-6man-efficient-nd , Samita Chakrabarti, 15 min. Wireless Neighbor Discovery Stateful Address Identification and Location exchange, draft-thubert-6man-wind-sail , Pascal Thubert, 15 min. SSAS: A Simple Secure Addressing Generation Scheme for IPv6 AutoConfiguration, draft-rafiee-6man-ssas , Hosnieh Rafiee, 15 min. Packet loss resiliency for Router Solicitations, draft-ietf-6man-resilient-rs , Suresh Krishnan, 10 min. Privacy Considerations for IPv6 Address Generation Mechanisms, draft-ietf-6man-ipv6-address-generation-privacy , Alissa Cooper, 20 min. Deprecating EUI-64 Based IPv6 Addresses, draft-gont-6man-deprecate-eui64-based-addresses , Fernando Gont, 15 min. Speed Talks (5 Minutes, 3 slides) --------------------------------- IPv6 ND Option for Network Management Server Discovery, draft-liu-6man-nd-nms-discovery , Bing Liu, 5 min. Identifying Addresses of IPv6 Tunnel Packets at Tunnel Exit-point, draft-liu-6man-ident-tunnel-packet-addr , Cong Liu, 5 min. IPv6 Tunnel MTU Configuration, draft-liu-6man-tunnel-mtu-config-00 , Cong Liu, 5 min. The Subnetwork Encapsulation and Adaptation Layer (SEAL), draft-templin-intarea-seal-65.txt , Fred Templin, 5 min. Operational Issues Associated With Long IPv6 Extension Header Chains, draft-wkumari-long-headers , Ron Bonica, 5 min. Introduction, Agenda Bashing, Document Status, New Charter, Chairs, 15 min. ----------------------------------------------------------------------- Bob opens the meeting, and Ole goes through document status. Ole and Bob go through the New 6man charter. Ted Lemon: Double-checking that milestones will be added for the items being discussed in the previous slides. Updates to the IPv6 Multicast Addressing Architecture, draft-ietf-6man-multicast-addr-arch-update , Stig Venaas, 15 min. ----------------------------------------------------------------------- Bob asks for comments, and asks whether people have read the document (some hands, not a lot). Bob notes that this document does a good thing. We should get a reviewer and then WGLC. Ole asks for volunteers to review the document. Jinmei and Suresh volunteer. Efficiency aware IPv6 Neighbor Discovery Optimizations, draft-chakrabarti-nordmark-6man-efficient-nd , Samita Chakrabarti, 15 min. ----------------------------------------------------------------------- Brian Carpenter: I'm confused by your 64-bit unique ID, that you introduced to handle multiple-address hosts. It's not clear if it's an interface identifier or something else. You hint that there might be networks were there might not be EUI-64.. you need to be more specific regarding how you create this if there's no EUI-64. Erik Kline: What happens registration fails or is denied? Can the client fall back to advertise itself with DAD? Samita: If address registration fails, it client should try to go to another default router if available... the client should be able to keep track of who they are,. If one fails, it should try another one. Erik Kline: That might mean that the client might need to register with many routers (e.g., multiple provisioning domains). This is very complicated. This could be used as a mechanism for operators for deny you more than one address. Mixed mode SHOULD be supported but is not required. Erik Nordmark: If you do mixed mode, it actually works falling back. If you want to move to a place where you're not doing mixed mode, where the router registration information is the authority, you don't have to send any multicasted NSes ever. Then you're not going to have mixed mode. Erik Kline: What's the harm in having a fall back? Erik Nordmark: You will always have to deal with unknown IPv6 addresses by sending multicasted NS to see if anybody is there. It would be nice to get to the point where you don't have to do that. Would be nice to throw everything at the router: if the address is not in my cache, it doesn't exist. Period. Can people use this to prevent you from using multiple addresses? Sure. But they can do the same thing by enforcing filtering. Erik Kline: It would be possible to create a network where you can register with only one address. Erik Nordmark: There's nothing in the spec that says that you'd reject a registration based on some policy. An implementation can always say if I already have a registration and I receive another registration request, I can replace the existing one or reject the current one. There's nothing that says that such implementation is incorrect with respect to the standard. The only difference with this protocol is that it has explicit signaling with respect to adding entries to the neighbor cache. Erik Nordmark: Follow up to Brian with respect to the 64-bit IID. Not sure if that was related to the /64 discussion. Anyway, we need to separate between two registrations from the same host for the same address from two registrations from different nodes for the same address. For that we need some uniqueness value. And when this was done in 6lowpan, people started to use EUI64 for that... but has nothing to do with the length of the prefix. This is separate from the /64 discussion. We can deal with any length of the subnet length. Pascal Thubert: Agree with Erik that the limit on the number of addresses is already present in e.g. SAVI, so this is not changing anything in that respect. If you compare this model with DHCP, with DHCP you have to go to the server to get your address. In DHCP, you apply your policy on every request. In this protocol, applying a policy would be the exception rather than the rule. As we progress this, we have to look at error codes, and suggest what should be the "plan B" based on the error code. Samita: The policy could be implementation dependent or deployment dependent, which would be hard to specify. Ole asks whether we're ready to make a call for adoption. Weak hum in favor of adoption. None against. To be confirmed on the mailing-list. Wireless Neighbor Discovery Stateful Address Identification and Location exchange, draft-thubert-6man-wind-sail , Pascal Thubert, 15 min. ----------------------------------------------------------------------- Brian Carpenter : There is a comment in the Security Considerations that says that the use of EUI64 precludes the use privacy techniques. My question is why you say you cannot use privacy techniques. Pascal: Should review that. Michael Richardson: Is this the canonical "I know where this address is in an arp-ish network"? Pascal: Yes. Erik Kline: We seem to be pushing a lot of complexity to the clients to deal with a variety of network scenarios. We're complicating the protocol and the client. Did we have have this problem with IPv4? If we didn't, should we throw ND and go back to ARP? Pascal: It's already screwed with v4, but it doesn't show so much. v6 can make it even more, because we send more multicast messages. Regarding complexity, I don't think this is much additional complexity. IPv6 brings in the scale problem, because with 64 bits you grow the subnet to an immense scale, as opposed to the small IPv4 subnet. The problem is not IPv6... initially the problem is multicast and scale. Eric Vyncke: I see a field named "trust" in this slide, which kind of relates to security, but I don't see any kind of signature notification in this message. Pascal: This draft in particular doesn't say how you do it, but clearly if these messages are in trusted they must have been secured in some way. Erik Nordmark: Response to Erik Kline: We're trying to take v6 where we have not taken v4, like 6lowlpan. If we move across those types of networks without changing my IPv6 address we need to have something that can scale up to that. We haven't solved that for v4. The interesting questions is what is the state of wifi in terms of the impact of arp vs Neighbor Discovery. Would be good to have some data from operators. Question to Pascal: This draft still refers to the backbone router... are you planning on pulling in all of those pieces, or are we having another backbone draft with other use cases and other pieces of this puzzle? Pascal Thubert: My call would be discuss how you do proxy ND over the backbone as a separate draft. If think that if we put this, efficient, and backbone router in the same document it's going to be crazy.. but we have to discuss that. SSAS: A Simple Secure Addressing Generation Scheme for IPv6 AutoConfiguration, draft-rafiee-6man-ssas , Hosnieh Rafiee, 15 min. ----------------------------------------------------------------------- Ole asks how many people have read the document... he counts about 4 people. Bob asks for comments. Erik Nordmark: There reason I thought was interesting is that these local attacks might become more prevalent. If we can address the backhaul/longhaul security issues, if people use more and more public access, man in the middle attacks might become more popular, and these local attacks might be the weakest leak. Trying to lock down the address mapping would be important. A fair question that has been asked is "Why would this be deployed if SEND?" hasn't? That's a fair question and the answer maybe that people don't care that much about security to implement and deploy it. This is simpler and more efficient than SEND+CGA. If we don't add this to our toolbox, we might not find a way out should thing get significantly worse in terms of these attacks. I encourage people to look at this, and see if this makes sense to implement, etc. Bob encourages the wg to read this (not many folks have). Once we get reviewers, we can do a wg call for adoption. Privacy Considerations for IPv6 Address Generation Mechanisms, draft-ietf-6man-ipv6-address-generation-privacy , Alissa Cooper, 20 min. ----------------------------------------------------------------------- Ole asks for comments. Brian Carpenter: Very useful and informative stuff. I wonder how many bits in the IID for the IID to be opaque. e.g. most of the 64 bits? Alissa: We want to separate the mechanism from the prefix length. Brian: But if someone wanted to change the prefix length, they should have this into consideration. Erik Nordmark: Opaqueness is not a binary quality. We should also consider how the IID is tied to the prefix. We should make sure it's cryptographically hard to map one prefix/IID into another prefix/IID. Kerry Linn: I have a point and a confusion. The point is that at times tracking must be useful (in some scenarios). The confusion is that EUI64s were supposed to be useful to have a globally-unique identifier. With respect to the /64, how many bits do we need to have such uniqueness? Fernando Gont: Those are unrelated issues. When it comes to embedding the MAC addresses, it has already been found that there's a lot of MAC address duplication, so you cannot really really on the MAC addresses for uniqueness. Ole Troan: Do you think that the scope of the document could be such that you could recommend how these addresses should be used? e.g. a server not needing temporary addresses, etc. Alissa: The draft would explode if we did that... and I'm not sure if it would be possible to enumerate all cases. And in many cases the recommendation wouldn't be obvious. Ole: Maybe the app area should work on this? e.g. an app might have for different types of addresses available and would need guidance with respect to how use such addresses, and which addresses should be made available by the hosts to the applications. Bob: There's a void and we need to fill it. Guidance should be provided. We cannot just provide a discussion of the properties of these addresses. James Woodyatt: Regarding CGA, it could also change when the modifier is regenerated. It's also the case that the subnet ID is employed in generating the key.. hence the addresses would be stable but not constant. You should also distinguish between publishable and referable. Referable being "published in some small community". e.g. stable addresses might be publishable.. but temporary might be referable, but not publishable. Another point I'd like to make is that MAC addresses are not guaranteed to be unique. The OUI just specifies who administer that bloc of the address space. But the address is not necessarily unique. Michael Richardson: Two things. Is there a prohibition here for a host to prohibit the generation of EUI-64 IIDs? Alissa: Not at all. That's the next document. Michael Richardson: It's useful to have the MAC address as an asset ID. Bob: Let's leave that for the next document. Tim Chown: Good document. Good to publish as informational. Deprecating EUI-64 Based IPv6 Addresses, draft-gont-6man-deprecate-eui64-based-addresses , Fernando Gont, 15 min. ----------------------------------------------------------------------- Dave Thaler: I want to compare this to is the process we went through with site locals. At the time, it was implemented, there were valid uses, but we deprecated it anyway. If you look at the document that deprecates site locals "some are going to use them even if we deprecate them". The question I have to Michael and all, is you didn't have this available in IPv6. Is this really some shiny thing that if we were to remove you'd say "IPv6 is no better than IPv4". Jen: Even if you replace MUST NOT with SHOULD NOT, that's still two strong. Because some people rely on this feature. The security concerns could be addressed without this change. I can live without this feature, but I like it. Fernando Gont: Among the possible ways forward is to just recommend a more sane default. And if you have a really good use case for Modified EUI-64 IIDs, you just override that default. Besides, how can you possibly address these security/privacy concerns without this change? Jen: If we make this change, we leave the door open to changing the subnet size. People will think that they can use interface identifiers that are not 64-bits long. Fernando: These are completely unrelated issues. People can think whatever they want -- we cannot prevent that. For instance, Microsoft has been doing something else, and they still comply with 64-bit interface identifiers. Alex Petrescu: You've discussed what the draft does not require, but it is not clear what it requires and what it deprecates. Fernando: We're saying that nodes should not generate interface identifiers by embedding a hardware address. Alex Petrescu: Can I use something else for the IID, such as a plate number? Fernando: Yes, you can. But we recommend that the default is draft-ietf-6man-stable-privacy-addresses. Alex Petresescu: In IPv4 we had NATs. In IPv6 it is probably less recommended to use IPv6 NATs. So we need to be able to generate addresses starting from something. You don't want that? Fernando: We just don't want to embed the MAC address in the IID. As an example, Microsoft uses a different scheme that generates addresses automatically, without embedding the MAC address. Alex: Are you recommending Microsoft scheme as the default? Fernando: No. We're recommending draft-ietf-6man-stable-privacy-addresses. We're just referencing Microsoft approach as an example of an implementation that deviated from the standard to mitigate these issues. Erik Kline: I'm well on board with all caps "SHOULD" for this stuff. However, I don't see the value for changing this for link-local addresses. Fernando Gont: When it comes to link local addresses, they might leak out. e.g., you connect to a local MTA on the local link, and that addresses might leak in the email headers. Erik Kline: Doing this for link-locals seems a bit excessive.. it could be even "MUST" for global addresses, but "SHOULD" for link-local. Fernando Gont: I could live with that. Andrew Yourtchenko: I agree with Erik Kline. For some nodes, it's fine. For other, e.g. servers, it's different. For example, I may want to predict what's the address that the server. Right now I can do that by writing the MAC address on the box. Samita: I agree with the previous speakers. For backwards compatibility, the default should be the current scheme, but it should it possible to override it to make it private. Fernando: I don't think there's any backwards compatibility issues. This is a local policy. It's not a change to the protocol. It's a local policy that you can implement in whatever way you want. Tim Chown: A few points. What you're suggesting is that there are several ways to generate IIDs. It's not clear how you'd apply your policy. Dave Thaler: Four points. First, a general comment: Far more useful than "I'd like EUI-64" is "I have this use case that I cannot do without them". There's an analogy here with the deprecation of site locals, where there were some valid use cases. The wording that there is in the site local deprecation document is that, standardization-wise, they are deprecated, and hence new implementations are not required to implement them. Maybe we should look at the site local deprecation document and see if there's wording that everybody likes. Regarding the use cases, the only one I've heard is the inventory use case. Regarding enforcing these to link-local addresses, there are cases where they suffer the same issues. e.g. there's the example that Fernando mentioned. Another is that at times an application my send addresses for e.g. referrals, and send all addresses... and the same issues apply. It's possible that this sort of thing might happen with MAC addresses... but it's far more common with IPv6 addresses. Another is that in some subnets, the link-local addresses may go further than MAC addresses. I don't like that, but people often do it. Erik Nordmark: A SHOULD should normally be followed with a reason for which you might not follow the advice. And that language can be made as strong as we want. The language for globals may be different from that of locals, with a warning of what might happen if you do it. Another thing is that it might make sense to make it clear that this is just about stable address and not about temporary addresses. Regarding the use case for servers, we use to ship boxes with MAC addresses or barcodes in them so that they could pre-provision their systems before opening the box. I don't know how common is this today.. they probably don't want to tie the system to the MAC addresses, because if the card breaks, they are going to replace that card. Anyway, this case could be addressed as follows: when the vendor burns the box, they generate the stable address and print it on the box along with the MAC address, and problem solved. Suresh Krishnan: One comment against the MUST NOT. There's a header compression in 6lowpan that might stop working if we make this a MUST NOT. We could either say "screw those guys" or "relax this". Brian Haberman: Just want to channel my IESG colleagues. There are no interoperability issues so... SHOULD, MSUT etc don't make no sense. Alain Durand: I'd like to talk about the inventory case. We've been asked by customers to do this... so I'd like that this inventory case makes it into the document. Ole asks for hums in favour of adoption. There seems to be support for adoption. Will confirm on the mailing-list. Bob notes that adoption does not mean that the recommendation is frozen. The wording will be discussed as part of the process. Packet loss resiliency for Router Solicitations, draft-ietf-6man-resilient-rs , Suresh Krishnan, 10 min. ----------------------------------------------------------------------- Suresh summarizes the changes, and notes that folks should check whether everything's okay. Dave Thaler: I don't have an answer, but want to rephrase the question so that folks may have an answer to it. What does it mean for Router Discovery to be successful? Does it mean that you got a response from one router, or that you got a response from all routers? And if you think it's the latter, how do you known. Ted Lemon: I thought you already had it in the document. Suresh: Do we want to prohibit sending further RSes once an RA is received? Ole: What does RFC4861 says? Suresh: It doesn't say much. It says you send a RS when the interface goes up. Ole: Even if you receive a RA after the first one? Suresh: You stop after the first one. Erik Nordmark: The operational/network load question here is. When the information you have times out, you should go back to sending RSes again. If I knew three routers and now hear one, I may one to send more RSes.... but... do we really want to have all devices send this background RSes? James Woodyatt: I think there's a real problem here, but maybe the answer to Dave Thaler is that routers may indicate whether hosts should continue soliciting after they get RAs. Erik Kline: This is a difficult thing to answer. There might be multiple operators on a link, each with their own router advertising not a default route but an ARO for special services, and if one of them says "stops after getting a default router", it would be tricky. I guess my question for Brian Haberman is is this an interoperability issue? i.e., you already have connectivity.. Ole: Existing implementations are going to reply to each of your RSes, and this is going to be a load problem and control plane issue. Brian Haberman: The key to take away from RFC2119 is that they are supposed to be used to ensure interoperability. Suresh: In this case is implementation guidance. Brian Haberman: In that case, be very careful. Because people's impression from what those keywords mean from an implementation perspective is different from they impression of what they mean from an interoperability perspective. Ralph Droms: The problem here is that nobody has a list of where all the routers are. Suppose routers listen to RAs so that each of them comes up with a list of what they think is the complete list of routers, and they all send out. In that case you might tell whether you have heard from all of them. Suresh: This is the kind of stuff we did for DNA a while ago.. but it's very complex... Bob asks for reviewers of this document. --------------------------------- Speed Talks (5 Minutes, 3 slides) --------------------------------- IPv6 ND Option for Network Management Server Discovery, draft-liu-6man-nd-nms-discovery , Bing Liu, 5 min. ----------------------------------------------------------------------- XXX: I didn't see in the I-D what NMS stands for. And if you mean for routers to give this information, rather than any neighbor, which would be a bad idea. XXX: Erik Kline what are the alternatives today for disseminating this information? Identifying Addresses of IPv6 Tunnel Packets at Tunnel Exit-point, draft-liu-6man-ident-tunnel-packet-addr , Cong Liu, 5 min. ----------------------------------------------------------------------- Jinmei Tatuya: It would be helpful if you described what current implementations do. IPv6 Tunnel MTU Configuration, draft-liu-6man-tunnel-mtu-config-00 , Cong Liu, 5 min. ----------------------------------------------------------------------- Erik Kline: 1240 would be a vaild IPv6 link? I'm not sure you can just make the MTU less than the IPv6 minimum MTU. The Subnetwork Encapsulation and Adaptation Layer (SEAL), draft-templin-intarea-seal-65.txt , Fred Templin, 5 min. ----------------------------------------------------------------------- Ole: Isn't the whole point of the minimum MTU of 1280 bytes that since most links are 1500 bytes, you have 1500-1280 bytes for encapsulation? Fred: For that assumption to be true you have to have a careful orchestration of the MTUs of the link. Let's take this to the mailing list. Operational Issues Associated With Long IPv6 Extension Header Chains, draft-wkumari-long-headers , Ron Bonica, 5 min. ----------------------------------------------------------------------- Dave Thaler: Routing Header does not belong here. You must process it only if it is destined to you. I that case, you're kind of proxying -- i.e. regenerating the packet. Ron: This may need to go to enhanced. Tim Chown: Both Fernando Gont and I have done some tests with respect to extension headers and fragmentation, and briefly talked about it yesterday at IEPG... and the statistics of the amount of packets that are dropped if you do longer and longer headers chains is startling and similar if you employ fragmentation. Ole: Can you send it to the mailing-list? Tim: We're pushing some short article, but I can send a summary of the stats. Ron: I'd love to reference those stats. ----------------------------------------------------------------------- Meeting Adjourned -----------------------------------------------------------------------