[14:39:34] Dave Winter joins the room [14:50:46] Jiro Yamaguchi joins the room [14:51:17] Philip Matthews joins the room [14:51:18] karen.s.seo joins the room [14:56:05] donley.chris joins the room [14:56:36] donley.chris leaves the room [14:58:31] matthijs joins the room [14:58:54] hirocomb12 joins the room [14:59:18] hscholz joins the room [14:59:25] mlm.michael.miller joins the room [14:59:37] Is anyone on the chat actually present in the room? [14:59:45] TJ joins the room [15:00:49] Does anyone know if the session has started? I am not getting any audio [15:01:02] magnus joins the room [15:01:08] the session has not yet started [15:01:21] Cullen Jennings joins the room [15:01:37] narten joins the room [15:01:46] benno joins the room [15:02:05] I assume session has not started yet (there is no audio coming through the feed) [15:02:18] I don't hear any audio either [15:02:28] not started yet [15:02:30] No, it hasn't [15:02:36] i think they ping us if it starts ;) [15:03:22] alfredh joins the room [15:03:42] fdupont joins the room [15:03:43] audio is really low [15:03:48] jiang_xing_feng joins the room [15:04:01] adjust the microphones please, we can't hear... [15:04:01] Bruce joins the room [15:04:07] Starting ... Agenda @ http://tools.ietf.org/wg/behave/agenda?item=agenda73.html [15:04:09] Suz joins the room [15:04:27] venaas joins the room [15:04:28] jinmei joins the room [15:04:33] wouter joins the room [15:04:39] Nothing or just very low? [15:04:40] Agenda slides @ http://www3.ietf.org/proceedings/08nov/slides/behave-0.pdf [15:04:42] very low. [15:04:45] arifumi joins the room [15:04:47] very very low [15:04:47] can barely hear... [15:04:48] I can hear something [15:04:57] DUDI joins the room [15:05:02] FWIW - Sounds fine in room ... [15:05:06] momose joins the room [15:05:15] very low here also [15:05:15] (Agenda slide 6) [15:05:21] no signal here, while channel1 and channel2 are there, but low [15:05:34] donley.chris joins the room [15:05:39] sdstrowes joins the room [15:05:41] he's on the chair mic. hopefully the wireless is on the feed [15:05:42] loooow [15:05:56] kanda joins the room [15:06:05] Lars joins the room [15:06:11] please have them adjust the microphones... it is not good enough to hear and will make the mp3 recording useless. [15:06:25] yes all 100%, i can hear some whisper [15:06:28] i contacted joel [15:06:40] Question - do you intend to attend Malta? (and have not been counted before) [15:07:25] ... and who would participate remotely? [15:07:32] yes, I will attend remote! [15:07:40] coutn me in! [15:07:44] I will attend remotely [15:07:45] matthijs put my hand up [15:07:58] s/my/his/ [15:08:10] was magnus' question clearer on the audio? [15:08:16] no [15:08:17] no [15:08:19] no [15:08:22] no [15:09:01] The audio delay seems to be at least 30 - 40 seconds [15:09:08] Randy comments on mic [15:09:17] mhp joins the room [15:09:42] Frd speaking momentarily on http://tools.ietf.org/html/draft-baker-behave-v4v6-framework, http://www3.ietf.org/proceedings/08nov/slides/behave-5.pdf [15:10:06] (Unnumbered slides) ...Outcome from Montreal [15:10:13] kanda leaves the room: Replaced by new connection [15:10:13] kanda joins the room [15:10:32] please speak up, thanks [15:10:46] (in the mic) [15:10:58] (someone is over tweaking nobs, presumably audio levels?) [15:11:01] audio is being adjusted [15:11:08] not the right ones (yet)! [15:11:20] flyinhome joins the room [15:11:23] what was the hand count in room of people that can come to malta [15:11:32] 8 new [15:11:35] @cullen 8 new ones [15:11:35] Audio still low [15:11:40] thanks [15:11:41] I think we have now totalled 14 ... [15:11:42] Jelte joins the room [15:13:09] ruri joins the room [15:13:09] anybody remember the date of malta interim ? [15:13:12] maybe, I will attend also the Malta intermediate (not virtually, but present there). [15:13:29] 20-22 jan [15:13:34] thanx [15:13:39] and i am not counted yet. [15:13:44] Next Slide - "Scenario" ... [15:13:45] the behave part are scheduled for 20-21 [15:13:47] Have we given up on adjusting the volumne? [15:14:13] @narten still waiting for reply form the noc/joel [15:14:13] I still have my local volume at max [15:14:19] No, but I don't understand the setup to separate the volume to the streaming box and room speakers [15:14:43] ((Next slide - Terminology) [15:14:43] aalain joins the room [15:14:45] please fix sound, and who is scribing? [15:14:58] I am scribing ... [15:15:05] Magnus is looking at the audio box ... [15:15:14] markkao joins the room [15:15:15] ... NOC has been pinged ... [15:15:19] ok thanx [15:15:20] DThaler joins the room [15:15:21] ... can you suggest another POC? [15:15:23] suz joins the room [15:15:52] (Next slide - terminology 2) [15:16:44] (Slide += 1 .... errr, 2 now ... "temporary tool") [15:16:45] Can the speakers talk louder into the mic? [15:17:05] No, because the audio volume in the rooms is just right [15:17:17] So it is the mixer to streaming box levels that are wrong [15:19:08] a big part of the problem is limiting the exposure of DNS ALG to only those hosts/apps that need it [15:19:40] What slides are we on? [15:19:46] @flyin - wanst that asked to the room? [15:19:47] sureshk joins the room [15:19:48] ashida joins the room [15:19:51] Did the sound level improve? [15:19:55] yep [15:19:58] yes [15:19:59] a little [15:20:00] no, it wasn't a question. [15:20:05] No clipping? [15:20:05] no really for me [15:20:07] turn a bit further up [15:20:08] (Still on "temporary tool" ... it is animated, have now shown all componenets(?)) [15:20:09] yes, but increase 3x more [15:20:36] (Next slide = "address format chosen") [15:21:04] That is all that you get until someone can readjust across the whole board. [15:21:21] Thanks, Magnus [15:21:21] thanks magnus [15:21:30] tnx. I can at least hear now. but it needs to be turned up further. [15:21:50] In otherwords that really know this setup comes and look at it. [15:21:52] For me, I still have my local audio turned all the way up [15:22:21] (Next slide ... ISP usage) .... [15:22:21] yes, audio at max, under headphones, I can not at least hear. not optimal, but better than before. [15:22:23] Dave at mic [15:22:43] simon joins the room [15:22:53] (Sorry, usage # 1) [15:23:59] The only things deprecated in 4291 are site locals and IPv4-compatible addresses which were defined for a specific type of tunneling (not translation). The addresses used for translation were not deprecated. [15:25:08] (Next slide, ISP usage #2) [15:25:43] Andrew Sullivan joins the room [15:26:26] (next slide, "stub network") [15:27:00] roque@ietf73 joins the room [15:27:40] (next slide, "Routing Adv") [15:29:13] After run-out may be the case of IPv6 only data-centers serving IPv4 customers. Not enough IPv4 addresses for all the servers, so translation will be needed. I know big content providers are "watching" this issues. [15:29:27] I guess that scenario can be added [15:29:56] @roque: Send e-mail to fred [15:30:10] I've only half been paying attention - did anyone get Joel to try and sort out audio levels? [15:30:25] yes [15:30:30] They are better, but need an expert to improve more [15:30:45] benno leaves the room [15:30:57] i didn't hear improvement in the audio... [15:31:08] JonathanLennox joins the room [15:31:11] (Next slide, "usage of 1:n") [15:31:12] BillC joins the room [15:31:25] have to disagree with fred's assertion that you don't need ipv4 access to general ipv6 hosts [15:31:44] Charlie is saying that at mic now'ish ... [15:32:05] saumitra.m.das joins the room [15:32:06] Fred's response - out of scope of this conversation, not completely off table [15:32:31] benno joins the room [15:33:40] Andrew Sullivan leaves the room [15:33:43] the problem is the assumption that v4 apps can't adapt to talk to v6 hosts before the networks all upgrade [15:33:46] Andrew Sullivan joins the room [15:34:10] Ed speaking @ mic now [15:34:29] venaas leaves the room [15:34:30] ruri leaves the room [15:34:31] momose leaves the room [15:34:31] aalain leaves the room [15:34:38] @Flyin ... do you mean via tunneling (e.g. - Teredo) ... ? [15:35:00] 10 years seems a bit enthousiastic [15:35:17] momose joins the room [15:35:20] no, I mean something like nat-xc (similar to turn with all of the proposed extensions). tunneling is harder to use [15:35:22] Fred's response to Ed ... basically, get to the tipping point and life becomes easy [15:35:34] Remi at mic [15:36:17] sm joins the room [15:36:35] @Flyin ... I suspect Fred's answer is that we don't control every app, so try to solve this sans that. [15:36:53] Dave capping lines ... [15:37:12] wherrin joins the room [15:37:16] "Perfect is the enemy of the good" invoked [15:37:24] the problem is that by trying to provide a separate solution for each case, you slow things down. doing a general solution is less complicated than doing it piecemeal [15:37:52] (next slide, "usage of dns translator") [15:38:42] you really can't expect p2p apps to use DNS names as endpoint IDs. it's too unreliable and inconsistent. [15:38:55] strongly disagree with fred that this solves the p2p problem [15:39:08] true [15:39:37] @Flyin - have a quote/comment/question to relay to room? [15:39:42] Marcelo at mic [15:40:08] I'll let you know. it's hard to know how to respond constructively at this point. [15:40:30] and we're now 10 minutes behind in the agenda :) [15:41:16] (slide on screen - "temporary tool") [15:41:34] benno leaves the room [15:42:10] I bleieve Iljitsch is on mic, questionin the address formats ...(and relevant slide onscreen) [15:43:23] benno joins the room [15:43:28] Marcelo on mic [15:44:09] Dave ... this issue is being punted to ML / future drafts ... important issue, not prepared to address (pun intended?) this here/now [15:44:26] the points I'd make if I could put up a slide now are: 1. you really want to avoid exposing DNS ALG except to legacy v4 only apps. 2. you really need to give apps a programmatic interface to the translator to let them ask "how do I communicate with this address in the other realm?" that works independent of whether the translation is stateless or not. 3. if you have that programmatic interface then the way you embed addresses for stateless translation is less of an issue [15:45:19] @Flyin - at this point, I'd say place that in an email ... [15:45:28] Eric(?) ata mic ... [15:45:31] Andrew Sullivan leaves the room [15:45:35] either that or hack the video projector :) [15:45:37] Andrew Sullivan joins the room [15:45:47] Randy at mic [15:46:38] Next presentation ... Fred ... http://tools.ietf.org/html/draft-baker-behave-v4v6-translation. http://www3.ietf.org/proceedings/08nov/slides/behave-6.pdf [15:47:15] (Slide 2) [15:47:47] levigner joins the room [15:47:51] (Slide 5) [15:48:06] (Atleast, it says 5 on the bottom ...) [15:48:15] yeah the slide numbers on the bottom don't match the actual numbers in the PDF [15:48:36] (Next slide ... 4 is deck ... 9 on bottom ... "4-->6 translation) [15:49:21] Actually, looks like something got skipped or is out of order ... in the deck i show ascii art on slide 4 ... [15:49:51] (Next slide ... #6 in deck ... says 10 on bottom) [15:49:55] maybe he has "hidden" slides he doesn't want to use [15:50:21] ruri joins the room [15:50:22] benno leaves the room [15:50:23] wouter leaves the room [15:50:24] (Next slide ... #7 / #14) [15:50:55] (Next slide ... #8 / #15) ... (already #9/#16 now) [15:51:02] I really don't think the siit document should say how to translate addresses at all. [15:51:11] benno joins the room [15:51:19] wouter joins the room [15:51:46] (Next slide *2 ... 11 / 21) [15:52:09] (Next Slide ... 12 / 22) [15:52:56] ... and a note on that slide to the Addr Sel dseign time ... be sure to incorporate this ... [15:52:56] Bob joins the room [15:53:05] (next slide *2 ... um, end) [15:53:20] Andrew Sullivan leaves the room [15:53:26] Andrew Sullivan joins the room [15:54:09] ____ (missed name of person at mic) ... Dave now [15:54:22] Erik Nordmark [15:54:29] @Bob Thx [15:55:16] lebobits joins the room [15:55:30] what I meant is that there are multiple ways to translate addresses and SIIT is useful independent of which translation mechanism is chosen. [15:55:49] iljitsch joins the room [15:55:54] there is a case to be made for a translation that doesn't embed v4 address in the v6 address [15:56:04] donley.chris leaves the room [15:56:31] @flyin - Dave didn't have his laptop w/ him at mic ... so seeing your comments about now ... [15:56:38] Ed on mic ... [15:56:39] Hi all, I just posted a message to the list about using HTTPS proxies to get from IPv4 clients to IPv6 servers, as well as the other way around. I think this nicely compliments our other efforts. [15:56:56] thx, I'll take a look. [15:57:02] Rob on mic [15:57:34] Next up: Marcelo presenting http://tools.ietf.org/html/draft-bagnulo-behave-nat64, http://www3.ietf.org/proceedings/08nov/slides/behave-8.pdf [15:57:49] donley.chris joins the room [15:57:56] we're back on schedule [15:58:18] (slide = "Application Scenario") [15:58:48] (next slide "appl scen refined") [15:58:50] wouter leaves the room [15:58:52] benno leaves the room [15:58:59] Can someone please retransmit the request to get "experts" to adjust the audio streaming volume? Tnx! [15:59:08] wouter joins the room [15:59:10] (next slide "appl scen refined" ... IPv6 internet now) [15:59:34] (Slide 6 in deck ... "Relation") [16:00:20] (Next slide = "Overview") [16:00:23] ogud: Olafur Gudmundsson joins the room [16:00:34] Suz leaves the room [16:00:45] ... next step in animation (slide # 8 in deck ) ... 9 now [16:01:29] (Slide 16 now) [16:01:29] suz leaves the room [16:01:32] benno joins the room [16:01:57] sureshk leaves the room [16:02:02] suz joins the room [16:02:19] Dave at mic [16:02:29] (Slide 17 calling for questions) [16:03:09] agree with Dave's comment. [16:04:00] (next slide ... 18 ... Protocols supported) [16:04:11] marc.blanchet.qc joins the room [16:04:59] ... Marcelo proposes just TCP, UDP ... punt rest to other docs / future work ... [16:05:13] __missed one speaker ... Magnus now [16:05:22] Remi now [16:06:10] ... Magnus ... the conversation is over SCTP, multihoming ... [16:06:23] Iljistch on mic [16:07:02] Suz joins the room [16:07:19] ... voicing support for punting SCTP, DCCP to "future work" ... IPsec possibly quite useful, requiring knowledge on hosts side [16:07:25] Jelte leaves the room: Replaced by new connection [16:07:27] J.Jansen joins the room [16:07:36] Comment to WG: We want the document to progress ASAP; do just UDP and TCP, leave rest to another document [16:08:02] that's what Marcelo just said too [16:08:08] Yup [16:08:10] hscholz leaves the room [16:08:18] (FWLIW - I agree with Marcelo, Philip ... could we just make a call for consensus on that and roll on?) [16:08:35] Magnus on mic ... [16:09:03] benno leaves the room [16:09:14] As editor of TURN, I know how extra stuff can really slow down a document [16:09:35] hscholz joins the room [16:09:43] Chris on mic ... [16:10:51] philip: over-fragmentation of the problem can also slow down the solution. there's a difference of opinion about how big a piece is appropriate to bite off in the near term. but I certainly agree that splitting off SCTP is appropriate - let the SCTP experts specify how to do that through a translator. [16:11:25] Dave poses question, Greg on mic now ... [16:12:20] @flyin: From my TURN experience, it is the last 10% that takes 90% of the time. TURN has been mostly done for a while, but getting all the little details nailed down has really delayed the document, dispite the fact that we have kicked a bunch of stuff out. [16:12:32] Yes, but I fail to see why the stateful 46 translator for protocol X becomes such more complex when we know how to do 44 translator for them. [16:12:56] Cullen on mic [16:13:00] =JeffH joins the room [16:13:03] that depends on whether you think of TURN as a solution for legacy NAT or a solution for general v4-v6 translation. it started out to be the former, and isn't quite there for the latter yet. [16:13:07] @Magnus: Again, it is the little details that take huge amounts of time [16:13:24] agreed, but the little details are sometimes important [16:14:00] Yes, but if people are less interested in them, then it delays the document [16:14:20] I also agree with what Cullen said [16:14:40] i kind of missed the reason why this is not done on the ip layer [16:14:45] it's hardly surprising if people are less interested in answering the most difficult questions - it's easy to pretend that they're really not important, even if they are. of course, sometimes they're not important. [16:15:01] @jansen: You need to do port translation [16:15:49] JonathanLennox leaves the room: Replaced by new connection [16:15:49] JonathanLennox joins the room [16:16:00] Sheila on mic ... [16:16:05] @Jansen: Because straight address translation doesn't always work, due to the fact the IPv4 address space is smaller than the IPv6 space [16:16:10] Philip when one have already sorted out the details, why wouldl that slow down so much. [16:16:28] Margaret on mic [16:16:41] thanks [16:17:17] @Magnus: But we don't have all the details. The DCCP and SCTP documents for 4-4 translation are not yet published, and we don't know about any extra complexity that 6-4 translation would bring [16:17:55] http://www.productivity501.com/wp-content/uploads/2008/02/efficiency-perfection.png [16:18:02] @Magnus: We have known how to do 4-4 translation for UPD and TCP for some time now, but we are still working the details of the new SIIT. [16:18:34] Margaret : ~"The current question seems to be over document management, reference/ordering and timing" ... votes for inclusion of TCP/UDP only, with a normative should for the others [16:18:42] Cullen agrees [16:18:45] venaas joins the room [16:18:50] wouter leaves the room [16:18:51] venaas leaves the room [16:18:52] ruri leaves the room [16:18:55] momose leaves the room [16:18:56] it would help if we had some confidence on how much impact DCCP and SCTP would have on the overall architecture. if you can get that down, and make sure the overall architecture supports them, you can bifurcate and let SCTP and DCCP progress separately without much coupling between those efforts and the UDP/TCP efforts. [16:19:03] wouter joins the room [16:19:03] venaas joins the room [16:19:14] ruri joins the room [16:19:32] there should be three seperate things: UDP/TCP, IPsec & SCTP. None should be dependent on the other, and all should be published when they are ready, regardless of whether the other documents are ready. [16:19:42] (Missed name) at mic ... Asks the everlasting question "What is a NAT"? [16:20:12] @Narten ... jusr for clarificaiton, +1 for DCCP .. +N for all future transports ... ? [16:20:33] It would be wrong/silly to require/mandate that all translation devices include (say) SCTP. That would be useless for home routers, for example, where SCTP is not used. [16:20:44] Dave proposes to move forward: TCP/UDP in doc now, others in separate [16:20:49] Humming ... [16:21:03] (any votes out there?) [16:21:05] I vote yet [16:21:11] s/yet/yes/ [16:21:16] can't hear humming:) [16:21:23] Room voted yes ... [16:21:25] @TJ, yes let market/demand drive work for any other transports where it makes sense. [16:21:28] ... generally [16:21:33] Good [16:21:37] I don't like making architectural decisions based on what is used now. the internet keeps evolving. and yet I agree that there's not a strong case to be made to force translation boxes to support SCTP, at least not until we know how to do it. [16:21:47] @Narten Excellent [16:23:05] (missed name) - assuming WG doc acceptance ... do we make them reliant on each other or push forward separately? Iljistch comments [16:23:17] Why not publish a BCP saying "Vendors should support all protocols" [16:23:29] jm joins the room [16:23:43] Greg ... theory --> practice ... [16:23:47] @Philip. Yes. you SHOULD implement all 1237 protocols.... [16:23:47] That way, the base doc could get published as an RFC quickly [16:23:52] "Vendors should support all protocols and MUST NOT have any bugs" [16:24:03] ... MUST be secure ... [16:24:08] maureen.stillman joins the room [16:24:12] and intermediaries MUST NOT break anything :) [16:24:28] My goal is to get the base doc ppublished as an RFC ASAP [16:24:43] donley.chris leaves the room [16:24:44] my goal is to make v4/v6 translation safe for applications [16:24:58] @Philip ... make a motion for that ... :) [16:25:05] wouter leaves the room [16:25:06] Dave : Do we hold up base doc? ... vote now [16:25:09] (because the net exists to support apps, after all) [16:25:13] wouter joins the room [16:25:27] DUDI leaves the room: Replaced by new connection [16:25:42] Room votes for both, not linking = mor ehumming [16:25:49] ylee joins the room [16:26:00] momose joins the room [16:26:07] Chris Donley joins the room [16:26:07] Chris Donley is now known as donley.chris [16:26:07] donley.chris is now known as Chris Donley [16:26:24] ... conversation about timing, Dave calls for volunteers to work on the others ... [16:26:30] Adopt as WG doc? [16:26:40] Yup. We need people to work on the other protocols [16:26:42] Andrew Sullivan leaves the room [16:26:48] Andrew Sullivan joins the room [16:26:54] Vote yes -- but I am a co-author [16:26:59] DUDI joins the room [16:27:08] hm [16:27:12] Chairs: The vote will be on ML ...with differentiation for each doc ... [16:27:28] DUDI leaves the room [16:27:56] Chris Donley is now known as donley.chris [16:27:56] donley.chris is now known as Chris Donley [16:27:57] (Slide 19 now "endpoint independence ...") [16:28:15] My concern about NOT having endpoint independence is that we don't fully understand the implications of that [16:28:28] Remi at mic ... [16:28:31] re: endpoint independence. the only way to use it without breaking things is to have some way of reliably knowing whether the app that's using the mapping doesn't need that mapping to be independent of the remote peer address. [16:28:37] Simon Perreault joins the room [16:28:46] fujisaki joins the room [16:28:52] so you can't get this via heuristics - you have to let the app tell you that it's okay [16:29:00] @fly: Yes. And we don't really know how to do that [16:29:08] well, there is one proposal for it. [16:29:36] sorry, I was wrong. but a couple of different approaches could be extended for it. [16:29:39] markkao leaves the room [16:29:40] Is there? I am behind in my reading. Which doc? [16:29:47] ... conversation ... Marcelo, chairs ... specified in this doc or other ... [16:29:55] Fred at mic [16:29:57] Simon Perreault leaves the room [16:30:01] TURN could be extended to do something like that. so could nat-xc. [16:30:22] @Fly: How? Don't see that [16:31:06] @Fly: Rather than do this on jabber, let's take this discussion to the mailing list [16:31:12] if an app makes an explicit request for a binding in the translator, it can add an option that says "I don't care whether the binding is independent of the remote peer address". that would free up the translator to make thebinding dependent. [16:31:21] markkao joins the room [16:31:36] @philip, yea, I'm trying to keep it brief on jabber and taking notes for later email. [16:31:38] Magnus .. [16:31:40] @Fly: But apps do not explicitly ask for a binding. They just send packets [16:31:41] Henk joins the room [16:32:02] Henk leaves the room [16:32:05] @phillip: the point is that that approach is fundamentally insufficient. [16:32:23] Chairs capping lines ... Cullen at mic [16:32:55] wouter leaves the room [16:32:57] Chris Donley is now known as donley.chris [16:32:57] donley.chris is now known as Chris Donley [16:33:01] @philip: you have to give apps a way to explicitly ask for bindings. [16:33:04] wouter joins the room [16:33:09] Andrew Sullivan leaves the room [16:33:15] Andrew Sullivan joins the room [16:33:22] Iljitsch at mic [16:33:37] flyinhome leaves the room [16:33:41] @Fly: The problem is getting such a proposal deployed. There have been MANY attempts, and almost all have failed to gain traction [16:35:24] (Missed name) at mic ... and now Alain at mic [16:35:24] =JeffH leaves the room [16:35:41] flyinhome joins the room [16:36:34] Dan at mic .... presentations on this to follow @ IETF74, draft and ideas underway [16:36:49] (or at Malta) [16:36:56] Next up, Marcelo presenting DNS64 ... http://tools.ietf.org/html/draft-bagnulo-behave-dns64 ... http://tools.ietf.org/html/draft-bagnulo-behave-dns64-01 [16:37:33] (Sorry ... slides @ http://www3.ietf.org/proceedings/08nov/slides/behave-9.pdf_ [16:37:46] (Dang ... try this again ... http://www3.ietf.org/proceedings/08nov/slides/behave-9.pdf ) [16:37:58] Chris Donley is now known as donley.chris [16:37:58] donley.chris is now known as Chris Donley [16:38:23] (On slide 6 now) [16:38:37] (Same animation stream ... as NAT64) [16:38:54] (Slide 17 now) [16:38:56] weiler joins the room [16:39:33] they are different in the sense of dnssec [16:39:34] Angelo(?) at mic [16:39:41] Alain Durand. [16:39:42] alain durand [16:39:44] Alain Durand [16:39:46] hehe [16:40:00] @ReplyToAll thx ... [16:40:34] (Marcelo ... another mention to RFC3484, so another note to the re-design team to make note of ...) [16:40:53] Rob on mic ... DNSsec on the table [16:41:12] (Slide 18) [16:42:18] Andrew on mic [16:42:59] Chris Donley is now known as donley.chris [16:42:59] donley.chris is now known as Chris Donley [16:43:08] do you need to include the NSEC record to prove that there was no non-synthetic AAAA at the name, too? [16:43:09] Don't see yet why this is the same as CNAME/DNAME... [16:43:11] JonathanLennox leaves the room: Replaced by new connection [16:43:12] JonathanLennox joins the room [16:43:19] Next up, Akira presenting "Large Scale NATs, NAT444" ... http://tools.ietf.org/html/draft-nishitani-cgn-01.txt, http://tools.ietf.org/html/draft-shirasaki-nat444-isp-shared-addr-00.txt ... slides @ http://www3.ietf.org/proceedings/08nov/slides/behave-7.pdf [16:43:58] (Slide 2) [16:44:01] or can an attacker (nee translator) strip the real AAAA and substitute a fake (nee translated) one? [16:44:33] (Slide 3) [16:44:52] matthijs: for DNAME, the validator checks if the synthesized CNAME is correct, by checking the signature on the DNAME, then checking the CNAME. Here they propose the same, check signature on the A record, then check if AAAA was correctly created. [16:45:02] right [16:45:11] There is an important difference [16:45:16] (Slide 4) [16:45:32] because CNAME and DNAME are both defined such that nothing else is allowed at that name [16:45:44] (~IPv6 addresses as page numbers ... sweet) [16:45:44] AAAA and A aren't like that. [16:46:05] allright, thanks for clarifying [16:46:08] (Slide 6) [16:46:18] the problem then is that there _could_ be a real AAAA or A record [16:46:20] conceptually the translation would create additional AAAAs . next to the ones already there. [16:46:32] benno joins the room [16:46:56] lets ping6 page address. [16:46:57] wouter: right. So the idea is that the dns64 asks for the AAAA first [16:46:58] jiang_xing_feng leaves the room: Replaced by new connection [16:47:05] and when it doesn't get it, then asks for the A [16:47:17] Andrew: with synthesized AAAA RRs, you don't have real AAAA RRs [16:47:20] (Slide 7) [16:47:24] yes, I know [16:47:38] but you can't know that _a priori_ [16:47:40] but A for sure [16:47:40] right, so in DNS the zone could change quickly and an AAAA could be created, a real one, and the target could learn of this AAAA using some other resolver path. [16:47:57] correct, there's a danger of that race [16:48:00] Chris Donley is now known as donley.chris [16:48:06] have to deal with that. [16:48:10] it's never going to be a really clean solution [16:48:10] wouter: I wasn't chasing the race condition yet. [16:48:17] I was chasing the downgrade attack. [16:48:25] I keep thinking that there has to be a better way than DNS64. let apps on v6 only networks continue to see the world as separate address realms. let them build port-specific tunnels to v4-land if they must. [16:48:43] the validator must know the prefix, prefix + A record implies the AAAA, with no room for forgery [16:48:47] weiler: what's the downgrade you think there is? [16:49:05] (Slide 8) [16:49:18] I think actually we should also create an RR (call it TRANSPREFIX) that contains the prefix [16:49:21] one goal of NAT64 and DNS64 is to have some solution that requires no changes to hosts (and hence nothing that goes away if translation goes away for some domain) [16:49:21] it can be signed too [16:49:29] (Slide 9) [16:49:36] bring back A6! [16:49:39] hscholz leaves the room [16:49:55] Call for questions ... [16:50:23] but I agree that an NSEC record is a good one to pass along. The validator should look it up to see if real AAAAs are available. Similar like NSECs that are passed to prove that wildcard synthesis was not performed. [16:50:23] (missed name at mic) ... [16:50:32] and you could hand that back in the answer too, which would mean you'd have the the whole thing if you wanted to validate it [16:50:40] Jinmei Tatuya [16:50:45] sra joins the room [16:50:49] @Dave thx [16:51:08] wouter: yes. This AAAA+A trick is way better than the approach in the existing draft [16:51:13] @dthaler: I understand the goal. but DNS ALGs mess up apps. and you need to give the apps a fighting chance of seeing the world as it is. when you try to fool the apps you create a tussle. I think apps will adapt if you give them a clean, uniform way to do that. [16:51:33] which drops the signature data when the querying node sets DO and not CD [16:52:04] weiler leaves the room [16:52:20] weiler joins the room [16:52:35] Andrew? dropping signature data? sounds bad. [16:52:41] dropping sigs with CD clear is just broken. [16:52:42] @flyin: I don't think anyone's trying to say "translation is nice". It's just "if you're going to do translation, this is the way" [16:52:49] right [16:52:53] flyinhome: the problem is supporting both unmodified IPv4 servers and unmodified IPv6 clients. Then you end up with stuff like DNS64. One solution would be to allow clients to indicate that they don't want fake records or to recognize fake records and ignore them. [16:53:00] donley.chris is now known as Chris Donley [16:53:03] that's why I was trying to get people to read the draft :) [16:53:06] @ajs: part of "the way" has to be giving apps a way to see the untranslated view. [16:53:08] It's a horrible idea [16:53:12] JonathanLennox leaves the room: Replaced by new connection [16:53:12] JonathanLennox joins the room [16:53:18] yes, so in that case you're responding with data that is not what the querier asked for, and you have removed all evidence of why that is [16:53:23] Andrew: The new type for the prefix is only possible for the IPv4 endsite approach. If DNS64 is deployed with IPv4-internet approach, every site has its own prefix. You'd have to learn the prefix from DHCP, maybe. [16:53:27] well, the AAAA-with-A does give apps that way [16:53:49] @ajs: yeah, but it's really ugly. [16:53:59] wouter: with a well known prefix this wouldn't be an issue [16:54:06] wouter: why? the DNS64 box is already changing the answer [16:54:11] so it could insert this record too [16:54:16] Peny joins the room [16:54:41] one thing I've been thinking about is doing something like ULA for the NAT64 prefix, so each operator can have their own prefix but they fall in a larger prefix so they are recognizable where necessary. [16:54:48] once we're into changing DNS for some answers, I don't see any big reason to be conservative about how much we put in [16:54:59] Next up: Randy starts presenting "Port Range" ... slides @ http://www3.ietf.org/proceedings/08nov/slides/behave-4.pdf Listed Drafts: http://tools.ietf.org/html/draft-ymbk-aplusp-01 http://tools.ietf.org/html/draft-bajko-v6ops-port-restricted-ipaddr-assign-02 http://tools.ietf.org/html/draft-boucadair-port-range-00 http://tools.ietf.org/html/draft-despres-sam-01 http://tools.ietf.org/html/draft-boucadair-dhc-port-range-01 [16:55:00] benno leaves the room [16:55:01] So, the proper answer could be a AAAA for old hosts, with the 'proof of the synthesis' in the authority section. NSEC (AAAA type bit) + A record + prefix (if possible) [16:55:16] 'when you are going towards a slippery slope, bring a sled'? [16:55:20] right, that's what I've been thinking, anyway [16:55:26] wouter: are you talking about the DNSSEC case or the general case? [16:55:27] Dave notes that some is out of scope for our group, but ADs have approved us to talk ... [16:55:28] one thing I'd like to do is let apps that are already written to a DS model be able to continue to work in that world with minimal changes - maybe relinking, maybe an extra API call that says "I really do want to see the world as it is". AAAA-with-A raises the bar for those apps. [16:55:34] wouter's summary sounds right to me [16:55:36] well, sure. It all makes me feel very filthy [16:55:55] but if we're going to play in the mud, we might as well get completely dirty [16:56:12] we might as well wear hip boots [16:56:30] (I drive a Jeep when I play in the mud) [16:56:34] flyinhome: they call that a firewall [16:56:42] (Slide 3) [16:57:13] (Slide 4) [16:57:14] I thought it was a condom :) [16:57:14] benno joins the room [16:57:35] flyinhome: I think old apps do not set DO bit for you ... Ones that do will simply either understand translation , or not and then you won't convince that validator any way. [16:57:57] (Slide 5 ... this is my favorite slide from the v4v6CoExist mtg) [16:58:01] Chris Donley is now known as donley.chris [16:58:05] wouter: not sure what you mean by DO bit [16:58:09] (Slide 6) [16:58:26] keith: read 403* [16:58:41] SLide 7 ... 8 ... 9 ... 10 [16:58:51] ... 11 [16:58:53] Rob (re-)wrote them, and I think they're pretty readable. [16:59:24] ((Randy ptg at CPE devices, bottom center'ish of pic) [16:59:59] flyinhome: well I thought you mean DS RR type above. We are cross talking. [17:00:00] ((The shared part was the hexagon to CPE)) [17:00:16] I'm not even considering DNSSEC at this point. [17:00:27] @Suz/suz: why are there two of you? [17:00:28] (Slide 12) [17:00:34] sdstrowes leaves the room [17:00:39] keith: they we're having different discussions. [17:00:53] s/they/then/ [17:01:53] dnssec or no dnssec, you can still tell whether you've got a translated address if you get an A record in your AAAA answer [17:01:54] Suz leaves the room [17:01:58] (Slide 13) [17:02:02] If you are translation-aware, that is [17:02:04] how? [17:02:21] suz leaves the room [17:02:24] If I query for AAAA and my answer comes back with both AAAA and A in the answer section [17:02:33] Suz joins the room [17:02:41] suzsuz joins the room [17:02:45] then I can infer that the AAAA was synthetic [17:02:54] I would put that A record somewhere else than the answer section. But agreed otherwise. [17:02:55] Suz leaves the room [17:03:03] donley.chris is now known as Chris Donley [17:03:10] Randy hands off ... [17:03:14] Who is at Mic? [17:03:15] benno leaves the room [17:03:15] Suz joins the room [17:03:17] @ajs: yeah, provided every translator maps v4 to v6 in a consistent way. the other problem is that it is simply unreasonable to assume that addresses obtained from a DNS query will be used from the same location from which the query was made. [17:03:28] (Slide 16) [17:03:45] flyin: yes, that's my biggest worry now [17:03:48] Who is presenting now? [17:04:04] benno joins the room [17:04:06] @Phil Dunno [17:04:14] but I don't think every translator needs to do it in a consistent way [17:04:15] Teemo [17:04:27] er Teemu Savolainen [17:04:31] Thanks [17:04:42] @ajs: if they don't (and I don't think they can) then there's no reliable way for an app to know which AAAA records are synthesized. [17:05:05] why not? I still have this A record that's coming back with the AAAA I asked for [17:05:14] why is it there? What happened? I shouldn't get it. [17:05:21] (Slide 17 "Physical point to point links...:) [17:05:27] If we define this trick, then that's the reason [17:05:30] the apis don't really expose that to the app. [17:05:39] oh, I get it [17:05:48] given real world experience with some resolvers getting RRs they didn't expect, that open a whole new set of worries. [17:06:23] (Slide 18 - "...over IPv6" [17:06:25] ) [17:06:46] Sam: yeah, I know. But again, we're well into the dirt as soon as we accept that translation is happening [17:06:47] I agree wit wouters last message: put the A RR somewhere else, together with the prefix. [17:06:51] the translated address is valid where that prefix is valid ... [17:06:54] bottom line: I can accept DNS ALGs as a necessary evil in corner cases, but (a) you have to give apps a way to see DNS as it really is and (b) you really want to work hard to minimize exposure of DNS ALGs to those apps that really have to have them. [17:06:55] (Slide 20 - "gtwy mux tables") [17:07:16] (SLide 21) [17:07:23] once we accept the premise that we're going to translate, I expect some things to break [17:07:28] weiler: yes. you would need to signal translation awareness; maybe DO is sufficient (receiver can remove signature if that wasn't what he wanted) [17:08:04] Chris Donley is now known as donley.chris [17:08:06] Keith, for more on the DO bit, see: RFC3225 [17:08:29] ((This case == "Physical pt 2 pt w or w/o IPv6")) [17:08:47] (Now on slide 22) [17:09:28] @flyin: alternative answers that solve those problems will be enthusiastically entertained [17:10:05] benno leaves the room [17:10:17] it looks like it's hard to avoid giving apps yet another API to do DNS lookups. not that this would be a bad thing, getaddrinfo() sucks dead pigs through a straw [17:10:23] Lars at mic [17:10:26] fwiw, rfc3225 = 6 pages to define one bit. [17:10:29] what I said above, does show the way DNS really is, at least in the answer packet. APIs are another problem. [17:10:56] (On slide 23 now ... Pierre presenting) [17:10:57] yeah I think APIs are the problem. I don't doubt that there's a way to hack this at the DNS protocol level. [17:11:10] (Slide 25) [17:11:12] keith: we've been trying to give them a new API. One that exposes dnssec validationr esults. [17:11:14] well, the API would get from getaddrinfo A and AAAA results, yeah? And if it knows the prefix (some other way?) then it is all set. [17:11:48] (Slide 26) [17:11:52] Part of the reason I want to put the prefix in the answer is that I can imagine deployment scenarios where it changes [17:11:53] if it knows translation is happening it wouldn't even need the AAAA :p [17:12:20] good idea, getaddrinfo could return only AAAA (or only A) and prefix some other way. [17:12:35] (Slide 27) [17:12:40] remember that DNS64 is only ONE way to get a translated address of a peer [17:12:57] Jelte: right. The proposal in the existing draft actually handles that case nicely: if DO=1 and CD=1, then you just hand back an unmolested DNS answer from the global DNS [17:13:05] donley.chris is now known as Chris Donley [17:13:09] and assume that the end point will do the translation itself [17:13:11] so there's some interest in e.g. a DHCP option to get the translation prefix [17:13:18] (Slide 28) [17:13:26] for scenarios where the translator is in the initiator's site [17:13:37] so a node doing validation can't reach the world, and has no way to know that? fun. [17:13:38] ideally validator needs secure means of getting translation prefix [17:13:40] DThaler, I simply wanted the DNS64 answer to contain enough info for the packet to pass DNSSEC validation (enhanced with translation knowledge) [17:13:43] i am not entirely comfortable with piggybackriding of awareness signaling [17:13:44] benno joins the room [17:14:05] rvdp joins the room [17:14:06] although there of course is no 'correct' way to do this with do=cd=1 [17:14:20] @wouter: understand, only commenting on the fact that you may have other means to detect what prefix is synthesized, if it helps [17:14:39] (Slide 29 --> 30) [17:14:46] the thing is, you can't decouple the DNS46 case from the DNS64 case. either the app is written to a dual stack model or it isn't. if it's written to a dual stack model, you want to let it keep that view of the world. you don't want a separate solution for DS apps living on a v4-only network and DS apps living on a v6-only network. [17:15:04] (Slide 31) [17:15:07] DS? [17:15:13] DS = dual stack [17:15:48] We could do the same trick the other direction for DNS46 [17:16:03] (Slide 32) [17:16:07] thought synthesis wasn't really necessary in other direction [17:16:07] so the prefix stored in DNS is only useful if DNS64 is deployed far away from the requestor (at the A owner, everyone uses same prefix, it can be signed) [17:16:32] (Slide 33) [17:16:38] wouter: yeah. If the A owner is doing this, I don't think there's any synthesis at all [17:16:49] (Slide 34) [17:16:53] If I'm running a site with a v4-only host [17:17:05] that I personally want to expose to v6-only hosts [17:17:17] yeah you can simply sign the AAAA [17:17:19] another wrinkle is that if you're trying to do DNS queries through a translator, doing source port randomization starts to get really expensive. so I think the translator needs to act as a DNS resolver/proxy, in effect. [17:17:22] I can do some tricks at my own border and publish a AAAA [17:18:04] @flyinhome: yes, that's why the idea is to make this a feature of a resolver [17:18:06] Chris Donley is now known as donley.chris [17:18:06] donley.chris is now known as Chris Donley [17:18:07] I should have said stateful translator in the last statement. [17:18:33] flyinghome: you need to distinguish between dns lookup process and validation [17:18:38] rather than a different piece the way (like the DNS-ALG was described) [17:18:45] (Slide 36) ... presenter = ____? [17:18:51] olaf [17:19:07] Who is the presenter? [17:19:10] @sra: I'm just talking about lookup. validation is definitely part of the problem. [17:19:32] (Slide 37) [17:19:32] Olaf who? [17:19:39] see preso slides :) [17:19:41] Olaf Maennel [17:19:45] benno leaves the room [17:19:46] Thanks [17:19:47] ruri leaves the room [17:19:50] oops? [17:20:43] benno joins the room [17:20:44] (Slide 38) [17:21:41] venaas leaves the room [17:21:42] momose leaves the room [17:21:43] (Slide 39) [17:22:09] (Slide 40) [17:23:05] Chris Donley is now known as donley.chris [17:23:11] Greg at mic [17:23:12] markkao leaves the room [17:23:17] flyinhome leaves the room [17:24:01] flyinhome: yes port randomiztion is hard in this environment, really would like to push iterative dns lookup process to somebody better connected than end user host, but may not trust so want validating stub [17:24:05] Randy @ mic [17:24:39] Andrew Sullivan leaves the room [17:24:41] Next presneter --> Rémi Després [17:24:45] Andrew Sullivan joins the room [17:25:00] (Slide 42) [17:25:26] all these port+address tricks are going to break that [17:25:39] yep [17:25:58] (Slide 44) [17:26:20] right andrew (thats why I said to lars his comment applied to most/all of them) [17:26:37] so without port randomization we kinda need.....dnssec :) [17:26:41] It occurs to me that they're also not going to work with protocols that don't translate ports when NATing (IPSec, SCTP) [17:26:44] benno leaves the room [17:26:51] which this is breaking. [17:26:57] (Slide 45) [17:27:02] some catch, that catch-22 [17:27:08] perhaps jonanthan. (Unless you do SPI-range, etc :) [17:27:09] nat and dns fight it out for last few remaining bits in port space, tickets go on sale tomorow [17:27:23] $20 on NAT. [17:27:25] ... steel-cage death match ... [17:27:35] .... and we might just all end up losing ... [17:27:47] add mud? [17:27:52] mud match! [17:28:06] donley.chris is now known as Chris Donley [17:28:06] Chris Donley is now known as donley.chris [17:28:07] benno joins the room [17:29:47] (Slide 46) [17:31:23] fdupont leaves the room: Computer went to sleep [17:31:27] Andrew Sullivan leaves the room [17:31:33] Andrew Sullivan joins the room [17:31:35] (Slide 47 ... last slide, prepare questions ... although we might just be (read:are) out of time ... ) [17:31:55] rvdp leaves the room [17:32:57] donley.chris leaves the room [17:33:12] marc.blanchet.qc leaves the room [17:33:16] xavi.mila joins the room [17:33:43] weiler leaves the room [17:33:51] wherrin leaves the room [17:34:01] sra leaves the room [17:34:09] benno leaves the room [17:34:15] sm leaves the room [17:34:21] Dave - ~"we can run over, it's just lunch ... questsions apply to some|all proposals" [17:34:55] Alain ... Question 1 of 1000 :) .... voices support for merging efforts, concern over unintended consequences [17:35:54] ((Some disagreement over IPv4 routing table --> IPv6 routing table ... ?)) [17:35:56] Charlie at mic [17:36:30] Clarification of goal - restore end to end transparancy [17:37:15] saumitra.m.das leaves the room [17:37:47] Jon repeating his Jabber concerns @ MIC ... non-port-remapping-when-traversing-NAT protocols ... [17:38:00] jinmei leaves the room [17:38:08] Bruce leaves the room [17:38:22] Cullen Jennings leaves the room [17:38:32] Peny leaves the room [17:38:52] Randy, read S.Bellovins relevant IPSec proposal ... addresses(?) routing table injection concerns [17:39:19] Bob leaves the room [17:39:58] (... and mentions ongoing, relevant collaboration efforts ... signaling, location) [17:40:54] Andrew Sullivan leaves the room [17:40:59] Remi : ~"We are starting to all get along" [17:41:09] (Missed name) at mic ... [17:41:41] JonathanLennox leaves the room: Computer went to sleep [17:41:48] J.Jansen leaves the room [17:42:00] suzsuz leaves the room [17:42:18] And Teemu, and now Dave @ mic [17:44:52] magnus leaves the room [17:44:53] --fin ... [17:44:57] TJ leaves the room [17:45:03] ylee leaves the room [17:45:07] arifumi leaves the room [17:45:12] levigner leaves the room [17:45:16] Is there going to be a session on Friday? [17:45:17] iljitsch leaves the room [17:45:19] hirocomb12 leaves the room [17:45:39] matthijs leaves the room [17:45:43] Lars leaves the room [17:46:16] karen.s.seo leaves the room [17:50:20] simon leaves the room [17:50:29] lebobits leaves the room [17:50:29] lebobits joins the room [17:51:41] lebobits leaves the room [17:52:05] arifumi joins the room [17:52:13] mhp leaves the room [17:52:22] arifumi leaves the room [17:53:26] ogud: Olafur Gudmundsson leaves the room [17:53:41] xavi.mila leaves the room [17:53:55] Jiro Yamaguchi leaves the room [17:55:02] Suz leaves the room: Replaced by new connection [17:55:02] woolf joins the room [17:57:10] woolf leaves the room [18:04:14] BillC leaves the room [18:06:00] DThaler leaves the room [18:06:07] ashida leaves the room [18:07:28] roque@ietf73 leaves the room [18:12:05] fujisaki leaves the room [18:16:28] wouter leaves the room [18:17:04] Dave Winter leaves the room [18:19:38] simon joins the room [18:29:19] flyinhome joins the room [18:31:59] simon leaves the room [18:56:02] maureen.stillman leaves the room [18:58:39] flyinhome leaves the room [18:58:41] jinmei joins the room [18:58:42] bnsmith leaves the room [18:58:46] DThaler joins the room [18:58:50] DThaler leaves the room [18:59:04] jinmei leaves the room [19:02:10] mlm.michael.miller leaves the room [19:06:11] hscholz joins the room [19:07:07] hscholz leaves the room: Replaced by new connection [19:07:45] donley.chris joins the room [19:08:31] donley.chris leaves the room [19:09:04] kanda leaves the room [19:21:08] ashida joins the room [19:42:16] ashida leaves the room [19:49:12] narten leaves the room [21:22:42] fujisaki joins the room [21:29:55] jm leaves the room [23:25:09] fujisaki leaves the room