[05:58:57] --- BillC has joined [06:01:50] --- jm has joined [06:02:06] --- healthyao has joined [06:06:15] yeaaa, audio :-) [06:06:46] --- trond has joined [06:07:05] --- yoshfuji has joined [06:07:09] hello. [06:07:19] --- nm has joined [06:07:27] --- Tatuya Jinmei has joined [06:07:55] --- dthaler has joined [06:08:05] IPv6 Address assignment to End Sites (Thomas Narten) [06:09:11] --- rhe has joined [06:09:43] http://www3.ietf.org/proceedings/08mar/slides/v6ops-12.ppt [06:09:59] slide: goals of 3177bis [06:10:15] --- jpc has joined [06:10:21] --- venaas has joined [06:11:15] slide: 3177bis history [06:12:36] slide: next steps [06:12:49] both v6ops and 6man have interest in this doc [06:14:51] --- gvandeve has joined [06:14:52] hinden: not sure any indication of current policy ever running out of /48s [06:15:37] --- dudi has joined [06:21:19] --- healthyao has left [06:21:20] --- healthyao has joined [06:22:23] --- yaronf has joined [06:24:31] --- trond has left [06:24:36] --- trond has joined [06:24:55] thaler: for larger sites, /48 allows migration from 6to4, and lack of incentive to do 6to4 rather than native [06:25:09] matsu@ntp.net.fujitsu.co.jp [06:25:17] durand: enterprises not really doing 6to4 today [06:25:49] (aside: that's a comment on the migration part, but not the lack of incentive part) [06:26:12] --- nishida has joined [06:26:29] lacnic person (name?): current policies require everyone with a /48 to be in whois [06:26:45] --- yaronf has left [06:27:06] ... so same boundary for everyone makes things hard to decide who goes in whois and who doesn't [06:28:04] --- nm has left: Replaced by new connection [06:30:08] couple of mike speakers: good to allow isps to allocate the size they need [06:30:30] (Remis Dupres & Bernard Tuy) [06:31:21] hain: whatever number you pick, the routing system will see fragmentation anyway [06:32:06] hain: move policy discussion to the RIR list. the whois discussion should go there since it could be changed, not IETF's job to decide such policies [06:32:27] further discussion on this draft on list [06:32:34] --- nm has joined [06:33:34] http://www3.ietf.org/proceedings/08mar/slides/v6ops-1.pdf [06:33:39] Modified NAT-PT [06:34:04] slide: new in this version [06:34:52] slide: Huh? [06:34:56] slide: RFC2766 [06:35:22] fake AAAA records are a big problem [06:35:31] slide: problems with NAT-PT [06:36:27] slide: modified NAT-PT [06:37:02] slide: DNS ALG [06:38:00] option in EDNS0 response marks AAAA records as fake so can be detected by new resolvers [06:38:28] slide: AAAA vs A [06:39:08] slide: EDNS0 "poison pill" [06:39:44] zipped through next slides [06:39:48] slide: IPv4->IPv6 [06:40:56] well-known ports don't work! [06:41:07] slide: translation vs tunneling [06:41:37] tunneling requires host changes [06:42:08] last slide: remember... [06:43:37] baker: what requirements did you learn about? [06:43:57] push back on people who impose too many requirements... do easy things like web and mail [06:44:26] --- sakuma.macx has joined [06:44:32] if you want to do IPsec but solution can't do it, that may be ok [06:45:09] --- levigner has joined [06:45:56] marcelo bagnulo: poison pill is good to contain the fake records, and moving the DNG ALG is good but need some communication about v4 address between DNS ALG and NAT-PT so this is hard [06:46:35] draft mentions 8 possible ways and will narrow down in future version (DHCP option, and DNS) [06:47:05] --- gvandeve has left: Replaced by new connection [06:47:16] alain durand: some cases where don't want DNS ALG, where mappings come from external source or are algorithmically computed... do you support those cases? and do we need a protocol to inject mapping into NAT-PT box? [06:47:41] --- gvandeve has joined [06:48:27] don't know, two choices - store 32 bit address and store 128 bit address [I didn't follow this] [06:48:49] --- John Ronan has joined [06:49:02] --- kodonog has joined [06:49:38] pekka savola: the "remember..." slide is all about assumptions. can come up with other scenarios and this is just one so be careful about statements to only target mass market apps [06:50:26] next up "Approach for translator" [06:50:39] http://www3.ietf.org/proceedings/08mar/slides/v6ops-7.ppt [06:51:03] Fred Baker presenting since author had to leave, this draft was originally on Tuesday's agenda but didn't get to [06:51:28] slide: How to utilize? [06:52:09] --- Roque@lacnic.net has joined [06:52:28] host administrator essentially manually configures AAAA record (in DNS server) for each A record [06:52:41] fred hopes there'd be a way to automate this instead [06:52:58] similar to iljitsch's problem presented but solution is a bit different [06:53:20] remis: don't see a real need for a v4only host to call a v6only server, but others disagree [06:53:58] --- lebobits has joined [06:54:51] remis: for v6only host talking to v4only server, no need for DLG ALG if v6only host does something new [06:55:06] fred: requriement is a bidirectional service and you disagree with that requirement [06:55:31] iljitsch: shanti went away because it was decided it was reinventing SOCKS which already exists [06:56:11] durand: strongly disagree with remis, strong requirement for v4only host to talk to a v6only server [06:56:49] remis: "v6only host" is a bit ambiguous... [06:57:04] fred: discuss offline, we want a requirements discussion here [06:57:32] remis: agree we need to talk from v4-only host to a host that has no v4 address [06:57:53] fred: "v6only" in this context means only reachable by v6 [06:58:21] --- aalain has joined [06:58:23] mark townsley: there is a difference between reachable by v6only and only capable of v6, make taxonomy clear [06:58:33] durand: and there's a v6-only app case on a dual stack node [06:58:38] next presentation [06:58:42] Brian Dickson [06:59:47] not sure which slides this is from the web, anyone else know? [06:59:53] slide: why ipv6? why now? why? [07:00:38] slide: long term view is important [07:00:42] --- bortzmeyer has joined [07:01:40] ok slides are http://www3.ietf.org/proceedings/08mar/slides/v6ops-15.ppt [07:02:08] slide: side issues [07:03:16] slide: what about "growing" assignments? [07:05:35] dickson: end sites don't care whether new prefix is adjacent to existing one [07:05:52] fred: end sites still care if they're dual-homed [07:06:19] dickson: if you have provider-aggregatable space, no one will allow that. [07:06:37] dickson: we're talking about provider-aggregatable blocks only here [07:06:52] slide: long term == 10 years or so [07:07:37] kurtis lindqvist: money rules... people do pay to get PA space advertised elsewhere, this is reality [07:07:52] dickson: want to prevent that in ipv6 [07:08:18] ron bonica: given that the economic realities haven't changed, you'd expect policies to be the same [07:08:41] dickson: there's a huge growth in PI space in IPv6 so it's different now [07:08:59] --- sakuma.macx has left [07:09:10] pekka savola: if many ISPs filter then would remove incentive, but not sure we're there yet [07:09:15] back to the slide... [07:09:24] how many people have read the drafts? [07:09:33] some [07:11:04] slide: why sequential is bad [07:11:58] --- jpc has left [07:12:17] slide: why bisection is bad [07:12:53] slide: hidden dangers of bisection [07:13:17] slide: what works well? [07:14:08] slide: topological pools [07:14:17] --- iljitsch has joined [07:15:01] slide: customer assignments [07:16:16] can give customers multiple blocks, as long as you can still aggregate them [07:16:59] slide: optimal assignment packing [07:17:51] slide RFC 3531 [07:18:27] slide: be lazy [07:19:36] slide: it's math, not computers [07:20:13] --- sm has joined [07:20:54] looks weird to have large empty space and tightly packed existing allocations... until you get a big request and it works out fine [07:21:05] slide: thank you [07:22:08] pekka savola: is this what ISPs do for IPv4 today? [07:22:54] maybe some ISPs, get HD ratios of more than 95%, but not widespread in industry [07:24:52] fred baker: kampai addressing is an example of an Informational RFC... the one dickson says is a bad idea [07:24:54] --- sakuma.macx has joined [07:26:41] --- internetplumber has joined [07:26:45] is this a topic for v6ops or elsewhere? [07:26:58] --- rhe has left [07:27:19] (btw, I believe the KAMPAI RFC Fred referred to is RFC 1219) [07:27:48] seems to be a v6ops related topic but will need to discuss on the list [07:28:32] next is Gunter Van de Velde on IPv6 RA-Guard [07:28:33] http://www3.ietf.org/proceedings/08mar/slides/v6ops-11.ppt [07:28:36] --- kodonog has left [07:29:04] mitigating against rogue RAs [07:29:10] slide: draft objective [07:29:21] --- iljitsch has left [07:29:37] slide: SEND deployment model [07:31:13] slide: proposed deployment model [07:31:46] switch blocks non-SEND RAs even if hosts don't do SEND [07:32:00] does anyone else still have audio? [07:32:04] slide: RA-Guard complementing SeND [07:32:09] no [07:32:30] (audio in the meeting room is still fine) [07:32:40] --- iljitsch has joined [07:32:49] http://128.223.162.20:8001/ [07:32:59] All the streams seem to have vanished [07:33:07] slide: RA-Guard Use Considerations [07:33:11] slide: Next steps [07:33:25] adopt as WG item? [07:33:29] (silence so far) [07:33:42] humming [07:33:47] more hums for yes [07:34:31] --- fdupont has joined [07:34:39] bob hinden: no strong opinion. some v4 techniques in switches today to look for rogue DHCP agents, so same for v6 might be useful [07:34:57] fred: ok to post next version as a WG draft [07:35:48] next up "CPE Default Route Detection" [07:35:54] http://www3.ietf.org/proceedings/08mar/slides/v6ops-2.pdf [07:36:53] slide: Objective [07:37:21] slide: Next [07:37:43] audio back [07:38:05] (I'm not following this presentation at all, no diagrams... probably need to read the draft) [07:38:52] --- yushun has joined [07:39:09] alain durand: why do we need this doc? we use DHCP to get information. Couldn't get from document [07:39:15] --- lebobits has left [07:39:27] there may be other mechanisms that could be used on wire [07:39:53] ralph droms: DHCP doesn't have an option to carry the route [07:40:16] (I'm going to mike, maybe someone else can jabber scribe...) [07:41:28] --- kquinn has joined [07:41:45] droms: This is one side of the demarc, we need to think about other side of the demarc too, and perhaps there's a solution that would solve both problems for inserting the route into the providers tables. [07:42:42] pekka savola: To support clients that don't have a distinct CPE you still need RAs. [07:43:34] Mark Andrews: Essential IETF acknowledges there are hybrid devices where cpe talks to cpe. [07:45:28] Dave Thaler: Definition of host and router is per-i/f rather than per-device. On the WAN side you're like a host, so you can listen to RAs. On the LAN side you send RAs. No mech to do that with DHCP, but you can do it with RAs. [07:45:38] Alain: Agree with Dave Thaler. [07:46:21] Fred Baker: Upstream and downstream is well defined in home, but not in a larger network. [07:46:50] (we now return you to your regularly scheduled scriber :)) [07:47:59] --- iljitsch has left [07:48:12] --- gvandeve has left [07:48:55] --- aalain has left [07:52:15] --- nm has left [07:57:22] --- iljitsch has joined [07:58:25] --- jpc has joined [08:04:03] (Sorry, guess Dave has dropped off. Missed most of this question. Suggests a pointer to RFC4890 would be useful.) [08:04:26] (Questions are to Woodyatt on Simple CPE Security.) [08:04:44] --- dthaler has left [08:06:10] (Apologies, missing this as I don't know about STUN.) [08:07:11] (?): You're talking about a hole-punching mechanism. UPnP Forum has just started working on this. [08:07:38] Woodyatt: Has UPnP forum considered making their specifications available as widely as IETF? [08:08:40] Dave Thaler: Is it the intent to recommend a specific behaviour, or to say units should do the same for v6 as they do for v4. [08:09:16] Woodyatt: Neither. It gives options depending on what your main concern is. [08:10:01] Woodyatt: We could narrow it down to one, I would err towards transparency rather than security. [08:10:04] --- fdupont has left [08:10:10] --- iljitsch has left [08:10:52] Thaler: Many options in v4. Is now the time to tie options down? (Over-simplifying.) [08:16:52] Shuresh: Thought the design team was also working on other CPE recommendations, what has happened to that? [08:17:10] Fred: Out of scope for this draft, feel free to write another up. [08:22:38] --- John Ronan has left [08:22:57] --- John Ronan has joined [08:23:13] --- nishida has left [08:25:11] --- sakuma.macx has left [08:25:43] Remis Dupres: Do not translate addresses, preserve the end-to-end. [08:25:54] Woodyatt: There is no mention of translation in the document. [08:29:06] Bob Hinden: Lets not replicate IPv4. Think that new IPv6 boxes will be more secure than older systems. [08:29:56] --- healthyao has left [08:31:30] --- nishida has joined [08:32:30] --- internetplumber has left [08:33:19] --- venaas has left [08:34:34] --- kquinn has left [08:37:16] thanks to the scribes [08:37:25] --- John Ronan has left [08:40:03] --- nishida has left [08:40:25] --- levigner has left [08:40:36] --- dudi has left [08:40:42] --- sm has left [08:43:38] --- Tatuya Jinmei has left [08:43:38] --- yushun has left [08:46:20] --- trond has left: Disconnected [08:50:37] --- jm has left [08:51:58] --- bortzmeyer has left [08:56:37] --- yoshfuji has left [09:05:29] --- Roque@lacnic.net has left [09:55:30] --- jpc has left [10:43:24] --- BillC has left