Intarea wg meeting IETF 82 Taipei WEDNESDAY, November 16, 2011 1300-1500 Afternoon Session I Chairs: Suresh Krishnan & Julien Laganier Minutes: Ole Troan 1. WG & Document Status (Chairs) --------------------------- draft-ietf-intarea-ipv4-id-update. Joe giving update. Joe: problems that this creates are already in IPv6 treat IPv4 without fragmentation as IPv6. draft-ietf-intarea-ipv6-required: Suresh: going to be an update after this meeting. doesn't look like it will require a new WG last call draft-ietf-intarea-tunnels: Suresh: document stalled new documents: draft-fleishhauer-ipv4-addr-saving can someone volunteer to take a look at it? Wes and Tina Tsou will review. draft-shen-traceroute-ping-ext volunteers to review document? No volunteer. 2. L3 Overlays for Network Virtualization -------------------------------- Thomas Narten 15 minutes draft-narten-nvo3-overlay-problem-statement-01 Objective: This presentation aims to provide an overview of the potential IETF work related to providing L2 network virtualization service over an L3 overlay network. The main work will be performed in l2vpn but the work is connected to several INT area working groups and hence is being presented here to publicize the work. Rajesh(?): the applicability is primary in the DC? Tomas: the driver is the DC. 3 . Revealing a Host Identifier in Shared Address Deployments ------------------------------------------------- christian.jacquenet@orange.com ( Mohammed Boucadair 10 mins) draft-boucadair-intarea-nat-reveal-analysis-04 Objective: The authors would like the wg to adopt the document as intarea wg item. There will be a call for adoption in the meeting (to be confirmed on the mailing list after the meeting) Suresh: Clarification. why in intarea? even though it says NAT, the concerns are valid outside of NATs? Hanes(?): some use source address as a way for authentication. my recommendation is to NOT do it. it is a stupid way. there are other mechanisms much better suited in other layers. Christian: there is a reality for that. where there are use cases for the source address being used for authentication without having to re-enter username/password. H: only because people are doing something, doesn't mean the IETF should do it. C: the scope of the document is to document the problem. S: it analyses different approaches. H: other people do something else, and they use different solutions. my recommendation is using ip address as a way as a new authentication is not a good thing to do S: clarify the document. if you are using ip addresses today for this, these thing is going to break with shared ip address. if you still want to do this, then this is how to. doesn't make a stand if it is good or bad. Joe Touch: co-author. the document doesn't say don't. it says where it is problematic and doesn't work. it does list pros and cons. it is an analysis, doesn't give recommendation H: it is a biased analysis. it describes a fairly obviously flawed idea... do we need to explain to people that a shared IP address doesn't work for authentication? Alistair(?): privacy implications should be included in the chart in the draft. what endpoints may do when they receive an XFF header and what the interactions may be. the document needs a thorough review. S: you are volunteering to review? Dan Wing: privacy being provided by NAT... there is not much privacy, I wouldn't worry. there are both good and bad guys behind a single IPv4 address. there needs to be a way to distinguish between the good and bad guy. they can't do that anymore, only choice is to turn off service for everyone behind that shared address. that's the big one Wes George: +1 to Dan. just one piece of a larger. SPAM and abuse; all sorts of blocking of that. we have a number of behave orphans that need a home. quite a few behave orphans, don't know where this should belong. Tina Tsou: this draft listed 7 different approaches. besides this document we need a recommendation Allan: like to see real world problems. this is a major problem. needs sense to document the problems space. we need a reference from the BBF for this. Alain Durand: this is an existing problem. if you have a wireless phone you're behind a NAT. nothing to do with authentication. it is about a DOS attack. today the whole address even if shared by 1000 people will have to block. Hanes: comment on privacy. I wish the document would be more complete on that. if the attitude is there is no privacy anyway; that's not getting us anywhere. there are a couple of other recommendations fro mthe regulatory bodies. done on other layers. S: are you volunteering add privacy text, or do you volunteer to review? H: I would do it entirely differently. it should not be talking about the 'authentication' that should not be the scope. S: this is a broader document. H: who doesn't know that many hosts can be behind a NAT...? no purpose in stating that. Dave Thaler: telling people that it exists is already in 6269. this documen should be scoped to the DOS case, then you could evaluate what you could do. and it may be different what solution chosen for the DOS problem versus the 'authentication' problem. my suggestion is to take the document and talk about the DOS problem. Joe: there are many problems it created beyond DOS. there are not attributed to the assumption of single IP address == single user. there are other groups making assumptions about traffic going to the same IP address. got do with cookies... TCPM. 1122 is responsible for all these requirements and it is ignored. same IP address does not mean same machine. don't focus on only DOS attack just for that reason. *Dave / Joe exchange... Suresh: the comment is to take the scope down. Allan: many other examples. QoS, billing... traceability should be a target. if you scope the document in that realm Hanes: scoping down would help... S: blame tcp, some parameters are determined based on IP address. S: at this point it is a personal document. if it becomes a working group document we can handle that. Alain: the NAT is in another administrative domain, you have no control. it must work for basic cases we care about. DOS is shared between all of us. if it is a local problem you don't need to talk about it here. Joe: this document is about what people do. not all approaches work for for all solutions. if we end up documenting these approaches, then we can turn around and document recommendations in another document Alain: that doesn't change the problem. if I try to distinguish the traffic on the other side of the Internet, we need to standardize... Joe: it is not necessarily through that they have to do the same thing... Suresh: Clarifying. * Discussion: Joe, Alain, Suresh Joe: your problem is with a document doesn't exist. that is the next one. out of scope for this one. Hanes: the presentation stated that it would present recommendations? Chris: this is between 6269. intermediate phase. Joe: there is no recommendation what to use, it tells you what is bad. Dave Thaler: same confusion. I liked what Joe said. take my comments on the future unwritten document. I understood from the slides that both would be included in the current document. Chris: sorry about the confusion. Alain: thanks for clariying. I'm interested in the stage 3, where will this recommendation and solution document go? intarea, softwires, behave? Suresh: Jari, Ralph any comment? Jari: finish this work first. we're not there yet. we have to see where go from there. Hanes: the abstract says something different... S: it will get fixed. Alain: nervous when we have no clear path forward to a solution Ralph: hold on. which are you complaining about? target wg? or solutions? we gave you an answer. Alain: I'm not happy with the answer Dave: I think it should be here. Suresh: how many in the room believe that there is a problem to be solved? and that this document is a starting point for that? Hanes: the question should be: does the document adequately is a starting point for summarizing currently deployed solutions for the problem, what we discussed here? Suresh: the document needs to be fixed. Jari: earlier you mentioned the document solving a problem. I'll phrase is this a good document for documenting the possible alternatives for addressing these problems? we're trying to analyse them no committment. Suresh: do you believe an analysis of this problem is needed? *** YES: Many (35) hands NO: Few (2) hands Francis: it would be nice to have someone from ISOC this infringe my right as a European citizen. Suresh: I declare the document adopted depending on mailing list verification Ralph: we haven't come to a conclusion where it should be you? the analysis is fine, sorry was confused. Suresh: do you believe this document should be adopted as a starting point for Yes: Many (25) No: very few ** Document adopted in intarea pending verification on the mailing list. 4. Energy Awareness in Neighbor Discovery ---------------------------------- Erik Nordmark/Samita Chakrabarti 15 mins draft-chakrabarti-nordmark-energy-aware-nd-01 Objective: This potential update of ND could end up being useful to multiple wgs (armd, lwip, 6man etc.). It is being presented in intarea to publicize the work. Suresh: why is this interesting to multiple working groups in the intarea? Erik: if it applies to different radio technologies, Ethernet. thinking of splitting this off. Jari: repeating comments from 6man. this is interesting, we need to something like this. we also need to look at optimizing ND for low power devices. is it possible that 4861 say something stupid with regards to low power nodes. Erik: we need to go through DNA thoroughly Jari: DAD may be something to think about. you are doing it in a more efficient manner. tiny transistor things don't have an UI. they can't do what 4861 recommends. you're stalled if you have a collision. the outcome may be not be different even if you optimize... Erik: you have to keep on trying. Dave Thaler: this is good work. unrelated multicast, isn't the probability close to zero? Erik: depends on the link layer type. Jari: if they are not implementing MLD snooping... Dave Thaler: the point is if you do MLD snooping Erik: it matters on a radio network Dave: I like the direction, one aspect is to use less multicast. down to a single message. we have some link types that don't support multicast. the techniques are not common. e.g. ISATAP. there is no multicast there. here you are going one step further. Carsten: the more general point. there are node types that don't do multicast as well as link types. the take home message is that we have to reconsider that all links have multicast. secondly you run into all the DAD issues that we had in 6lowpan. 5. IPv6 Flow Label for Server Load Balancing -------------------------------------- Brian Carpenter 10 mins draft-carpenter-v6ops-label-balance-00 Objective: This document is operational in nature and describes the use of flow label for server load balancing. It is being presented in intarea to publicize the work since load balancing community tends to go across multiple layers and therefore multiple IETF areas. Brian: open question. should we do this and if so where? Wes: yes, v6ops. Hanes: the question I would have. have you talked to some of the vendors, they like it a lot. they have to implement application layer functionality... Brian: there is a lot of proprietary stuff in load balancing. L3-L7 load balancing. haven't talked to any vendors. want to see some adoption of flow labels in host stacks. Brian: this is not a standard, a descpription Joel: v6ops chair, we're not opposed to it. as a customer of load balancers. they love stuff that don't require producing more state in their devices. I think there is certainly room for this discussion to mature. Dave Thaler: yes, and I don't know. you pointed out two problems. there is no document on load balancing. I don't know what the answer is to the second question. maybe v6ops isn't the right place. Joel: we've gone around... about rehabilitating the flow label. if I was provokative if people had routinely had reset it on the edge it would be less useful for hosts. 6. One Vision for IPv6 ------------------- Randy Bush, Mark Townsley and Dan Wing No Draft Objective: This is a discussion about how to arrive at a unified vision for IPv6 Brian: I have wondered for years. why are so many SPs working so hard on extending the life of IPv4. why aren't SPs making it their business to pressure content providers to make their content available on v6. Randy: we published v6 in 97. there were no packets. the content people came out this year. it all has to happen at once. the chances of that happening was about as good as cash falling through the sky. that didn't happen, so where do we go now? the content providers have dual stack. the next step we'll see is the content providers are leaving it up. don't spend energy on keeping v4 on life support. Hanes: I like the presentation. most people here agree with you. involved in transition mechanisms. Randy: there is a life support salesman behind you (Alain) Hanes: you're talking to the wrong people. quick money == selling life support. what should we in the IETF do? Randy: go to the mechanisms that move you towards IPv6. don't choose mechanisms that use IPv4. do not choose IPv4 transport. we have all the mechanisms we need, but we are spending all this energy over here, supporting v4 life support. what looks like short term solutions that create long term problems. suicide is a short term solution for a long term problem. Alain Durand: life support vendor. this is great. this is what we have articulated for a long time. to decouple IPv6 in the network and IPv6 service. the patient that is very sick now, may not be able to wait 10 years for all the pieces to be there. we can't unplug the patient now... Mark: within the IETF, there are mechanism that makes us head in the same direction. Alain: no objection. Mark: no objection to not working in mechanisms that use IPv4 transport? Alain: it makes no sense to me since all mechanisms require ip address sharing Randy: can you do that over IPv6 transport? are you dropping SD-NAT? Alain: no. it can be done over IPv6. read the document. Randy: bullshit... Mark: it doesn't belong in the IETF. the IPv4 over IPv4 is not the thing we should do. Dan: NAT reveal stuff. that's only necessary when we share IPv4 addresses. that's part of the stuff we need solving on the left. Andrew Sulivan: I'm surprised if anyone in this building disagrees with this presentation. ** discussion of transition mechanisms. we need to stop doing 80% to 80.02% optimizations... Wes: yes, you are right. a leadership problem. this is my new idea, the use case is slightly different, and I will not make any compromise. many proposals shouldn't get past the discuss stage. the should be a statement from the IAB. Mark: trying to delineate between mechanisms that are life-support and which ones are transition. and we have to deprecate the things that don't work. that require a lot of leadership. the simple question on the table. do we focus on the left lifesupport.. or transition Jari: full agreement on the recommended direction. .... I've been pushing back on many of these things. we have 100 people saying that we need a 1% improvement on this... if we hear that this is the right direction, then that gives leadership a direction Ralph: 100% getting the message. we shouldn't do transition mechanisms that aren't moving us forward to IPv6. we must be dilligent about adopting and working on transition mechanisms that are mechanisms that only optimize the 1% or that are life support IPv4 mechanisms. working group chairs should also be introduced to the fact that we should only work on mechanisms that move towards IPv6. Randy: Q from Ralph. stop IPv4 life support mechanisms? Ralph: I will try to do the right parenting thing, I can't promise to do the right thing Jari: we've tried to dictate. with the help of IETF consensus, it is easier to say no. Randy: some thing we've talked about is architecture. it would be nice if this group had someone who dealt with architecture. Stuart Chesire: need to support long tail IPv4 and skype. I see them as different things. the Internet has become so crappy... only HTTP works. as long as we can make HTTP work moving forward, that's the long tail that we can't fix. skype on the other hand, is not in that legacy unsupported mode. I believe if we have an IPv6 network, then those applications will change. Alain Durand: life system support vendor. it isn't only about unicast. the want to move along this line, but they multicast is required too. we're getting religious. we need to make sure IP addresses are shared as efficiently as possible Randy: doing so over an IPv4 transport is bad. stop giving life support is bad. you are construction a false argument. Mark: