6MAN Working Group - London IETF Meeting Tuesday, 1610-1840, March 4, 2013, Viscount Chairs: Bob Hinden, Ole Troan Minute taker: Fernando Gont Jabber Scribe: Dan York Jabber Room: 6man@jabber.ietf.org Meetecho: http://www.meetecho.com/ietf89/6man Slides can be found at: http://www.ietf.org/proceedings/89/6man.html ----------------------------------------------------------------------- Agenda ----------------------------------------------------------------------- Working Group Documents Introduction, Agenda Bashing, Document Status, New Charter, Chairs, 15 min. Packet loss resiliency for Router Solicitations draft-ietf-6man-resilient-rs , Suresh Krishnan, 10 min. Recommendation on Stable IPv6 Interface Identifiers draft-ietf-6man-default-iids , Fernando Gont, 15 min. Privacy Considerations for IPv6 Address Generation Mechanisms draft-ietf-6man-ipv6-address-generation-privacy , Alissia Cooper, 15 min. Analysis of the 64-bit Boundary in IPv6 Addressing draft-carpenter-6man-why64 , Brian Carpenter, 30 min. Efficient ND session (45 minutes) Problem statement draft-yourtchenko-colitti-nd-reduce-multicast, draft-vyncke-6man-mcast-not-efficient draft-chakrabarti-nordmark-6man-efficient-nd, Erik Nordmark, Eric Vyncke, 13 min. Solutions within existing protocol specifications, Andrew Yourtchenko, Lorenzo Colitti, 13 min. Unresolved problems and larger changes required, Erik Nordmark, 13 min. Summary , Chairs, 5 min. Speed Talks (5 Minutes, 3 slides) --------------------------------- Transmission of IPv6 Packets over IEEE 802.11p Networks draft-petrescu-ipv6-over-80211p , Alexandru Petrescu, 5 min. Triggering ND Address Resolution on Receiving DAD-NS adraft-halpern-6man-nd-pre-resolve-addr , Helen Chen and Joel Halpern, 5 min. IPv6 Universal Extension Header draft-gont-6man-ipv6-universal-extension-header , Fernando Gont, 5 min. Validation of Neighbor Discovery Source Link-Layer Address (SLLA) and Target draft-gont-6man-lla-opt-validation , Ron Bonica, 5 min. Introduction, Agenda Bashing, Document Status, Chairs, 15 min. ----------------------------------------------------------------------- Ole opens the meeting Ole goes through the proposed meeting agenda, and document status. Stig: Regarding the Architecture I-D, we put out a new version a couple of weeks ago. Unless there are any issues, that should be the last one. Ole notes that there was consensus on abandoning draft-ietf-6man-addr-select-considerations. Documents that referenced this I-D were updated accordingly. Ole notes he did an experiment to measure how the wg discusses topics. Graph show in slides. Discussions are mostly bursty. Packet loss resiliency for Router Solicitations draft-ietf-6man-resilient-rs , Suresh Krishnan, 10 min. ----------------------------------------------------------------------- Ran Atkinson: I prefer what you call b.2 ("Make it a SHOULD and add a MAY to allow retransmission"). I think that ND is over-specified. If we relax the specification a bit, we can let people optimize their implementation for their deployment environment. And it will prevent ND code bloat from getting worse. Erik Nordmark: We will talk more about ND later. But I suspect we will end up with an specification that has some for of "refresh". I kind of agree with Ran, but if we left implementations do all kinds of things. We should give implementations enough information such that they can make an informed decision. Lorenzo: Saying "hosts must stop retransmitting RAs" is silly. They should be allowed to send an RA whenever they want. - e.g., when expiration of some information is imminent. e.g., there might be losses in multicasted RAs. I don't think there's a good way of supporting 1.b.. In any case we should say (even if we remove 1.b" that a host MAY send an RA is some connectivity parameter is about to expire (DNSS, DNSSL, PIO, etc.). Suresh: I think we should do "b.2" and "a"- Andrew: I agree with both Erik and Lorenzo. We should not explicitly prohibit hosts from 1.b. Suresh: If we keep 1.b., we would need to address it. Andrew: Don't prohibit it, so that it may be addressed in another document. Erik: What we don't want is packet floods arising from nodes retransmitting RAs once some information expiration is imminent -- particularly when it was actually intended. We should put some necessary guards here. Thomas?: You want a MUST for rate-limiting. There's a lot of room for flexibility within rate-limiting. Suresh: In the I-D there's a configuration variable that specifies the maximum rate. It says the host may transmit at this maximum once every half an hour. Thomas: Even here some judgement would be useful. On a cellular network, it might seem like a lot. But on a 1G interface, what's the problem? Ran: Tom hit the nail on the head. We have a single ND spec, which doesn't take into account the specific of the link-layer. We have to have implementations that are reasonable. Reasonable implementations could behave normally, and good advice such that they do not something stupid (e.g. retransmit after 1 ms). Tom: Absolutely. Dave Thaler: Keep scenario 1.b. Do constraints on rate-limiting. We have cases where ND varies by a specific ling-layer. Indeed, the mechanisms in this document comes from one of those documents. I think I'm in agreement with what I think is the consensus. Lorenzo: The reason why we have this draft is because we put ourselves in a corner because we said "3", but no-one can do "three". And nobody can do 4 either, because it'd be against a std track document. We should relax the spec such that we don't get into this problem again. Recommendation on Stable IPv6 Interface Identifiers draft-ietf-6man-default-iids , Fernando Gont, 15 min. ----------------------------------------------------------------------- Phillip Mathews: Why do we have this second document to mandate what's in stable-privacy-addresses rather than doing that in stable-privacy-addresses itself? Fernando: At some point we had a single document, and as sections began growing, the wg decided to split the documents. Bob: The other document is the RFC-Editor. We could pull it back and ran it through the whole standardization process to add this, but I think that'd be a bad idea. At the time, we didn't know what the recommendation would be. Now that we have figured out what the recommendation is, it seems reasonable to have it in a separate document. Mathews: Just hoping that we could keep the number of documents small. Fernando: Summing up, what we have in our todo list is to add the missing "ipv6 over foo" references, and then the document would be ready for WGLC. Samita: Please consider sending a note to 6low asking for input. Should be ready for w.g. last call after next revision of the document. Privacy Considerations for IPv6 Address Generation Mechanisms draft-ietf-6man-ipv6-address-generation-privacy , Alissia Cooper, 15 min. ----------------------------------------------------------------------- Bob Moskowitz: I want link-local addresses to be included. I been pulled very heavily into the connected car. IEEE 1609.2 has a tremendous work in trying to maintain anonymity for safety. I'd like to count on link-locals to provide anonymity. There's people that wish to turn safety off because of concerns with privacy. Dave Thaler: Can you clarify in which scenarios you could have access to the link-local address but not to the link-layer address? Alex: It's true that in Ethernet and wi-fi when you see the link-local, you see the MAC address. But we're not sure about other link-layers. Dave Thaler: It is not obvious what to say. That's why we don't say anything. Bob: I'm just getting into this. The more protection we put in different places, the better I'm going to feel. I don't want to rely on MAC randomization for this. ???: Not sure why you say link-locals are out of scope. Link-locals have to do with the prefix, but this I-D is really about the suffixes. So it is in scope.. there's nothing unique about them. Dave: Let's just remove the text that says "link-locals are out of scope". Fernando: I agree. For instance, when working on stable-privacy-addresses, we decided to employ the mechanism for link locals too, because there are scenarios in which these addresses might leak out -- e.g., consider a host connecting to a local mail server, and the link-local address gets recorded in the email header. Another example could be nodes that just publish all of their addresses in the DNS, etc. We should probably not talk about scopes here. The only effect of the scope is that, in principle, that's how far the address might leak in principle. But there are ways in which they could leak further. ???: What's the change that you propose? Fernando: Essentially, we shouldn't focus on the scope of the prefix. We should just remove the comment that link-locals and ULAs are out of scope. Erik Nordmark: Good to improve privacy properties of link-locals. IN some cases things might be tricky. e.g., at times you don't really know when you move to a new link. e.g. when you send a RS, do you keep the same Source Address, or use a new one? Beware that there are additional concerns when considering boot-strapping with link locals. Tim: You have a section on compliance. But it's not entirely truth what it says there. For example, for the US GOV the test requires that the address is privately generated. It is not required to be EUI-64. There's a test case to be made only *if* the address is based on the MAC address. If it's not, you don't need to do that test. Fernando: There was a request to analyze the impact of the prefix length on privacy. I'm not sure whether we should discuss that in this I-D or in the why64 -- since this document assumes we're operating with the current specifications. Mikael Abrahamson: In 3GPP we're already sharing the same &64 on two links.. so that might be done with link-locals, too. So i believe there are cases where the link-locals might leak out. Ole: Once the issue of link-locals is sorted out, we can do a WGLC. Analysis of the 64-bit Boundary in IPv6 Addressing draft-carpenter-6man-why64 , Brian Carpenter, 30 min. ----------------------------------------------------------------------- Lorenzo: RIO is supported in Linux, but needs to be turned on. Fernando: I tested systems with the default settings. For the "L" bit, the reason for which anything other than 64 bits doesn't work is because IIDs are currently required to be formed from a MAC address. Jinmei Tatuya: For BSDs, the specs required the IIDs to be 64 bits. That's why anything else won't be allowed. Brian continues the presentation, and notes that some forwarding devices have been shown with prefixes longer than /64s. Lorenzo Colitti: We have some that do not work. Ran: There are boxes for multiple commercial vendors (routers) for which the way in which they use TCAMs mean that if the prefix is more than 64 bits it treats all instances longer than 64 as the same hit in the TCAM entry. That's pretty common. Lorenzo: Ours wasn't that broken, but it didn't work. Lorenzo: Some boxes use a different table for supporting /127, such that they don't need to increase 2x for the whole table. Brian continues, and notes that there's evidence that people use longer prefixes with DHCPv6. Lorenzo: /120 will only work if everything is off-link. Otherwise there would be the breakage you mentioned before. Brian continues with the discussion of privacy. Lorenzo: What you describe is not exactly true... since in IPv4 there's NAT, which masquerades the systems. Jouni: There might be other non-ietf documents that rely on /64. Dave Thaler: Useful to adopt, such that the discussion does not come over over again. Additional notes: the /64 thing is also hardcoded in many books, etc.. Another is that /64 is also hardcoded in a non-zero number of applications. Lorenzo: You noted that a motivation might be "insufficient address space". The provider always has more address space. If it simply wants to charge more for that, then we'll get into an arm race: i.e., eventually they'll assign /128 to customers. Thomas Narten: You mentioned that at least 30 RFCs would need to be updated if one were to update this. But many of those are probably historical. If one were to try to fix it, there's too much out there that you can probably not fix any more. Erik Kline: I like this. I would support wg adoption. Dan York: Relaying for two people on Jabber, they find this document useful, and would support adoption. Ditto for him as an individual. Dimitri: I'd remind that NAT64 support prefixes other than /96. The other thing is that when you change the subnet size, you change the probability of collisions e.g. for temporary addresses. In such cases, you probably couldn't do optimistic DAD. There may be many RFCs that do not explicitly mention "64", but still rely on it. Erik: The document seems to be written down defensively. Like explaining the obstacles to changing this. But it doesn't mention the benefits. Brian: If that's what the wg, we'll go that way. We just tried to be neutral. Phillip Mathews: The document should say up front "why 64 is the right decision". ???: Out of curiosity: Did you check whether changing the length to something larger would affect the performance of forwarding devices? Brian: No, but there's a rumor that it does, because of how the way silicon is implemented. Jinmei Tatuya: Some DHCPv6 clients assume an /64 link. Otherwise, if there's no local router, they cannot communicate with each other. Ole polls the wg for adoption. There is strong support to adopt. Chairs will confirm on the mailing-list. Efficient ND session (45 minutes) ----------------------------------------------------------------------- Bob introduces the ND session Bob: We were reading the mailing-list discussions on the topic. There seems to be interest to work on this topic, but not necessarily on the specific solution. So we thought it would be good to make a step back, discuss the problem, come up with a design team, work closely together, and come back with a recommendation for what the wg should do. There's a lot of agreement this is an important area, but not necessarily about the specific details. Problem statement draft-yourtchenko-colitti-nd-reduce-multicast, draft-vyncke-6man-mcast-not-efficient, draft-chakrabarti-nordmark-6man-efficient-nd , Erik Nordmark, Eric Vyncke, 13 min. ----------------------------------------------------------------------- Erik Nordmark introduces the topic, and notes that there has been some overlap in terms of the problem statement among different documents. Stuart Cheshire: I agree with the slides. One thing to add: battery powered devices work hard to save battery. There's a parameter for the beacon frame I think it DTIM....it's basically a promise "I'm not going to have any multicast for you on the next beacon or the one after, so you can actually wait 300ms, but you can get aggressive and make it ten, and only need to wake up after 1 second. Eric continues the presentation, and discusses the issues of multicast in wi-fi networks. Lorenzo: It's not as simple as that. If you take one single packet between one station and one host, multicast is cheaper because in the multicast case the packet is sent, but not acknowledged. And in the case of unicast, the packet needs to be acknowledgement, and the acknowledgment causes the radio to spin up. For instance, there was a presentation by Aruba in which the tried to save battery by converting multicast to unicast. ???: Extending on what Lorenzo said. Run a network with 10K people, and still didn't solve the problem, with conversion of multicast to unicast, but that didn't solve the problem. There are still NDP scaling issues. Eric continues with his presentation, and notes that MLD snooping is not widely implemented. Phillip Matthews: I would like to note that a number of IPv6 nodes don't send their MLD reports. Eric continues... Erik: We talked about wi-fi, but we don't want to end up with an IPv6 over wi-fi specification, but rather want to do something that is useful for other radio technologies. We also care about incremental deployability. Next we'll look at different timeframes: from protocol tuning (operational advice) to protocol changed. Erik Kline: Question about the traffic in your previous slide: isn't the NS traffic NUD? Eric: No, they were multicasted. Ralph Droms: When you talked about generalizing this improvements, there's a crucial binary choice: are you restricting to "hub & spoke" or are you including mesh networks. Erik Nordmark: I don't want to restrict myself very much, but don't want to have IPv6 or NDP over wi-fi. e.g., have a set of options and parameter that you can tune for your set up. Ran Atkinson: Typical RF link-layers prefer multicast, because it's the most efficient thing they have. I'm concerned that we might be over optimizing for 802.11, and this might permeate into the IPv6 stack itself. Typical RF link-layer don't have these problems. Pascal Thubert: Back to your first o second slide, radio did not only cause more devices to be connected, but also the mobility that is important. We should consider supporting mobility. Mobility causes more multicast exchanges. Dimitri: Just to make sure that I wasn't mis-interpreted. I agree that ND is to chatty. But should also note that in the traffic you've shown there was a lot of mDNS traffic, etc. Stuart Cheshire: I agree the mDNS traffic is too much. The answer is to make the multicast domain smaller without sacrificing the scope ???: Expanding on my previous comment. I'd be careful with considering replacing multicast with unicast, because there are two things that work very well. caching ND and ARP, and playing with the timers. Solutions within existing protocol specifications , Andrew Yourtchenko, Lorenzo Colitti, 13 min. ----------------------------------------------------------------------- Samita: This (raise the maximum RA interval limit) is the mechanism that is used in many of the networks that have problems. For example 3GPP networks and 802.16. Just wanted to note that this is already used. Andrew: We don't want to prohibit this, but also don't want to say "You can send RS whenever you want". Ran Atkinson: What you're saying is that if we relax the current specs without adding stuff, IPv6 implementations running on 802.11 can do significantly better? Andrew: Yes. ???: How much data do we have to back much of this stuff? My concern is that a lot of details are important, and we might be misunderstanding what the root causes are. Lorenzo: I agree with you. Pascal Thubert: For the next rev, discuss unsolicited NAs, e.g. during DAD. THey are particularly disruptive. Another one is movement: what do implementations do in this area. Last one: I agree with you about proxies (they could be a good solution). But then it needs a better process to get all the attached addresses, other than snooping. Lorenzo: There's a fundamental difference between the two. That's why we said "snooping proxy". Eric Levy?: We should have the tools in order to be able to handle cases where discovery is unreliable. Lorenzo: We have a bullet on that. Unresolved problems and larger changes required , Erik Nordmark, 13 min. ----------------------------------------------------------------------- Erik describes the case of a node rebooting and loosing state. ???: We had three or four router reboots, and it broke the network for about ten minutes. Erik finishes his presentation. ???: One of the goals could be that power consumption in home networks is similar to power consumptions in networks such as here -- currently it's in the order of 4x. Summary , Chairs, 5 min. ----------------------------------------------------------------------- Ole: First, we need more information. Second we need to form a design team (talk to the chairs if you want to volunteer). --------------------------------- Speed Talks (5 Minutes, 3 slides) --------------------------------- Transmission of IPv6 Packets over IEEE 802.11p Networks draft-petrescu-ipv6-over-80211p , Alexandru Petrescu, 5 min. ----------------------------------------------------------------------- (no time for discussion of this presentation) Triggering ND Address Resolution on Receiving DAD-NS draft-halpern-6man-nd-pre-resolve-addr , Helen Chen and Joel Halpern, 5 min. ----------------------------------------------------------------------- Lorenzo: Have you considered making this more efficient by including a link-layer address option in the DAD solicitation, hence the router will get it and create a stale cache entry. IPv6 Universal Extension Header draft-gont-6man-ipv6-universal-extension-header , Fernando Gont, 5 min. ----------------------------------------------------------------------- (no time for discussion of this presentation) Validation of Neighbor Discovery Source Link-Layer Address (SLLA) and Target draft-gont-6man-lla-opt-validation , Ron Bonica, 5 min. ----------------------------------------------------------------------- Ran Atkinson: You meant "Must discard with ICMPv6 processing" Erik Nordmark: This is a no brainer. One of the scenarios could still be triggered with these checks if you have two routers on the same subnet, and you send forge NAs such that you make the mappings of each router point at each other. Chairs will do adoption call on the mailing list. ----------------------------------------------------------------------- Meeting adjourned -----------------------------------------------------------------------