Intarea WG IETF 84 WEDNESDAY, August 1, 2012 1510-1710 Afternoon Session II Minute taker: Linda Dunbar 1. Agenda Bashing, WG & Document Status (Chairs) 10 minutes Suresh: Most of the agenda items are informational Way forward with the NAT reveal analysis draft All 20 mins draft-ietf-intarea-nat-reveal-analysis-02 Objective: There were some significant concerns raised about this draft in WGLC. This slot will entail a short presentation and a discussion as to what the goal of the draft should be. The goal is to figure out how to move forward with this draft. Dan Wing made the presentation: 1. There is a engineering problem RFC 6269 Issues: One user who fails a number of login atemps may block out other users who have not made any previous attemts but who will no fail on their first attempt. 2. Discuss solutions Collect proposed solutions Analyze differences Recommend solution: Analyze 8 proposals: IPID field, IP option, Port sets, ICMP, TCP option, PROXy protocol, 3. Engineer the best solution Consensus on problem in RFC 6269 $13.1? It doesn’t look like that we reached it. Charlie Perkins: a lot of options are missing from your 8 solutions listed. It seems to me that whatever solution you made, you are favoring some subset. I agree with you that it is not done, but we need to explain the ramifications. Suresh (Chair): today’s design is poorly designed, using IP address to check. When multiple people have same IP address, how to Charlie: I fully understand it. There is FMC which has similar things defined. Chair: you are already having some assumption. Whether using FMC or not is another topic. You are welcome to contribute to the solution here. Joel Halpern: There is problem. I think the draft mischaracterizes the issue. The people who wrote it think it is a good answer, but other people disagree. I don’t think that recommending an answer when all the option of answers are wrong. Dan: What is your answer? Joel: I don’t think that we have any answer. Recommending a bad answer when there is no good answer is bad practice. Chair (to Joel): is it a good idea to document it? Joel: yes, just recommending an answer is bad idea. Chair: would you be able to read the document and provide the comments? Joel: OK Francis (ISC): Any solution needs a change to the servers. It is easier to ask them not to use IP addresses. Chair: you are saying, if the server is changing anyway to use one of the solutions, you might as well recommend something better. Francise: Yes. it is simpler to fix it without using IP address. ??: it is definitely a problem. How long it will take for any of the solution to perfect itself. Dan: I keep hearing the complaint. Is IPv6 geared for privacy? Chair: The goal is not to make any recommendation. So I don’t want to have the discussion here. Francis: IPv6 doesn’t solve the problem. Tim: It is not TCP option; it is middle box inserting TCP option. All of them look like in-band solution. I think that we need to look at out of band solutions. ZhangSheng: If we have to choose one, the second best choice is to use what we have. The second best choice is ours because it is already widely used. Chair: are you aware of the pros/cons? Zhang: I know, that is why I state it is the second best. Chair: would it be OK to document pros and cons? Chair: We need to close this document. Do you think the problem is real? Response: most. Chair: Do you think it is valueable to document the pros and cons: Response: 10. Chair: Do you think it is not valuable? Response: none. Chair: if you think there are pending issues, please raise your hand. Response: 1 (Tim) Dan: Can you point out where is the problem then. Tim: I don’t know what to do with this document. This document is not on one solution, but on a group of solutions. I don’t know how to improve it. Tim: Maybe category of out-band should be addressed. Different people may want to use it differently, some people may want to use it out of band. Chair: Sometimes we need to move on with the draft. We can’t just keep looping here. Dan: So we just document this and say none of them works? Chair: no, we just document the pros and cons of each solution. Chair: We will just continue with the mailing list discussion. Omniran update Charlie Perkins 15 mins Make people aware of an effort called Omniran that is currently being worked on by the IEEE. OmniRAN Architecture done by IEEE Heterogeneous Networks. Functionality Menu: it is impossible to do all of them. Brian: they are very interested Charlie: it would be nice if IEEE did it right. Multihoming with NPTv6 Ron Bonica 20 mins draft-bonica-v6-multihome-03 This draft was presented earlier at the intarea meeting and significant objections were raised. The authors have made updates to the draft to resolve some of the issues (e.g. BCP38 filtering) but the generic address translation related issues remain. This presentation will discuss these open issues and the goal is to see if there is interest in further exploring this problem space. Address Translation types:1:1; N:1 We have more experience with N:1. 1 Is sues of Transient N:1 Translation 1 –Routing symmetry required 2 –Connections can be initiated from one side only 3 –State/scaling Issues 4 –Accounting/logging/lawful intercept issues 5 –IP addresses embedded in IP payload don’t get translated (aka, the referral problem) 1 Persistent 1:1 Translation 1 –The referral problem Referral problem will stay with us for a long time. Referral problem is broader scope. There are 3 proposals in front of us. Trying to get feedback on which is better. Sheng: Why it is a problem? Ron: Dave: The referral problem is not new. The big difference is the translation. You are proposing something which is not short term. Ron: We have to find a solution which is not so painful that it can last. Dave: I am not sure the difference between the two is necessarily the same. ??: TCP was a short term solution. It was a hack solution. But 20 years later, we are still using it. My point is that Referral problem is just the symptom of the problem. The problem is that the problem addressed by this one is the simpler one. There are harder ones. If we declare victory on this one, but the leave the harder one Ron: that is why I have another document. Concern about whether the solution will be looked at as a whole if it is in two documents Lorenzo: Lots of NAT used today – it isn’t perfect but is used. Go ahead and progress the current document. Don’t wait to solve the referral problem Margaret: Referral problem is a general problem that needs to be fixed anyway. Don’t put it in an experimental document. Put it in its own document as a standard – generic, fully visible. Ross: Don’t hold this document up for referral solution. There is no free lunch. People want one address per client. Less routes in the router. Outside the NAT, there is a single address. I’ve seen all kinds of solutions which will cost too much. The hard problem is to get application to use it. I don’t think it worth Chair: I don’t think we can make decision now. Let’s poll on the mailing list and reach consensus. IPv6 Flow Label for Server Load Balancing Sheng Jiang 15 mins draft-carpenter-flow-label-balancing-01 The document (in a different form) was presented earlier at the intarea meeting. The draft has been updated significantly and reorganized since Paris and the authors will present the changes. Chair: the problem with this draft is that we don’t have LB experts. Luckily Julia, who just stepped in, is LB balancer expert. Maybe we should let her review it. Sheng: initially there were two authors. Recently we added the 3rd author who is LB expert. Chair: Let's get a review and then discuss on the mailing list. Scaling ARP for large data centers Tal Mizrahi 15 mins draft-nachum-sarp-02 This document provides recommendations for architecture of data centers to constrain ARP and ND messages. The authors would like to get some feedback from intarea regarding the idea. ??: Sunset: should we continue any work for IPv4? Dave Thaler: It looks that the solution is not IPv4 specific. If yes, should revise the text to reflect IPv6. This solution alone doesn’t work for IPv6. Ralph (AD): Has this problem been discussed on the mailing list? Tal: yes, it has been discussed on the armd mailing list. IEEE Registration Authority Committee Glenn Parsons 15 minutes (No Draft) Make people aware of the work of the IEEE Registration Authority Committee. RAC: goal is to make sure that MAC addresses don’t run out for next 100 years. Should an EUI-48 be the network identifier for VM, equivalent to an EUI-48 on a physical machine? Yes, in the short term, maybe not in the long term Assign OUI address blocks for VM applications (for either or both of the local and global address space) and allow them to be reusable. If in the global space, concern that this will dilute the value of EUI-48. Create a DHCP like mechanism to allow dynamic assighment of EUI-48 addresses. Force deprecation of random EUI-48 assignment. Create a new “EUI-128” identifier for VMs. Virtualization is software so a new address may be feasible in the long term. New proposed OUI-based registries: OUI existing OUI-36 Company ID-24 Company ID-36 Addresses-A (48 bits) Addresses-B (36 bits) Addresses-C (28 bit) Addresses-D (24 bit) Need input from IETF: stds-rac-public@ieee.org ??: it seems that you are aware of IP in 1991 when you can only sold addresses in very large block. I wonder if there is anything to be learned there. Glenn: there are only 2 ways (6 millions or 4 thousands) that you can buy addresses now. Glenn: we haven’t looked at the variable lengths address options. Chair: MAC addresses are flat. There is no need to be in blocks. ??: Maybe you should present it to multiple WGs. Pat Thaler: just want to clarify that part of concern is the addresses to be used by hardware. Now with VM using MAC addresses. Now every cell phone and TV is using addresses. Part of the concern is to make transient devices have enough addresses. The company ID is separable from OUI. Cathy: There might not hierarchy, but you would still have issues. Dave Thaler: OUI is used at multiple places. END OF MEETING