OPSArea Open Meeting Tuesday, March 24h IETF 74 -- SF, CA, USA (based on notes taken by Margaret Wassermann and Balazs Lengyel) RENUMBERING STILL NEEDS WORK -- Brian Carpenter draft-carpenter-renum-needs-work Despite what it says in the agenda, this talk is entitled "Renumbering still needs work". [Slides presented: opsarea-1.pdf] Slide 6: Dave Thaler: RFC4191 is not used by hosts. Brian agreed to make a correction. Slide 8: Brian Carpenter: Noted that there is operator resistance to using multiple addresses for each host. Iljitsch Van Beijnum: Wants to know if resistance to using two different addresses at the same time is specific to renumbering or general. Brian: Resistance is general. When you explain to a user that they can simplify renumbering by using multiple addresses on every host, their eyes start to glaze over. Slide 14: Brian Carpenter: Would welcome someone writing a paragraph about what happens to multicast during renumbering. Slide 23: Iljitsch: Discussion of how one can use ULAs for local communication to ease renumbering. Tim Chown: Renumbering of the networks and hosts works reasonably well. The trouble is in all of the details. Stuart Cheshire: DNS maps names to IP addresses, but on the local link an IP address is not useful -- need to know Mac address. Mapping is done by ARP. If you need to replace an ethernet card, you do and there are no problems. Iljitsch: Differences: (1) ethernet addresses are rarely global, (2) DNS is not reliable enough to serve for all purposes. Maybe we can do something to make the address resolution more reliable/quicker. This is how we got here. Brian: At this point, there is 20 years of history doing it this way. Dave Thaler: There is no source name in the IP packet, so when you have a packet you have addresses, but no names. Brian: Hence, DNS reverse lookup became a security feature, apparently. Brian: What next? Dan Romascanu: Could be a OPSAWG item, would be best to do an AD-sponsored submission. Conclusion: Brian to update the draft and send it to Dan for publication. We will use ops-area@ietf.org for any discussion. IPFIX EVOLUTION TOWARDS A MORE GENERIC PUSH MODEL -- Benoit Claise draft-claise-structured-data-in-ipfix00 [Slides presented: opsarea-3.pdf] Slide 3: Benoit: Syslog has performance impact. Example of firewall that handled 8.4 GB, when syslog enabled dropped to 7.?, when switched to NetFlow, went back up to 8.1 GB. Slide 10: Benoit: IPFIX stands for IP _flow_ information export, but we are starting to move away from the flow part. Dan Romascanu: Why would you need another push mechanism? Benoit: If I want to export performance data every one second, I want to know what protocol I should be using now. Need methodology that involves measurement, export and metrics. Right now, this is the best tool we have. Brian Trammel: This seems to be the direction that the network is moving. More and more processing and decision making at the edge. A lot of the information that comes out of that is based on association. Need a way to export this information. Why have two different tools to do this at the data plane and for metadata? Benoit: Want to correlate data from different locations in space and different points in time, and bring it all together at one collector. Juergen Quittek: If we want to define a new push mechanism, we would need to discuss what we have now and how this would be better. ?? from NTT: Agrees that there are problems with syslog. Wants to see the whole data at the same time, events and flow data. Rahul : If there are multiple applications are dealing with the netflow record, how are they represented? Benoit: By applications, do you mean one for security, one for management? Rahul Agarawal: Yes. Benoit: If you want to represent your data a certain way, you should design your template that way. Amir Ochter: Question is "Where is the observation point?". Rahul: Benoit: Understands the question now. The question is about the use of the application ID. The draft does not go into how the application ID is assigned. Dan: Where is this proposal in IPFIX? Benoit: Proposed for first time two hours ago. Will do an update to address feedback, particularly for examples. Dan: IPFIX is a few months away from a new charter. Keep working on this, discuss in IPFIX, announce new versions of the draft to the opsarea list. Brought this here because it is about extending ipfix to other management functions. Input from operators and management community would be useful regarding this effort and potential WG recharter. SHARED ISP ADDRESSES -- Akira Nakagawaa isp-shared-address-02 [Slides presented: opsarea-2.ppt] Slide 14: Margaret Wasserman: Asked for clarification on slide. Example does not show actual addresses that will be used at each level. Why would a local address be used for (3), where would it come from? Shin Miyakawa: Example is bad, but item (3) could be an internal ISP server. Does not want to force connections to internal servers to go through LSN. Margaret: Still uncertain. Does this imply that the ISP will run a split DNS for all nodes inside the local network? Shin: Yes. Ruedigger (sp?): This is a walled garden. The ISP may provide services that are avaiable to their subscribers and not to anyone else? Alain: There are lots of implementations that exist that have knowledge of what is a private address and do things differently. Stuart Cheshire: If we put as much effort into deploying IPv6 as discussing this problem, maybe we wouldn't have this problem. All of this comes down to one thing: When two devices have the same address, you can't figure out who you are talking to. That's because IP was designed to have one address per node, but we're running out of addresses. All of the effort to make this work is just moving the passengers around on a sinking ship. Iljitsch: We still have address, so we have time to eat the food and listen to the music for a while before we sink. :-) This is a bad solution. When we don't have any more addresses, this may become a better solution. Suggests that we hand out this address block as the very last IPv4 address block. Marla Enzinger from ARIN: This has been discussed in ARIN and is not highly thought of. Also doesn't support Iljitsch's proposal. Stuart Cheshire: RFC 1918 addresses are not NAT addresses. They were meant to be used on isolated networks, not for use behind NAT. That's why we are running into all of these problems. Mark Townsley: This all comes down to "what are you willing to touch to extend the list of your IPv4 network"? If you are not willing to touch or obsolete anything, then eventually we may have to do this. But, is that necessary? He'd like to hear from the service providers. Alain: Mark is taking the assumption that if you don't do this [NAT444], nothing works, but that isn't true. Mark: Broadband forum is interested in this. They should speak up. If we do it NAT444 in IETF we need to do it properly, need a separate addresses space. If we can really not touch the the residential networks, this might be needed. Alain: What is wrong with asking hosts in the home to use something other than net10? Mark: This proposal is based on the assumption that we can't touch anything in the home. When he talks to service providers, they say "yes, I want that" again and again and again. Only some of them are brave enough to stand up and say so in this room. Alain: Still doesn't understand why we can't insist that a customer use 192.168 in the home... Mark: As soon as you touch the users' device, you aren't meeting the requirement. How can you drop this in and not need to change anything in the home? Alain: That is too expensive. Jari: No matter what, there will be pain. We are trying to decide this without much information. Has anyone actually looked at what addresses are used in the home? Dave Thaler: Everything he could find in the market was 192.168.something. If anyone knows of anything outside of that range, they should let us know. Jari: That is very good information, because if you assume you can use a net10 and not interfere with what people use in their homes, or at least what is configured by default, then that is good news. It would be good to avoid needing to allocate "net11". Iljitsch: This assumes that people will be on IPv6, so they will need to replace the CPE, anyway. [Yelled down from the room] Jari: Regardless of what the slide says, this proposal does not assume everyone is using IPv6. Iljitsch: If they can't use native IPv6, and they can't use 6to4, then they are in a tough positions. (Unclear), so I don't think this is actually needed. Shin: This scenario has already been explained in the tech plenary a couple of times before. They don't need to do any hardware replacement to make IPv6 ready. Their customers may have to replace CPE to get native IPv6, but they have a step-by-step migration plan. Andrew Sullivan: What does it mean that we can't touch the CPE? Does it mean actually touch it, or can't restrict it via terms of service, etc. Mark: Touch means replace or upgrade. Alain: Hasn't heard of a case where anyone plans to do a wholesale upgrade of their terms of service. (Unclear) Ron Bonica (as individual): We have choices between painful alternatives: (1) assign these address from public space, (2) providers assign them from public space, (3) say to use RFC 1918 addresses. Does anything break if we assign these addresses? Mark (and others): 6to4 (general agreement). Margaret: Also causes all of the problems that net10 caused, and requires us to put all of the checks in place that are there for net10. In the meantime, we will have a mess. Andrew Sullivan: Confirmed specifics of DNS issues. Marla: Actually, if we do this, we would need two /8s based on ISP sizes. (Confirmed by Jari and ?? from Time Warner). Ron Bonica: Sees no consensus. Mark Townsley agrees. Dave Thaler: Posted summary information to jabber room: "The home IGD's that I know use 192.168 by default are (including the ones at the link above and more): Netgear, D-Link, Actiontec, Ugate, SMC, Eumitcom, Linksys, Zyxel, Westell, 2Wire, Airlink, Proxim, SMC, USR, Ovislink, Asus, Aztech, Billion, Netcomm, Netopia, Belkin, SMC, FON, Buffalo, Asante, USR, Siemens, Cayman, Microsoft" Jari: Thinks that even if we don't do this work, we should write a document about it. Including Dave's information. Mark: Also cover how to make 6to4 work. Jari: 6to4 is only an issue if you are in non-RFC1918 private space. Implementations would need to be updated to know that "net11" is private space. (agreement) Ron Bonica: Asked for hands of people who want to do work. (no hands) OPEN MIC QUESTIONS None.