[06:27:07] tatsuji joins the room [06:27:36] tatsuji leaves the room [06:34:26] Joel Jaeggli joins the room [06:41:59] jlcJohn joins the room [06:47:09] leo joins the room [06:48:23] Dmitry Anipko joins the room [06:49:38] Tony joins the room [06:49:38] echo reply [06:50:17] we're here [06:54:31] behcet.sarikaya joins the room [06:55:40] John Dong joins the room [06:57:29] satoru.matsushima joins the room [06:59:02] Arifumi joins the room [06:59:29] rbonica joins the room [06:59:54] about to begin [07:00:31] Jacky Yao (Health Yao) joins the room [07:00:34] jhf joins the room [07:00:35] coopdanger joins the room [07:01:53] Patrik Halfar joins the room [07:02:36] swb joins the room [07:02:39] agenda bashing [07:02:50] tatsuji joins the room [07:03:02] tore@jabber.org joins the room [07:03:08] SwedeMike joins the room [07:03:27] going to walk through with the wg comments that came from the plenary [07:03:45] we have erred on the side of inclusion that has not worked in some ways [07:04:02] have had to discuss with authors what our charter is [07:04:30] we're also bothered by the amount of time that we can devote to each presentation [07:04:46] slh joins the room [07:04:53] didn't allow new items unless they had already developed traction on the list [07:05:30] we have three talks this morning that how now draft behind them at all [07:06:01] jpdionne joins the room [07:06:07] two effects, if you file a draft 5 second before the cutoff it may not have time to develop traction on this list [07:06:30] hum [07:06:40] mostly positive [07:07:19] teemu savoleinen [07:07:37] Patrik Halfar has set the subject to: v6ops -- IETF80 [07:07:38] share expereinces with host behavior [07:08:06] Anybody going to start webex? [07:08:25] Janos Mohacsi joins the room [07:08:26] oops [07:09:04] the laptop that's presenting is the one we'd do that on [07:09:17] slide 3 [07:09:24] results [07:10:39] are these slides somewhere? [07:10:43] Shane Amante joins the room [07:10:48] http://tools.ietf.org/wg/v6ops/agenda [07:11:27] http://tools.ietf.org/agenda/80/slides/v6ops-12.pdf [07:11:40] i had scrolled down to the agenda and the first 3 don't have links [07:11:45] slide brwosers learning something [07:12:12] when the network was broken all browsers took 21 seconds to time out [07:12:22] use of comon api [07:13:05] Answers: fix IPv6 network [07:13:34] sandoche joins the room [07:13:45] yah the goal of the exercise was to characterize the behavior [07:14:38] Suzanne joins the room [07:14:40] simon talking example of bad i6p behabior due to rogue ras [07:14:56] tetsuya.mrk@jabber.jp joins the room [07:15:24] with not counter-measures there would have been 250,000 of these rogue ras [07:15:31] mostly related to connection sharing [07:15:48] sample period of 376 days [07:16:33] mark t - do you plan to keep countermeasures in place? [07:16:43] comment: with the most recent proposal RFC 3484 bis, 6to4 would be deprioritized compared to IPv4, so if most rogue RAs are 6to4, no other solution may be needed? [07:16:48] Bjoern A. Zeeb joins the room [07:17:17] Simon Leinen joins the room [07:17:38] fdupont joins the room [07:17:48] Tomas Podermanski joins the room [07:17:51] Bernie joins the room [07:18:10] danwing joins the room [07:18:11] simon - not quite that simple [07:18:43] happy eyeballs implementation report [07:19:00] mg joins the room [07:19:03] removing rogue RA is something any service provider should do, it's basic stuff. Don't let customers talk L2 to each other. [07:19:32] Ole Troan joins the room [07:19:36] implmentation of happyballs in draft in erlang [07:19:40] Which presentation are we at the moment? [07:19:52] http://tools.ietf.org/agenda/80/slides/v6ops-17.pdf [07:20:18] findingd global p mechanism is broken [07:20:18] t.k joins the room [07:20:33] sandoche leaves the room [07:20:39] dominated by simple stack ipv4 [07:20:55] ipv6 will never be used with dual stack servers [07:20:58] t.k leaves the room [07:21:03] t.k joins the room [07:21:33] thanks [07:21:37] for today ipv6 would be disavantaged by happy eyeballs [07:21:47] rbonica leaves the room [07:21:58] solutions [07:22:08] only update p for dual stack hosts [07:22:31] do it asyncronously so that you can wait for it to finish [07:22:40] use only per destination p [07:22:48] or do away with p [07:23:04] another finding - do away with useless delays [07:23:57] spec says wait lookup collect but if lookup for ipvx returns no result ipvy should start connecting immmediately [07:24:06] questions to happy-eyeballs: what about DNS based round-round load-balancing? It is very wudely used [07:24:40] we'd like to put this impletementation into an http proxy so that we can use it with convention values [07:25:19] question from janos [07:25:31] dudisaki joins the room [07:25:48] it would break the round robin load balancing. [07:25:49] ywang830 joins the room [07:26:11] Happy Eyeballs works fine with DNS load balancing. [07:26:13] andri yourshecko - we do parallel attempts with different address families [07:27:39] jan ker - didn't head that very clearly - I don't disagree - why is dns spamming considered out of scope. think it's out of scope. [07:27:46] no api's? [07:27:52] fred - we do do apis [07:27:59] jeff huston preso [07:28:20] http://tools.ietf.org/agenda/80/slides/v6ops-1.pdf [07:28:28] Agree with Fred: We should work on API to help proper behaviour - like happy-eyeball [07:28:32] someone is breathing into a mic... it's not too annoying, but... [07:28:35] look at the problem from the side of the server [07:28:41] sorry [07:28:52] Dave Thaler joins the room [07:29:21] g.e.montenegro joins the room [07:29:45] when you look at the world from the vantage point of how much does a server see you see a huge amount of capability, new experiment every time it runs [07:30:06] ywang830 leaves the room [07:30:12] v6only test is using ipv6 lteral e.g. no dns [07:30:16] jpc joins the room [07:30:44] full blown tcpdump along with typical server logs [07:31:07] ywang830 joins the room [07:31:16] dual stack failures are interesting [07:32:09] the internet is remarking hetrogenious not homogenious, apnic site users about 5% will prefer v6 [07:32:31] on a more popular site it's more like .02 % [07:32:43] ywang830 leaves the room [07:32:49] v6only is 4% [07:33:20] why are there 20x more folks that could use v6 but don't use it [07:33:35] 6to4 is enabled by default if you have a GUA on windows vista/7 [07:33:47] gl joins the room [07:33:50] but they don't prefer it [07:33:57] ywang830 joins the room [07:34:05] if you perfer v6 in autotunneling things get pretty rough [07:34:54] folk coming in on v6 unicast seem to do so at about the same rate as ipv4 [07:35:04] narten joins the room [07:35:16] the penatly for 6to4 is around 1.2 seconds [07:35:40] teredo setup is at least 1rtt [07:36:26] behcet.sarikaya leaves the room [07:36:28] Bruno STEVANT joins the room [07:36:35] tried to mitigate 6to4 but putting v6 relay in the server [07:36:38] ywang830 leaves the room [07:36:45] behcet.sarikaya joins the room [07:37:01] 6to4 has almost no setup time penalty [07:38:18] measure tcp-3way tunnel setup penalty at 150ms median peak [07:38:38] rjs joins the room [07:39:05] if you think that's bad lets look at teredo [07:39:34] if the only interface you have is teredo it will not retrieve quad a [07:39:51] only exercised for literal [07:40:12] 30% of clients can pull down the object using terredo [07:40:28] imense capacity for v6 [07:40:56] distribution of setup time, seems to take around 2/3 of a second to setup [07:40:58] ywang830 joins the room [07:41:12] peak at 2 seconds and 3 seonsd [07:41:27] tunnel rtt cost is about 300ms [07:41:41] some clients get away with almost no added cost [07:41:54] if you're on unicast v6 be happy and smile [07:42:06] if you're on tunneled v6 turn it off it's crap [07:42:31] dual stack failure (.6%) [07:42:41] we're not sure why [07:43:16] number is high but unreliable. [07:43:24] which is the current slide? [07:43:26] where are we ? [07:43:29] :) [07:43:30] how many folk can send me a syn but not an ack [07:43:53] connection failure is the title of the slide [07:43:57] ("how many naked SYNners?") [07:43:59] I'd say 36 [07:44:20] 35-37 is connection failue, so that is good enough [07:44:26] v6 connections work better at home. [07:45:06] failure rates for unicast v6 are 2-4% [07:45:19] NAKed SYN [07:45:52] teredo connection - how many folks send me the icmp packet and nothing else [07:45:56] I like the humor O:) [07:46:07] tetsuya.mrk@jabber.jp leaves the room [07:46:14] terredo failures = 25% [07:46:18] er 35% [07:46:25] what slide are we at? I can't find that slide... [07:46:32] one third of all teredo connections fail [07:46:34] 40 [07:46:46] 40 is a conclusion slide in my slide set? [07:47:00] 12-24% of 6to4 failure due to protocol 42 filtering [07:47:21] 38% of teredo fail [07:47:22] get v6ops-22.ppt [07:47:25] Comment: (Tore Anderson) Regarding 6to4 relay congestion being unlikely due to the low levels of 6to4 traffic: I understand that most of the relayed 6to4 traffic is actually BitTorrent traffic that is rendezvousing with Teredo. This is of course invisible from the web server vantage point, but it might anyway cause congestion on the same 6to4 (and Teredo) relays that also handle the web server traffic that are actually observed in the experiments [07:47:36] due to icmp filtering [07:48:14] you also don't like outgoing udp ice/stun/turn probably don't work either [07:48:33] (that was for the mic later) [07:49:07] Tore: We have more than 100 Mb/s on our 6to4 relay right now; looks like most of this is indeed BitTorrent. [07:49:13] if you want to run v6 tunneling today don't [07:49:35] help us, see url labs.apnic.net [07:49:55] simon l - thanks for imperical work [07:50:10] p2p works much better than non-native to native (which is actually related to why Windows doesn't do AAAA queries if it just has Teredo, as Fred said... by design) [07:50:28] when I looked at graph with rtt cost wondering if you cut at zero [07:50:40] jeff small numbers on the other side [07:50:46] (p2p = 6to4-to-6to4 or Teredo-to-teredo) [07:51:07] simon l - should it be depricated [07:51:13] jeff - killed [07:51:30] simon l would it be better to turn it off [07:51:47] igor - killing relay isn't effective kill os. [07:52:10] igor g - do they have unique hosts names [07:52:26] jeff - there is not ability to cache the dns [07:52:45] (geoff) [07:52:47] igor - counting dns failure rate is atrocious [07:53:29] geoff - this is tcp failure counting so the dns failures don't show up [07:53:57] igor - thanks this awesome [07:54:39] rajev - if we look at the data from the weekend do we draw different concusions about tunnel performance. [07:55:10] geoff we don't consider 12% failure as drammatically better than 20% it's just bad. [07:56:26] lorenzo c - the results match what we see, we've been looking at the network, we have certain large isps with peaks around 3-4% [07:56:27] g.e.montenegro leaves the room [07:57:00] geoff would that we had more data, we seem to have tiny aperatures. badness clumps [07:57:08] lorenzo - we have more data [07:57:09] carolin joins the room [07:57:24] the time for automatic tunneling has really passed [07:57:38] some operating systems and home routers should turn it on by default [07:58:11] we'll discuss this later but I think that a statement from this body supported by this data would be helpful. [07:58:16] comment to Lorentzo: connection from automatic tunneling to native IPv6 is not preferred by default per RFC 3484 [07:58:37] geoff we can't hop over brokeness in the isps netowrk. [07:58:52] lorenzo - don't try and make pigs fly [07:59:36] it is insane to insist on deploying a transition technology half-ass, then blame it for failures.. [07:59:54] mark t - qualify statement, in a controlled environment we can hop over v4 netowrks [08:00:15] bless joins the room [08:00:38] if the content providers deployed 6to4 on their end the path would be exactly the same as IPv4 door-to-door [08:01:21] message for providers: control the path - probably help your 6to4 and teredo users! [08:01:21] ywang830 leaves the room [08:01:24] adrew [08:01:27] http://tools.ietf.org/agenda/80/slides/v6ops-21.pptx [08:01:29] ywang830 joins the room [08:01:43] slide 4 [08:01:52] changes slide 5 [08:02:10] +srv records sections [08:02:11] jham joins the room [08:02:11] hsalgado joins the room [08:02:16] +mif reference [08:02:25] + debug strawman [08:03:12] becarpenter joins the room [08:03:18] todo slide [08:03:25] need more implmentations [08:03:32] hysterisis problem [08:03:52] need pluggable name based connect api [08:04:05] write seperate draft for that? where to take it [08:04:44] comments [08:05:00] fred - int agrea? [08:05:05] jari a - yes [08:05:32] hsalgado leaves the room [08:06:18] dave thaler - microsofts pm's went to content providers level of concern about multiple simulatnious connections and pontetially large number of resets [08:06:34] major agreement that problem needs to be solved. [08:06:52] can we do a better job about which one to try first [08:07:13] maybe p could actually be fairly large if you had a good guess [08:07:32] mark andrews - happy eyeballs is a really generic problem with multihomed machines [08:07:34] Agree with Dave Thaler: Some providers blacklisting clients with high syn and rst rates [08:07:47] um addressing that problem might actually a better problem [08:08:14] fred - some sort of memory about specifc addresses or prefixes [08:08:49] I actually think you should do this for source × destination [08:09:49] igor - I'm going to disagree with that sorry, as on operator I'll take the pain from happy eyeballs over the pain from not haivng happy eyeballs [08:10:26] per prefix or per destination memory plus address family memory might mollify providers [08:10:31] g.e.montenegro joins the room [08:11:01] adrew - feedback needs to be incorporated into the list [08:11:12] Agree with Simon Leinen. That is the correct solution as I have written earlier on v6ops mailing lists: RFC 3484(bis) can be used as a hint what makes sense and what is not. [08:11:14] http://tools.ietf.org/html/draft-ietf-v6ops-multihoming-without-nat66 [08:11:55] 1wglc ended - name cahnges [08:12:45] @simon: be careful, you need to it converge fast. starting with 0 knowledge for every s*d would be bad. That was my point about sharing knowledge so you guess right the first time almost always [08:12:46] I disagree with Thaler, because a Happy Eyeballs user will _not_ be sending a lot of SYNs and RSTs. "P" prevents them from doing that. It's only the first connection that would be in parallel. Subsequent connections will continue to trend towards IPv6 (if it's working) or towards IPv4 (if it's working). And content providers have one, and only one primary job in life: deliver content. Happy Eyeballs is aligned with that goal. Which Igor re-inforced at the mic. [08:12:58] definition of multihoming - intended to address small sites and preserve end to end transparency [08:13:05] rvdp joins the room [08:13:06] @dan: I'm just channeling what others said [08:13:11] understood. [08:13:23] expanded security considerations section [08:13:26] it's the first connection from every client to every destination [08:13:38] I perhaps should have said "the content providers quoted by Thaler are confused, in that they did not understand how "P" in the draft works." [08:13:39] next steps? [08:13:48] fred - net feedback [08:14:00] thats why I explicitly stated I didn't know for sure whether the feedback still applied to the current version [08:14:36] http://tools.ietf.org/agenda/80/slides/v6ops-4.ppt [08:14:50] fred t - tunnel looping [08:14:59] problem - [08:16:13] mitigations - [08:16:57] don't use onlink prefixes at all [08:18:16] @Thaler: one extra connection, of the ~40 they are receiving, is going to cause them harm? I am /very/ doubtful. [08:18:27] @Thaler: Happy Eyeballs has always had "P". [08:20:27] on the previous slide, I don't understand why an ISP would ever want ISATAP [08:20:50] @dan: it's possible they were confused, I can't say as I wasn't the one who talked to them :0 [08:20:52] :) [08:20:53] requirement [08:20:56] s [08:21:01] swb leaves the room: Replaced by new connection. [08:21:03] swb joins the room [08:21:19] for zeroconf dymaic routing [08:22:38] we've come up with proposal that meets these requirements - out of scope for this group. [08:22:54] fred tunnel loops draft [08:23:18] ron asked us to do parallel last call on ietf vs ietf last call [08:23:36] s/ietf/wg [08:24:33] coopdanger leaves the room [08:24:45] adrew yuchenko - well keep decrimenting the hopcount if it gets below a certain threshold [08:25:21] http://tools.ietf.org/html/draft-korhonen-v6ops-3gpp-eps [08:26:10] j korhonen - [08:26:18] updates since ietf 79 [08:26:36] making hte draft opinion neutral [08:26:54] operational aspects of v6only networks [08:27:08] ipv6 address configuration clarifications [08:27:51] ipv6 roaming considerations [08:28:01] inter-rat handovers [08:29:36] Problem with v6 in the mobile world is that implementations are way behind the 3gpp releases. [08:29:46] just a bit [08:29:55] Which are themselves way behind IETF specs [08:30:17] well, yes, 2-3 years, but that's a long time [08:30:56] coopdanger joins the room [08:31:05] needs 3316 recomendations [08:31:14] who is gl? [08:31:29] tina tsou [08:31:35] about epc [08:31:57] is it addressed here [08:32:19] Guillaume Leclanche, I'm not in prague, i'm implementing v6 in mobile for swisscom and just following what's happening today [08:32:46] Merci Guillaume [08:33:32] fred - calll the question [08:33:38] is this a workign group doc? [08:33:49] are they done? [08:34:04] coopdanger leaves the room [08:34:43] hum 1st was stronger [08:35:10] ꈲ joins the room [08:35:17] someone is breathing into the mic again [08:35:29] wglc hum in favor no noted opposition [08:35:30] Chris Griffiths joins the room [08:35:31] support 3gpp work as v6ops wg document [08:35:50] http://tools.ietf.org/html/draft-chen-v6ops-nat64-cpe [08:35:59] gang chen [08:36:12] Tomas Podermanski leaves the room [08:36:19] use cases - [08:37:40] Ole Troan leaves the room [08:37:51] requirements - [08:38:11] changes since 79 [08:39:13] pcp upnp and nant-pmp are recomended with nat64cpe [08:40:54] fred - we'd work on the requirements, the solution would be behave [08:41:22] chen - we're geenrateing requirepments [08:41:55] fred - we'll have to take t h adoption question to the list. [08:42:04] rjs leaves the room [08:42:14] rjs joins the room [08:42:19] g.e.montenegro leaves the room [08:42:27] dan wing - first half is a draft for v6ops, second half is a scenario in behave [08:42:38] fred - thanks [08:42:51] (which isn't there yet) [08:43:34] fred - the everything meats everything work to where? [08:43:59] John Dong leaves the room [08:43:59] unkown speaker [08:44:35] http://tools.ietf.org/agenda/80/slides/v6ops-18.ppt [08:44:35] Hui Deng [08:44:40] thanks [08:44:42] was the person at the mic [08:44:46] got it [08:45:07] kathy [08:45:40] test environment [08:46:17] danwing leaves the room [08:47:56] danwing joins the room [08:49:18] Tomas Podermanski joins the room [08:52:51] Couldn't someone build generic inverse (and back forward) mapping for ALL IPv4 addresses, so that µTorrent could use hostnames instead of IPv4 address literals? [08:52:52] it should be more specific in VPN solutions. [08:53:36] dan wing - thanks for reasearch it's easy to draw the wrong conclusion everyone has breathed air has died [08:53:49] some other exmaples are caused by ipv4 address sharing [08:54:30] I realize this is the first generation of this anayliss in behave we have cgnat in nat444 analysis [08:54:33] swb leaves the room: Disconnected. [08:55:09] we need to uplevel this to the spefic problems in nat65 that make this harder and or which can be addressed [08:55:17] thanks [08:55:53] fred - readback testing on the algrythm on that behave has just produced [08:56:08] needs to be traced back to a root cause [08:56:25] where can we help [08:56:40] last two lines from dan [08:57:00] jari arko - thank you this is important work [08:57:30] Hugo Salgado joins the room [08:58:24] rjs leaves the room [08:58:36] also want to emphasis on finding the root cause - different failure modes, some are in application there are some problems with the content, third class where there's something wrong with the nat64 or natpt device [08:58:36] Simon Perreault joins the room [08:59:01] rjs joins the room [08:59:05] rjs leaves the room [08:59:16] FYI: We're running a NAT64 experiment right now (SSID: ietf-nat64) with a survey to gather your experiences. Please try it. [08:59:53] hui deng - we do need to analyis the issues that those applciations really have [09:00:04] jari - it's going ot be a long task [09:00:16] there's clearly far more than you've done here. [09:00:50] two comments - mainly affected by the p2p2 applications [09:01:04] who supports nat64 [09:01:32] couldn't find it on the market [09:01:37] tina [09:02:33] Jacky Yao (Health Yao) leaves the room [09:02:47] jari - there are vendors with this product already so do nat64 testing [09:02:50] to testers:: [09:02:52] http://ecdysis.viagenie.ca/ [09:03:10] http://tools.ietf.org/html/draft-jjmb-v6ops-comcast-ipv6-experiences [09:03:21] Bruno STEVANT leaves the room [09:03:31] slides didn't go up yet [09:04:07] trials in jan 2010 [09:05:21] making determination of need based on volume [09:05:23] Jacky Yao (Health Yao) joins the room [09:05:45] deployed 6rdbr [09:05:56] performance varied based on proxmity [09:06:21] proximity quntity placement is important [09:06:28] geoloication is impacted [09:06:45] 6rd ce limited support [09:07:09] manual configured every cpe [09:07:14] needs support [09:07:35] dhcp support trequired for large scale support [09:07:36] i'm experiencing tons of IPv6 packet loss to comcast6.net (both addresses). is it just me? [09:07:47] native dual stack [09:08:12] deployed l2 services to trial subscribers [09:08:35] residential subscriber trials are geographically limited [09:08:42] minor bumps in the road [09:08:56] make sure the rest of our access netowrk supports v6 [09:09:21] just turn it on is not realistic [09:09:25] hmmm... same for ipv4 [09:09:34] incremental approach to enably and pleased with our approach [09:09:40] back office is a critical part [09:10:07] started work on 4-5 years ago [09:10:35] outstanding issues with dhcpv6 reverse dns [09:10:57] enabled some content [09:11:11] proxies some content to cdn [09:11:24] next steps [09:11:27] Tomas Podermanski leaves the room [09:13:43] wes george - 6to4 world ipv6 day 6to4 relays what will happen, we'll shut it off or there are some relay out there that make it ok [09:13:54] so wes a couple points on that from [09:14:23] jmbb - it's gona go somehwere [09:14:48] er jjmb [09:15:10] fred could nullroute the anycast address [09:15:26] wes - assuming the client behaves well in that case [09:15:47] trying to run functioan lsuck less 6to4 relays [09:15:48] narellec joins the room [09:16:00] swb joins the room [09:16:07] at one point saw a 5x increase [09:16:13] jjmb [09:16:38] fred t - isatap [09:17:03] jpdionne leaves the room [09:17:15] jjmb we use it internally, our focus is on the native aspect. [09:17:33] dave thaler - 6to4 trials [09:18:02] did you run into issues casued by broken relays [09:18:30] Simon Leinen leaves the room [09:18:55] return path is still an issue [09:20:03] dhcpv4 of the want side [09:20:13] cheng asked question [09:20:27] wna side provising of the dhcpv4 [09:20:51] ipv4 address changing and renumbering of v6 home side. [09:21:21] all the cpes have dynamic addresses [09:21:47] voichtek [09:22:14] http://tools.ietf.org/agenda/80/slides/v6ops-8.pptx [09:22:33] tim chown [09:22:56] world ipv6 day call to arms [09:23:03] Jacky Yao (Health Yao) leaves the room [09:23:10] aims - [09:23:57] issues - unamanged tunnels [09:24:02] pmtu [09:24:07] connection timeouts [09:24:25] fdupont leaves the room: Computer went to sleep [09:24:55] danwing leaves the room [09:24:57] danwing joins the room [09:27:03] next-steps [09:27:09] I support Tim's draft [09:27:20] do we influence the experiment [09:27:23] slh leaves the room [09:27:33] ꈲ leaves the room [09:27:35] mark we should hardn this in advance of june [09:27:46] I want ot hear from eople about influencing it [09:28:38] I'm not sure that deploying local 6to4 relays is influencing the experiment [09:28:53] unknown [09:28:58] wes - george [09:29:11] we need to stop looking at htis as an experiment [09:29:21] it's testing for [rimetime [09:29:23] about 6to4: discourage for this experiment - 6to4 should be used as a interim solution - not what IPv6 should be used. [09:29:31] not influencing it is wrong headed [09:29:44] if we do this right people shouldn't notice [09:30:32] tim - change [09:30:46] fred - value is two fold y2k equivalent [09:30:51] it's also marketing [09:30:59] behcet.sarikaya leaves the room [09:31:17] dave thaler yes we want to influence the experiment [09:31:21] Shane Amante leaves the room [09:32:25] Wes joins the room [09:32:53] igor - I hate to say this but the expierment is to break the users and see how many get fixed [09:33:08] they meaningfully data is what happens [09:33:23] swb leaves the room: Disconnected. [09:33:59] lorenzo - lets not try to demonstrate that we can do this well but rather recognize what problems we have and make them better [09:34:04] carolin leaves the room [09:34:04] Bernie leaves the room [09:34:31] somebody may decide to leave this stuff on [09:34:50] igor what ever hacks you deploy please leave them in place [09:35:15] in case they have proven to work well [09:35:20] mark h - deployment on v6 day as though it were more than one day capture that as prime directive [09:35:22] jpdionne joins the room [09:35:32] danwing leaves the room [09:35:34] jpdionne leaves the room [09:36:06] jan - do we want to uncover real issues [09:36:15] igor - we want the real issues [09:36:21] jpcm joins the room [09:36:31] mark said what I meant... we want people to think and do what they would do if this were longer term, and learn what happens and get experience [09:36:39] jham leaves the room [09:36:43] lorenzo -more lreay won't help or hinder them [09:36:49] jham joins the room [09:36:50] and if you call that influencing the experiment, then we should. [09:37:21] roman a - we discourage it in the end hosts [09:37:36] ipv6 literals [09:38:04] jpc leaves the room [09:38:21] narten leaves the room [09:38:21] jhf leaves the room [09:38:24] fred tempin - pmtud admin config [09:38:30] comment: if you can provide IPv6 only with 6to4, then deploy 6to4 relay for your users - buy only for [09:38:32] broken pmtud [09:38:34] simon.leinen joins the room [09:38:36] exists [09:38:36] Chris Griffiths leaves the room [09:38:39] done [09:38:42] dudisaki leaves the room [09:38:45] picking up again at 5:40 [09:38:46] Simon Perreault leaves the room [09:38:49] Joel Jaeggli leaves the room [09:38:57] satoru.matsushima leaves the room [09:39:04] Janos Mohacsi leaves the room [09:39:13] tatsuji leaves the room [09:39:21] jpcm leaves the room [09:39:21] jpc joins the room [09:39:34] Hugo Salgado leaves the room [09:39:51] rvdp leaves the room [09:40:00] jham leaves the room [09:40:10] ywang830 leaves the room [09:40:16] Patrik Halfar leaves the room [09:40:22] narellec leaves the room [09:40:34] Suzanne leaves the room [09:40:46] jpc leaves the room [09:41:04] t.k leaves the room [09:42:28] simon.leinen leaves the room [09:44:32] leo leaves the room [09:44:50] mg leaves the room [09:45:04] Dave Thaler leaves the room [09:45:04] Dave Thaler joins the room [09:45:30] Joel Jaeggli joins the room [09:48:57] Dave Thaler leaves the room [09:49:27] Tony leaves the room [09:50:04] Wes leaves the room [09:51:32] Arifumi leaves the room [09:52:23] Dmitry Anipko leaves the room [09:56:34] becarpenter leaves the room [10:06:07] bless leaves the room [10:11:04] Bjoern A. Zeeb leaves the room [10:11:05] Bjoern A. Zeeb joins the room [10:17:29] Bjoern A. Zeeb leaves the room [10:38:38] t.k joins the room [10:51:41] Joel Jaeggli leaves the room [10:51:55] narten joins the room [10:55:52] Joel Jaeggli joins the room [10:56:01] ꈲ joins the room [10:57:48] Shane Amante joins the room [10:58:10] Shane Amante leaves the room [11:00:20] t.k leaves the room [11:01:25] ꈲ leaves the room [11:03:58] narten leaves the room [11:05:06] swb joins the room [11:08:00] Chris Griffiths joins the room [11:23:44] Bernie joins the room [11:34:01] Chris Griffiths leaves the room [11:39:22] becarpenter joins the room [11:41:59] gl leaves the room: I'm happy Miranda IM user. Get it at http://miranda-im.org/. [11:55:05] Bernie leaves the room [12:04:56] swb leaves the room [12:07:34] Guillaume Leclanche joins the room [12:18:39] danwing joins the room [12:24:05] becarpenter leaves the room [12:24:22] becarpenter joins the room [12:27:30] danwing leaves the room [12:30:21] tore@jabber.org leaves the room [12:32:20] danwing joins the room [12:50:07] Tony joins the room [12:58:08] Joel Jaeggli leaves the room [13:02:12] Joel Jaeggli joins the room [13:07:05] becarpenter leaves the room [13:12:21] becarpenter joins the room [13:18:09] Joel Jaeggli leaves the room [13:22:05] Joel Jaeggli joins the room [15:11:02] if someone is in congress hall 2, the volume is kind of low, if this could be looked into before v6ops meeting, that'd be great. [15:11:45] it's not so low so not to be audible, but it's a bit low [15:18:58] danwing leaves the room [15:27:36] hm, it seems my computer volume goes to 130% (ubuntu) if I go into sound settings, so I think I'll be fine. [15:34:15] t.k joins the room [15:34:41] ok [15:35:42] the host has not joined the webex [15:35:47] guess this is better than from some other rooms where there is massive clipping [15:35:52] m joins the room [15:37:36] becarpenter leaves the room [15:38:35] becarpenter joins the room [15:38:38] ietf 80 v6ops session 2 17:40-19:40 [15:38:48] fyi found code [15:39:00] freds laptop is presenting [15:40:36] rbonica joins the room [15:40:37] tore joins the room [15:41:07] tore leaves the room [15:41:09] Patrik Halfar joins the room [15:41:19] ꈲ joins the room [15:41:20] fyi webex has started [15:41:34] WesG joins the room [15:41:43] yes, we can see freds email and calendar [15:42:21] tore joins the room [15:44:35] we are starting [15:45:15] http://tools.ietf.org/agenda/80/slides/v6ops-6.pdf [15:45:22] brian carpenter [15:45:24] sandoche joins the room [15:45:35] I spent half my life in this room. [15:45:44] trying to put toothpaste back in the tube [15:46:07] people having been complaining about 6to4 for years [15:46:18] this is an attempt to do something [15:46:30] jhf joins the room [15:46:48] Packetgrrl joins the room [15:46:52] a lot of 6to4 out there [15:47:01] we don't know how to get it back in the tube [15:47:22] jpc joins the room [15:47:35] was not deisnged as an unmanaged solution [15:48:17]