BEHAVE Minutes, IETF79, Beijing Chairs: Dave Thaler, Dan Wing Note-takers: Stuart Cheshire and Ed Jankiewicz Chairs presented: Doc status: * Finished some major milestones, in editor queue, one RFC 6052 * Another in IESG * Waiting for updates for SCTPNAT draft * ftp64 updated, may be ready for IESG Milestones: * FTP ALG pretty much done. * LSN, Analysis of NAT-PT at risk. * "How to avoid NAT64" and SCTP NAT -- both late and insufficient focus. These should be priorities to get finished. * Good energy and moving along on NAT64 load balancing and BIH. On track. Dan W: Questions to room. Is there interest in multicast or MIBs? Alain D: Lots of interest in Software WG for multicast Behcet Sarikaya: Regarding 6to4 Multicast, there's a masters thesis that shows how to do it Dan W: Yes, I've read that masters thesis. It solves a whole bunch of problems. We need to see which problems are interesting to standardize. -- 15:30 Results of NAT444 tests at CableLabs, Rogers, (Chris Donley, 10) and Time Warner draft-donley-nat444-impacts-01 summary of presentation points: * Independent test of NAT444 * Characterize operations in broadband network, impact on average user, operators and content providers * Sample topology - single client, multiple client, multiple houses and dual ISP * Basic IPv4 connectivity, most stuff works, some advanced tasks fail or degrade. Performance depends on configuration, which CGN, etc. Gaming, p2p, FTP, 6to4 * Source address/port will change, impacting geolocation, lawful intercept and abuse reporting * Not unique to NAT444 * Move to IPv6 ASAP Stuart Cheshire: Would like to see more investigation of results. If nesting NAT hurts performance, why? Since internal NAT looks like single host to external network, why doesn't it perform like a single host? Chris Donley: Because of decisions made by content providers Stuart Cheshire: NAT444 not something in the future -- it's with us already. Many users have DSL modem with NAT, and then they add their own NAT gateway in front of that. Chris Donley: Because content providers may throttle bandwidth per client IP address, and now one client IP address is shared between different households. Liu Hong: Some ISPs think that per-interface single-level NAT44 will support subscribers for at least the next hundred years. Chris Donley: Less nesting of NAT would be a good thing Wes George: Do you have any experience using RFC 1918 addresses on the middle link of the NAT 444? Chris Donley: Yes, the choice of whether to use private or routable address makes a difference. E.g. using private address disables use of 6to4. Using a routable (but not actually globally unique) address results in non-working 6to4. Mohsen Souissi: Go to IPv6. Nested NAT is bad. Mark Townsley: Nested NATs in a single household are one thing. When you move NAT to ISP, it does add new problems. -- 15:40 Analysis of IPv6 synthesis (Jouni Korhonen, 20) draft-korhonen-behave-nat64-learn-analysis-00 milestone date: April 2011 ("avoiding NAT64 with dual-stack host for local networks") Summary of presentation points: * Analysis of issues on IPv6 address synthesis. * New requirements - must support apps that don't use DNS, ability to learn multiple pref64. Late comments, not reflected in the draft yet * 10 different proposals for discovering synthesis (see slides) * Various combinations of DNS, DHCP and other protocols such as STUN * Using DNS seems logical, fate sharing is a good aspect. * RA-based mechanisms hard to get deployed * Heuristics are feasible, but may not be useful in the long term. * Proposal- standardize EDNS0 option Andrew Sullivan: As long as you understand that getting EDNS0 options deployed will not be free either, it's not the end of the world, but it won't be deployed overnight. Andrew Sullivan: Don't really understand why we're doing this at all. DNS64 is a hack. Intention was just to make a few things work acceptably well. Now seem to be attempting to make everything work really well. Why? Jari Arkko: Favour option 2 (two heuristic-based methods). Not clear this detection is needed at all, but if it is, then the heuristic-based method is best. Gang Chen: Support Router Advertisement method for 3GPP networks. Simon Perreault: Do these proposals support multiple prefixes? Jouni Korhonen: Yes, if all prefixes have the same prefix length. Simon Perreault: As stated before, I need support for multiple prefixes. -- 16:00 Dual Stack Hosts Using "Bump-in-the-Host" (BIH) (Teemu Savolainen, 15) draft-ietf-behave-v4v6-bih-00 milestone date: April 2011 Summary of presentation points: * new charter item * translation embedded in the host * apr 2011 target to IESG * what scenarios? What IPv4 addresses to use * all IPv4 application support, various host, network server capabilities * configuration options for the extension name resolver * need guidance on exclusion of some addresses, could tune to recommendation set when to use direct IPv4 or not * discussion on list about IPv4 addresses Jari Arkko: Who decides which addresses are "permanently unreachable" or "observed to be problematic"? The host? How does it know? Teemu Savolainen: The IETF would decide. Dave Thaler: The points on this slide are for discussion. Jari Arkko: From my perspective this work was not intended to take double translation. Would like document to say that double translation is not in scope. Andrew Sullivan: What's to stop the scope of this work growing out of control. Alain Durand: Doc should say MUST always use a tunnel. Single most important goal to get IPv6 successful is application adoption, and techniques like this that mean application developers can get away without updating their code help delay IPv6 adoption even more. Stuart Cheshire: The draft asserts, "classes of applications are going to remain IPv4-only". It would be good for the document to cite some compelling examples of this. Modern networking APIs hide addresses from applications, so all those applications are IPv6-capable already. What are some examples of applications that have IPv6-capable servers but the client is still IPv4-only (but runs)? -- 16:15 NAT64 Load Balancing (Dacheng Zhang, 10) draft-zhang-behave-nat64-load-balancing-00 milestone date: April 2011 Summary of presentation points: * Combines nat64 load balancer and nat standby drafts Lars Eggert: Requirements are not consistent. Requirements say user should not be able to tell load balancing is in use, yet if they use whatismyip.com and get different answers for different connections then they can tell load balancing is in use. Requirements say should not send connection Behcet Sarikaya: Prefixes are selected by NAT64 box, so how is there a prefix selection problem? Andrew Sullivan: Why are we doing this? Proposal requires DNS server to guess what client wants. This does not work reliably, like all other DNS-based load balancing mechanisms. Suzanne Woolf: This won't work well, but people will want it to work well, so implementers will struggle to make it work well, but it can never work well. -- 16:25 Analysis of 64 Translation (Christian Jacquenet, 10) draft-penno-behave-64-analysis-04 milestone date: February 2011 Summary of presentation points: * 64 refers to a set of 4 docs cited * Are issues in RFC 4966 mitigated? * Update coming soon, please read and comment on the list Two questions posed to the room: Open Question #1 The current version covers Stateful NAT64 only Shall we extend the document to Stateless NAT64? Open Question #2 No recommendation is provided in the I-D as we want the document to be analysis document and avoid solution-related discussion. Does the WG agree with this scope? No comments from the room on two open questions. Jari Arkko: Document classifies things into issues that have not been addressed and issues that have been addressed elsewhere. Would be better to classifies things into issues that can be addressed, and what is impossible to fix. -- 16:35 Large-Scale NAT Requirements (Shin Miyakawa, 15) draft-ietf-behave-lsn-requirements-00 milestone date: December 2010 Summary of presentation points: * WG draft since last meeting * Minor changes based on mailing list Discussion on "Large Scale NAT" versus "Carrier Grade NAT" versus "multi-entity NAT" Dan Wing: Large-Scale NAT is perfectly fine name. Let's not waste time here today talking about what to call it. Dave Thaler: We should discuss this on the mailing list. Alain Durand: Don't care what name, but we should agree on a single name. Liu Hong: I like the name "Carrier Grade NAT". Shin Miyakawa: Who likes "Large-Scale NAT"? About 25 hands raised. Shin Miyakawa: Who likes "Carrier-Grade NAT"? About 25 hands raised. David Harrington: Making "high availability" a requirement looks like an attempt to do an end-run around the charter. It has already been discussed and agreed: We don't want to do "high availability" in this WG. Christian Jacquenet: High availability is a true requirement. Gregory Lebovitz: Every customer tells Juniper that they require a high availability solution. Dan Wing: Intention is not that we think a high availability solution is not useful, but that we don't forsee the IETF being able to create a multi-vendor high availability solution. Alain Durand: This is an opportunity for vendor differentiation Liu Hong: I am from China Mobile. I ask group to consider to develop mechanism so that when one CGN is failed user can select another one. David Harrington: If in requirements doc, must be clearly stated that the IETF is not taking on this work. Tina Tsou: How does the administrator of LSN identify a CPE? CPE should be authenticated to ISP. Authentication should be in the document. Jari Arkko: Could make ports appear random externally, but actually they are pseudo-random. -- POTENTIAL NEW WORK -- Large-Scale NAT port management/logging: 16:50 NAT port management (Alain Durand / Tom Taylor, 15) draft-cheng-behave-nat44-pre-allocated-ports-00 draft-tsou-behave-natx4-log-reduction-02 draft-durand-server-logging-recommendations-00 Tina Tsou presented: * Durand's draft recommends logging, complementary to the other drafts * Cheng and Tsou's drafts allocate in blocks to reduce logging, with differences * Tradeoff between randomization and clearance of unused blocks Alain Durand presented: * Tradeoffs on port management * Static - security (entropy) is dependent on the size of the pool; no way to extend, failure on exhaustion, overengineer. * Dynamic - more sharing, larger logs Lars Eggert: 5.6TB is two hard drives. Who cares? Putting all this complexity into the NAT to reduce logging size is an insane trade off. Jari Arkko: What does this cost? 10 cents per user per month? It's not important. Lars Eggert: For Legal Intercept purposes, will want to know time of every connection. Alain Durand: No, when a connection is made, Legal Intercept will ask who had the source port at that time, and logging which user had which bucket at which time is enough to answer that. Iljitsch van Beijnum (via Jabber): If the mappings are static and obvious, people can have incoming connections. Security is a non-issue because today people have a whole address and nobody worries about that. Francis: I understand why you want to minimize size of logs at ISP. Customer has opposite interest. If you publish this then customers will deliberately do the exact thing to maximize log size. Simon Perreault: Denial of Service attack. What stops one user consuming all the ports? Dave Thaler: Should requirements document include logging requirements? Jari Arkko: Logging is required. What's the question? Dave Thaler: Requirements document can specify requirements of products, not necessarily requirements on protocols coming out of this working group. Lars Eggert: Should not be in requirements document. Logging is not required for functional connectivity. Logging (or not) is vendor decision. Logging is not needed for interoperability. Roberta Maglione: Requirements document should mandate logging. Alain: Requirements document should only specify what's needed for interoperability. Requirements document should not say things like requiring all LSNs to support oversubscription. That's a vendor decision. But... a "static allocation considered harmful" doc would be good. -- 17:15 Extended IPv6 Addressing for Encoding Port Range (Xing Li, 10) draft-bcx-address-fmt-extension-00 Summary of presentation points: * Address format for translation * For sharing, use ports to help share IP address * Stateless, there is no binding database. Must be algorithmic. Port range index embedded in IPv6 address * Inform the mapping device that port range is limited. * 4 bits for Sharing ratio, 12 bits for the index * RFC 6052 allows different prefix length, so use 16-bit with zero * Modulus operator to determine port range * Extend 6052 address with the 16-bit * Applicability to translation, tunneling and PCP * Minimize port logging requirements in LSN Lars Eggert: This seems like a really really horrible idea. END