[06:31:42] alfredh leaves the room [06:36:17] alfredh joins the room [06:48:36] alfredh leaves the room [06:58:18] alfredh joins the room [08:15:34] alfredh leaves the room [15:39:24] BillC joins the room [15:39:50] BillC leaves the room [16:03:35] Woj.Dec joins the room [17:18:19] TJ joins the room [17:23:59] TJ leaves the room [17:35:52] williw joins the room [17:36:41] williw leaves the room [17:41:37] williw joins the room [17:42:05] TJ joins the room [17:53:29] williw leaves the room [17:54:07] williw joins the room [18:07:15] joins the room [18:12:40] williw leaves the room [18:12:40] Woj.Dec leaves the room [18:12:54] TJ leaves the room [18:15:16] TJ joins the room [18:55:19] karen.s.seo joins the room [18:58:10] hirocomb12 joins the room [18:58:25] Philip Matthews has set the subject to: BEHAVE session [19:00:10] arifumi 2.2 joins the room [19:01:03] JonathanLennox joins the room [19:01:39] Agenda @ http://tools.ietf.org/wg/behave/agenda?item=agenda73.html ... first up, Agenda, note takers (Chair, 5) [19:02:27] Is there a change in the agenda? [19:02:30] jinmei joins the room [19:03:17] The agenda as I see it: [19:03:18] Next presentation: UDP Path MTU Discovery using STUN (Marc Petit-Huguenin, 15) ... http://tools.ietf.org/html/draft-petithuguenin-behave-stun-pmtud-02 ... http://www3.ietf.org/proceedings/08nov/slides/behave-10.pdf Next presentation: NAT security implications (Fernando Gont, 15) ... http://tools.ietf.org/html/draft-gont-behave-nat-security-01 ... http://www3.ietf.org/proceedings/08nov/slides/behave-12.pdf Next presentation: NAT66 (Margaret Wasserman, 40) ... http://tools.ietf.org/html/draft-mrw-behave-nat66-01 ... http://www3.ietf.org/proceedings/08nov/slides/behave-14.pdf Next presentation: Virtual IPv6 Connectivity for IPv4-only networks (Alain Durand or Christian Vogt, 25) ... http://tools.ietf.org/html/draft-vogt-durand-virtual-ip6-connectivity-00 ... http://www3.ietf.org/proceedings/08nov/slides/behave-13.pdf Next presentation: IPv6 destination header option (Remi Denis-Courmont, 15) ... http://tools.ietf.org/html/draft-denis-behave-v4v6exthdr-00 ... http://www3.ietf.org/proceedings/08nov/slides/behave-11.pdf Next presentation: On-demand privacy protection (Remi Despres, 10) ... http://tools.ietf.org/html/draft-despres-sam-01#section-3.6 ... no slides? [19:03:32] suzsuz joins the room [19:03:37] Thanks [19:04:26] Chari: No malta ... possible interimn elsewhere [19:05:03] **Next presentation: UDP Path MTU Discovery using STUN (Marc Petit-Huguenin, 15) ... http://tools.ietf.org/html/draft-petithuguenin-behave-stun-pmtud-02 ... http://www3.ietf.org/proceedings/08nov/slides/behave-10.pdf [19:05:54] satoru joins the room [19:05:57] magnus joins the room [19:06:09] kanda joins the room [19:06:18] (Slide #2) [19:06:24] Remi @ mic [19:07:46] Thanks Remi Denis-Courmont and not Remi Dupres [19:07:58] s/Thanks/that's/ [19:08:06] @Phil - correct, thx [19:08:19] (Slide #3) [19:08:47] flyinhome joins the room [19:09:02] (Slide #4) [19:09:40] (Slide #5) [19:10:39] levigner joins the room [19:10:43] Lars joins the room [19:11:07] (Slide #6) [19:11:41] (Slide #7) [19:11:58] Can you give slide titles: the uploaded presentation has no slide numbers ... [19:12:10] Reporting method 1 [19:12:11] (Slide #7 - Reporting Method 1: SImple) [19:13:10] (Slide #8 - Reporting Method 2: Complete) [19:14:25] (Slide #9 - Reporting Method 2: Checksum ... ) [19:14:58] (Slide #10 - Reporting Method 2: Header ... ) [19:15:12] Andrew Sullivan joins the room [19:15:42] (Slide #11 - Discovery Mechanisms) [19:16:29] (Slide 12 ... end ... Q&A) [19:16:47] ashida joins the room [19:16:53] Bruce @ mic ... padding problem? [19:17:20] sm joins the room [19:17:25] To WG: I think this work is interesting [19:17:28] Magnus: downref ok. [19:18:05] @Phil - Magnus in room, got your vote ... IIUC [19:18:12] surely PADDING could be moved to this draft if it's going to PS? why invite a process hangup over such a trivial issue? [19:18:18] (In room - hums for, none noted against) [19:19:00] @Flyin ... I don't think it is being held up ... I'll let Magnus(?) answer the move-it-to-here question ... [19:19:07] **Next presentation: NAT security implications (Fernando Gont, 15) ... http://tools.ietf.org/html/draft-gont-behave-nat-security-01 ... http://www3.ietf.org/proceedings/08nov/slides/behave-12.pdf [19:19:17] It is not a hangup and if one moves the other way the behavior discovery couldn't be published as that is basically done. [19:19:29] (Slide #2 - Motivations) [19:19:59] (Slide #3 - Doc Overview) [19:20:06] richard.barnes joins the room [19:20:33] I'd be very surprised if it got through IESG with a downref for part of the protocol specification. [19:20:51] The process for downref would when doing the IETF last call for the PMTUD draft would be to explicitely mention the downref and why. I don't see anyone objecting to using an attribute. [19:21:13] Andrew Sullivan leaves the room [19:21:20] Andrew Sullivan joins the room [19:21:25] IESG must have lightened up a bit. [19:21:36] (Slide #4 - Example of (not) ... ) [19:21:42] we can also re-specify the same attribute that was in an info doc in a PS doc and "upgrade" it that way [19:24:19] Stuart @ mic ... [19:25:55] Bruce asking ... [19:26:30] David speaking ... [19:27:40] Is that Eric? [19:27:41] fujisaki joins the room [19:27:45] yes [19:28:56] ... conversation over header field overwrite ... to, not do, why ... what breaks or doesn't ... TIME_WAIT vs header field overwrite ... [19:29:07] pselkirk joins the room [19:29:12] fujisaki leaves the room: Replaced by new connection [19:29:22] basically I agree with Eric - though I'll note that the NAT can get away with reusing the source port during TIME_WAIT as long as the destination address is different. (which makes the hazards more complex) [19:30:03] @Flyin - you want that to the room? ... nevermind, I think Iljitsch just did ... :) [19:30:09] (agree?) [19:30:21] agree. [19:30:27] Margaret @ mic ... [19:30:41] but it does have implications for v4/v6 NATs that do algorithmic mapping [19:30:47] i.e. stateless nats [19:31:35] Andrew Sullivan leaves the room [19:31:38] fujisaki joins the room [19:31:41] Andrew Sullivan joins the room [19:33:16] I think they've just demonstrated that there's no reliable way to do stateless NA[P]T. either the NAT has to estimate RTT and avoid resuing a binding during TIME_WAIT, or it has to make the mapping depend on previous state to avoid assigning the same mapping on subsequent connections. [19:33:57] (Chair caps line) [19:34:15] Mark @ mic ... [19:35:31] Mark notes that ... TCP seq rewrite wrong = painful to troubleshoot, troublesome ... and raises concern over 64k ports becoming a gating factor w/ CGNs (now LSN or MSN?) [19:35:49] Adam @ mic [19:36:30] ... stateless maintenance + monotonic increase w/0 breaking the lawas of physics [19:36:36] Iljitsch at mic ... [19:36:58] ((lawas --> laws)) [19:37:52] (Slide #5 - Rewriting the source port) [19:38:45] (Slide #6 - Feedback so far) [19:39:20] behcet.sarikaya joins the room [19:39:44] Lars @ mic [19:39:45] no jabber scribe? [19:40:18] (That's me) [19:40:28] Cullen Jennings joins the room [19:40:35] EKR [19:40:37] Thanks TJ [19:40:49] EKR @ mic ... [19:41:16] (missed name) [19:41:42] Iljitsch @ mic [19:42:15] Tony + IPv6 [19:42:32] perhaps more to the point, these issues have to be addressed by v4/v6 translators also. [19:42:33] (EKR's point, IIUC, was that an explicit goal of topology obfuscation is separate from the goal of "simple" NATing ... ) [19:42:42] assie joins the room [19:42:44] sureshk joins the room [19:42:51] **Next presentation: NAT66 (Margaret Wasserman, 40) ... http://tools.ietf.org/html/draft-mrw-behave-nat66-01 ... http://www3.ietf.org/proceedings/08nov/slides/behave-14.pdf [19:43:30] (SLide 2 - What is ...) [19:44:21] (Slide 3 - a quote ... ) [19:44:35] (Slide 4 - Motiviations ... ) [19:44:43] Andrew Sullivan leaves the room [19:44:49] Andrew Sullivan joins the room [19:46:54] Woj.Dec joins the room [19:46:59] Greg @ mic [19:47:41] (Missed name) @ mic [19:48:04] Remi @ mic [19:48:21] (Despres, that is) [19:48:29] I don't think those two are mutally exclusive: we could have a document that says (more strongly) "don't do IPv6 NAT". we could have another document that says "if you're going to do IPV6 NAT, do it this way, and don't claim that it's a standard". though I think it's hard to make a case for no IPv6 NAT at all as long as there's no good solution for multihoming. [19:48:32] Iljitsch @ mic ... [19:49:35] @Flyin - in the itnerest of time, I vote for letting Margaret proceed ... if your comment doesn't get addressed pls repeat ... acceptable? [19:50:04] (Slide #5 - Striking a Balance) [19:50:19] yeah. I'm making these comments for jabber watchers and the log. that and Margaret seems to be about to address this topic now anyway. [19:51:03] @flyin: have you looked at shim6 [19:51:07] @Flyin - good deall ... ((Chair caps mic questions to clarifications only, real Q&A to follow @ end)) [19:51:36] @sureshk: yes, but it's been awhile, and I probably get it confused with other proposals in my memory [19:51:39] (Slide 6 - Simple NAT66 ...) [19:52:03] (Slide 7 - NAT66 scenarios...) [19:52:29] Andrew Sullivan leaves the room [19:52:31] (Slide 8 - Mapping ... ) [19:52:35] Andrew Sullivan joins the room [19:53:17] hartmans@jis.mit.edu/owl joins the room [19:53:46] (Slide 9 - 2way ... ) [19:54:29] (Slide 10 - 2way example ... ) [19:54:42] (Slide 11 - 2way example ... cont) [19:55:10] (Slide 12 - Topology Hiding ... ) [19:55:45] ... comments about topology obfuscation being punted elsewhere? [19:56:03] (Slide 13 - Topology Hiding Mech ... ) [19:56:18] (Slide 14 - Topology Hiding Ex ... Out) [19:56:34] (Slide 15 - NAT66 vs ... ) [19:57:52] ashida leaves the room [19:58:29] (Slide 16 - Open Issues) [19:58:53] (Slide 17 - A NAT by any other name ... ) [19:59:54] Andrew Sullivan leaves the room [20:00:01] Andrew Sullivan joins the room [20:00:08] Christopher @ mic ... [20:00:49] Remi (Despres) @ mic ... [20:00:54] (Slide 18 - Hairpinning ... ) [20:01:12] (Slide 19 - Topology hiding ... ) [20:01:33] (Slide 20 - Use of ULAs) [20:01:40] Andrew Sullivan leaves the room [20:02:29] ... RFC3484 complications? ... [20:02:48] (Slide 21 - Motivations / applicability) [20:03:38] (Slide 23 - Why do I care?) ... presentatin by Fredd Baker now ... [20:03:45] encouraging apps to prefer ULAs over globals is a Really Bad Idea. the problem is that there's no way for an app to know whether it's better to use a global or a ULA in any particular case. it depends on the stability of the global and the reliability of routing to the network for that prefix, and also on the scope in which the ULA is routed, and also on the nature of the app (p2p or 2 party) [20:03:48] (Fredd --> Fred) [20:04:00] narten joins the room [20:04:31] I don't think anyone is talking about encouraging apps to prefer ulas over globals. [20:04:48] margaret's slide seemed to imply that. or maybe I misunderstood? [20:04:51] @Flyin ... that is why I mentioned 3484 ... and I agree w/ you ... and current 3484 works fine, except for WRT multicast [20:05:02] (SLide 24 - B2B) [20:05:35] pselkirk leaves the room [20:05:41] pselkirk joins the room [20:05:53] @ Flyin, Hartman - WRT Unicast, ULAs would be preferred for talking to other ULAs, but to to GLobal Unicast ... [20:05:59] No, the issue is that people may e xpect that if they only bind a host to a ULA it will not be able to receive packets from the global internet So, for example you bind a printer only to a ula and get surprised when you have someone on the other side of the world printing documents. solution: if you want a firewall, use one. [20:06:38] Greg @ mic ... [20:06:44] sam: that's one issue among many. the other problem is that just becaue you are talking to another ULA does not mean that your ULA is routable from the other end. [20:06:52] or I should say another problem. [20:07:05] @Hartman - gotchya, agreed [20:08:07] I agree that one ULA might not be able to talk to another. . . I'm not sure how that has anything to do with this proposal though. [20:08:29] not the one being discussed at the moment. just a note on margaret's last slide. [20:08:47] @Hartman - agreed, can a host always assume it's global address can reach any other global address? [20:08:52] EKR @ mic [20:08:53] I don't understand how one ULA to another has anything to do with nat66. [20:09:26] it's only related inasmuch as it's assumed that ULAs will be used behind the NAT66s [20:09:38] No, a host cannot assume one global address can reach another because of firewalls. nat66 does not make this any worse as far as I can tell. [20:09:46] Tony(?) @ mic [20:10:00] @Hartman - that was my point :) ... [20:10:30] Eric Kline @ mic [20:10:35] I think the assumption is that as with any use of ULAs you want to avoid making the ULA appear globally [20:10:36] no, but it's generally the case in ipv4 land that if you can't get there by talking to a host's global address, you probably can't get there at all (at least not without violating security rules). having multiple addresses in ipv6 with potentially varying reach for each opens a big can of worms. [20:10:40] williw joins the room [20:11:24] as for nat66, arguably anything that encourages use of ULAs makes the situation worse in practice, though the situation inherently exists in the v6 architecture as currently defined [20:11:26] @Flyin - multiple addresses, from multiple protocols, with varying reachability ... good times! [20:11:33] are we having fun yet? [20:12:13] Woj.Dec leaves the room [20:12:16] williw leaves the room [20:12:20] Woj.Dec joins the room [20:12:22] I think the "IPV6 has multiple addresses" ship has already sailed:-) [20:12:55] (sorry, missed name @ mic) [20:12:56] well v4 hosts can have multiple addresses too. but in general when people try it, they find it's a bad idea unless they impose lots of constraints. [20:13:04] (Slide 26 - Present model - PI/PA HultiHoming) [20:13:17] IT was Greg at the mic [20:13:39] @Flyin - the difference is the "default assumption" ... IPv4 broadly assumes one address per interface, everything beyond that is expected to be "interesting" [20:14:16] (Slide 27 - RFC3582 ... ) [20:14:17] yeah but multiple addresses per interface and multiple interfaces (now quite common) are only slighlty different from an app's perspective. [20:14:47] (Slide 28 - SHIM6) [20:15:04] I don't know. Source and dest address selection seem a lot more complex when you add in v6 [20:15:06] (Slide 28 - RFC3582 + SHIM6) [20:15:27] (Slide 30 - GSE) [20:15:57] sam: in practice, you're right. one way to deal with it is to discourage adding more addresses per host than necessary. another way is to try to make all prefixes more-or-less equally usable. [20:16:18] Greg @ mic [20:16:45] williw joins the room [20:17:10] (Slide 31 - RO) [20:18:33] sureshk leaves the room [20:19:14] (Slide 32 - RFC3582 + GSE) [20:19:40] Iljitsch @ mic [20:19:47] williw leaves the room [20:20:27] (name) @ mic [20:21:01] Margarate @ mic [20:21:08] erp, Margaret [20:21:38] flying, if it is true, we need a document that states multiple address is harmful. [20:22:00] @Ari ... probably way to late for that ... atleast in that genreal of a case ... [20:22:09] (Slide 33 - Remaining ... ) [20:22:15] I probably have the text already written somewhere....just need to dig it up and add boilerplate. [20:22:28] @Ari ... maybe make a statement WRT multiple addresses of conflicting scopes ... [20:22:34] though I don't know how helpful it would be to bring it up at this point...I'm more interested in seeing how to move things forward than freaking people out. [20:22:46] (Slide 34 ... Q&A) [20:23:09] Christian @ mic [20:23:27] ... votes in favor of us documenting this [20:25:02] Woj.Dec leaves the room [20:25:04] Tony @ mic ... [20:28:07] Greg @ mic [20:29:11] here's the thing - NAT66 starts to become beneficial (as opposed to the best way of doing something evil) IFF (a) it lets all apps - no matter where they are on the network - work in terms of a single global address space and the appearance of one address per host (or at least protocol engine), (b) it enables GSE or something like it, and (c) it allows redundant paths into or out of a network (which I think it does already). [20:29:14] pselkirk leaves the room [20:30:54] Greg ~"lack of reachability due to policy/acl/etc." ... assymetric routing vs state vs these ... (Seems to depend on placement of filtering) [20:31:20] pselkirk joins the room [20:31:37] Note that with hairpinning, you do get global addresses. [20:32:19] right. and that's close to what is needed. but you don't want to essentially force all traffic on the local network to go through the nat. [20:32:30] (missed name) at mic [20:33:22] Remi Despres @ mic [20:33:47] (It was Merica (sp?) ...) [20:35:04] (The other Remi @ mic [20:35:34] ((Chair encourages "Do we think that the IETF should define NAT66?" to be our primary Q)) [20:36:06] Jari @ mic [20:37:37] hehe ... --> the "least bad way to do NAT66", followed by immediate deprecation ... oh, and doesn't believe in topology obfuscation [20:38:09] Steve @ mic ... do it, but don't much with low-order 64b [20:38:30] Iljistsch @ mic [20:39:23] --> ~"conceptually treat NAT66 as firewall" [20:39:27] Bob @ mic [20:40:17] --> NAT66 is less evil that NA[p]T ... getting every customer a /48 is an added benefit ... scared by GSE [20:40:47] --> EID / ID vs locator split a myth ... [20:41:31] ((Margaret - the GSE was a possible future use, not part of the doc / proposal itself)) [20:42:13] Mark @ mic [20:43:01] I think there is a case to be made for topology hiding. problem is, there are a number of other requirements or highly desirable goals that contradict it. e.g. you really don't want apps to have to know which address to use in which context, and that's exactly what topology hiding gives you. about all that topology hiding via NAT gives you is that it hides information about where your hosts are on your local network. and there are other ways of doing that - e.g. trill. NAT doesn't hide your hosts' identities from outsiders. [20:43:08] --> mentions use of NAT66 to limit renumbering pain ... impactful change, but no internal renumbering [20:44:13] @Flyin - you are using topology hiding to mean hiding from (internal) hosts ... I think the term usually means hiding it from external hosts ... am I misunderstanding? [20:45:07] no I mean hiding it from external hosts. but from an application's POV you really don't want your hosts to have different addresses from inside the network than from outside the network. [20:45:36] Margaret calls for some consensus ... [20:45:50] vote [20:46:18] (Lotsof hands for, a couple against) ... note: Not a vote in support of the solution, but for using this as a basis to continue the conversation [20:46:25] jinmei leaves the room [20:46:59] Lars @ mic [20:47:24] Mark & Sam @ mic ... [20:47:33] v6/v4 translators have to deal with these issues also - because it's impossible to entirely avoid back to back translations [20:48:09] Dave @ mic [20:48:32] behcet.sarikaya leaves the room [20:48:53] --> encourages consideration of NAT64 while discussing NAT66 [20:49:04] Jari also wants to scope the discussion ... [20:49:22] Randy @ mic ... "keep your enemies close" :) [20:49:32] **Next presentation: Virtual IPv6 Connectivity for IPv4-only networks (Christian Vogt, 25) ... http://tools.ietf.org/html/draft-vogt-durand-virtual-ip6-connectivity-00 ... http://www3.ietf.org/proceedings/08nov/slides/behave-13.pdf [20:50:26] lion joins the room [20:50:50] (Slide #2 - Motivation ...) [20:52:10] (Slide #3 - Impetus ...) [20:52:41] odd that this is thought of as a tool for the future, when v4 only networks are the norm now. to a large degree whether you want to do virtual v6 from within v4-only or virtual v4 from within v6 only depends on whether you run clients or servers. [20:53:34] @Flyin - I think the assumption is that the server side is "easy", the client side is hard ... but I could be wrong! [20:54:16] ... and mapping/translation in one direction is currently seen as easy ... [20:54:49] I think it's highly dependent on circumstances and the nature of your protocol. bottom line - both cases are important. and one is about as hard as another in terms of deployment, even if not in terms of technical difficulty. [20:55:03] (Slide #4 - Virtv6...) [20:56:27] @ Flyin - not arguing that one ... and I think this slide makes it applicable for either case, if I am reading/understanding properly [20:58:08] Cullen Jennings leaves the room [20:58:43] (Slide #5 - Inbound ...) [20:59:13] Bob joins the room [21:00:06] (Slide #6 - Outbound ...) [21:00:53] lebobits joins the room [21:01:23] (Slide #6 - Conclusions, Next Steps ... Q&A) [21:01:34] Correction : (Slide #7 - Conclusions, Next Steps ... Q&A) [21:02:25] lion leaves the room [21:02:49] lion joins the room [21:03:14] **Next presentation: IPv6 destination header option (Remi Denis-Courmont, 15) ... http://tools.ietf.org/html/draft-denis-behave-v4v6exthdr-00 ... http://www3.ietf.org/proceedings/08nov/slides/behave-11.pdf [21:03:46] ((Note : we may lose network connectivity hear in 10 or so minutes ... I assume the audio feed dies as well ... )) [21:04:00] (erp, hear --> here) [21:04:23] (Slide #2 - Principle) [21:04:49] (Slide #3 - Open 1/4) [21:05:27] (Slide #4 - Open 2/4) [21:05:41] What was the conclusion about the IPv6-connectivity draft? Is the author just going to keep working on it? [21:05:59] assie leaves the room [21:06:13] ... there wasn't a concolusion, per se - no vote, etc. ... so yes, I guess their work will continue ... [21:06:21] (Slide #5 - Open 3/4) [21:06:23] Thank you. [21:06:27] NP [21:07:37] (Slide #6 - Open 4/4) [21:08:15] The chairs will bring up on the list discussion around accepting as WG item etc. [21:08:34] Chair moves to have author continue work, address open issues ... more discussion on ML ... [21:08:54] **Next presentation: On-demand privacy protection (Remi Despres, 10) ... http://tools.ietf.org/html/draft-despres-sam-01#section-3.6 ... no slides? [21:09:01] richard.barnes leaves the room [21:09:49] http://www.ietf.org/proceedings/08nov/slides/behave-15.pdf [21:09:57] @Jon - thx! [21:10:08] (slide #4) [21:10:37] richard.barnes joins the room [21:11:20] (Slide #5) [21:11:35] richard.barnes leaves the room [21:13:04] (Slide #6) [21:13:36] marka joins the room [21:13:44] richard.barnes joins the room [21:14:09] (Slide #7) [21:15:10] Q&A [21:15:10] suzsuz leaves the room [21:15:58] Dave & Remi talking ... [21:16:09] Bob leaves the room [21:16:23] arifumi 2.2 leaves the room [21:16:30] trejrco, thank you for scribing (for 3 sessions!) [21:16:32] --fin ... thanks all, say goodbye to IETF73! [21:16:32] levigner leaves the room [21:16:35] flyinhome leaves the room [21:16:41] marka leaves the room [21:16:48] No worries, but thanks for saying so ;) [21:16:49] JonathanLennox leaves the room [21:16:53] TJ leaves the room [21:16:59] karen.s.seo leaves the room [21:17:01] lion leaves the room: Computer went to sleep [21:17:01] richard.barnes leaves the room [21:17:10] Lars leaves the room [21:17:10] satoru leaves the room [21:17:20] hirocomb12 leaves the room [21:17:21] pselkirk leaves the room [21:18:02] sm leaves the room [21:18:25] leaves the room [21:19:22] narten leaves the room [21:23:05] magnus leaves the room [21:25:36] kanda leaves the room [21:27:27] lebobits leaves the room [21:27:28] lebobits joins the room [21:32:55] lebobits leaves the room [21:59:18] fujisaki leaves the room [23:56:16] Lars joins the room