APLUSP BoF minutes, by Charles Perkins IETF76, Hiroshima, Japan, Wednesday, Nov 11, 2009 chairs: Christian Jacquenet , Dan Wing Audio archive: ftp://videolab.uoregon.edu/pub/videolab/media/ietf76/ietf76-ch7-wed-afnoon.mp3 begins at 8:00 Jabber archive: http://www.ietf.org/jabber/logs/aplusp/2009-11-11.txt - Discussion about scope of BOF, chairs, 10 minutes limited to DS-Lite, so we have something concrete to discuss - Remi Despres Q: What about proposals other than DS-Lite? - Christian J: DS-Lite is just for the purposes of efficiency of discussion. - Dan: We're not talking about charter text in this BOF - Margaret: What if we have no idea what the tools would be used for? ===== A+P Overview (Pierre Levis, 30 minutes) - slide 2: _not_ a complete overview - slide 3: - slide 4: examples - slide 5: @priv <--> @IPv4(public/port range) IPv6 most A+P scenarios require IPv6 Lars: Isn't NAPT in the PC an option? Pierre: Yes. BIA = Bump in App. BIS = Bump in Stack. More slides explaining the typical port demultiplexing operations of NATs... IGP does not require modification for this. - Slides 20-26: A+P with PRR - Slide 33: If you have IPv6 Gateway, why not just use IPv6 NAT instead of doing encapsulation? Pierre: In the draft, we point out that sometimes translation is used instead of encapsulation Margaret: Why not just use v4-v4 NAT? Remi: advantage of aplusp is getting a public address(?) Margaret: How is that related to slide 33? Person X1: Slide 33 is about legacy PCs. Person X2: Slide 33 does not provide benefit over double NAT Lars: The host up there is not reachable for IPv4, and IPv4 applications already know it's not reachable. Dan: Clarification questions are great. Maybe we should get through the slides Xing: The figure is not very accurate. Can be done by port mapping, doesn't have to be NAT. Also can have IPv6 custom function. Slides 33-36: Do not want to modify routing protocols. Number of states proportional to number of users. Can use stateless encap. Colin Perkins: Some applications require awareness of port ranges Stuart: already applications assume they might not get the port they want. Colin: Not all applications are like that. Alain: disagree that # states == # users. Arifumi: upnp applications interact with port range restrictions Dan: That's UPNP of the future Remi: Applications have to adapt Shin Miyakawa on slide 10: Have to tell PC which port ranges they can use! Lars: How much would I have to pay to get one of the first 1024 ports? Remi: Already today, applications have to adapt. Colin: Applications can adapt in current schemes, but not in this new scheme. Sri Gundavelli: How does this work in a mobile environment? Dan: Have a mobile presentation coming up shortly. Margaret: Applications may need to know about how ports are chosen. It is more complicated than just tweaking the bits of the ports. Remi: Could change to get more information from DNS about NAT (?) Margaret: Hope we don't have to make this _more_ expensive as an _option_. ===== Address + Port in a Mobile Environment (Behcet Sarikaya, 10) Contexts & Motivations - more and more wireless, always-on connectivity - binding refresh at NAT vs. power - NAT ==> performance degradation - Problems with private addresses = overlapping addresses ==> additional complexity - Need a different way of doing things, aplusp seems to be one way - developing countries use mobile technology for broadband - mobile architectures are essentially centralized = but scalability and performance are at issue, also CAPEX and OPEX - local realm --> IPv6 doesn't solve the problem - A+P solves address exhaustion and NAT issues, being faced by operators - A+P is a step towards IPv6 - For convergence, "similar" solutions Alain: is this about A+P on a cellphone? But chairs said it was out of scope Dan: Chairs are unable to clarify Dave Thaler: It's in scope as long as it's in the scope of DS-Lite Jari Arkko: Mobile Networks are already v6-ready. Not clear that we need more solutions. Sri G.: There is still a code migration issue. Alain: Are we talking about cellphone, or card in a laptop? They are quite different scenario Chris Metz: About claim that hierarchical/double NAT introduces performance issues -- is there documentation on that? Greg Lebovitz: It's not just the mobile nodel, but also the mobile infrastructure. Remi: Cascade of NATs: peformance is not the problem, it's reachability. ===== Issues with A+P (Dave Thaler, 25 minutes) Slide 2: multiple issues (b) made _worse_ by A+P (c) specific to A+P Only talking about (b) and (c) - definition of "unicast address" = a big change to the IP model, as big as NAT was. - Implementation on hosts = legacy hosts fail = A+P aware hosts would run unaware applications = failure even on the same link! = If NAT is in host kernel, user confusion since default router is not as expected = Multiple interfaces with multiple port ranges? Applications just don't work. Would have to change all apps. = Roaming between A+P vs non-A+P networks = IN_ADDR_ANY loses its resilience to IP address change. = Can't ping A+P home router = In DS-Lite, can only tell if box is reachable, not whether v4 stack is configured correctly and operational Provisioning system = DHCP = databases = management tools = accounting = worse if port range allocation is dynamic Training/education = Whole new and different set of training requirements compared to NAT or IPv6 Security: = reduces effectiveness of port randomization (less random) = Sub-delegation of port ranges makes things even more complicated. Long-term Impact: = port restriction for IPv6? (case in point: NAT66) Summary = a drastic change = introduces complexity (people will get it wrong) = not necessary (worse than double-NAT) ===== Q&A time (all, 30) Questions: Masataka Ohta: Something about his solution, did not understand Alain: This came up when giving some control to the user Remi: ...? Margaret: Can't understand this BOF. It's like 0.5*NAT. Ralph Droms: The technology would help with coexistence of IPv4 and IPv6 would (presumably?) encourage migration. Margaret: What is the relationship between A+P and DS-Lite? Ralph Droms: There isn't a document specifying A+P for DS-Lite Alain: softwires is the place for the DS-Lite A+P discussion Ralph Droms: There isn't a document specifying A+P for DS-Lite Lorenzo Colitti: If we had a magic wand for doing IPv6, we would avoid A+P. Did anyone talk to the operational community, to see if they want to roll out A+P? Pierre Levis: refer to CPE, router needs simple new feature Julien: Is a new working group really needed? Lars: This is a really bad idea Remi: In year 2000, already had features of A+P. Masataka Ohta: His implementation is working without problems Bob Hinden: Often asked, which transition mechanism should be used? This one has a lot of side effects. The IETF is doing way more complexity than the world knows how to deal with. Colin: this approach has massive problems. This is a really bad idea. Xavier Marjou: Remember when the IETF would not work on NAT? Then we ended up with a major disaster. So this means we should go forward with the work Jari Arkko: Agree with Bob. Already have what we need to have. Philip Eardley: This is a big change to the IP model. Do people disagree with the detailed objections, or with the overall idea Satoru Matsushima: ??? Masataka Ohta: His implementation is 4-4-4, but can be changed to 4-6-4 and maintains end-to-end transparency even if 4-6-4. Greg Lebovitz: If we took the time and energy required for deployment, and applied it instead to making the operating system changes, we'd be done in 1/3 the time Markus Isomaki: Has some value compared to double NAT. We are comparing things that are not perfect. Remi: Bob Hinden's comment was that we have enough transition mechanism. Having this as a small net block might be valuable. A cascade of NATs. Lars: This is horribly complicated even if done in DS-Lite. Ohta: the change was only 100 lines. ??? Ralph Droms: we are going to run through some questions. This is a BOF. This is not a decision-making consensus. We will try to capture the opinion. ===== Next Steps (chairs, sponsoring AD, 5 minutes) Problem statement clear/not clear: hum was louder for "not clear" Clarification to problem statement discussed: hum was louder for "clear" Problem statement solvable/not solvable: hum louder for "not solvable" Should any work in this space be taken on? A+P in the conext of DS-Lite? [louder for NO]