[00:13:43] akira.nkgw leaves the room [02:04:20] Marc Blanchet leaves the room [02:04:27] magnus leaves the room [04:46:44] Marc Blanchet joins the room [05:39:23] Marc Blanchet leaves the room [05:39:45] Marc Blanchet joins the room [05:46:14] Marc Blanchet leaves the room [05:49:03] Marc Blanchet joins the room [05:53:09] Marc Blanchet leaves the room [05:53:45] Marc Blanchet joins the room [06:15:42] Marc Blanchet leaves the room [06:15:58] Marc Blanchet joins the room [06:19:56] Marc Blanchet leaves the room [06:20:01] Marc Blanchet joins the room [06:23:02] Marc Blanchet leaves the room [06:24:04] Marc Blanchet joins the room [13:47:37] Marc Blanchet leaves the room [13:48:46] Marc Blanchet joins the room [14:44:02] Marc Blanchet leaves the room [15:51:54] Marc Blanchet joins the room [16:08:14] wmhaddad joins the room [16:08:14] wmhaddad leaves the room [18:13:26] Marc Blanchet leaves the room [18:17:03] Marc Blanchet joins the room [18:23:27] Marc Blanchet leaves the room [18:30:08] Marc Blanchet joins the room [18:34:19] chris liljenstolpe joins the room [18:34:22] Marc Blanchet leaves the room [18:37:58] chris liljenstolpe leaves the room [19:55:35] chris liljenstolpe joins the room [19:57:42] Marc Blanchet joins the room [19:58:12] suz joins the room [20:00:07] HUI joins the room [20:01:33] Lars joins the room [20:02:35] Dan Wing joins the room [20:02:49] Gregory [scribe] joins the room [20:02:55] becarpenter joins the room [20:02:56] Gregory scribing [20:03:01] questions on agenda [20:03:02] Andrew joins the room [20:03:07] fred baker coming to present [20:03:08] brian.bnsmith joins the room [20:03:23] IETF-3GPP workshop on IPv6 migration [20:03:25] skudou joins the room [20:03:29] chris liljenstolpe leaves the room [20:03:41] Joint workshop in march [20:03:42] tinnami joins the room [20:03:47] chris liljenstolpe joins the room [20:03:51] Fred one chair, a 3GPP guy the other [20:03:58] look at IPv6 deployment in 3G [20:04:16] esp where net would be IPv6 only, and had to deal with handsets that may or may not be v6 [20:04:27] Looked at scenarios for 6 migration [20:04:41] [someone scribe for a min, pls] [20:04:43] ? [20:05:18] [i'm back] [20:05:23] conclusions: [20:05:24] slide 4 [20:05:46] we have enough transition solt'ns on the table and don't need (much) more [20:06:00] some operators reported running dual stack [20:06:05] some reported v6 only [20:06:09] a few v4 only [20:06:25] gtwy intitiated dual stack light was favored [20:06:40] as was ???? [anyone catch the second one?] [20:07:08] 3GPP wanted our behave docs to go to RFC so they could depend on them [20:07:10] he said 'stateless'. However, he meant 'stateful'. (3gpp seemed not interested in stateless 6/4 translation.) [20:07:11] so they are happy [20:07:45] 3GPP wanted some help with how to share IPv4 addr's [20:07:57] Jari Arkko at mic [20:08:21] they wanted us to focus on STATEFUL v4/v6 xlat, not stateLESS [20:08:24] shinmiyakawa joins the room [20:08:29] Fred agrees now [20:09:00] pls pong if u r on jabber and listening from home (vs here in room) [20:09:01] PING [20:09:10] slides: http://www.ietf.org/proceedings/10mar/slides/behave-18.pdf [20:09:22] NAT64 experiment [20:09:37] linux on old PowerPC [20:09:57] I like the slide numbers [20:10:04] ja [20:10:11] "slide ::2" [20:10:23] this was an experiment here at IETF77 [20:10:50] SSID reads "ietf77-nat64" [20:10:54] 34 people tried it [20:10:59] problems encountered [20:11:29] on snow leopard (Mac OSX.6?), [20:11:49] in v6-only network, CNAME's don't work [20:11:53] so web doesn't work [20:12:09] mic was alexander ??? [20:12:11] arifumi joins the room [20:12:17] Stuart Chesire at mic [20:12:23] from apple [20:12:37] not to do with CNAMEs, it's to do with slow responses [20:12:55] tries a AAAA [20:12:58] Tina TSOU joins the room [20:13:03] if doesn't get it fast enough, tries v4 [20:13:13] if no v4, render cached page [20:13:27] network managers think ur offline [20:13:39] v4 only apps don't work [20:14:09] can't find a v6 enabled XMPP client on Windows [20:14:12] any suggestions? [20:14:25] do u want this experiment in Maastricht [20:14:32] +1 [20:14:32] John Matthews - yes [20:14:39] s/John/Philipp/ [20:14:51] stuart - thx. valuable. Wouldn't have found this timing bug w/o this. [20:15:06] support [20:15:11] would like to see an experiment where turn off all other ssid's in plenary and this is only way [20:15:36] Dave Thaler: yes. Great. if repeat, the dns server was hard coded, and use some auto provision mechanism, pls [20:16:21] Wes George: yes, do it again w/ stronger HW. Think about XP machine that can't do v4 xlat of DNS. even if only one helper addr out there doing recursion [20:16:30] or just fix XP. [20:16:49] thx to noc folks and testers [20:16:51] dudisaki joins the room [20:17:15] anyone remote listeners, pls pong. [20:17:16] PING [20:18:08] pong [20:18:13] pong [20:18:21] marc: thx for the correction [20:18:30] gotcha brian and chris [20:18:49] preso 3 [20:18:57] slides: http://www.ietf.org/proceedings/10mar/slides/behave-14.pdf [20:19:12] compare and integrate approaches that has wide applicability [20:19:21] slide 3 [20:19:26] slide 4 now [20:19:52] slides were presented in the 3GPP / IETF workshop too [20:19:56] slide 5 [20:20:09] 1:1 IVI (2) [20:20:27] slide 6 [20:20:41] from now on s/slideN/sN/ [20:21:05] [that last was a note to remote folks for how I'll represent slides] [20:21:07] s7 [20:21:18] s8 [20:21:33] Marc Blanchet leaves the room [20:22:10] 1:N - way to get more use of IPv4 addrs on the boxes [20:22:15] s9 [20:22:22] form 2 of 1:N [20:22:24] s10 [20:22:29] skipe s11 [20:22:32] s12 now [20:22:40] SIPNAT (1) [20:23:59] HUI leaves the room [20:25:08] s15 [20:26:18] s16 [20:26:25] comparison chart [20:27:15] healthyao2000 joins the room [20:27:54] jacniq joins the room [20:28:15] note the very bottom right cell should be a "no" not a yes [20:28:18] s17 [20:28:22] conclusions [20:28:40] supporting v4 initiated comm's is crucial [20:29:02] integrating a few of these together can provide a comprehensive solution [20:29:17] draft-nat46compare-perkins-01.txt [20:30:03] mic: andrew sullivan [20:30:13] didn't understand interaction of caches [20:30:21] checked draft and not there. [20:30:29] what section? pls explain again now. [20:30:39] Charlie: I'll make sure it's recognizable [20:31:24] SIPNAT associates address by when v6 addr comes in, sees which is closest to v4, then caches that [20:31:31] [i think] [20:31:46] practical for all communications to characterizet he length of the flow [20:31:54] can tell when traffic gone quiescent [20:32:06] then can see a wait time expire, and break association [20:32:23] Rather, SIPNAT has a DNS A query come in. It creates state in the NAT from an IPv4 address to the IPv6 address, and returns 'an IPv4 address' in the A response (the IPv4 address it created for that mapping). [20:32:32] but if then the dns cache, w/o the xlat'er knowing, will still have it [20:33:16] Andrew: this doesn't appear to be true anymore. TTL's seem to be respected [20:33:39] Thaler: 5 yrs ago, did tests and found that some home gateways had a min timeout of 30 seconds [20:34:03] Andrew: if already out there and doing it, then we can't fix them, and disinclined to worry about it [20:34:13] Magnus Westerlund: [20:34:27] re: SIPNAT, how have addressed the issues we brought up before? [20:34:34] Charlie: this is one of the them. [20:35:07] M: already put this solution up before, and also critiqued before. [20:35:19] Charlie: not trying to be a perfectionist here. [20:35:30] Good goal is to make v6 as easy as v4 is [20:35:34] [is that easy?] [20:35:55] don't have to hold v6 to higher standard than v4 standard for home users [20:35:58] Magnus: [20:36:25] agree somewhat. But customers have same probs as NAT-PT with new answer, we are not gaining on it [20:36:47] LAST PRESENTER at mic (name?) [20:37:05] [apparently I don't speak that language] [20:37:09] Simon Perrault [20:37:11] Simon? [20:37:12] merci [20:37:28] Simon Perreault [20:37:28] du rien [20:37:42] oops, yes. I missed an e [20:37:53] would be nice to define one rfc describing one or two mechanisms, so people don't have to read and implement them all [20:37:57] Charlie: agree [20:38:00] new preso [20:38:12] Dan Wing presenting, as co-author [20:38:30] when NAT PT deprecated, there was analysis on all its bad [20:38:37] Agree with the last comments regarding an RFC [20:38:42] this says how we've done so far in trying to recover from it [20:39:14] yes [20:39:24] oh [20:39:33] HUI joins the room [20:39:35] I tell y'all what: [20:39:41] Dapeng Liu joins the room [20:40:03] if you need to be channelled, pls use open and closed square brackets on your comment [20:40:17] otherwise, we'll assume its just chat room talk [20:40:19] k? [20:40:58] writing this to try to explain why this is a better solution over NATPT (so we can get the PLM's to prioritize it and implement) [20:41:02] cheshire joins the room [20:41:09] some probs remain [20:41:12] slide 7 now [20:41:17] HUI leaves the room [20:41:37] NAT44 and 64 still cause the same probs for SIP, IPsec, and AH, and FTP [20:41:47] (though we trying address FTP) [20:41:51] conclusions: [20:41:58] we've improved things, but not perfect [20:42:06] Translation is still harmful [20:42:21] better to run native, and tunnel, but when have to xlat, have to xlat [20:42:31] want this as WG item? [20:44:04] HUI joins the room [20:44:21] phillip matthews agrees [20:44:33] Gregory: spoke w/ IAB hat on [20:44:48] Chair slides: http://tools.ietf.org/agenda/77/slides/behave-13.pdf [20:44:50] thinks it's important to be wg document for 2 reasons: [20:45:11] 1 - status out to rest of community, and that is "better, but not perfect" [20:45:18] shinmiyakawa leaves the room [20:45:22] 2 - NAT's still suck, and need to press to v6 asap [20:45:24] shinmiyakawa joins the room [20:45:32] then Phillip agreed [20:45:39] Thaler now, as chair [20:45:42] new slide deck [20:45:44] slide 6 [20:45:55] (I believe my link above isn't the slide he is showing.) [20:46:30] s7 [20:47:10] Ok, found them: [20:47:11] http://www.ietf.org/proceedings/10mar/slides/behave-17.pdf [20:47:25] (sorry about the delay) [20:48:44] s8 [20:49:03] SCTP NAT, needs new milestone date [20:49:39] Dan: as chair [20:50:15] none of the sctp authors here [20:50:19] push out 6 months? [20:50:24] anyone else want it? [20:50:35] Magnus W (AD) at MIC: [20:50:38] people are working on it [20:50:46] some hope they can complete it reasonably soon [20:51:01] we should continue to try to get this work done [20:51:15] Thaler: demand coming from people not presently in this room. [20:51:19] Magnus: agreed [20:51:30] [not sure the point of thaler's comment, really] [20:51:41] magnus joins the room [20:51:46] Thaler: FTP64 document [20:51:49] suz leaves the room [20:51:50] any comments on this? [20:51:54] Ashida joins the room [20:52:02] phillip: we still need it [20:52:26] suz joins the room [20:52:30] Dan wing: that was due w/ the others in Jan '10. Slipped. thru wglc, but not update in time so not yet progressed [20:52:36] s9 [20:52:40] s10 [20:52:45] tinnami leaves the room [20:53:09] BEHAVE scenario 3 = IPv4 net to IPv6 Internet [20:53:18] is the problem urgent to be solved by the working group [20:53:40] Simon: from slide (which has 7 drafts) we see people want more nat [20:53:53] Thaler: planning to implement, ship, deploy? [20:53:56] Phillip: [20:54:17] 2 related scenarios for v4 to v6 direction, one net to net and one net to Internet [20:54:28] think will become important, but not immediately [20:54:43] tough problem, with one know and ugly solution [20:54:56] hiromi.morita joins the room [20:55:02] think we should simply wait on it and tackle it when becomes more urget [20:55:09] s/urget/urgent/ [20:55:23] if we wait we'll see a constrained pain point that we can focus in on [20:55:26] we should wait [20:55:33] [big line at mic] [20:55:55] Hui Deng: [20:56:44] we have multiple implementations and we find 3 and 4 very valid [20:56:52] also 5th one on slide [20:56:59] still on slide 10 [20:57:33] Thaler: just say if you think the problem is urgent, that's all [20:57:48] Hui: continues commenting on each of the bullets [20:58:00] Dapeng Liu at mic [20:58:20] no objection to IPv4 to IPv6 network/Internet problem [20:58:35] would like to make a unified document to address these 2 scenarios [20:58:42] implementers will want a unified solution [20:58:49] Andrew Sullivan at mic [20:59:00] just cuz can solve problem doesn't mean u should [20:59:01] what deck are we on - I can't find it on the agenda [20:59:16] many of the solutions here create damage elsewhere [20:59:24] may have to say, yes, sucks, sorry [20:59:33] would like to put that on the deliverables [20:59:45] ANYONE KNOW THE SLIDE DECK NAME??? [21:00:31] Jari Arkko: [21:00:53] thx to wg for doing this. This was big task. U followed through and sent IESG big set of important docs [21:00:54] now, [21:00:58] slow down and bit, [21:01:09] don't fill all entries in the matrix, just cuz we could [21:01:17] ikuhei joins the room [21:01:28] attempt to measure what industry really wants/needs based on having the last wave (current wave) of solutions [21:01:33] and ensure need the need stuff [21:01:41] be careful of too much stuff [21:01:49] The slides are part of http://www.ietf.org/proceedings/10mar/slides/behave-13.pdf [21:01:52] from yesterday [21:01:56] they're near the end [21:01:59] slide 10 still [21:02:01] ok, thx [21:02:03] thx dan [21:02:35] the deck being presented today is actually http://www.ietf.org/proceedings/10mar/slides/behave-17.pdf [21:02:40] deliver what 3GPP wants from us, and see how that goes [21:02:51] Name??? [his tag is turned] [21:02:56] tinnami joins the room [21:03:07] name?? [tag covered] [21:03:09] Zhen CAO [21:03:15] now Bo ZHOU [21:03:22] people predict this will happen in future [21:03:28] [showing slide 10 right now. Dave Thaler edited slide 10 to remove 'draft-thaler-6man-unique-v4mapped'] [21:03:28] try to get it solved before emergency [21:03:39] it will become an issue, then will come and complain. [21:03:42] let's do it now [21:03:53] name??? [again, covering slide] [21:03:59] s/slide/tag/ [21:04:06] want us to do all the stuff on the slide [21:04:10] Magnus W: [21:04:27] this scenario hard to solve in a good way, as we know from NAT-PT [21:04:36] some solutions from the sub-deployments [21:04:45] not sure we can do a good enough cost to afford the cost [21:05:14] lars eggert: [21:05:21] engineering means solving practical problems [21:05:37] for lots of the transition and exhaustion problems [21:05:48] +1 [21:05:48] have identified many solutions that can solve, [21:06:02] (with speaker) [21:06:10] and now we need to step back, don't tinker on and on, [21:06:15] and do something with them [21:06:31] if we keep showing more and more scenarios, then the community thinks [21:06:40] "oh, they aren't done yet. I'll hold off" [21:06:41] tinnami leaves the room [21:07:07] we shoudl wait until they come back and say "we tried it, and it has this and that problem" so that we address the real deployment issues. [21:07:20] step bakc and consider what we really want to do [21:07:59] Thaler: when asked in 2009, asked if u already doing this with NAT-PT today? If yes, go do NAT-PT and document the issues and tell us the specific holes [21:08:06] Lars: [21:08:31] important that we let the community find the more constrained problem and let us know rather than try to guess and solve a bunch [21:08:37] Sheng Jian, Huawei [21:08:51] /Jiang [21:09:10] many places where we have a good solution and most agree thi sis a serious sisue we need to solve [21:09:14] worth the wg time [21:09:23] we may not understand the issue deeply enough [21:09:35] but people have already reported some issues after trying [21:10:02] we should not suggest NAT-PT, because it is deprecated. I suggest them try it, but they come back and say, "but it's out dated" [21:10:13] Not enough, need true working solution [21:10:27] Julien Laganier [21:10:29] : [21:10:37] Dapeng Liu leaves the room [21:10:38] very few service avail on v6 net [21:10:47] and very few services that really work on v4 net [21:10:55] don't know why we want to go out and do all this [21:11:09] what we want do now is give hosts v6 addresses and deploy v6 [21:11:17] Dong Zhang == [21:11:39] a lot of these have been identified through testing, so it's time to start addressing them [21:11:48] Philip Matthews == [21:12:04] alcatel lucent [21:12:08] repeating myself [21:12:10] Suz joins the room [21:12:24] these probs going to become important, but we don't understand enough about them yet [21:12:44] as we go forward will find some pieces that are easier, and needed, but we can't see it now [21:13:06] one solution, NAT-PT is to bind the DNS xlat with the Xlat [21:13:45] so it would be good to show how your solution addresses the NAT-PT holes in this way, and therefore how it is better and solves previous gaps [21:13:58] so far the solutions are little variations on NAT-PT, but not really different [21:14:04] Thaler== [21:14:20] arguing for the work within the scope of charter, but w/o milestones [21:14:26] Matthews: == [21:14:30] yes, for now, [21:14:48] all solutions have to go through this process (like UNSAF) and show how they address it [21:15:13] and again years ago, in order to go through sub-IP area, had to show it's answer to foo [21:15:22] and the same now we should do wrt NAT-PT [21:15:33] show how it solves and is worth goinf worward with [21:15:48] Arifumi Matsumoto== [21:15:53] ok if we don't do them all [21:16:05] but some of them we want to know what the IETF thinks about this scenario [21:16:06] - joins the room [21:16:19] people trying to architectu the network [21:16:30] looking for rfc's to help [21:16:49] rjncgh joins the room [21:16:53] ???? didn't get his point. anyone else? [21:17:02] Simon: == [21:17:02] oops [21:17:08] sorry arifumi [21:17:17] i tried, but just didn't get it] [21:17:21] I want to have a document what ietf thinks about this kind of scenario. [21:17:22] simon== [21:17:25] no need to rush [21:17:33] Arifumi: wants IETF to give the opinion about 46 [21:17:46] but is something wg should do [21:17:53] even if ietf decides not to work on it, or defer this activity, it should be documented somewhere. [21:17:59] tony haine (sp?)== [21:18:04] make sense ? [21:18:07] Hain, IIRC [21:18:15] deprecation of nat-pt created a nusence [21:18:20] yes: Tony Hain [21:18:30] public has a problem [21:18:34] needs an answer [21:18:42] [arifumi: Thanks for clarifying your comments] [21:18:49] everyone wants a solution based on their business practice / focus on the net [21:19:12] where u put it, at cpe, at pop, at data center, [21:19:29] I keep hearing people say, "Public has a problem." What problem is that? Where in the world do we have the problem that you need to get from a v4 network to the 12 hosts on the v6-only Internet? [21:19:34] then we can evaluate against a particular location between different solutions [21:19:42] Hui Deng== [21:20:07] still people don't know what the difference is between nat-pt and these solutions [21:20:40] need see that evaluation [21:20:52] Sheng Jiang, Huawei == [21:21:06] stop talking about nat-pt because its not an active standard [21:21:27] customer comes by and wants something to handle this scenario, but don't want natpt because it's not standard [21:21:28] Hui: let me try to add, draft 3 and 4 is not linked to NATPT [21:21:30] miaofuyou joins the room [21:21:33] rjncgh leaves the room [21:21:37] thaler== Summary: [21:21:45] couple - important [21:21:56] He seems to be missing the point of the NAT-PT comparison, which is that if we just re-create all the horror of NAT-PT with a new specification, we might as well just ship the already-built crappy technology [21:22:04] some - spend time on reporting on real problems from real deployments [21:22:22] some suggestions from authors of interent drafts to say how the probs with natpt are or aren't addressedin their solutions [21:22:46] tinnami joins the room [21:22:54] natpt is deprecated [21:23:12] and other things are not and we can't spend time on something deprectated [21:23:21] suz leaves the room [21:23:24] will take under consideration and talk with the ADs. [21:23:35] slide 11 now [21:24:03] BEHAVE Scenario 4 = [21:24:08] suz joins the room [21:24:13] suz leaves the room [21:24:14] IPv4 Internet to an IPv6 network [21:24:22] list of 6 drafts [21:24:24] suz joins the room [21:24:27] 2 perkins [21:24:30] suz leaves the room [21:24:32] 3 xli [21:24:36] 1 wing [21:24:45] (those were numbers of drafts) [21:25:11] Brian Carpenter== [21:25:15] suz joins the room [21:25:32] Not necessarily possible to do IPv4 publically in the near future. [21:25:49] content provider and sp's should provide dual stack, full stop [21:25:57] marc blanchet == [21:26:07] Until you exhaust your allotment [21:26:16] this is not constrained to v6 only [21:26:30] philip == [21:26:54] agree w/ brian, if you are initiating from the v4 side, then u should be dual stack [21:27:08] bob hinden== [21:27:20] agree. I think ISPs can do dual stack well [21:27:27] Xing Li == [21:27:38] this problem is easier than the one we did before [21:27:51] easier for SP to do dual stack too [21:27:55] Wes George == [21:28:12] محسن joins the room [21:28:22] clarify pls, does this include IPv4 Internet ONLY, or IPv4 private IPs too on the left side [21:28:39] I agree that the device u r trying to connect to should be dual stack [21:29:00] but many scenarios where can't assume the initiator will be dual stack [21:29:04] for the mic: [21:29:21] have 40 - 50 M devices that will NOT be capable of doing dual stack [21:29:33] Joseph Snyder == [21:29:49] the subscribers from Verizon aren't going to be dual stack [21:29:58] Go CHRIS [21:30:01] I can point to trend lines in our network where I will exhaust my v4 allotment and driving me to something like nat444 in a timeframe where I now have to have OSS/BSS solutions being deployed to intersect that date. It's no longer in theory [21:30:04] I'll channel for u [21:30:07] got it [21:30:08] thx [21:30:14] Chairs== [21:30:25] this is NOT that solution (@ Snyder) [21:30:50] this is for the v6 network, do I need to have access for incoming connections FROM a public v4 addr [21:30:55] Mark Andrews == [21:31:05] u need a v4 addrss somewhere on yoru net, [21:31:17] somewhere, so you can get a tunnel back into ur network [21:31:32] Chairs== [21:31:36] that's what this is, yes [21:31:41] Mark == [21:31:57] when r people not going to be able to get a v4 address, then we need this done 2 yrs earlier [21:32:06] Simon == [21:32:08] What's simon's name? small??? [21:32:17] cloud services [21:32:23] .. [21:32:32] Simon Perrault [21:32:36] this more important than the previous one, yes [21:33:06] showing slide 7 [21:33:09] Perreault, actually. [21:33:23] thanks, I heard wrong [21:33:59] Xing Li== [21:34:11] this can encourage the transistion from v4 to v6, [21:34:34] Dapeng Liu joins the room [21:34:42] Nobody is going to implement this in order to encourage v6 deployment. That will cost money. [21:34:44] u build this, and then your services and apps can be reached from v6 hosts, with out having to redo your content and apps [21:34:52] SOMEBODY == [21:34:54] agree [21:35:00] Marc Blanchet joins the room [21:35:12]