[08:57:30] tony joins the room [08:57:41] tony leaves the room [09:28:14] tony joins the room [09:30:02] tony leaves the room [09:40:40] Panagiotis.Saragiotis joins the room [09:52:52] jweil@jabber.org joins the room [09:59:16] Panagiotis.Saragiotis leaves the room [09:59:33] jweil@jabber.org leaves the room [10:11:56] jason weil joins the room [10:35:11] tony joins the room [10:40:05] Aleksi Suhonen joins the room [10:46:31] aman joins the room [10:47:36] Panagiotis.Saragiotis joins the room [10:53:30] Barbara Stark joins the room [10:55:11] SwedeMike joins the room [10:55:37] Jan Johannesson joins the room [10:57:25] jmohacsi@gmail.com joins the room [10:57:29] Panagiotis.Saragiotis leaves the room [10:58:07] Einar joins the room [10:58:18] shengjiang joins the room [10:59:14] tsavo_work@jabber.org/Meebo joins the room [11:01:05] sean.s.shen joins the room [11:01:37] Jan Boogman joins the room [11:02:52] sean.s.shen leaves the room [11:03:05] Jan Johannesson leaves the room [11:03:52] there is only audio for left channel and at very low volume [11:04:19] tsavo_work@jabber.org/Meebo leaves the room [11:04:26] tsavo_work@jabber.org/Meebo joins the room [11:04:46] Yes. Audio is difficult to hear. [11:04:49] Magnus Bergman joins the room [11:05:07] Jan Johannesson joins the room [11:05:10] jonas joins the room [11:05:59] martin joins the room [11:06:38] yasuo.kashimura joins the room [11:07:14] shamus joins the room [11:07:49] Magnus Westerlund joins the room [11:09:40] Brian Haberman joins the room [11:09:50] Magnus Bergman leaves the room [11:10:16] sean.s.shen joins the room [11:11:22] shinmiyakawa joins the room [11:12:38] Ole Troan joins the room [11:12:49] Eason joins the room [11:12:53] Jean-Francois joins the room [11:12:58] tachibana@jabber.org joins the room [11:13:04] tinnami joins the room [11:13:31] mgysi joins the room [11:13:44] Meeting started, agenda at http://www.ietf.org/proceedings/75/agenda/v6ops.html [11:14:03] kawashimam joins the room [11:14:03] Panagiotis.Saragiotis joins the room [11:14:08] --- Roque Gagliano, IPv6 Deployment in Internet Exchange Points (IXPs) [11:14:08] jhw joins the room [11:14:24] i am the jabber scribe for the v6ops session. [11:14:27] Jan Johannesson leaves the room [11:14:35] we are on slide 3 of... [11:14:35] (ok) [11:14:45] is there an audio stream? [11:15:06] jjmbcom@gmail.com joins the room [11:15:11] yeah, but only left chan and low volume [11:15:13] yep http://feed.verilan.com/ietf/stream07.m3u [11:15:23] arifumi joins the room [11:15:30] Jan Johannesson joins the room [11:15:49] ok. slide 3 of 6 on the ixp preso. [11:15:54] slide 4. [11:16:26] clns joins the room [11:17:07] hello [11:17:26] hello. i am the jabber scribe. [11:17:41] danwing joins the room [11:17:49] mld snooping? [11:17:54] slide 5. [11:18:29] jason weil leaves the room [11:19:20] brzozowski [11:19:35] jhw leaves the room [11:19:58] jhw joins the room [11:20:53] another question: operators want to filter the exchange point fabric addesses by getting rid of a single or a few /32s [11:21:04] slide 3. [11:21:11] so the globally routable /48 should be from a different /32 [11:21:20] hence it can't be a /47 really [11:21:20] zhangjie joins the room [11:21:46] is there a question there i should take to the mic? [11:21:57] zhangjie has set the subject to: v6ops -- IETF75 [11:22:08] take it as a comment, not a question [11:22:42] hama-the-sailor joins the room [11:23:04] ams... you are who? [11:23:22] Aleksi Suhonen [11:23:57] ok? [11:24:14] martin leaves the room [11:24:18] perhaps we should ask for global IXP space out of a /32 that everybody can filter? [11:24:25] stefan.a joins the room [11:24:36] your name? [11:24:39] SwedeMike: we already have one in ripe, and another in arin [11:24:44] martin joins the room [11:24:49] jhw_: just discussing, I'm in the audience. [11:24:49] and maybe a few others too? [11:24:54] ok [11:25:09] yes, wording it. important. [11:25:22] kurtis joins the room [11:25:32] fujisaki joins the room [11:25:32] Kurt clarified that what the ID meant is 2 /48s and Roque agreed [11:25:50] yao joins the room [11:25:57] rhe joins the room [11:26:01] kurtis leaves the room: Replaced by new connection [11:26:02] mm joins the room [11:26:04] kurtis joins the room [11:26:08] dougm.home joins the room [11:26:33] next up: "Hybrid ISP Framework for IPv6 Services and IPv6/IPv4 Intercomunication" [11:26:44] slide 2,. [11:27:29] Greetings to all at the IETF meeting :) [11:29:34] slide 4 [11:29:46] (sorry, i missed that we were on 3 just now) [11:30:04] Desire joins the room [11:30:30] welln joins the room [11:31:50] slide 5 [11:32:34] kawashimam leaves the room: Replaced by new connection [11:33:22] slide 6 [11:33:34] kawashimam joins the room [11:33:41] fujisaki leaves the room: Replaced by new connection [11:33:41] fujisaki joins the room [11:34:10] martin leaves the room [11:35:05] slide 7 of 8 [11:35:05] slide 7 [11:37:30] slide 5 [11:37:58] Fred: in the top red block, you have identified 1/2 of the transition mechanism. Do you mean it in that sense, only scalable NAT64 or do you mean the entire BEHAVE framework? [11:38:16] kurtis leaves the room [11:38:20] speaker: yes, meant _a_ translation technology [11:38:41] Fred said 'unscalable NAT64', by which he means 'stateful NAT64'. [11:39:04] martin joins the room [11:39:23] (thx for correcting the typo Dan) [11:40:57] a quick scan through the i-d didn't reveal option82 mentioned in the draft [11:41:14] do i need to take that to the mic? [11:41:34] Now Up: Incremental CGN for IPv6 Transition (Update) [11:41:38] some operators have used the lack of option82 as a reason to not even begin trying to deploy it [11:41:42] slide 2 of 8 [11:41:46] and i guess no need to take it to mic anymore [11:42:29] (but maybe someone else might want to give their opinions offline? :-) [11:42:32] slide 3 [11:43:06] fdupont joins the room [11:43:18] kurtis joins the room [11:44:13] slide 6 (i think we skipped 4-5) [11:44:28] martin leaves the room: IETF meeting.. [11:44:35] (no, we just went through them quickly) [11:44:39] fujisaki leaves the room: Replaced by new connection [11:44:40] fujisaki joins the room [11:44:47] jhw: slides 4-5 looked very similar to 3, but had different colours and titles [11:44:54] yes. [11:45:03] ja joins the room [11:45:13] martin joins the room [11:45:28] mm leaves the room [11:45:51] slide 7 [11:47:17] slide 8 [11:48:04] jhw leaves the room [11:48:13] jhw joins the room [11:48:28] Fred recommends that things related to translation go to BEHAVE, things related to tunnels go to SOFTWIRE, asked for opinions [11:49:16] Fred Templin: preference for the doc to stay in v6ops since it talks about operational stuff [11:49:31] support for stay in operational area [11:49:48] Mark Townsley: would like the behave + softwire specs to be tight and operational considerations to stay here [11:49:53] i'll take that comment to the mic. [11:50:11] anyone else want to +1 that comment? [11:50:52] marc.blanchet.qc joins the room [11:51:00] roque joins the room [11:51:18] Tony Hain at the mic now. [11:51:21] Geoff Huston joins the room [11:51:25] I feel this document is too abstract, it needs more specifics [11:51:35] Andy Malis joins the room [11:51:40] go to the microphone [11:51:43] you are in the room :) [11:51:48] yeah, I know. [11:51:52] Tony at mike: documenting guidances is what people need [11:51:54] the devils advocate in me says: "people are looking for guidance and they are going to ITU-T to look for it" [11:52:07] another vote in favor of keeping this in ops [11:52:11] alex joins the room [11:52:16] so having good drafts here would be a good thing [tm] [11:53:42] next up: ... [11:53:53] ICMPv6 Echo Replies for Teredo Clients [11:54:07] martin leaves the room [11:54:10] marc.blanchet.qc leaves the room [11:54:14] slide 1 [11:54:20] slide 2 [11:54:33] martin joins the room [11:54:58] Einar leaves the room [11:55:04] Einar joins the room [11:55:10] slide 3 [11:56:24] welln leaves the room [11:56:39] slide 4 [11:56:56] Mark Townsley joins the room [11:57:13] sean.s.shen leaves the room [11:57:27] juampe.cerezo@gmail.com joins the room [11:58:42] CNNIC-Xiaodong joins the room [11:59:33] the synthesized AAAA should not be recognizable by the end-client [11:59:43] slide 6 [11:59:45] comment: the address selection people would want to have native address pairs be more preferable than any tunnelling method anyway [12:00:24] so according to that, any teredo host should prefer ipv4 when it encounters a destination with both A and AAAA [12:00:32] i am at the mic now. [12:00:37] martin leaves the room: IETF meeting.. [12:00:44] well, after eric klein is done speaking. [12:01:22] The teredo based addresses are less preferred if A and AAAA both exist. [12:01:49] martin joins the room [12:02:13] when i say "more preferable", it means it should be tried first [12:02:17] naturally [12:02:21] jason weil joins the room [12:02:36] not necessarily, i would say. [12:02:49] another common strategy is to try them all in parallel. [12:03:00] oh, i'm all for that [12:03:11] 6to4 (another tunnel protocol) is preferred rather than ipv4 usually, though. [12:03:14] like the windows resolver ;) [12:03:28] but there's a downside to that: it can create a lot of excess traffic when both peers have a dozen addresses [12:03:34] Barbara Stark leaves the room: Replaced by new connection [12:03:35] Barbara Stark joins the room [12:03:43] I'd prefer v4 first and v6 if that fails [12:03:48] aleksi: yeah [12:04:05] kawamucho joins the room [12:04:08] Eason leaves the room [12:04:26] according to RFC4890 Recommendations for Filtering ICMPv6 Messages in Firewalls second assumption should not happen [12:04:45] arifumi: i'm running a teredo server in finland and 95% of my traffic is between teredo and 6to4 --> there are a lot of implementations out there that prefer ipv6 transition methods over native ipv4 [12:05:20] even tho it's considered harmful [12:05:20] to arifumi: 6to4 should be less preferred according to rfc 3484 [12:05:47] these sound like issues for the address selection people to drive, yes? [12:05:51] yes [12:06:02] Andy Malis leaves the room [12:06:14] I think windows prefers v6 when running 6to4 whilst v4 when running teredo, not sure if they changed that yet [12:06:17] Prefix Precedence Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0:0/96 10 4 [12:06:30] my original point was sort of that: the addr sel people are already working on the first bullet on the slide on the screen right now [12:06:39] 6to4 has higher prec than ipv4, this is what i mean. [12:07:13] ok. i'll try to fwd that comment. [12:07:52] ok? [12:07:52] satoru.matsushima joins the room [12:08:28] martin leaves the room: IETF meeting.. [12:08:45] Now: Non-deterministic IPv6 Tunnels Considered Harmful. [12:08:55] jhw leaves the room [12:09:02] martin joins the room [12:09:06] jhw joins the room [12:09:12] slide 2 [12:10:42] slide 3 [12:11:14] Jan Johannesson leaves the room [12:11:37] slide 4 [12:12:14] Einar leaves the room [12:12:20] Einar joins the room [12:13:05] roque leaves the room [12:14:35] johl joins the room [12:15:09] Jan Johannesson joins the room [12:15:12] jhw leaves the room [12:15:14] jhw joins the room [12:15:29] (i had a network fade... sorry.) [12:15:32] slide 6 [12:15:59] slide 7 [12:16:15] Magnus Westerlund leaves the room [12:16:24] would it make sense to start "policing" automatic tunneling method server runners? [12:16:35] policeing [12:17:04] i.e. monitor them more actively and report deviations [12:17:41] belorn joins the room [12:17:57] personal comment: "Asymmetric 'Non-deterministic' Tunnels Considered Transitional." [12:18:16] concur [12:18:25] the sixxs model for deterministic tunneling is that the tunnel end point is preferably very close by network topologically [12:18:43] martin leaves the room [12:19:33] jhw and tony: the initial premise of this presentation was that these transitional methods are giving native ipv6 a bad name in the eyes of people evaluating it for the first time [12:19:41] especially at the content provider end [12:19:58] which is, sort of, the only piece of the puzzle we are missing now from global adoption [12:20:12] i'll take that comment to the mic then. [12:22:02] now enqueued. [12:22:03] johl leaves the room [12:22:34] johl joins the room [12:22:37] your name? [12:22:40] jhw: which bit exactly did you queue? [12:22:42] ams? [12:22:46] Aleksi Suhonen [12:22:54] zhangjie leaves the room: Replaced by new connection [12:22:55] zhangjie joins the room [12:23:23] comment about initial premise. [12:24:00] that bit maybe a bit out of the blue without mentioning your personal comment first [12:24:12] i intend to do that. [12:24:14] k [12:24:15] I agree with Gunter Vandevelde: look what Google is doing with IPv6 deployment [12:24:32] Einar leaves the room [12:24:36] aalain joins the room [12:24:37] Einar joins the room [12:25:20] martin joins the room [12:25:44] rhe leaves the room [12:26:28] rhe joins the room [12:27:07] What should we do: educate IPv6 users - describe trade-offs using "non-deterministic" tunnels [12:28:31] fujisaki leaves the room [12:28:38] johl leaves the room [12:28:41] maybe you should add: "the finnish ipv6 task force finds that a clear majority of the network devices, server software and client software already supports ipv6, with or without tunneling, so all that is needed is to add AAAA records to turn it on. they've taken ipv6 adoption at content providers as this years theme." [12:28:53] fujisaki joins the room [12:29:09] johl joins the room [12:29:45] Mark Thompson joins the room [12:30:41] Einar leaves the room [12:30:47] Einar joins the room [12:32:08] who was this speaker btw? [12:32:21] Jan Johannesson leaves the room [12:32:22] Current speaker is Tim Chown [12:32:26] yes. [12:32:28] Gunter Vandevelde presented [12:32:35] Jan Johannesson joins the room [12:32:37] tim chwon, thanks [12:33:33] *chown [12:34:32] mark townsley "IPv6 via IPv4 SP Networks -- 6RD" [12:34:37] slide 1 of 18 [12:35:14] johl leaves the room [12:35:43] slide 2 [12:35:53] yao leaves the room [12:36:15] johl joins the room [12:36:18] slide 3 [12:36:43] johl leaves the room [12:36:48] slide 4 [12:36:54] martin leaves the room [12:38:02] wej joins the room [12:38:31] aalain leaves the room [12:38:35] slide 5 [12:39:44] slide 6 [12:39:52] Warren Harrop joins the room [12:40:19] yao joins the room [12:40:25] martin joins the room [12:40:25] CHENGANG joins the room [12:40:58] slide 7 [12:41:09] shengjiang leaves the room [12:41:15] yao leaves the room [12:42:33] shengjiang joins the room [12:42:45] slide 8 [12:42:49] slide 9 [12:43:23] slide 10 [12:43:44] slide 11 [12:44:05] Einar leaves the room [12:44:11] Einar joins the room [12:44:20] slide 12 [12:45:54] slide 13 [12:46:36] lstewart joins the room [12:47:26] Which standard is coping 6rd options for IPCP? [12:47:54] kurtis: could you ask him if he knows the amount of traffic they're able to do on linux box, if it's several gigabits/s [12:48:07] I can't remember if that's a separate draft or not. I'll ask. [12:48:13] slide 14 [12:48:21] yanick.pouffary joins the room [12:50:14] Einar leaves the room [12:50:16] sm joins the room [12:50:20] Einar joins the room [12:50:35] slide 15 [12:53:51] slide 16 [12:53:54] bnsmith joins the room [12:54:12] martin leaves the room [12:54:48] slide 17 [12:54:52] slide 18 [12:54:54] jhw: ask if there's been any thought put into reverse DNS? (this caused heated debate yesterday elsewhere) [12:55:49] ok [12:56:01] that was in dnsop [12:56:33] i'm missing the context. it's hard for me to see what extra consideration 6rd requires for reverse dns. [12:56:42] yanick.pouffary leaves the room: Replaced by new connection [12:57:25] fred templin at the mic. [12:57:28] the 6rd address space is fully controlled by the SP and from reverse perspective shouldn't be any different from native IPV6 [12:58:29] ok, scratch the question [12:58:32] ok [12:58:48] lstewart leaves the room [12:59:05] martin joins the room [12:59:38] Wes Beebee joins the room [13:01:36] danwing leaves the room [13:01:38] jonas leaves the room: I'm happy Miranda IM user. Get it at http://miranda-im.org/. [13:01:45] arifumi leaves the room [13:02:44] kawashimam leaves the room [13:02:52] shamus leaves the room [13:03:56] Brian Haberman leaves the room [13:04:02] the home net may have jumbo capable internal network and network-attached-storage [13:04:06] satoru.matsushima leaves the room [13:04:28] so dictating small MTU on the home subnet because the tunnel is that way is silly [13:06:04] discussion at the mic seems already to be covering this point. [13:06:10] (Fred just conveyed that point about not clamping the MTU on the home side) I think [13:06:15] yeah [13:06:15] (fred templin speaking now) [13:06:42] Jan Johannesson leaves the room [13:06:55] hama-the-sailor leaves the room [13:08:23] Any lowering on the MTU below the normal Ethernet maximum will most likely break 20% of the public websites/services. [13:08:26] tinnami leaves the room: Computer went to sleep [13:08:27] Panagiotis.Saragiotis leaves the room [13:08:34] yasuo.kashimura leaves the room [13:08:36] Jean-Francois leaves the room: Computer went to sleep [13:08:40] taking break. [13:08:46] jhw leaves the room [13:08:50] fdupont leaves the room: Computer went to sleep [13:08:57] alex leaves the room [13:08:58] Ole Troan leaves the room [13:09:06] Einar leaves the room [13:09:25] Geoff Huston leaves the room [13:09:27] Jan Boogman leaves the room [13:09:34] tony leaves the room [13:09:38] kawamucho leaves the room [13:09:40] Mark Townsley leaves the room [13:09:53] Mark Thompson leaves the room [13:10:08] dougm.home leaves the room [13:10:10] tsavo_work@jabber.org/Meebo leaves the room [13:10:11] tachibana@jabber.org leaves the room [13:13:49] jjmbcom@gmail.com leaves the room [13:14:10] belorn leaves the room [13:14:21] shamus joins the room [13:14:32] martin leaves the room [13:15:32] Mark Thompson joins the room [13:16:21] are the presentations available online? [13:16:29] Doug_Otis joins the room [13:16:40] Mark Thompson leaves the room: Replaced by new connection [13:16:40] Mark Thompson joins the room [13:19:15] bnsmith: http://tools.ietf.org/wg/v6ops/agenda?item=agenda75.html [13:19:34] CNNIC-Xiaodong leaves the room [13:20:13] zhangjie leaves the room: Computer went to sleep [13:21:37] CHENGANG leaves the room [13:23:40] Magnus Bergman joins the room [13:23:43] arifumi joins the room [13:25:04] thanks! interesting I don't see them on http://tools.ietf.org/agenda/75/#2009-07-28_1300 [13:26:50] shinmiyakawa leaves the room: Replaced by new connection [13:27:48] tinnami joins the room [13:27:51] Jean-Francois joins the room [13:28:39] tony joins the room [13:29:30] Jan Boogman joins the room [13:29:37] dragan joins the room [13:30:04] Jan Johannesson joins the room [13:32:08] tony leaves the room [13:32:13] yanick.pouffary joins the room [13:32:14] martin joins the room [13:32:31] hama-the-sailor joins the room [13:32:49] kawashimam joins the room [13:33:44] Eason joins the room [13:33:46] anyrhine joins the room [13:33:48] clatze joins the room [13:34:09] Ole Troan joins the room [13:34:15] sm leaves the room [13:34:48] yasuo.kashimura joins the room [13:35:00] (taking relay from James until he finishes his presentation [13:35:03] YGHONG-X300 joins the room [13:35:21] Ole Troan leaves the room [13:35:32] --- next up, Use Cases and Requirements for an IPv6 CPE Router [13:35:38] slide 2 [13:36:04] Mark Thompson leaves the room [13:36:12] Mark Townsley joins the room [13:36:21] slide 3 [13:36:38] sm joins the room [13:37:18] Ole Troan joins the room [13:37:21] satoru.matsushima joins the room [13:37:47] slide 4 [13:38:39] zhangjie joins the room [13:38:59] jhw joins the room [13:39:00] slide 5 [13:40:17] slide 6 [13:40:58] slide 7 [13:41:21] slide 8 [13:41:35] lstewart joins the room [13:42:06] CHENGANG joins the room [13:42:23] jhw leaves the room [13:42:26] jhw joins the room [13:42:28] Magnus Bergman leaves the room [13:42:34] aalain joins the room [13:42:39] slide 9 [13:42:58] jinmei joins the room [13:43:11] slide 10 [13:43:13] Mark Townsley leaves the room [13:43:56] martin leaves the room [13:43:59] Dave Thaler - slide8 [13:44:20] What future consideration are you looking for DNS? [13:44:21] iljitsch joins the room [13:44:45] my problem with this draft is that it doesn't require cascading CPEs. [13:44:48] Mark Townsley joins the room [13:44:58] martin joins the room [13:45:03] Dave Thaler: comment on 3rd bullet about "stateful DHCP may be required" - what is the requirements here? stateful DHCP is one way to maintain some correlation but there are other possible solutions [13:45:22] iljitsch - you are in the room right? [13:45:26] why wouldn't dhcp relaying convey the same information to a database as a local dhcp service at the router? [13:45:46] Fred: the 'legal' requirement relates to legal intercept sometimes [13:45:55] yes [13:46:04] but it's too inconvenient to go to the mic [13:46:13] If this is for consumer CPE Router, then it's not for public hotspot Router. Public hotspot router <> consumer CPE router. [13:46:14] I'll get another chance to speak up at some point [13:47:01] (speaker); does this CPE IPv6 requirement can say anything about IPv4? [13:47:17] response: left out of scope [13:47:34] (Aleksi - want us to make that comment at the mike?) [13:47:54] bhoeneis joins the room [13:47:56] (Barbara - you're in the room too right?) [13:48:07] if you please [13:48:21] No, I'm on Webex, though. I think my comment is something I'd rather discuss on thet list. [13:48:31] florin coras joins the room [13:48:34] (queued) [13:48:40] stefan.a leaves the room: Replaced by new connection [13:48:43] stefan.a joins the room [13:48:46] Jan Boogman leaves the room [13:50:06] more Q&A at the mike about including IPv4 in scope of this document [13:51:25] CNNIC-Wang Wei joins the room [13:51:29] Tony: transition pieces need to be discussed in those documents (could not get the question well) [13:51:31] i suspect i'm just mixing up the bullets or something? [13:51:49] Jan Boogman joins the room [13:52:04] Michael A: don't understand how you deliver the service without having PD? [13:52:44] Jean-Francois: i withdraw my question [13:54:16] (ok , was just behind Michael) [13:54:35] long queues gave me time to think O:-) [13:55:18] Fred has posted an ID and a request to 6man list to have some protocol work done on v6 PD sub-deleguation [13:55:59] Ted Lemon @ mike: w.r.t. PD, there are 2 issues: sub-deleguation and how to set up a route. On the latter, there is a document in DHC wg that is on the agenda on Friday [13:56:43] florin coras leaves the room [13:56:56] John B: should enumerate the possibilities: one is sub-delegation, ... [13:57:21] Kurt: waiting for DHC wg feedback [13:57:35] jhw leaves the room [13:57:56] Tony: trying to make this too hard, cascading CPE routers is similar to PD, it is not that hard [13:58:31] belorn joins the room [13:58:42] Chris: how does a CPE router know the length of the prefix to sub-delegate [13:58:49] [13:59:08] --- next: James Woodyatt, draft-ietf-v6ops-cpe-simple-security-06.txt [13:59:38] martin leaves the room: IETF meeting.. [14:00:09] slide 2 [14:00:14] martin joins the room [14:00:49] stefan.a leaves the room: offline [14:01:04] slide 3 [14:01:15] slide 4 [14:01:55] martin leaves the room: IETF meeting.. [14:02:33] danwing joins the room [14:02:47] slide 5 [14:03:22] Small question: Why introduce NAT behavior into v6? [14:03:57] eh? James isn't introducing NAT behavior into v6. Could you be specific on what you're referring to? [14:05:01] slide 6 [14:05:57] slide 7 [14:05:58] donley.chris joins the room [14:07:22] open mike [14:07:29] Atarashi Yoshifumi joins the room [14:07:41] As I understand it, NAT security effects on a network was a "bad" by-product by NAT on ipv4. What I'm wondering is why reintroducing this effect into ipv6? (If I have understood this introduction correctly) [14:08:45] Exodus joins the room [14:09:07] Dave Thaler, slide 5: an effect of Teredo blocked if native is supported: the way Teredo is used when you have native, you act as a teredo relay for yourself => the deterministic way of doing Teredo is blocked and you are forced to use a relay. Dave thinks it is harmful as a result [14:10:27] this is off topic to this presentation, but on topic for v6ops, and i only want to ask people on jabber: has anyone else had problems reaching www.kame.net from teredo? [14:10:27] CNNIC-Xiaodong joins the room [14:10:37] James: recommendation is to block the Teredo port used to talk to the relay, so it may be the case that it may work. [14:11:11] Dave Thaler: we agree on the goal, just need to make sure the language in the ID is clear that you block a particular mode of Teredo [14:11:11] (background: i've always used kame as a test of whether my ipv6 works, but when i started testing teredo, i haven't found any place where that combo would work) [14:12:08] regarding DHCPv6-PD, why do we NEED subdelegation? you hand the CPE a /56 and then the ISP should care no more? then it's up to CPE policy to decide what to do with further PD requests on its LAN. I don't understand why that fact should stop anything? [14:12:14] ams: ipv6.google.com [http://ipv6.google.com] [14:12:30] iljitsch: yes i've started using that instead :) [14:12:36] Ron Bonica at the mike responding to Fred re: requirement 41 [14:13:03] suz joins the room [14:13:06] swmike: yes we need it [14:13:10] iljitsch_: why? [14:13:13] swm: 1) Not all usecases for PD are CPE delegation for ISPs [14:13:17] we don't need to specify complex algorithms, though [14:13:28] kurtis: but in this specific case it is. [14:13:32] SwedeMike: we need to define a BCP of how to code a CPE? [14:13:52] 2) in "fully managed" networks you want the same behaviour for all CPEs the customer connect [14:13:59] because if my isp gives me a $10 cpe that is crap and I want to use my own I can't if there's no subdelegation assuming that my good CPE doesn't have a cable/dsl model while the crappy one does [14:14:21] Panagiotis.Saragiotis joins the room [14:14:38] Fred: it seems a pointless recommendation (re: REQ#41) [14:14:42] iljitsch_: in my market you buy your own CPE. why should the v6ops WG hinder this deployment scenario? [14:14:54] Magnus Bergman joins the room [14:15:08] swmike: subdelagation _helps_ buying your own cpe [14:15:15] you may also want to have more than one [14:15:36] more than one cpe? [14:15:38] yes, I have no problem with that, so require that it does work with subdelgation and can hand out a /64 via PD then [14:15:39] or prefix [14:15:45] I dont understand the big controversy [14:15:51] Stuart C @mike: Stuart's concern is when we make IPv6 emulate NAT [14:17:16] portscans in v6? [14:17:39] has the chair calculated the time required to scan a /64 at 10gbps? [14:17:46] I dont agree to that argument. Assuming the threat level for IPv6 to be the same for IPv4 is incorrect assumption. [14:17:59] fred: the bandwidth is already used, whether the cpe filters it after it passes through the pipe or not [14:18:07] "Received:" headers in email, which are often visible in IETF archives, would show Fred's IPv6 address. [14:18:32] to Aleksi: portscan is possible - malicious website after visiting can start scanning back to you [14:18:37] privacy extensions [14:18:38] danwing: reverse mapping (if zone transferable) will of course betray it too [14:18:42] The number of traffic/machines needed to scan every IPv6 address is a question of scale that effects threat level. [14:19:17] hm... Received: from dhcp-56c8.meeting.ietf.org [http://dhcp-56c8.meeting.ietf.org] (dhcp-10-61-101-21.cisco.com [http://dhcp-10-61-101-21.cisco.com] [10.61.101.21]) [14:19:56] Ted Lemon: concerns that we break e2e with filters [14:20:05] lebobits joins the room [14:20:07] SwedeMike: privacy extensions is recommended to switched off by default [14:20:09] (stopping the jabber for a few mn) [14:20:15] if you can't get out, contact the administrator [14:20:22] anyrhine leaves the room [14:20:29] hkirksey joins the room [14:21:09] thomson joins the room [14:22:38] zhangjie leaves the room: Replaced by new connection [14:22:39] zhangjie joins the room [14:22:50] rhe leaves the room [14:23:14] bnsmith leaves the room [14:23:34] Exodus leaves the room [14:23:41] rhe joins the room [14:23:43] Exodus joins the room [14:24:04] bnsmith joins the room [14:24:20] satoru.matsushima leaves the room [14:24:31] hkirksey leaves the room [14:25:35] does "i don't want to write this bit of code because it's tricky" improve security on the internet? [14:26:13] gigix73 joins the room [14:26:22] tachibana@jabber.org joins the room [14:26:42] Barbara Stark leaves the room: Replaced by new connection [14:26:42] Barbara Stark joins the room [14:26:56] also, why ip-in-ip, but not ipv6-in-ip or ipv-in-ipv6? [14:27:21] and stateful doesn't work (not simple enough) ? [14:27:43] if we allowed inside initiated connections, it would emulate the security "promise" of NAT in v6 [14:27:46] v4 [14:28:00] the last one was supposed to be "ipv4-in-ipv6" [14:28:05] people would basically get the same as them being behind a NAT device for v4 [14:28:43] anyrhine joins the room [14:29:40] Staffan Kerker joins the room [14:30:14] clatze leaves the room: Replaced by new connection [14:30:23] If it turns out this thing is bad then it won't be implemented. If it needs to be tweaked, the CPE Router community will tweak it. I think defining it is useful and good. [14:31:04] Barbara Stark: are you refering to the whole draft or the tunneling issue? [14:31:48] CNNIC-Xiaodong leaves the room: Replaced by new connection [14:31:49] CNNIC-Xiaodong joins the room [14:32:15] The whole draft. The tunneling aspect is something that might be tweaked if we find that something is commonly used and needs to be allowed. Right now, the most common "tunnel" is IPsec, which the draft considers. [14:32:36] belorn leaves the room [14:33:32] belorn joins the room [14:37:25] CNNIC-Wang Wei leaves the room [14:39:13] these firewall people REALLY DON'T KNOW WHERE TO STOP [14:39:33] sure they do: at the firewall [14:39:52] :-) [14:40:00] clns leaves the room: offline [14:40:01] Staffan Kerker leaves the room [14:40:07] Staffan Kerker joins the room [14:40:27] Exodus leaves the room [14:40:30] Staffan Kerker leaves the room [14:40:33] Exodus joins the room [14:40:38] Chris Griffiths joins the room [14:40:50] Panagiotis.Saragiotis leaves the room [14:41:34] Firewall people are full of beliefs and hopeful thinking on what firewalls do, what they protect against, and how the world would fall down if they aren't used. [14:42:01] still I don't see any firewalls here at the IETF network [14:42:28] someone go to the queue and suggest that the firewall/tunnelling issues could be continued on the mailing list? :-) [14:42:41] While it is true UPnP IGD does not support IPv6, UPnP IGD version 2.0 will have IPv6 support, according to the UPnP Forum, http://www.upnp.org/resources/documents/UPnPIGD2vsIGD1d10032009.pdf [14:42:45] on /dev/null maybe? [14:43:19] upnp is an abomination that wouldn't even be allowed to be posted as a draft at the ietf [14:43:36] this is our turf, we need to build this stuff ourselves [14:43:59] note to the current speaker at the mike: there have been multigigabit DDoS attacks already in 1999 [14:44:10] on ipv6 [14:44:11] as long as we realise that users are used to NAT+uPnP signalling of opening ports in their NAT, the ipv6 equivalent we come up with, should have similar functionality. [14:44:17] and how do firewalls help against those...? [14:44:27] iljitsch: sure, they are useful fuses [14:44:49] donley.chris leaves the room [14:45:08] iljitsch: i was just pointing out the flaw in his comment "nobody wants to ddos ipv6" [14:45:23] donley.chris joins the room [14:48:05] per what I said away from the mic: [14:48:12] I'm going to send my preference to the list [14:48:24] I've asked for others who believe the same to ack [14:48:27] AND [14:48:42] I'm not going to defend UPnP IGD; I agree it's horrid. Nevertheless, they are adding IPv6. [14:48:44] what is it tht you believe? [14:48:49] I am willing to write the text that needs to be written. (my guess it's not more than a paragraph or two) [14:49:05] sorry, [14:49:07] Strong security is needed against targets that are public. Against private targets (home users), it's all a question if automatic tools can be used effectively (gain > cost). For example, people who runs public FTP servers today aren't targeted anymore (several research results proves this). In the past people blocked public use because there was a threat (CP and other crime circles used them as dumb sites), but threat levels change with time! [14:49:49] the need for layered filtering, i.e. if something is sent in a tunnel, like IP-n-IP or GRE, then the filter ought to be able to look into the next header and 5 tuple to enforce a policy on that [14:49:53] to current speaker: for ipv4 threat model - prevent downloading malicious codes - therefore it would require content filtering engine by default.... [14:50:05] david.kessens@jabber.org joins the room [14:52:08] gigix73 leaves the room [14:52:31] Exodus leaves the room: Replaced by new connection [14:52:38] Exodus joins the room [14:52:41] good [14:53:08] remove ip-in-ip and gre inbound [14:53:18] takasima joins the room [14:53:25] leobits: are there any ipv4 cpes that do this? [14:53:59] --- next up: IPv6 CPE Router, Wes Beebee [14:54:30] Exodus leaves the room [14:54:32] slide 2 [14:54:39] slide 3 [14:55:26] anyrhine leaves the room [14:55:29] slide 4 [14:56:21] slide 5 [14:56:45] shinmiyakawa joins the room [14:57:05] slide 6 [14:57:33] CHENGANG leaves the room [14:57:39] slide 7 [14:58:28] Magnus Bergman leaves the room [14:58:52] slide 8 [14:59:43] lstewart leaves the room [14:59:58] tachibana@jabber.org leaves the room [15:00:00] slide 9 [15:00:21] belorn leaves the room [15:00:26] open mike [15:00:33] sm leaves the room [15:00:54] sm joins the room [15:01:38] speaker@mike: no sure if we have considered how much of a moving target do we want these documents to be? [15:01:55] (Pekka Savola) [15:02:02] sm leaves the room [15:02:26] (thx rhe) [15:02:43] jhw joins the room [15:03:04] wb James, ready to take over? [15:03:19] Chris Griffiths leaves the room: Replaced by new connection [15:03:19] Chris Griffiths joins the room [15:04:22] YGHONG-X300 leaves the room [15:04:37] david.kessens@jabber.org leaves the room [15:05:09] Atarashi Yoshifumi leaves the room [15:05:36] ja leaves the room [15:06:38] Eason leaves the room [15:07:17] Chris Griffiths leaves the room [15:07:37] Chris Griffiths joins the room [15:08:09] ok... i guess i can take over jabbering. [15:08:25] i may need to bail out early to conference with my family in california before the social event. [15:09:29] MING joins the room [15:09:34] juampe.cerezo@gmail.com leaves the room [15:09:53] Kris Bransom joins the room [15:13:09] mgysi leaves the room [15:13:34] mgysi joins the room [15:15:20] iljitsch leaves the room [15:16:26] sm5 joins the room [15:16:41] sm5 is now known as sm [15:16:48] aalain leaves the room [15:17:00] Doug_Otis leaves the room [15:17:18] MING leaves the room [15:18:25] jlcjohn joins the room [15:21:19] Chris Griffiths leaves the room [15:21:26] Jean-Francois leaves the room [15:21:35] satoru.matsushima joins the room [15:26:45] yao joins the room [15:27:20] belorn joins the room [15:27:35] i gotta run. [15:27:37] jhw leaves the room [15:28:56] tinnami leaves the room [15:30:12] thomson leaves the room [15:30:14] suz leaves the room [15:30:31] jason weil leaves the room [15:30:44] aman leaves the room [15:30:57] shamus leaves the room [15:31:34] hkirksey joins the room [15:31:35] mgysi leaves the room: offline [15:34:33] rhe leaves the room [15:34:48] Jan Boogman leaves the room [15:36:46] dragan leaves the room [15:37:30] jason weil joins the room [15:39:35] hama-the-sailor leaves the room [15:41:16] tinnami joins the room [15:42:33] jason weil leaves the room [15:43:10] satoru.matsushima leaves the room [15:44:08] kurtis leaves the room [15:44:11] shinmiyakawa leaves the room [15:44:27] kawashimam leaves the room [15:44:33] tinnami leaves the room: Computer went to sleep [15:44:36] yasuo.kashimura leaves the room [15:44:47] yao leaves the room [15:45:08] shengjiang leaves the room [15:46:00] Jan Johannesson leaves the room [15:46:13] Warren Harrop leaves the room [15:46:18] arifumi leaves the room [15:46:22] Wes Beebee leaves the room [15:46:30] sm leaves the room [15:49:04] belorn leaves the room [15:49:36] jinmei leaves the room [15:49:58] CNNIC-Xiaodong leaves the room [15:50:02] hkirksey leaves the room [15:50:06] Jan Boogman joins the room [15:50:23] Barbara Stark leaves the room: Replaced by new connection [15:50:23] Barbara Stark joins the room [15:50:54] Barbara Stark leaves the room [15:51:24] yanick.pouffary leaves the room [15:51:35] shengjiang joins the room [15:54:07] jlcjohn leaves the room [15:54:43] donley.chris leaves the room [15:55:40] bhoeneis leaves the room [15:58:42] lebobits leaves the room [15:59:19] Ole Troan leaves the room [15:59:48] Magnus Bergman joins the room [16:01:34] Jan Boogman leaves the room [16:03:53] donley.chris joins the room [16:04:04] Desire leaves the room [16:04:22] danwing leaves the room [16:05:04] fujisaki leaves the room [16:05:54] Magnus Bergman leaves the room [16:08:12] zhangjie leaves the room [16:09:14] Mark Townsley leaves the room [16:09:35] takasima leaves the room [16:11:06] jmohacsi@gmail.com leaves the room [16:11:44] donley.chris leaves the room [16:32:52] shengjiang leaves the room [16:50:31] wej leaves the room [16:56:11] shengjiang joins the room [17:18:18] Mark Townsley joins the room [17:18:48] shengjiang leaves the room [17:28:41] Mark Townsley leaves the room [17:29:55] Mark Townsley joins the room [19:39:35] arifumi joins the room [19:39:45] arifumi leaves the room [19:58:06] Mark Townsley leaves the room [20:01:51] Mark Townsley joins the room [20:07:16] Atarashi Yoshifumi joins the room [20:07:18] Atarashi Yoshifumi leaves the room [20:59:49] kurtis joins the room [21:31:10] Magnus Bergman joins the room [21:31:17] kurtis leaves the room [21:31:27] kurtis joins the room [21:50:58] kurtis leaves the room [21:59:07] kurtis joins the room [22:04:07] kurtis leaves the room [22:06:51] Magnus Bergman leaves the room [22:06:51] Magnus Bergman joins the room [22:08:36] Magnus Bergman leaves the room [22:10:30] kurtis joins the room [22:16:01] kurtis leaves the room [22:17:07] kurtis joins the room [22:31:38] kurtis leaves the room [22:37:18] kurtis joins the room [22:55:46] Kris Bransom leaves the room [23:23:31] kurtis leaves the room