[15:42:40] Eadson.zhangdong joins the room [15:47:12] yangqinqin09 joins the room [15:51:17] lowekamp@gmail.com joins the room [15:52:41] csp joins the room [15:53:44] anyone have audio yet? [15:55:42] Nothing yet [15:57:08] L41587ME0F2AAF7 joins the room [15:58:02] dmw joins the room [15:58:26] hirocomb12 joins the room [15:58:58] Robert Raszuk joins the room [15:59:57] Lee Howard joins the room [16:00:58] Andrew Sullivan joins the room [16:02:21] Andrew Sullivan leaves the room [16:02:43] A. Mäkelä joins the room [16:03:23] matthijs joins the room [16:03:37] Andrew Sullivan joins the room [16:04:07] fdupont joins the room [16:04:14] shep joins the room [16:04:17] momose joins the room [16:04:30] suz joins the room [16:04:50] Suzanne joins the room [16:05:12] ruri joins the room [16:05:12] Mark Baugher joins the room [16:05:17] mikemlb joins the room [16:05:37] Dave Thaler joins the room [16:05:53] iljitsch joins the room [16:06:02] Hi, I'll be the jabber scribe [16:06:12] Antonio Moreiras joins the room [16:06:21] it would be good if someone else could relay questions to the mike because I'm not particularly close [16:06:26] A. Mäkelä leaves the room [16:06:28] wmhaddad joins the room [16:06:28] dan talking [16:06:41] shikob joins the room [16:06:42] existing milestones, not enough review for sctp [16:06:45] turn on track but date slipped [16:07:13] donley.chris joins the room [16:07:13] I gave feedback on the SCTP draft at the last IETF. Have they revved the draft in response to those comments? [16:07:52] anyone relay? [16:07:55] yes [16:07:59] iljitsch relayed [16:08:08] dan: will check on that [16:08:08] (no answer to the question yet) [16:08:17] becarpenter joins the room [16:08:19] Magnus Westerlund joins the room [16:08:25] fujisaki joins the room [16:08:35] new editor for turn tcp, will be a new date for that [16:08:42] same for turnv6 [16:08:53] Atarashi Yoshifumi joins the room [16:08:53] shep leaves the room [16:08:55] momose leaves the room [16:09:10] ndelregno joins the room [16:09:14] momose joins the room [16:09:31] (sorry, blue sheet) [16:09:41] turn uri draft needs reviews [16:10:08] gurudeep joins the room [16:10:09] fred baker about framework for ipv4/v6 translation [16:10:23] http://www3.ietf.org/proceedings/09mar/slides/behave-4.pdf [16:10:26] Ole Troan joins the room [16:10:41] thanks dave [16:10:58] outcome from montreal [16:11:06] all of this is in 4 documents [16:11:13] * framework [16:11:19] * update to SIIT [16:11:29] * extensions for stateful translator [16:11:35] * DNS gateway [16:11:41] * possible future stuff like ftp [16:11:46] (isn't that 5?) [16:12:02] lowekamp@gmail.com leaves the room [16:12:05] only two things updated in this version [16:12:19] stateless translation: ivi [16:12:27] stateful: nat64 (v6 initiated) [16:12:38] (ivi can be initiated from either dirction) [16:13:16] some providers are telling us want to build v6-only networks and then have ability to access v4 content [16:13:21] almost any translator will do that [16:13:24] many proposals [16:13:49] but this only gets you so far [16:13:54] Wes Beebee joins the room [16:14:29] people are only "tv consumers" this way, but they will also want to offer services, so further up the adoption curve we have a choice: v4 in parallel (hm...) or embed v4 address somewhere in v6 [16:14:37] hi wes [16:14:56] hi iljitsch... [16:14:56] Jabber-Wile joins the room [16:15:46] (fred explaining different options) [16:17:05] see pictures in "the scenarios and the solutions" slide [16:17:20] strongly recommend that you read the document [16:17:27] explained in further detail there [16:19:48] "our" (draft authors???) recommendation: use LIR prefix [16:20:06] for stateful wellknown would be possible but see no advantages [16:20:13] yes draft authors [16:20:17] some choices for prefix length such as 40, 44, 96 [16:20:37] (the drafts aren't WG drafts... that's part of the discussion later on the agenda) [16:21:42] alain durand at the mike: [16:21:55] this won't let a v4 legacy device in the home talk to... (I assume v6 world) [16:22:05] ...talk to another v4 device [16:22:16] fred: each subscriber has at least v4, might have both [16:22:43] give them a prefix, use all bits but one for subnet id, use zero subnet or some such for translator [16:22:52] alain is probably meaning to clarify the division of labor between behave and softwires [16:23:17] seems they are now discussing translating inside the home [16:24:20] alain: so this is complementary to dual stack light? [16:24:27] yes [16:24:42] new set of slides: IP/ICMP translation algorithm (SIIT update) [16:25:11] rfc 2765 has stateful and statless options [16:26:05] see translation model slide [16:26:12] shikob leaves the room [16:26:59] yangqinqin09 leaves the room [16:27:15] in stateless there s a 1-to-1 mapping between v4 and v6 addresses [16:27:26] http://www3.ietf.org/proceedings/09mar/slides/behave-6.pdf [16:28:21] dave at non-chair mike: [16:28:32] mhasib joins the room [16:28:40] one of the issues with original SIIT it constrains the prefix [16:28:53] kanda joins the room [16:28:54] propose that we avoid that mistake, don't talk about prefix in this document [16:29:00] slides: http://www.ietf.org/proceedings/09mar/slides/behave-6.pdf [http://www.ietf.org/proceedings/09mar/slides/behave-6.pdf] [16:29:30] fred point at the document? [16:29:39] dave: preferably point at nothing [16:29:53] satoru.matsushima joins the room [16:30:03] philip matthews: I see daves point [16:30:30] another person agrees but doesn't say their name (nobody has so far, come on, people, I don't know all of you!) and is gone before I can look [16:30:37] that was keith moore [16:30:48] ipv4 embedded and "ipv4 related" addresses [16:31:31] shep joins the room [16:31:50] udp translation: in v6 the checksum is mandatory [16:32:11] fine for translator, create one if there isn't one at 56k, not so much for multi-gigabit [16:32:32] should be some flexibility that translator doesn't accept these messages [16:33:02] there are suggestions to allow no udp checksum for tunneling [16:33:13] fred wants to let the administrator allow that [16:34:23] remote joins the room [16:34:24] next slide [16:34:31] mneed to look at checksum in stateful mode [16:35:12] mhasib leaves the room [16:35:22] not in stateless mode [16:35:40] (iljitsch: if you are very careful about selecting the IPv6 address) [16:36:01] in stateless obviously can't forward packet without table entry [16:36:10] from v4 to v6, in other direction not a problem [16:36:58] christian vogt: charlie perkens had a proposal for v4 initiation [16:37:00] dave: is on the agenda [16:37:22] will be discussed tomorrow [16:37:29] christian: can combine with this [16:37:47] fred: my concern is that this is a weakness of NAT64 [16:38:13] philip: original SIIT left this very flexible, maybe keep it that way [16:38:26] fred: specification doesn't preclude this [16:38:53] fred is done [16:39:05] next: marcelo about nat64 [16:39:49] marcelo: [16:39:57] going to talk about stateful translation called NAT64 [16:40:08] already discussed this previously so keep it short [16:40:20] http://www3.ietf.org/proceedings/09mar/slides/behave-9.pdf [16:40:30] mikemlb leaves the room: Replaced by new connection [16:40:36] behcet joins the room [16:40:42] scenario: v6-only host wants to talk to v4 host, asks for AAAA record from DNS64 function, isn't found, then asks for A, DNS64 synthesizes AAAA record [16:40:53] v6 guy sends v6 packet, NAT64 translates [16:41:18] still work to do [16:41:31] timeline seems to be one year, if we can't finish by the end of the year not that useful anymore [16:41:36] so we want to finish in a year [16:41:53] need to decide on prefix64, we need to move forward [16:42:31] we're going to maek basic spec that progresses very fast, only basic stuff in there, we have udp, going to do tcp, icmp, fragmentation, endpoint independence as per current behave guidelines [16:43:01] other features in companion documents that may progress in a different timeframe: sctp, dccp, ipsec, ftp alg, alternatives to endpoint independence [16:43:20] shep leaves the room [16:43:22] satoru.matsushima leaves the room [16:43:23] momose leaves the room [16:43:26] alain: about ftp, we have trials and ftp agent is one of the things that we run into over and over again [16:43:36] matthijs leaves the room [16:43:37] ruri leaves the room [16:43:49] momose joins the room [16:44:44] ruriham joins the room [16:45:24] dan agrees this is important [16:45:33] me: active or only passive ftp support [16:45:43] alain: just want it to work [16:45:58] (dan said 0nly 70% of ftp servers handle epsv) [16:46:10] me: so yo udon't know [16:46:12] brian carpenter: both [16:46:19] L41587ME0F2AAF7 leaves the room [16:46:31] brian: can you recap what you just said, I missed it [16:47:24] satoru.matsushima joins the room [16:47:26] dave: want input on which items are high priority, should be in same document or not [16:47:40] ftp in same document, hum [16:47:45] shep joins the room [16:47:46] in different, hum [16:47:55] strong consensus on latter [16:48:13] = high priority, but separate document [16:48:41] @Iljitsch: 1. Make sure that the missing topics are listed as 'future work' 2. Have a separate section listing responses to RFC4966 issues. [16:50:03] other people have more to say about this, missed the details [16:50:17] L41587ME0F2AAF7 joins the room [16:50:19] marcelo: proposal: progress nat64 fast, keep discussion going on the rest [16:51:00] endpoint independece [16:51:11] philip: currently required, so what we're doing is not a change [16:51:39] gurudeep leaves the room [16:51:41] stuart cheshire: is a danger, ask what people want and they'll want everything, personally think passive mode is enough for ftp [16:52:22] if there is a real problem someone will build a web gateway, don't ahve to solve every thingle probelm with translators [16:52:47] eliot.lear joins the room [16:52:51] magnus: endpoint independence needs to be default or we break nat traversal, separate document about protocols that can do without is the right way forward [16:53:23] dave: people are thinking that alternatives to endpoint independence aren't a requirement [16:53:25] (???) [16:53:27] behcet leaves the room [16:53:49] philip: interesting question, don't know if we want it or not, do need debate but not as part as nat64 [16:54:12] magnus: let this progress as individual draft then see if there's interest to take it on [16:54:17] marcelo: more input on this? [16:54:19] mohsen joins the room [16:54:31] next DNS64 [16:54:48] http://www3.ietf.org/proceedings/09mar/slides/behave-8.pdf [16:54:48] slides: http://www.ietf.org/proceedings/09mar/slides/behave-8.pdf [http://www.ietf.org/proceedings/09mar/slides/behave-8.pdf] [16:54:54] (still marcelo) [16:55:06] picture is the same, but we're now going to focus on the dns64 part [16:55:14] draft is in better shape than nat64 [16:55:18] yangqinqin09 joins the room [16:55:26] lliuhto joins the room [16:55:33] dns64 function can be in local dns server or host itself [16:56:34] dnssec works for the most part [16:56:41] yangqinqin09 leaves the room [16:56:49] see slide for details [16:57:29] doesn't work if you have a stub resolver that knows dnssec but not translation, this will break because you need to validate and then translate [16:57:42] but probably not an issue because few validating resolvers out there [16:57:53] alain: get dnsop wg opinion [16:58:04] marcelo: that's what we did last IETF [16:58:44] andrew sullivan with dnsext hat: practically no dnssec stub resolvers, so standardize this fast and it can be put in as people write the code [16:59:16] (note that nuances get lost in translation! ask people whether this is what they actually said/meant before flaming) [16:59:33] mikemlb joins the room [17:00:00] if the dns64 does the validation can indicate that it's valid although it gives AAAA rather than A record so it's really lying [17:00:04] shep leaves the room [17:00:17] someone at mike: don't trust bits unless you know server's policy [17:00:51] ndelregno leaves the room: Replaced by new connection [17:00:51] ndelregno joins the room [17:00:58] andrew: I don't think what we intend to do breaks anything but can't prove it yet [17:01:19] discussion of bits [17:01:29] yangqinqin09 joins the room [17:01:48] the cd bits mean that I validate and just give me the data so I can do that [17:02:00] marcelo: so even without cd bits want DNSSEC info [17:02:43] ndelregno leaves the room: Replaced by new connection [17:02:45] ndelregno joins the room [17:03:20] dave no chair: windows includes non validating security aware stub resolver that wouldn't break, expect to be widely deployed in the future [17:04:14] (I'm leaving out the bit discussions because I don't think I'll get it right) [17:05:53] behcet joins the room [17:05:55] Jabber-Wile leaves the room: Replaced by new connection [17:06:21] Jabber-Wile joins the room [17:06:27] marcelo: wrap up: setting ad bit matter of local policy? [17:06:50] andrew: not happy about that, need to think about this more [17:09:41] lixia joins the room [17:10:21] much discussion about what exactly will be returned under what circumstances [17:10:28] (by the DNS) [17:11:51] eliot.lear leaves the room [17:13:49] wes? [17:13:58] we have an implementation [17:14:08] we'd drop this info because it's not authentic [17:14:33] we need the A record to check [17:14:42] this could allow a denial of service [17:15:35] other person: would need to know that prefix is valid [17:17:42] gurudeep joins the room [17:18:11] gurudeep leaves the room [17:18:37] Wes Hardaker [17:19:08] Hemant Singh joins the room [17:19:29] DDD joins the room [17:20:22] we're back to the issue whether the translated records are tagged, which may be useful for applications but in last meeting dns people feedback was that this wasn't needed [17:21:42] andrew: don't forget this is only for new stuff for people who know what they're doing [17:21:51] this is the least sucky way to do it [17:23:13] suggestion: SHOULD for returning A record in additional section [17:26:20] marcelo: scenario for ipv6 internet to ipv4 stub site [17:26:28] no need for dns64 here, just put in the right AAAA records [17:26:33] but: dynamic DNS [17:26:44] generate AAAA record when updating A record [17:27:11] trouble with DNSSEC but largely the same as for other dyndns/dnssec interoperation [17:27:27] alternative: synthesize AAAA record when you get the query (less preferred) [17:28:04] need to do dnssec on the fly, not so great [17:28:34] include all three approaches in order of preference [17:30:26] mark andrews: don't want to sign on the fly, too painful [17:30:30] stuart: agree [17:31:27] if you use the non-validating stub resolver model then you don't need to sign on the fly was my point [17:31:50] dthaler: are we talking about the same thing? the authoritative servers wouldn't know about this [17:32:04] dave & dan: new behave milestones [17:32:33] satoru.matsushima leaves the room [17:32:39] dave: [17:32:56] http://www.ietf.org/proceedings/09mar/slides/behave-1.pdf [http://www.ietf.org/proceedings/09mar/slides/behave-1.pdf] [17:33:08] see doc organization slide [17:33:58] satoru.matsushima joins the room [17:36:37] Jabber-Wile leaves the room [17:38:23] need to decide on milestones and which documents to adopt [17:38:33] eliot.lear joins the room [17:39:45] fred: withdraw baker-behave-ivi, use framework draft instead [17:39:56] philip: so fframework is not informational? [17:40:13] fred: no [17:42:31] magnus: [17:42:45] don't know if we can publish as informational [17:43:07] dave: is one of my issues, yes [17:43:14] needs to be figured out [17:43:29] philip: like subdivision [17:43:31] dave: nobody against [17:44:25] wmhaddad leaves the room [17:46:00] dave: agree that all 6 scenarios are important? [17:46:16] so push 1,2 and 4 first [17:46:30] ASHIDA joins the room [17:46:39] target for september last call [17:47:59] DDD leaves the room: Replaced by new connection [17:48:00] DDD joins the room [17:48:08] ftp-alg: high priority but decoupled [17:48:15] so in the first batch? [17:48:25] ASHIDA leaves the room [17:49:12] should milestone for ftp-alg be with first batch [17:49:26] slight preference for not in first batch [17:50:25] Andrew Sullivan leaves the room [17:50:39] now document adoption [17:50:46] doesn't mean they're ready for last call [17:51:15] adopt framework? by acclamation [17:51:40] siit update: again, unanymous [17:52:08] nat64: nearly unanymous [17:52:14] dns64: also [17:52:34] so will check for those on the list but assume adopted [17:52:48] next: prefix64 discussion [17:53:19] marcelo talk about wellk known, fred about lir [17:53:30] Andrew Sullivan joins the room [17:53:41] ASHIDA joins the room [17:54:21] dmw leaves the room [17:54:36] marcelo: http://www.ietf.org/proceedings/09mar/slides/behave-10.pdf [http://www.ietf.org/proceedings/09mar/slides/behave-10.pdf] [17:54:37] Andrew Sullivan leaves the room [17:54:52] Andrew Sullivan joins the room [17:56:29] well known prefix: everyone uses the same one [17:56:44] lir prefix: everyone uses their own address space to map v4 addresses into v6 space [17:56:58] normal nat64 scenario [17:57:12] wk doesn't work if ipv4 addresses are private [17:57:36] tsavo_work@jabber.org/Meebo joins the room [17:57:45] hang on: scenario is ipv6 internet to "an" ipv4 network [17:57:55] we don't want to address this because it doesn't work in either case [17:58:02] now an ipv6 network to v4 internet [17:58:10] jpcerezo joins the room [17:58:13] then we don't have ambiguity / route injection issues [17:58:35] advantages aren't so clear [17:58:44] length: wk can be short [17:59:24] useful because reports of router performance issues with routing on longer than /80 prefixes [17:59:37] don't think this is a big problem [17:59:47] dave non-chair: [18:00:11] you route on the portion of v4 space that goes to one translator [18:00:25] marcelo: right [18:00:54] fred: on router performance: we have routers that have 64 bit paths but still fast enough [18:01:05] (some routers) so not an issue [18:01:28] configuration of the prefix64 [18:02:17] with wk can hardcode it where it needs to be configured [18:02:53] for instance in rfc 3484 policy table [18:03:23] what if we have multiple translators? [18:04:17] behcet leaves the room [18:04:25] not so good when you end up with another translator after a routing change [18:04:45] could have more bits to route towards given nat64 box [18:05:26] there are solutions may get a bit messy though, need to be further considered [18:05:36] then context change: two sites have different translators [18:06:08] what if synthetic address from one site ends up in other site, like after referral [18:06:18] with wellknown the referral may work [18:06:38] but it's rather complex: other site may not even have v6! [18:07:13] it's not like SIP is going to work if you do this but at least there are some possibilities [18:07:41] arifumi joins the room [18:10:08] iljitsch: well known has two flavors: strong if you know all the bits and then you never need any config, weak is you can recognize it but still some unknown bits in there [18:10:24] fred: http://www.ietf.org/proceedings/09mar/slides/behave-5.pdf [http://www.ietf.org/proceedings/09mar/slides/behave-5.pdf] [18:11:40] easier to avoid roo much route injection with lir prefix [18:11:45] (me: not sure how, though) [18:12:12] talking about stateless [18:12:17] referral support [18:12:36] the route injection issue is for the IPv6 internet, same as marcelo's first slide (out of scope of scenarios 1 & 4) [18:13:10] @dave: right, fred is now talking about stateless, which is different than what marcelo was talking about [18:13:20] is fred's mic far or is it me? [18:13:37] yes but the scenario and conclusion seem to be the same on that issue [18:15:02] much better thank you [18:15:15] recommendations: lir for stateless [18:15:23] wk may be useful for stateful [18:15:43] Antonio Moreiras leaves the room: Logged out [18:15:47] but conservation of mechanism suggests only using one type [18:15:51] Antonio Moreiras joins the room [18:16:12] fred is done [18:16:17] dave non-chair: [18:16:48] two arguments: lir anyway, so use for all [18:16:55] wk easier for scenarios 1 and 4 [18:19:24] ndelregno leaves the room [18:19:26] someone who wants to implement or deploy just 1/4 and not 2/3 would want WG because it's simplest and easiest to deploy [18:19:26] momose leaves the room [18:19:28] yangqinqin09 leaves the room [18:19:28] Eadson.zhangdong leaves the room [18:19:28] L41587ME0F2AAF7 leaves the room [18:19:39] someone who wants to implement all fo 1-4 would want LIR because it's 1 mechanism [18:19:43] momose joins the room [18:20:29] Robert Raszuk leaves the room [18:21:20] Suzanne leaves the room [18:21:23] momose leaves the room [18:23:35] momose joins the room [18:24:33] My preference as an implementer: default the prefix policy table, DNS64 config etc to the WK prefix but allow configuratoin of LIR for the other cases. [18:24:37] tsavo_work@jabber.org/Meebo leaves the room [18:24:39] well known prefixes have had a number of problems in IPv4, particularly when it comes to wanting to add more for a particular purpose [18:24:59] take for instance various tunneling semantics and public/private addresses [18:26:57] temporary solutions aren't [18:27:08] yangqinqin09 joins the room [18:27:12] donley.chris leaves the room [18:27:23] L41587ME0F2AAF7 joins the room [18:27:38] Ole Troan leaves the room [18:28:25] Atarashi Yoshifumi leaves the room [18:29:29] becarpenter leaves the room [18:30:12] Andrew Sullivan leaves the room [18:30:14] satoru.matsushima leaves the room [18:30:54] csp leaves the room [18:34:26] suz leaves the room [18:34:28] mohsen leaves the room: Computer went to sleep [18:34:28] momose leaves the room [18:34:29] lixia leaves the room [18:34:31] fdupont leaves the room: Computer went to sleep [18:34:46] Magnus Westerlund leaves the room [18:35:10] kanda leaves the room [18:35:21] mikemlb leaves the room [18:35:27] ruriham leaves the room [18:35:43] arifumi leaves the room [18:35:48] jpcerezo leaves the room [18:35:57] Antonio Moreiras leaves the room: Computer went to sleep [18:36:01] iljitsch leaves the room [18:36:12] lliuhto leaves the room [18:36:42] Wes Beebee leaves the room [18:41:42] L41587ME0F2AAF7 leaves the room [18:43:46] yangqinqin09 leaves the room [18:44:00] Lee Howard leaves the room [18:44:45] Mark Baugher leaves the room [18:53:16] Li-Fan WU joins the room [18:53:26] Dave Thaler leaves the room [18:53:52] hirocomb12 leaves the room [18:54:58] Antonio Moreiras joins the room [18:56:34] Antonio Moreiras leaves the room [18:56:37] fujisaki leaves the room [19:23:49] Ralf Weber joins the room [19:27:45] Ralf Weber leaves the room [19:38:00] DDD leaves the room: Computer went to sleep [19:39:58] Hemant Singh leaves the room [19:52:01] Ole Troan joins the room [19:52:11] Ole Troan leaves the room [19:55:28] Mark Baugher joins the room [19:56:08] kanda joins the room [19:57:32] momose joins the room [20:01:09] arifumi joins the room [20:01:22] arifumi leaves the room [20:04:39] mohsen joins the room [20:05:05] Mark Baugher leaves the room: Replaced by new connection [20:05:05] Mark Baugher joins the room [20:11:02] donley.chris joins the room [20:11:37] momose leaves the room: Replaced by new connection [20:14:16] donley.chris leaves the room [20:15:29] donley.chris joins the room [20:17:04] remote leaves the room [20:19:02] remote joins the room [20:20:53] DDD joins the room [20:23:02] kanda leaves the room [20:24:07] remote leaves the room [20:45:13] donley.chris leaves the room [20:56:41] Li-Fan WU leaves the room [21:11:25] Mark Baugher leaves the room [21:16:51] LT-DUFFIELD joins the room [21:18:10] IPR disclosure has already been submitted via IETF web form: pointer in burst loss metric draft [21:19:51] pls ignore last message (wring jabber session) [21:19:56] LT-DUFFIELD leaves the room [21:35:35] lliuhto joins the room [21:36:43] Mark Baugher joins the room [21:44:03] Mark Baugher leaves the room [21:55:49] mohsen leaves the room [22:02:56] DDD leaves the room [22:03:10] lliuhto leaves the room [22:11:32] Mark Baugher joins the room [22:15:24] Mark Baugher leaves the room [22:20:01] ASHIDA leaves the room [22:27:28] ruri joins the room [22:27:37] ruri leaves the room [22:52:24] wmhaddad joins the room [23:56:07] wmhaddad leaves the room