[00:00:02] wmhaddad joins the room [00:08:23] rdroms leaves the room [00:14:50] kehong leaves the room: Replaced by new connection. [00:14:50] kehong joins the room [00:27:17] (for remote folks: yes it's been longer than 30 minutes but still no sign of starting again )imminent...) [00:28:39] ok here we go, there's the warning [00:29:02] Double IVI moved to tomorrow... [00:29:09] ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100040.zip [00:29:30] actually now ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100050.zip [00:29:39] kehong leaves the room: Disconnected. [00:31:08] satoru.matsushima joins the room [00:32:27] kehong joins the room [00:33:28] http://tools.ietf.org/id/draft-nat46compare-perkins-00.txt [00:34:56] ok these are Behave scenarios 2 & 4, not 3GPP scenarios 2 & 4 [00:35:12] oh, man [00:35:58] Phil Roberts joins the room [00:39:38] this slide doesn't explain how port discovery works [00:42:00] rdroms joins the room [00:43:42] at the first presentation of Charles about SIPNAT, I went on the mike to describe a very easy DOS attack. To my knowledge, it has not been fixed. [00:46:32] What is IVI? [00:46:52] it seems like 4-6 [00:48:20] stateless translation [00:48:29] charlie is talking about IPv4 initiated communication [00:49:19] IVI does it statelessly but only for a small number of IPv6 destinations, other approaches like SIPNAT and NAT-PMP are stateful and work for a large number of destinations but only work for apps that use DNS [00:49:46] but they're all IPv4-to-IPv6 translation approaches [00:51:54] Thx Dave [00:53:03] IVI is the name of the China Mobile implementation. In the IETF, we have http://tools.ietf.org/wg/behave/draft-ietf-behave-v6v4-xlate/ which is the consensus version [00:53:09] and the IETF one isn't called IVI [00:53:36] but they're close enough to understand [00:54:07] (IVI isn't from China Mobile. Rather, CERNET/Tsinghua Univ.) [00:54:16] right, thanks for the correction [00:54:35] ryuji@mt.view joins the room [00:54:43] and comes from roamn numerals :-) [00:54:44] (do I understand correctly that IVI is Roman numerals for IV to VI, and for VI to IV?) [00:54:54] yes [00:55:35] ryuji@mt.view leaves the room [00:55:50] ryuji@mt.view joins the room [00:58:37] Lars leaves the room [00:58:44] Lars joins the room [01:02:54] ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100022.zip [01:03:15] slides at ftp://10.30.2.60/WORKSHOP/INBOX/IPW100052.zip [01:04:14] Dan Wing leaves the room [01:04:30] Dan Wing joins the room [01:11:09] Phil Roberts leaves the room [01:13:57] kehong leaves the room [01:15:01] these last 2 slides are hard to follow. I understood scenario 3, but not reall the other three [01:15:45] (well technically I understand the applicability to scenarios 1 and 2, but I don't understnad the bullets on the slide :) [01:16:18] ok, he's asking the same question [01:17:06] i didn't understand the answer [01:17:22] anyone? [01:19:58] I can't hear hui very well [01:24:32] ryuji@mt.view leaves the room [01:27:23] where's the slides shown now? [01:27:39] (the "CMCC Service" and "3rd Party Apps" slides) [01:28:28] Phil Roberts joins the room [01:32:03] ryuji@mt.view joins the room [01:34:59] Lars leaves the room: Replaced by new connection [01:35:02] Lars joins the room [01:37:48] Dan Wing leaves the room [01:39:21] Dan Wing joins the room [01:40:15] Phil Roberts leaves the room [01:42:56] wmhaddad leaves the room [01:43:29] Phil Roberts joins the room [01:44:15] Phil Roberts leaves the room [01:44:37] Phil Roberts joins the room [01:55:50] rdroms leaves the room [01:56:52] people are getting bored and leaving? [01:57:06] inscrutable is a good word [01:59:07] anyways I think it is time to go [02:00:04] Phil Roberts leaves the room [02:04:09] behcet.sarikaya leaves the room [02:04:15] jlaganie leaves the room [02:04:16] marc.blanchet.qc leaves the room [02:05:13] HUI leaves the room [02:05:15] sureshk leaves the room [02:06:09] ietfdbh leaves the room [02:06:28] satoru.matsushima leaves the room [02:07:12] Dan Wing leaves the room [02:07:13] Jonne Soininen leaves the room [02:08:38] spencerdawkins leaves the room [02:09:51] jouni.korhonen leaves the room [02:12:08] Magnus Westerlund leaves the room [02:13:16] Scott Brim leaves the room [02:16:46] Dave Thaler leaves the room [02:18:16] jariarkko leaves the room [02:24:49] ryuji@mt.view leaves the room [02:48:14] wmhaddad joins the room [02:48:33] wmhaddad leaves the room: Logged out [03:23:40] Lars leaves the room [03:44:09] Ruri Hiromi joins the room [05:05:14] Ruri Hiromi leaves the room [05:06:02] Ruri Hiromi joins the room [06:02:59] Scott Brim joins the room [06:03:05] Scott Brim leaves the room [06:22:39] Lars joins the room [06:41:03] Lars leaves the room [10:18:17] Ruri Hiromi leaves the room [16:03:07] behcet.sarikaya joins the room [16:03:30] behcet.sarikaya leaves the room [16:12:46] jouni.korhonen joins the room [16:15:19] Scott Brim joins the room [16:18:18] Dave Thaler joins the room [16:18:34] behcet.sarikaya joins the room [16:18:54] i can't sign into my ietf jabber acount this morning, something must be down [16:20:03] had to use an alternate account [16:21:51] same, I used gmail [16:22:17] Scott Brim leaves the room [16:22:21] ftp://10.30.2.60/WORKSHOP/INBOX/IPW100057.zip [16:22:54] now also at ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100057.zip [16:22:56] ietfdbh joins the room [16:23:01] DWING-WXP0DB1C9E5F joins the room [16:24:18] Jonne Soininen joins the room [16:26:53] presentation by Xing Li over Webex remotely [16:27:32] (audio quality is better than the in-room microphones!) [16:27:43] DWING-WXP0DB1C9E5F leaves the room [16:27:56] marc.blanchet.qc joins the room [16:27:59] Dan Wing joins the room [16:28:59] Scott Brim joins the room [16:29:35] tsavo joins the room [16:30:14] just entered. anyone would mind telling me which filename is currently being presented? [16:30:24] ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100057.zip [16:32:20] ryuji@mt.view joins the room [16:32:23] When I look in 57 in INBOX I get a Dan Wing presentation [16:32:59] @Scott: refresh your page [16:33:45] Slide 5 now [16:34:13] fixed thanks [16:37:06] jariarkko joins the room [16:38:05] but each IPv6 address only gets 1 port to use for communication with IPv4 destinations [16:39:18] ok N ports [16:39:54] jb joins the room [16:41:47] did they already get 2001 prefix reserved? [16:45:21] the middle section should be "Internet Drafts" (they're not "IETF" drafts) [16:47:40] sureshk joins the room [16:48:36] Behcet: "2001:0DB8::/32 has been assigned as a NON-ROUTABLE range to be used for documentation purpose [RFC3849 ]. " [16:49:01] Phil Roberts joins the room [16:52:00] ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100017.zip [16:52:15] no slides just the doc [16:54:15] just says it's applicable to the IPv6-only case [16:54:18] ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100038.zip [16:54:38] 17 was about NAT64/DNS64 [16:54:43] now on DS+NAT44 [16:55:12] I couldn't hear the speaker [16:55:51] DS+NAT44 is for scenario 2 & 4 (dual-stack, but not enough IPv4 space to give unique addresses to every device) [16:56:32] @dave, the document analyzes whether the NAT44 should be separate from the P-GW or colocated [16:56:41] ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100053.zip [16:56:50] it concludes that it is better to colocate the NAT functionality with the P-GW [16:57:02] apparently a new version of 53 is at ftp://10.30.2.60/WORKSHOP/INBOX/IPW100053.zip [16:58:19] rdroms joins the room [17:03:38] satoru.matsushima joins the room [17:04:51] wmhaddad joins the room [17:15:45] HUI joins the room [17:15:51] next preso at ftp://10.30.2.60/WORKSHOP/INBOX/IPW100058.zip [17:16:28] also older version at ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100058.zip in case someone can't get to the private server [17:22:51] next is ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100019.zip (no slides just word doc) [17:24:31] if anyone remote can't hear him well, he's just reading the doc (it's just a couple paragraphs long) [17:39:58] spencerdawkins joins the room [17:40:40] I think the question is that if a PNAT UE only asks for an IPv6 PDP context, then when it roams to a dual-stack network, it wouldn't get native IPv4 even though it's available [17:42:49] Magnus Westerlund joins the room [17:43:16] a visited network must provide nat64 even if everything supports v6, because the apps think they are speaking v4 [17:43:31] Dave, Scott: correct. [17:43:45] why??? [17:43:48] Scott - agreed. [17:44:19] because a PNAT UE never, ever, gets an IPv4 address from the network. [17:45:29] I mean I don't understand the motivation ;) [17:45:32] My understanding is that the is a complementary PNAT function in the operator network that demultiplexes the IPv4/IPv6 outbound traffic and multiplexes the inbound IPv4/IPv6 traffic into the IPv6-only stream to the UE. [17:45:51] Scott: motivation for what? [17:46:21] PNAT [17:46:53] IPv6-only traffic over the air, which saves capex/opex. [17:47:17] (repeating what I think I heard, not necessarily what I think is true) [17:48:04] I think their motivation is that you can have 1 solution that supports many scenarios, rather than a bunch of point solutions (tunneling for some things, translation for other things, etc), hence saving on expense and support costs [17:49:09] But there aren't many scenarios. [17:49:26] and the apps that would work with tunneling but not with translation they believe are rare enough to not care about [17:49:28] The IPv6-only scenario seems to be an artificial scenario. [17:49:46] @Dave the only problem there is you need PNAT GW in the network [17:50:07] yes, when you're talking to the Internet [17:50:13] but not when you're talking UE to UE [17:50:27] Sorry, the IPv4 apps over IPv6-only over-the-air traffic seems to be an artificial scenario. [17:50:31] Good point [17:51:34] @ralph: I think they'd phrase the scenario as IPv4 or IPv6 apps to anything else (IPv4 or IPv6) while minimizing the number of things to deploy and train people about [17:52:03] IPv6-only over the air isn't the scenario per se, it's their solution to that scenario [17:52:44] Hm. Now I have to rethink PNAT. I thought the issue was just IPvX<->IPvX. Wasn't thinking about IPvX<->IPvY. [17:53:01] yes. the whole point of PNAT was 1 solution to solve both. [17:53:19] rather that the currnt IETF story which is "deploy two separate solutions" [17:53:28] s/that/than [17:53:40] [17:54:16] the IETF story is that tunneling works for more apps than translation. The PNAT story is "yeah so what? look at the business costs" [17:56:03] Tunneling may work better for IPvX<->IPvX. If IPvX<->IPvY is a requirement, translation is required. So, if you've got to have translation anyway, why not use translation for everything. Do I have that right (thanks for your patience). [17:56:08] so the debate partly comes down to expected support costs when some apps break [17:56:25] that's their argument, right [18:01:14] Phil Roberts leaves the room [18:02:16] it depends who supports the apps. Yesterday we essentially demonstrated that this is a small problem, and the app vendors will be able to responsd [18:03:18] HUI leaves the room [18:03:20] I missed what doc # this preso is, anyone? [18:03:23] HUI joins the room [18:03:38] 23 I guess [18:03:48] @scott: I wasn't convinced of that [18:03:56] you would know better [18:04:08] ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100023.zip [18:04:14] (thx jb) [18:04:20] 23 is the .doc [18:04:50] Phil Roberts joins the room [18:05:12] Phil Roberts leaves the room [18:05:20] slide is 51 [18:05:24] slides ftp://10.30.2.60/WORKSHOP/INBOX/IPW100051.zip [18:05:48] Phil Roberts joins the room [18:06:00] ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100051.zip [18:12:07] lots of interesting points being made on the mic [18:14:04] @scott: the reason I think apps are a problem are for the case when you have a PC connected via a UE (I do this myself for instance with my phone) [18:14:59] Dave - are the problems different than problems current apps solve when traversing NAT44? [18:15:41] only negligibly so. It's basically the same. [18:16:14] Phil Roberts leaves the room [18:16:16] 30 minute break starting now [18:16:23] satoru.matsushima leaves the room [18:17:16] rdroms leaves the room [18:18:12] Ralph, problems are slightly different, because ALG has to make assumptions about the IPv4 address in the payload. The ALG can't do anything useful with IPv4 addresses in the payload that aren't the UE sending the packet. For example, 3rd party referrals. This also means the ALGs are not quite the same as the ALGs shipped for the last 5-10 years for various OSs. [18:22:08] Phil Roberts joins the room [18:26:14] Phil Roberts leaves the room [18:29:04] Phil Roberts joins the room [18:30:14] Phil Roberts leaves the room [18:30:57] Phil Roberts joins the room [18:36:05] jb leaves the room [18:37:44] Phil Roberts leaves the room [18:40:09] ietfdbh leaves the room [18:40:09] ietfdbh joins the room [18:40:33] julien.bournelle joins the room [18:40:34] Phil Roberts joins the room [18:40:46] Phil Roberts leaves the room [18:40:48] ryuji@mt.view leaves the room [18:50:17] julien laganier joins the room [18:50:28] hi julien [18:50:37] hi julien [18:51:00] julien laganier leaves the room [18:51:00] HUI leaves the room [18:51:00] sureshk leaves the room [18:51:00] jariarkko leaves the room [18:51:58] satoru.matsushima joins the room [18:54:39] ryuji@mt.view joins the room [18:55:44] would it make more sense to cast PNAT in terms of ecconomics typically there is a per PDP cost [18:55:47] starting again... [18:56:07] I didn't catch the doc number but the slides look like ones we saw yesterday [18:56:16] 54 [18:56:38] thx: ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100054.zip [19:00:07] Scott Brim leaves the room [19:00:23] julien.laganier joins the room [19:03:06] I don't understand the IPv4 address referral part [19:03:34] Dan on mic [19:04:56] Scott Brim joins the room [19:05:52] I don't understand it either, even after asking for clarification [19:06:04] Sri asked is PNAT GW in the path for UE-UE communication [19:06:16] The answer is no [19:06:33] wmhaddad leaves the room [19:07:04] ryuji@mt.view leaves the room [19:08:45] rdroms joins the room [19:10:01] sureshk joins the room [19:10:34] ryuji@mt.view joins the room [19:14:53] I don't understand why we are discussing a scenario that is not agreed on in 3GPP in the first place; are we in an IETF meeting or a 3GPP-IETF WS [19:15:45] or a China Mobile meeting? [19:16:18] ryuji@mt.view leaves the room [19:17:21] or a PNAT workshop =) [19:18:17] slides? [19:18:45] lovely... [19:18:49] I think it's a mistake to assume HTTP clients == browsers [19:18:59] well, yeah [19:19:06] there's web services, REST, etc that are popular today [19:19:28] on resource constrained devices [19:19:51] IPW100056, i think [19:19:56] http is the internet. [19:20:01] Yes, but isn't HTTP implementations usually provided in the software platform that most applications build on? [19:20:16] there's no 56 on either servier [19:20:41] which presentation is this? [19:20:48] magnus: yes. But I don't know whether those apps get dual-stack for free. [19:21:05] PPT on IPW100015. [19:21:15] (I think they do on windows, but not sure about all mobile OSs) [19:21:47] 15 is the draft [19:23:45] 56 now available in the INBOX [19:23:59] yep ftp://10.30.2.60/WORKSHOP/INBOX/IPW100056.zip [19:27:05] sureshk leaves the room [19:28:20] sureshk joins the room [19:29:30] sureshk leaves the room [19:29:41] sureshk joins the room [19:29:55] What is HBT in this slide 10? [19:30:04] host based translation [19:30:18] NAT46 in the host (+ALG) [19:30:22] @suresh, thx O:) [19:30:35] ryuji@mt.view joins the room [19:32:29] ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100047.zip [19:40:40] Phil Roberts joins the room [19:41:11] could someone repeat the pointer to this slide deck? (I didn't realize I'd dropped out of the jabber room) [19:41:17] (this is a nicely written slide deck) [19:41:23] (11:32:28 AM) Dave Thaler: ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100047.zip [19:41:23] ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100047.zip [19:41:47] Dave, yes - I would have liked this summary deck on Monday. [19:41:53] thanks [19:42:51] yeah [19:44:19] Yeah I wished they came upfront in the agenda [19:55:16] I think the devil is in the details [20:00:42] Microsoft's NAT64 scenario falls into behave's "IPv6 Internet to an IPv4 network" scenario, and the IPsec gateway and the NAT64 are used together and typically co-located. But this is different from the 3GPP scenarios which is more "an IPv6 network to IPv4 Internet" [20:01:37] all of this stuff the devil is in the details. Even my prezo talking about ALG concerns, i didn't get into 3rd party referrals; too esoteric. I mentioned 3rd party referrals during my comments to the previous presentation, though. [20:03:02] (waiting for Scott to say grobj) [20:03:09] :) [20:03:56] At a high level dual stack hosts and nothing else solves all problems [20:05:10] GROBJ would require application upgrades. PNAT's raison d'etre are un-upgradable applications. (That is, applications that are "not upgradable". We might call them "gnat upgradable". Sorry, was that too long for the joke?) [20:05:19] 2-hour lunch break beginning now [20:05:32] Dan - wow, didn't see that one coming. [20:05:34] Phil Roberts leaves the room [20:05:42] Scott Brim leaves the room [20:05:44] behcet.sarikaya leaves the room [20:05:47] :-) [20:05:54] spencerdawkins leaves the room [20:06:26] ryuji@mt.view leaves the room [20:07:04] rdroms leaves the room [20:07:12] ietfdbh leaves the room [20:07:24] julien.laganier leaves the room [20:08:03] satoru.matsushima leaves the room [20:08:48] julien.bournelle leaves the room [20:10:02] Dan Wing leaves the room [20:11:39] tsavo leaves the room [20:11:39] Magnus Westerlund leaves the room [20:12:24] tsavo joins the room [20:16:05] Jonne Soininen leaves the room [20:17:21] jouni.korhonen leaves the room [20:25:28] Dave Thaler leaves the room [21:15:11] marc.blanchet.qc leaves the room [21:15:19] marc.blanchet.qc joins the room [21:16:43] marc.blanchet.qc leaves the room [21:39:20] jouni.korhonen joins the room [21:39:20] tsavo leaves the room [21:46:01] Scott Brim joins the room [21:47:53] jariarkko joins the room [21:49:41] julien.bournelle joins the room [21:50:55] julien.laganier joins the room [21:52:04] julien.bournelle leaves the room [21:52:30] julien.bournelle joins the room [21:54:08] rdroms joins the room [21:54:43] jariarkko leaves the room [21:54:51] jariarkko joins the room [21:55:56] rdroms leaves the room [21:56:41] Dave Thaler joins the room [22:01:13] ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100055.zip [22:01:47] wmhaddad joins the room [22:02:03] behcet.sarikaya joins the room [22:03:37] slides are at ftp://10.30.2.60/WORKSHOP/Docs/IPW100055.zip [22:04:14] Jonne Soininen joins the room [22:04:49] rdroms joins the room [22:07:47] next is ftp://10.30.2.60/WORKSHOP/INBOX/IPW100059.zip [22:08:06] (older version at ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100059.zip) [22:09:53] ietfdbh joins the room [22:12:49] blinks [22:12:55] spencerdawkins joins the room [22:13:47] How will it be decided which group (3gpp, gsma) will receive the "more operational guidelines"? [22:14:41] satoru.matsushima joins the room [22:15:19] ryuji@mt.view joins the room [22:16:43] Magnus Westerlund joins the room [22:26:27] @scott: in GSMA this would drop under some existing or to-be-defined subgroup of IREG. [22:27:11] behcet.sarikaya leaves the room [22:29:33] julien.bournelle leaves the room [22:30:47] rdroms leaves the room [22:32:34] julien.laganier leaves the room [22:33:23] satoru.matsushima leaves the room [22:39:28] ryuji@mt.view leaves the room [22:40:40] ryuji@mt.view joins the room [22:41:36] Jonne Soininen leaves the room [22:42:38] ryuji@mt.view leaves the room [22:43:54] Scott Brim leaves the room [22:45:03] Dave Thaler leaves the room [22:56:20] ietfdbh leaves the room [22:57:34] jouni.korhonen leaves the room [22:59:37] ietfdbh joins the room [23:10:06] ietfdbh leaves the room [23:27:44] marc.blanchet.qc joins the room [23:40:39] marc.blanchet.qc leaves the room [23:43:05] spencerdawkins leaves the room [23:55:46] wmhaddad leaves the room