6AI BOF Chairs: Bob Hinden, Dan Wing Minutes by: Ed Jankiewicz 25 March 2009 San Francisco IETF ----------------------------------------------------------------- Agenda - Administrivia (Note takers, jabber scribe, review agenda), Chairs, 5 min. - Purpose and Goals of 6AI BOF, Chairs, 5 min. - IAB Thoughts on IPv6 Network Address Translation, Lixia Zhang/Dave Thaler, 15 min. - Summary of NAT66, Margaret Wasserman, 15 min. - Features and Problems of NAT44, Tony Hain, 15 min. - Source Address Finding (SAF) for IPv6, Dave Thaler, 15 min. - Qualifying the Harmfulness of Address Translation, Christian Vogt, 15 min. - The Lesser of Two Evils, Bob Hinden, 10 min. - Discussion, (all), 45 min. - Conclusions and Consensus, Chairs, 10 min. ------------------------------------------------------------------------ Community interest to create a working group on this topic? Constrained today to discussing one of the technical approaches, using NAT66 as a discussion point: * NAT66, draft-mrw-behave-nat66-02 * Port range, Section 6.6.3 of draft-boucadair-behave-ipv6-portrange-01 * SAM, draft-despres-sam-02 Will technology like this work to solve problems? Not here to discuss details, make a policy decision whether to have anything NAT-like in IPv6, not how. The WG if established will make charter decisions about when and how to evaluate and decide upon approaches. ----------------------------------------------------------------- Dave Thaler --- IAB Thoughts on IPv6 network address translation draft-iab-ipv6-nat-00 RFC 4924 end-to-end transparency "transparency is an ideal .... requiring ongoing effort" Problem Space: Avoid renumbering and Site Multihoming issues, perception of routing scalability issues Registries and upstream providers injecting Topology Hiding and Preventing Host Counting --- NAT today is helpful but translation may/not be part of the IPv6 solution Simple Security --- orthogonal to NAT discussion Architectural principles 1. accommodate different goals and different practices 2. non-IPv6-NAT parts of the Internet should not be adversely affected by the decision to use it how to hide the impact in each solution solution space Global PI addresses --- the host gets PI space, available to all managed networks. Ongoing research and experimentation (e.g. LISP). Avoids problems introduce by NAT. does not address Topology Hiding or Host Counting Native local, tunneled global --- RFC 4864 using MIPv6; stable local address, tunnels to get dynamic global addresses. Renumbering limited to systems over or beyond the tunnel, eg DNS. Incentive issues, different owners of end-points Local address with NAT --- could use local prefixes, global gets NAT'd. breaks e2e unless reversible; like a tunnel in some sense, incentive issues E2E Transparency --- key to the success of the Internet; immutable fields arrive intact, including source and dest addresses, many protocols and apps rely on this Each proposed solution has a way to preserve e2e --- does not automatically rule out Recommendations: consider e2e transparency as a requirement, and compare solutions on other aspects including scalability, incremental deployability Eric Nordmark --- any comment on time frame from IAB? It will take a while to get consensus, can we wait 10 years Dave --- "in time" on PI space --- short term vs long term solution may be different Margaret --- agree with the doc, mom and apple pie --- all good. How does this connect to what we should do? You could have built solutions with IPv4, market requirement to allow incremental deployment Jari --- ability to communicate between LISP and non-LISP Ran Atkinson --- "the market requirement" not obvious that there is a single market for this capability, non-identical requirements ---------------------------------------------------------------- Margaret Wasserman NAT66 draft-mrw-behave-nat66-02 What NAT66 is and how it differs from IPv4 NAT Why do people deploy NATs? Amplify address space, don't need that in IPv6 Simple security solution, not a good idea --- firewalls are better, we won't consider this requirement. Enterprises with plenty of IPv4 "swamp space" but still use NAT --- address independence and topology hiding What is address independence? Inside does not need to be renumbered when the ISP changes the global prefix or changing ISP. No need to convince/pay ISP to route private addresses, and it can be brittle Topology hiding --- poorly defined and understood. We need to define the problem, so out of scope for this BOF right now. Stateless, transport-neutral solution Simple NAT66 Example Only thing that changes on outgoing packet is the internal host source address Prefixes configured, one-to-one Tim Shepherd --- TCP checksum. Yes, covered. Three scenarios in the draft Leaf network, more than one NAT66 (no state sharing --- algorithmic) or NAT66 between two private networks Last IETF, Fred Baker at behave --- b2b VPN Private interconnection of two company VPNs Connectivity management and mutual exposure Keith Moore --- why not just route between? Fred --- context --- could use ULA, but Cisco IT wanted information hiding both ways, can't identify the systems. Business requirement James Woodyatt (clarifying questions now, discussion later) Simple multihoming --- either one preferred or per-flow load balancing; two external addresses (in DNS) but one internal address Two-way Algorithmic Mapping Source address prefix is overwritten (/48) --- update calculation of checksum --- append the correction bits into the calculated prefix Remi Despres --- this scheme can have trouble due to one's complement Margaret --- corrected in the new draft; no consensus on whether or how Marcelo --- do you need state? No, completely algorithmic. How do you recover the subnet bits? They are still there --- the correction is appended Compare NAT66 to IPv4 NAT solutions Several components to NAT, different issues, which to include/not Decompose a NAT Address Mapping --- in IPv4 the entire address is mapped, many:1 (shared address) --- address amplification (don't need in v6), address independence, superficially hides internal hosts; internal nodes cannot be addressed from outside, NAT maintains state; inconsistent with IPsec James Kent --- virtual network --- obscure use case Port Mapping --- not needed in IPv6; obscurity, alters transport layer, inconsistent with security Maintenance of Mapping State --- not needed in NAT66; single point of failure or sharing protocol; keep-alive needs; Checksum modification --- no need to do in the upper layers as in IPv4 NAT; App layer use of IP address (both) and port mapping (only IPv4) Need ALG to handle Even if FQDNs are used port mapping is done Keith --- no worry about ports in NAT66, but FQDN doesn't solve referral and other issues Margaret --- definitely some of the same disadvantages Eric Nordmark --- ICMP Dan --- STUN probably not useful in NAT66 Why publish NAT66? Demand from network operators. Vendors are already building. There will be IPv6 NATs, we cannot forbid. Two choices: * Refuse to document IPv6 NAT because it's icky, so we get a bunch of inconsistent NATs * Or document an IPv6 NAT that work consistently We should document something Gregory Leibovitz --- if you're going to do something, here are properties that you should follow Tim Chown --- 1996 time trip 8+8, limiting NAT to prefix translation? Bob Hinden --- if we form a working group we will consider that Stuart Cheshire --- NAT is not a firewall --- inadvertent blocking only; we keep hearing that people want NAT66 with or without IETF guidance. Eric Klein --- is info hiding in scope for the WG? Yes ? decomposing NAT (3) maintenance of mapping state will still be an issue with firewalls, Ran --- NAT66 is a specific proposal, IPv6 NAT is the generic ----------------------------------------------------------------- Tony Hain --- IPv6 NAT engineering tradeoffs (no draft) We're here because net managers want NATs, vendors are building them. Issue: whether or not we will try to define one Reversible only if you have the information on the return path Dave Oran --- mapping can be reversed only by the Fred Baker --- one to one and onto. Stuart Cheshire --- misunderstanding --- on one end stateless translation, returning to the same or peer NAT it is reversible (Margaret slide 6) if there are multiple NAT66 devices in the same domain Tony --- e2e transparency --- at the remote point there is no way to reverse it without some out of band signaling Dave T --- different model I will discuss later Tony --- not as trivial as made out to be, Mangling the header not a problem? Destroys audit trail. Multiple exit points with different mappings --- multiparty referrals fail Assuming edge deployment --- GSE-like deployment --- nothing says it is only at the edge Incompatible implementations can be removed over time Tradeoffs --- do not call this a standard, it cannot be recalled ----------------------------------------------------------------- Christian Vogt Qualifying the harmfulness of address translation draft-vogt-address-translation-harmfulness-01 Classic many:1 NAT Box needs disambiguation state to reverse Two components: rewriting action (stateless) and overloading (statefull) Use cases: Only address conservation/amplification requires overloading Topology hiding and provider independence only require rewriting 1-to-1 NAT --- rewriting without overloading Does not achieve address conservation Comparing many:1 to 1:1 NAT Gregory --- if there is a one to one mapping, how does that provide topology hiding? Christian --- permutation of subnet bits David Oran --- multiple addresses can be Margaret --- possible to configure the external and internal prefixes, multiple NAT boxes can maintain the 1:1 mapping Christian --- multihoming is interesting but discuss on the list Greg --- if we are just changing the prefix we are not hiding Christian --- a permutation can be arbitrary scrambling but algorithmic reversible Jari --- not a design discussion, plenty of choices to discuss later Remi --- topology concealment is one thing, not hiding the number of hosts Margaret --- when talking about whether something is 1:1 depends on how multihoming is handled Impacts: Introduces a second address for the host, limits reachability --- DNS and referrals consider global addresses NAT is a single point, in many:1 the disambiguation state may expire Lack of generic forwarding support The harmfulness of a NAT is the cost to solve the problems Time up --- see draft and slides ----------------------------------------------------------------- Dave Thaler --- Source Address Finding for IPv6 Translation Mechanisms draft-thaler-ipv6-saf-01 Get out of the pit Unilateral Self-address fixing (UNSAF) Like STUN some way to learn the address others see you as RFC 3424 --- UNSAF is a short term fix, needs an exit strategy; when you create NAT66, it becomes permanent SAF source address Finding --- can regain e2e transparency Reversible 1:1 translation Like tunneling with header compression, except incrementally deployable With a single NAT66, some apps are happy, some are not --- there is some benefit to the network, some hosts experience pain (in the same network) Virtual interface with some NAT66 added to the host, the network NAT66 reverses it; only the local leg uses a local address Eric Nordmark --- how do the bottom boxes talk? Same as a tunnel or expose both addresses to the application Keith --- if apps still need to be aware of realms it's still a problem, but the solution can deal with that Align the incentives --- the network that wants this has to solve the problem with no impact on the other end Tim Chown --- avoid exposing the host to external prefixes Suresh --- both the NAT66 boxes have the same configuration? Dave --- model permits either same or different NAT66 James Woodyatt --- is this the same architectural Remi Despres --- tradeoff in the multihoming case, encapsulation Jari --- incentives and whether the host changes are in the same administrative domain Dave --- each has a local incentive, the host change helps the host Greg Leibovitz --- the mechanism the host uses to find X::Y? Next slide. If topology hiding were in scope, could the mechanism that assigns X::Y solve that problem? What is a SAF mechanism? Learn the configuration of the virtual interface; not per flow negotiation, does not require changes to NAT66 device Requirements for SAF, Jabber --- not all hosts have the NAT66 vif? Those who have not may be unhappy Keith Moore --- need to see how it would work with multiple layers of NAT66 Dave --- draft looks at the issue, mechanisms should address Tony Hain --- assumptions are based on the single core with NAT66 on the edge, but layering will happen Christian Vogt --- in RRG we discussed a lot of proposals edge-to-edge, even in the same domain there are multiple stakeholders. Incentives split between NAT66 vendors and OS vendors to build NAT66 VIf Margaret --- either do local prefixes for local communication or hairpinning loses e2e transparency locally to get it globally. Suresh --- mobility? Short answer, same as if it were a tunnel ----------------------------------------------------------------- Bob Hinden --- the lesser of Two Evils (no draft) Not wildly crazy about this idea NAT for v4 is widely deployed, inescapable NAT solves address scarcity and other advantages at cost of e2e In IPv6 lack of NAT is a problem --- so widespread now, customers can't see living without them; it is going to happen Either repeat mistakes of the past, or define it well NAT66 is not as bad as the NAT for IPv4 Model requires allocating /48 to the site Allows mixture of NATed and pure routed subnets Do the advantages of NAT66 outweigh the problems? Is it better to specify or let vendor solutions happen? Should we form a working group? ----------------------------------------------------------------- Open Discussion: Tony Hain --- generic discussion, Address Independence may be a misnomer. Jari --- concept of NAT66 is under discussion, address independence is a larger issue, there may be other things that come up Tony --- why we are doing this is the fundamental question Gregory Leibovitz --- 1:1 NAT became NAPT, comparing NAPT to IPv6 1:1 NAT. customers want topology hiding also protection from host fingerprinting. One thing they get from NAPT is they do not need prefix assignment --- just DHCP get one address, put as many hosts as possible. Brian Carpenter --- scared that NAPT will happen again; only way to prevent is to produce the quickest, simplest NAT66 spec in 6 months Keith Moore --- how much can we help? If we publish a document what prevents vendors from doing what they want anyway? Can we get a world where apps have the same view of the world? NAT46 may have a different view of the world. Jari --- history repeating itself --- real differences not the same motivation as IPv4. Heard a lot from geeky insiders, not from end users Jonne --- if there is market demand, vendors will build with or without our guidance. Isolation or address independence not solved in IPv6 --- can it be solved without NAT? is there some other way to address? Dan --- non-NAT ? - don't want NAT as an end user; NAT66 is prefix translation, is there a slippery slope where we go down more NAT and NAPT and NAT-PT Eric Nordmark --- address independence feature --- we need more data; work out the address independence, short-term unilateral stateless solution Margaret --- interesting discussion --- if we do nothing it will still happen, if we write something positive people might follow, don't do it won't work. Net Administrators opinion --- they are not at IETF Suresh --- is the IETF going to give deployment guidance? This group should address if formed. Just changing address format and recycling NAPT may be easier Stuart Cheshire --- show of hands how many want/need NAT66? Who would turn it off? No concrete support here. We need real market assessment Greg Daily --- driver is feature parity; individual components/features of NAT vs NAT66. Provider independence --- there is another solution. IPv6 PI addresses for multihome users. Impact on the global routing table would not be bad with exact feature parity. Need a problem statement on topology hiding, and a solution that may not be NAT66 James Woodyatt --- no, no and hell no. does not address application amplification --- why is it not necessary? Apple products may have to include NATing for address amplification. Providers will probably give less than a /48. DHCPv6 may assign single addresses rather than a prefix. Maybe more appropriate as IRTF Philip Matthews --- should be standards rather than experimental, more scrutiny; must consider the interaction with IPv4 --- long-term coexistence, Remi Despres --- address independence, multihoming, but not NAT I would support the WG, make Eric Klein --- all for a group to address the problems raised by NAT66 discussion without assuming that as a solution; I am not personally aware of any need for NAT in IPv6. Serious thought about deploying IPv6 Remi Denis --- connection sharing --- already solutions Tim Shepherd --- hope Eric Klein observation is true; the advantages do not outweigh the problems. It is better to specify, especially in the light of Dave's virtual interface approach. Maybe if we write down a good way (like Dave's architecture) Christian Vogt --- not specifying, experimental, or standards track: we should avoid the perception that we are recommending doing this" ---------------------------------------------------------------------- Wrap-up --- Jari Arkko Obvious we could do this, there are solutions, a good architecture But should we? Are the right incentives there? Remi Despres --- Dave architecture is a good way to proceed Keith Moore --- need to define the use cases, to discover other solutions, a couple of use cases (rare but important) may require an IPv6 NAT. first identify and prioritize the use cases. Bob Hinden --- define something limited, well-defined and short term to get it out there, discover the operator pull, etc. Greg Daily --- not inclined to do a NAT66 solution, but the first task is to determine the problem statement. Bob Hinden --- no charter yet, but a problem statement would make sense Tony Hain --- you are asking the question in a way that you can't say no Greg Leibovitz - Remi Despres --- address independence is not enough. Also multihoming and e2e Jari --- alt 1 --- do nothing; alt 2 --- remaining problems that IPv6 doesn't solve that NAT did; alt 3 --- NAT66 solutions Thomas Narten --- yes, we want to do all of this, but a very short window Keith Moore --- time constraint, moving forward in a way we don't understand isn't useful. Should we form a WG? Another BOF but we need problem statements with realistic use cases. Should we ignore this area? Only 1 said do nothing Either or both? More no than yes on NAT66 ----------------------------------------------------------------------- In summary, there was not a consensus to either do nothing or to form a working group to work on a NAT for IPv6 document. The only consensus that did exist was to continue to study the issue and there was interest in holding another BOF at the next IETF. ----------------------------------------------------------------------- Meeting Adjourned -----------------------------------------------------------------------