[04:50:16] SwedeMike joins the room [06:17:44] Shwetha joins the room [06:17:52] Shwetha leaves the room [06:53:53] jani_h joins the room [06:54:07] yasuo.kashimura joins the room [06:54:13] jani_h leaves the room: offline [06:54:17] yasuo.kashimura leaves the room [06:57:11] Eason joins the room [06:58:19] iljitsch joins the room [06:58:52] Philip Matthews joins the room [06:59:11] Please set your middleboxes to BEHAVE-compliant, it's nearly 9:00! [07:00:41] Err, here it is 3:00 and I am feeling a bit sleepy... [07:01:35] wmhaddad joins the room [07:01:36] The audio seems to be working this time! [07:02:57] leslie@ecotroph.net joins the room [07:04:40] nobody is saying anything yet though :-) [07:04:52] rhe joins the room [07:04:54] marka joins the room [07:05:12] yasuo.kashimura joins the room [07:06:33] matthijs joins the room [07:07:01] Meetings would be conf calls? [07:07:05] Exodus joins the room [07:07:49] Works for me [07:08:01] shinmiyakawa joins the room [07:08:06] Andrew Sullivan joins the room [07:08:20] jinmei joins the room [07:08:22] johl joins the room [07:08:30] tinnami joins the room [07:08:43] johl leaves the room [07:09:59] I have read dave's prefix doc [07:10:06] rababy joins the room [07:10:12] ASHIDA joins the room [07:10:28] Suzanne joins the room [07:12:01] terminology proposal works for me [07:13:08] Atarashi Yoshifumi joins the room [07:14:10] jhw joins the room [07:15:04] fdupont joins the room [07:15:17] danwing joins the room [07:17:15] slide 4 of the DNS64 presentation. [07:17:39] (Sorry for delays; we had an electrical short at the beginning of the meeting that killed both my laptop and Dave's laptop.) [07:18:16] Desire joins the room [07:23:43] leslie@ecotroph.net leaves the room [07:24:31] Who is speaking? [07:25:15] xing le [07:25:19] xing li [07:26:41] hongyu@jabber.org joins the room [07:28:38] slide 5. [07:28:48] thomson joins the room [07:31:22] dns64 implementation report [07:31:52] slide 2 [07:32:04] simon talking? [07:32:14] http://www.ietf.org/proceedings/75/slides/behave-13.pdf [07:32:14] yes [07:32:20] slide 2 [07:32:46] 3 [07:33:36] 4 [07:34:08] tachibana@jabber.org joins the room [07:34:48] going to the mic: Andrew [07:35:39] slide 5 [07:35:50] tachibana@jabber.org leaves the room [07:35:52] hyperfeng joins the room [07:36:31] asking question: Marcelo. [07:36:46] matthijs leaves the room [07:37:05] matthijs joins the room [07:38:48] slide 6 [07:40:39] tachibana@jabber.org joins the room [07:42:55] juampe.cerezo@gmail.com joins the room [07:43:29] juampe.cerezo@gmail.com leaves the room [07:43:39] jpc joins the room [07:44:45] slide 7 [07:45:30] slide 8 [07:45:55] slide 9 [07:46:17] Next up, Iljitsch van Beijnum, http://www.ietf.org/proceedings/75/slides/behave-0.pdf [07:47:16] FTP64 [07:47:20] slide 2 [07:47:33] same prezo as yesterday in APPAREA [07:48:30] slide 4 [07:50:38] 5 [07:50:40] 6 [07:50:42] HeikkiMahkonen joins the room [07:51:25] 7 [07:51:29] 8 [07:52:12] 9 [07:53:48] sureshk joins the room [07:54:07] 10 [07:54:36] 11 [07:55:06] 12 [07:56:34] 13 [07:57:11] Next up, Christian Vogt, "Virtual IPv6 Connectivity for IPv4-Only Networks", http://www.ietf.org/proceedings/75/slides/behave-17.pdf -- that link was recently updated, so if you downloaded it earlier, please download a fresh copy. [08:02:25] Support adopting FTP64 [08:04:27] thanks. [08:04:30] slide 1 [08:04:56] 2 [08:05:04] shamus joins the room [08:07:20] marka leaves the room [08:07:28] marka joins the room [08:07:29] jinmei leaves the room [08:07:33] jinmei joins the room [08:07:43] 3 [08:07:57] woolf joins the room [08:08:05] Suzanne leaves the room [08:08:35] sds joins the room [08:11:21] 4 [08:14:47] 5 [08:17:32] lebobits joins the room [08:18:00] sorry, folks. I was being lazy. I'll go to mic next time. (shame on the lazy guy...) [08:18:23] Question for Christian: How does this differ from the old NAT-PT? [08:18:34] I will relay your question [08:21:16] hscholz joins the room [08:22:28] NAT-PT had both in one box [08:23:20] slide 6 [08:23:22] I don't want to go to the mic, because we're running out of time, but I think anything that breaks DNSSEC at the end nodes is a complete non-starter. [08:24:02] woolf leaves the room [08:24:07] woolf joins the room [08:24:07] unfortunately IPv4 appears to be a non-ender... [08:24:08] I'd have to agree, putting all this effort into DNSSEC deployment and then creating new mechanisms that doesn't work with DNSSEC isn't nice. [08:24:21] @ Andrew: may well be so, but it's good to hear out the idea to see if some positives can be taken from it and applied with alteration to address the DNSSEC issue [08:24:53] plz post comments to the list. [08:24:54] slide 7 [08:25:18] I think there is a challenge with corporate networks behind NAT already using this address space. [08:25:38] but I guess it's dynamic so that's managable [08:25:52] Yeah, I don't want to discourage the work. It seems interesting, but it's going to be pretty hard to fix this hole [08:26:50] To be fair, the proposal under consideration only affects DNSSEC resolvers on IPv4-only hosts when they're asking questions about A records that have to be synthesized. It seems to be that a security-aware recursive server is one way to address the basic issue. [08:27:10] Next up, Stig Venaas, "Multicast IPv6/IPv4 Translation Framework", http://www.ietf.org/proceedings/75/slides/behave-14.pdf [08:27:26] slide 2 [08:27:51] 3 [08:29:40] Is this SSM or ASM multicast? [08:30:05] (Have not read the draft -- sorry!) [08:30:21] draft covers both. This slide is not specific. [08:30:36] slide 4 [08:30:52] 5 [08:30:53] @jhw: The security-aware recursive server doesn't help the client if the client can't get a secure connection to the recursor. Also, if my ISP is going to lie to me, I want to be able to detect it. [08:31:23] woolf leaves the room [08:32:07] Suzanne joins the room [08:32:32] jmohacsi@gmail.com joins the room [08:32:54] 6 [08:33:41] 7 [08:33:44] @andrew: I think this problem is solvable [08:33:55] I'm not sure I can solve it all right now [08:34:04] but I have a strong sense we can get it close [08:34:21] I look forward to the details :) [08:34:31] 8 [08:34:41] if there is a trust relationship between the corp recursive DNS, and again between that DNS and the next hop external DNS [08:34:58] then we can at least be sure that the reponses given along the trust path are good [08:35:34] this ASSUMES that the host is willing to trust it's first DNS hop recursive service, and by transitive property, anyone it trusts [08:35:36] I feel this work is interesting, but I feel WG should focus on unicast case first. [08:35:50] Next up, Shin Miyakawa, "Common Functions of Large Scale NAT (LSN)", http://www.ietf.org/proceedings/75/slides/behave-16.pdf [08:35:58] @lebobits: Sure, if you have a DNS client that has a secured connection to the recursor, you're golden. Just set the AD bit and don't do validation on the end node. [08:36:06] if I've got this right, then the problem falls to the host/person to decide if they are comfortable with the train of trust model [08:36:09] @phillip_matthews +1 [08:36:38] speaking now: Xing Li. [08:36:56] matthijs leaves the room [08:37:07] hscholz leaves the room [08:37:19] matthijs joins the room [08:37:23] HeikkiMahkonen leaves the room [08:37:32] @lebobits: the problem is that over in DNS-land we are rapidly moving towards the position that validation anywhere except on the end node is a 2d-best answer. OTOH, we don't have any OS vendors shipping validators on end nodes [08:37:39] Next up, Shin Miyakawa, "Common Functions of Large Scale NAT (LSN)", http://www.ietf.org/proceedings/75/slides/behave-16.pdf [08:37:57] slide 1 [08:38:07] 2 [08:38:14] @andrew: yes, e2e is the best security model [08:38:24] and, as I'm sure you've also agreed in DNS land, [08:38:29] It's not always possible [08:38:46] there has to be a delegation of trust model in certain environments [08:39:00] the use case Christian provided is a great example [08:39:20] : client in a corp (or visitor) net, behind v4 NAT, needing access out [08:39:31] 3 [08:39:34] there will have to be trust, if access is desired, else, [08:39:36] 4 [08:39:41] 5 [08:39:57] he can wait until he gets back home before he checks his bank account balance via web. [08:40:00] wfy? [08:40:10] tony joins the room [08:40:11] @lebobits: yeah, there's a use case here for sure. [08:40:36] slide 6 [08:40:37] becarpenter joins the room [08:40:48] part of the problem here is that getting the recursor's address isn't actually properly secured in most contexts anywya [08:40:54] as security increases, convenience decreases [08:41:07] as convenience increases, security assurances must decrease [08:41:12] because it just comes from DHCP [08:41:18] slide 7 [08:41:20] you chose where you want to be on the line [08:41:44] Well, careful. Often it's not the "you" whose data is affected who's getting to choose [08:41:57] slide 8 [08:42:11] that is, what _I_ want is hard to enforce if my ISP is doing tricky things [08:42:13] that can be fixed w/ NEA and Network Access Control mechansism [08:42:36] slide 9 [08:42:37] perhaps, yeah [08:42:46] then you don't have a trustworthy IPS [08:42:51] s/IPS/ISP [08:42:55] Question to speaker: Is this "path-though" or "pass-through"? [08:43:11] pass-through [08:43:14] i think [08:43:21] matthijs leaves the room [08:43:33] @lebobits: alas, many people do not have a trustworthy ISP. [08:43:36] slide 10 [08:43:47] jinmei leaves the room [08:43:48] matthijs joins the room [08:43:49] arifumi joins the room [08:44:12] jinmei joins the room [08:44:12] Suzanne leaves the room [08:44:18] woolf joins the room [08:45:10] looking at slide 11 [08:47:52] "Large-scale NAT" vs. "Carrier-grade NAT" ...this is why I proposed calling them "Service-provider NAT" [SP-NAT]. [08:47:57] Mark Thompson joins the room [08:48:31] should we then have C-NAT which is what the residential gateways are doing today, or this is just plain NAT ? [08:48:47] CPE-NAT vs. SP-NAT. [08:49:13] SP-NAT has the fairness problem that isn't as troubling in CPE-NAT. [08:49:15] woolf leaves the room [08:50:11] "SP" isn't quite right, either. Consider that a large enterprise (the likes of Boeing, Ford, etc.) has similar issues/concerns with a rogue employee or rogue / poorly written applications consuming ports and DoSing other users. [08:50:26] slide 9 is being displayed [08:51:47] I'm okay with adopting LSN as the preferred term of art. [08:53:52] jinmei leaves the room: Replaced by new connection [08:54:13] tony leaves the room [08:55:00] Andrew Sullivan leaves the room [08:55:07] Andrew Sullivan joins the room [08:56:03] "Redundancy and Load-Balancing Mechanisms for Stateful Network Address Translators (NAT)", http://www.ietf.org/proceedings/75/slides/behave-5.pdf [08:56:13] Xiaohu Xu [08:56:29] dean cheng (I think) presenting [08:56:40] slide 2 [08:57:09] thanks. [08:57:36] Yes, correct. Can see his badge now. [08:57:48] Question for speaker: Is this stuff that really needs standardization? That is, is there stuff here that is externally visible? [08:57:48] sorry, was cutting and pasting when he introduced himself. [08:58:03] slide 3. [08:58:14] Philip, will relay your message at end of prezo. [08:58:38] wmhaddad leaves the room [08:58:46] Dan, I also have the same concern as Philip. [08:58:57] ok [08:59:16] Further comment: Our routers do hot standby for many routing protocols, but we didn't need any protocol changes. [09:01:11] Andrew Sullivan leaves the room [09:01:19] Andrew Sullivan joins the room [09:01:41] fujisaki joins the room [09:02:08] slide 4 [09:02:35] aalain joins the room [09:02:48] Actually, we do not think redundancy function is not needed to be starndarzed. but this kind of work is important as BCP, I think. [09:02:57] jmohacsi@gmail.com leaves the room [09:03:33] slide 5 [09:03:52] @shinmiyakawa: Why is it important for NATs, when it was not felt to be important for routing protocols? [09:05:14] yeah. Any status on LSN should be redundant. including routing protocol. [09:05:36] Philip: VRRP was standardised. Is it used? [09:05:48] jmohacsi@gmail.com joins the room [09:06:00] yes, VRRP is used a lot. [09:06:05] this proposal suggests using it. [09:06:15] now on slide 6 [09:06:39] VRRP was standardized because it is a protocol. [09:06:45] jmohacsi@gmail.com leaves the room [09:06:59] Yes, and they suggest doing it for this too [09:07:08] it = VRRP [09:07:12] In ACT-ACT case, every NAT status shold copy one to the other in real-time manner, VRRP is not sufficient to do that. Now we're asking several vendors to implement ACT-ACT backup, but every vendor uses its own system to synchronize machines. [09:07:23] Andrew Sullivan leaves the room [09:07:31] Andrew Sullivan joins the room [09:07:42] matthijs leaves the room [09:07:45] and if you want multi-vendor interop, you need a standard [09:07:59] yeah. but we do not want to do that :-) it fails often. [09:08:31] matthijs joins the room [09:08:44] sure, it's a hard problem, see the story of RSERPOOL [09:08:55] Ah. So you want multi-vendor interop for this proposal. In that case, I can see a standard would be needed. But is multi-vendor implementation really realistic? [09:09:32] @Philip: is the question being asked now sufficient for your question? [09:09:42] @Philip: I agree with Shin that it is hard, could be a distraction for BEHAVE [09:09:51] Please understand that, we (JP group) are just suggesting "LSN should have ACT-ACT backup functions." and no standard way is needed. maybe they (CN group) is aiming that [09:11:38] Desire leaves the room [09:11:47] jmohacsi@gmail.com joins the room [09:11:55] magnus joins the room [09:12:37] jinmei joins the room [09:12:46] Up soon, "RS-NAT based on BGP for IPv4/IPv6 Transition ", http://www.ietf.org/proceedings/75/slides/behave-7.pdf, by Chen Gang. [09:14:01] Up now, "RS-NAT based on BGP for IPv4/IPv6 Transition ", http://www.ietf.org/proceedings/75/slides/behave-7.pdf, by Chen Gang [09:14:06] rhe leaves the room [09:14:31] slide 1 [09:14:35] slide 2 [09:15:12] lixia joins the room [09:15:29] slide 3 [09:15:46] hongyu@jabber.org leaves the room [09:16:45] shamus leaves the room [09:17:07] slide 4 [09:17:48] lixia leaves the room [09:18:28] 5 [09:18:33] Andrew Sullivan leaves the room [09:18:40] Andrew Sullivan joins the room [09:19:35] Shwetha joins the room [09:19:44] Joel Halpern, "Generic Referral Object (GRO)", http://www.ietf.org/proceedings/75/slides/behave-2.pdf [09:20:02] slide 2 [09:20:18] slide 3 [09:21:21] shengjiang joins the room [09:21:29] 5 [09:21:54] HIP is another attempt to solve this problem [09:22:47] slide 6 [09:23:47] 7 [09:23:56] 8 [09:24:19] 9 [09:25:37] Andrew Sullivan leaves the room [09:25:38] matthijs leaves the room [09:25:42] 10 [09:25:45] Andrew Sullivan joins the room [09:25:56] matthijs joins the room [09:26:14] 11 [09:26:41] 12 [09:27:30] Atarashi Yoshifumi leaves the room [09:27:34] 13 [09:27:55] iljitsch leaves the room [09:27:58] 14 [09:28:21] fdupont leaves the room: Computer went to sleep [09:28:48] The ICE experience says that the receiver can not know apriori, which reference will work, so it must try them all until one works [09:28:52] 15 [09:29:03] JanMelen joins the room [09:29:53] I think this is interesting work. [09:30:34] sureshk leaves the room [09:31:46] Up soon, Wojciech Dec, "NAT Control Protocols Review", http://www.ietf.org/proceedings/75/slides/behave-15.pdf [09:32:09] Exodus leaves the room [09:32:41] Comment: I don't see why one how to name scopes, because I think the receiver just needs to try all received references. [09:34:13] Philip: see what you think about the way we describe it in the draft. We certainly argued about this point. [09:34:37] slide 2 [09:34:39] @brian: I need to read the draft. I will do so, then send more useful comments [09:34:43] jpc leaves the room [09:34:52] now presenting, Wojciech Dec, "NAT Control Protocols Review", http://www.ietf.org/proceedings/75/slides/behave-15.pdf [09:35:16] hyperfeng leaves the room [09:35:50] slide 3 [09:35:51] Eason leaves the room [09:36:17] matthijs leaves the room [09:36:25] slide 4 [09:36:27] woolf joins the room [09:36:47] 5 [09:37:17] tinnami leaves the room [09:38:01] I like what I see here. [09:38:20] magnus leaves the room: I'm happy Miranda IM user. Get it at http://miranda-im.org/. [09:38:23] shinmiyakawa leaves the room [09:38:26] jhw leaves the room [09:38:30] ok, thanks. [09:38:38] Shwetha leaves the room [09:38:40] thomson leaves the room [09:38:47] thanks [09:38:56] yasuo.kashimura leaves the room [09:39:00] jinmei leaves the room [09:39:10] jmohacsi@gmail.com leaves the room [09:39:38] rababy leaves the room: Computer went to sleep [09:39:39] danwing leaves the room [09:39:49] danwing joins the room [09:40:00] shengjiang leaves the room [09:40:12] danwing leaves the room [09:40:27] Philip Matthews leaves the room [09:40:39] becarpenter leaves the room [09:42:37] Andrew Sullivan leaves the room [09:44:08] lebobits leaves the room [09:44:08] lebobits joins the room [09:44:49] tachibana@jabber.org leaves the room [09:45:39] lebobits leaves the room [09:48:07] marka leaves the room [09:49:39] woolf leaves the room [09:53:05] Mark Thompson leaves the room: Replaced by new connection [09:53:06] Mark Thompson joins the room [09:53:30] JanMelen leaves the room [09:54:44] Mark Thompson leaves the room [09:59:36] arifumi leaves the room [10:00:39] fujisaki leaves the room [10:03:51] aalain leaves the room [10:08:40] sds leaves the room [10:09:10] Andrew Sullivan joins the room [10:42:57] ASHIDA leaves the room [10:58:43] Andrew Sullivan leaves the room [11:00:29] jinmei joins the room [11:00:57] jinmei leaves the room [11:07:44] Atarashi Yoshifumi joins the room [11:14:07] Atarashi Yoshifumi leaves the room [11:15:06] arifumi joins the room [11:15:17] arifumi leaves the room [11:26:06] Philip Matthews joins the room [11:27:14] Philip Matthews leaves the room [12:36:49] YGHONG-X300 joins the room [12:36:56] YGHONG-X300 leaves the room [13:42:31] jinmei joins the room [13:42:58] jinmei leaves the room [16:54:01] ASHIDA joins the room [16:55:02] ASHIDA leaves the room