[07:09:26] yanick.pouffary joins the room [07:09:42] yanick.pouffary leaves the room [07:41:42] fdupont joins the room [07:43:08] bortzmeyer joins the room [07:43:24] Great, we are two :-) [07:45:57] yanick.pouffary joins the room [07:49:34] we should switch to French (:-) [07:51:17] We cannot, everything is logged and distributed to the public [07:51:51] psavola joins the room [07:53:57] hirocomb joins the room [07:56:38] Exodus joins the room [07:56:45] Exodus leaves the room [07:57:41] iljitsch joins the room [07:57:53] morning everyone [07:58:02] brabson joins the room [07:59:26] anyone else having connectivity issues with IPv4? [07:59:46] I got private addresses on the ietf and ietf-a networks at first but when I got back on ietf it worked [07:59:50] fred can't ping stuff [08:02:05] kurtis@jabber.psg.com joins the room [08:02:23] pawal joins the room [08:02:24] ietf-1x works fine for me [08:02:37] Exodus joins the room [08:02:40] we're starting [08:02:41] philip_matthews joins the room [08:02:42] Fred: [08:02:59] jiangxingfeng joins the room [08:03:11] Agenda has been changed over the weekend to accommodate Alain's presentation [08:03:33] we have two meetings, now and thursday afternoon after lunch [08:03:40] hopefully finish nat requirements discussion this morning [08:04:06] want to reach community consensus closure on the requirements although there will probably be some discussion on the list afterwards [08:04:17] have/will have ops and sec area reviews [08:04:24] expect to last call within a few weeks [08:04:50] nail this all down because BEHAVE is working on the solution as of tomorrow, they need a clear statement from us [08:05:28] see the agenda at http://tools.ietf.org/wg/v6ops/agenda?item=agenda72.html [http://tools.ietf.org/wg/v6ops/agenda?item=agenda72.html] [08:05:33] swshin92 joins the room [08:06:03] also want to bring consensus/closure to rogue route advertisement issue [08:06:08] john.zhao joins the room [08:06:36] thursday thomas narten wants to "call the question" on his document, but lack of consensus so far [08:06:53] I'd like to think that we can get closure on the teredo thing and send off to the IESG [08:07:11] new draft on CPEs, we'll find out on thursday [08:07:21] agenda bashing, speak up or forever hold your peace [08:07:22] jiangxingfeng leaves the room: Replaced by new connection [08:07:24] remi's up [08:07:44] Remi Despres, 14-Jul-08, draft-despres-v6ops-apbp [http://tools.ietf.org/html/draft-despres-v6ops-apbp] [08:07:50] DWING-WXP01 joins the room [08:07:53] jiangxingfeng joins the room [08:08:22] Fred: 25 minutes per speaker, we can have discussions [08:08:24] DWING-WXP01 leaves the room [08:08:25] pawal leaves the room [08:08:31] danwing joins the room [08:08:31] pawal joins the room [08:08:39] Remi: the subject is evolving quite quickly, some stuff has been changed from the document [08:09:08] Suz@ISC joins the room [08:09:11] this solution avoids carrier grade NATs in ISP infrastructure [08:09:15] matthijs joins the room [08:09:22] perhaps the solutions are complementary [08:09:45] (philip: are you listening on audio? is it ok?) [08:09:59] yes it is ok [08:10:15] are remi's slides online? [08:10:29] dthaler@jabber.org/Meebo joins the room [08:10:43] Brian Haberman joins the room [08:10:59] authors: plz put your slides online and tell us the URLs, I can't type fast enough to describe all the schematics on the screen.... [08:11:18] 4p-6-4 scenario uses a "global address server": GAS [08:11:30] (I think the p refers to public addresses) [08:11:44] 6-4 scenario: between public addresses [08:11:56] oh no, that was 4-4, now we're moving to 6-4 [08:12:06] this is where the GAS is required [08:12:07] He is describing the draft that you should all in theory have read ;-) [08:12:34] kurtis: in theory there is no difference between theory and practice, in practice there is [08:12:45] dthaler@jabber.org/Meebo leaves the room [08:12:46] philip_matthews leaves the room [08:12:46] iljitsch leaves the room [08:12:49] jiangxingfeng leaves the room: Replaced by new connection [08:13:02] jpc joins the room [08:13:29] iljitsch joins the room [08:13:55] CPE router keeps NAT4p4 ALGs UPnP+ and also has to be a GAP client [08:14:03] WPM01906 joins the room [08:14:08] GAP client gets public IP (v4?) address and a range of ports [08:14:44] (Note that this is all somewhat similar to Brian Carpenter's draft from a few IETFs ago) [08:15:03] philip_matthews joins the room [08:15:09] pawal leaves the room [08:15:16] pawal joins the room [08:15:48] so these ports can be published and presumably used to receive incoming sessions [08:16:39] Yes, Remi's idea seems to be an abstraction of Brian Carpenter's SHANTI [08:17:32] The slides for this talk are not uploaded?? [08:17:36] no [08:17:40] (In our discussions when integrating SHANTI and MNAT-PT we observed that these approaches are similar in concept to SOCKS and SOCKS already exists so do we need soemthing new in this space?) [08:18:10] magnus joins the room [08:18:53] Remi: carrier grade NAT (CGN) solutions [08:18:56] john.zhao leaves the room: Computer went to sleep [08:18:56] frodek joins the room [08:19:11] CGN 4p-6-4 solution [08:19:20] CPE doesn't do NAT but tunnels [08:19:43] issues with number of ports per site (customer?) [08:19:45] BTW audio stream is good ... [08:19:56] questions about UPnP and ALGs [08:20:00] xiaodong.lee joins the room [08:20:05] Iljitsch: good question. I don't know if SOCKS can tell you the TCP (or UDP port) that the SOCKS proxy has allocated, and I don't know if you could reliably use STUN-over-TCP to learn the SOCKS-allocated TCP port and then be able to get the same TCP port for a subsequent connection. (Consider, for example, non-passive FTP where you need to learn your publicly-routable v4 TCP address, and give it to the remote peer in a control channel) [08:20:41] narten joins the room [08:20:52] nov joins the room [08:20:53] Slides are at https://datatracker.ietf.org/meeting/72/materials.html [08:21:06] my bad [08:21:52] we don't seem to have mikes... [08:22:02] thx Kurtis [08:22:02] question from me: 4p is private or public? [08:22:05] jiangxingfeng joins the room [08:22:10] answer: g = global, p = private [08:22:22] By the way I sent a request to mtd@ietf.org about the mic [08:22:22] lynch joins the room [08:22:29] audio listeners: do you hear the questions? [08:22:35] no [08:22:43] shep joins the room [08:22:51] With difficulty [08:23:03] The answer about the mic is: The hotel is currently working on getting the additional mics into the rooms. [08:23:06] pro for this scenario: CPEs are simpler because they don't have to NAT [08:23:14] NAT behavior is unified [08:23:24] can overbook port numbers [08:23:24] joining late - did he define "carrier grade NAT" ?? [08:23:35] xiaodong.lee leaves the room [08:23:40] almost completely based on existing applications [08:23:56] pros for GAS: simpler more stable, easier to dimension [08:24:19] lynch: no, I think it's supposed to be self-defining, ie a really big NAT in the ISP network [08:24:41] john.zhao joins the room [08:24:44] "Carrier Grade NAT" has not been defined. I guess you're supposed to imaging a Ford F-350 of NATs. With a lift kit. :-) [08:24:48] pro GAP(sp?)/GAS: can have different NAT behavior as required [08:24:50] shep leaves the room [08:24:59] shep joins the room [08:25:09] IPv4 E2E transparency for IPv6 address DS hosts (not sure what that means) [08:25:40] terminology has changed from Address Port Borrowing Protocol to Global ADdress Protocol [08:26:02] point is getting global addresses to devices that can't get it natively [08:26:09] by "public address" does he mean 48 bits? [08:26:10] (and some more, see slides) [08:26:19] (48 == 32 + 16) [08:26:28] I'll try to ask [08:26:35] roque joins the room [08:26:50] question: tunneling is new vs NAT44 carrier grade NAT [08:27:00] remi: carrier grade NAT is a big nat in the ISP [08:27:08] they exist today for private v4 to public v4 [08:27:15] DThaler joins the room [08:27:21] we now talk about v6 - v4 internetworking [08:27:26] other combinations are also possible [08:27:29] If someone gets a chance, ask the presenters to repeat the questions for the folks who are participating remotely [08:27:34] question from marcelo: [08:27:46] pawal leaves the room [08:27:52] pawal joins the room [08:28:10] satoru.matsushima joins the room [08:28:12] marcelo: do legacy nodes require changes? [08:28:14] remi: no [08:28:39] (ok this a bit too fast/detailed for me) [08:28:57] marcelo: you use UPnP but it doesn't work like this [08:29:02] so need changes to UPnP [08:29:13] marcelo's question: is this ok for the wg? [08:29:27] I've asked for a second microphone. Let's see if that comes before we are done [08:29:49] Great! [08:29:56] (I think the UPnP device can return a different port than was asked for, also possibly that's what Remi said) [08:30:14] please see slide 15 for detailed explanation [08:30:46] But the slides for this talk are still not uploaded, right? [08:30:47] aalain joins the room [08:30:55] oh right [08:31:01] kurtis, I hope they actually get 2 extra mics. One for the floor and one for the chairs. [08:31:04] question from dave thaler: [08:31:11] how does the client get the unicast address? [08:31:27] remi: not said anything about this, assume would be a wellknown address [08:31:55] benno@nlnetlabs.nl joins the room [08:31:58] correction above in dave's q: s/unicast/anycast/ [08:32:04] right pekka [08:32:07] mohsen joins the room [08:32:18] Without slides, it is hard to follow a talk ... [08:33:05] well with finite state machines with 4 point text it's not all that easy with the slides either.... [08:33:06] Iljitsch: (I think the UPnP device can return a different port than was asked for, also possibly that's what Remi said) --> Can you verify this somehow? I thoght it couldn't do that, but I admit that I haven't looked at any UPnP source code to verify. [ [08:33:11] next steps: [08:33:27] dan: you're remote? [08:33:29] I thought this talk was on the materials URL I sent [08:33:35] fred: [08:33:35] notice that we reordered the topics [08:33:46] we're here to finalize the requirements [08:33:59] you would address marcelo's draft [08:34:13] ruri joins the room [08:34:21] remi: I understandthat marcelo is in the scenario with no CPE [08:34:35] mohsen leaves the room: Logged out [08:34:39] ljb joins the room [08:34:39] ljb leaves the room [08:34:49] tv joins the room [08:34:51] tv leaves the room [08:35:58] Regarding the UPnP port number: Magnus is sitting next to me and suggests that if UPnP cannot return a different port than requested, the CPE could actually NAT the port number between what is requested and what was returned via G.A.P. [08:36:03] ljb joins the room [08:36:18] answer to dan's quetstion by stuart cheshire: haven't seen this in practice, seen silent override or error in practice [08:36:36] yanick.pouffary leaves the room: Replaced by new connection [08:36:37] but we don't know for sure if it's in the protocol because there is no public specification (Fred) [08:36:39] mohsen joins the room [08:37:28] remi: we need this behavior, though [08:37:56] mc joins the room [08:38:01] fred: may want t take this to behave [08:38:13] dave thaler: if the cpe is the gap client [08:38:30] nm joins the room [08:38:32] the observation is that the protocol is of the same category as UPnP or NAT-PMP [08:38:48] tvest joins the room [08:38:51] yanick.pouffary joins the room [08:39:10] may want to work in the context of one of those protocols rather than do something completely different [08:39:29] because CPEs already implement those protocols [08:40:03] Mark Townsley joins the room [08:40:13] marcelo is up [08:40:41] fred: bring this to consensus [08:40:58] Interesting, there seems to be a short delay in the audio stream, perhaps 15..20 seconds ... [08:41:05] IPv4/IPv6 Coexistence and Transition: Requirements for solutions Marcelo Bagnulo, Fred Baker, Iljitsch van Beijnum, 13-May-08, draft-ietf-v6ops-nat64-pb-statement-req [http://tools.ietf.org/html/draft-ietf-v6ops-nat64-pb-statement-req] [08:41:21] (philip: that's fairly normal for any time of streaming) [08:41:31] ok marcelo has a mike and is starting now... [08:41:51] I'll take input as I move forward, when time is up, just stop me [08:42:07] the draft describes three scenarios [08:42:17] (are his slides online?) [08:42:29] have had feedback: need more details [08:42:40] yes [08:42:54] questions about placing of the NAT [08:43:03] so may need to split some scenarios [08:43:16] question is: do we need more detaqils? Pekka? [08:43:16] atarashi joins the room [08:43:18] benno@nlnetlabs.nl leaves the room [08:43:22] pawal leaves the room [08:43:27] What slide is he on? [08:43:28] thomas narten: need more detail in some cases [08:43:29] pawal joins the room [08:43:35] the one with the butterfly [08:43:39] thanks [08:43:41] "translation scenario" [08:43:57] thomas: outside readers may not understand [08:44:18] dave thaler: it's not just the placement of the translot [08:44:35] question is whether the translator is in the path of the default route or not [08:44:40] this is an important difference [08:44:55] randy joins the room [08:45:23] so the service could be handled by an ISP or as a third party service [08:45:29] the requirements would be vastly different [08:45:46] marcelo: I'll come up with subscenarios and see if we need different requirements [08:45:56] we only have one list now, though [08:45:58] next slide [08:46:00] the service has to be at the cpe or it requires central approval to deploy new things [08:46:07] basic requirements MUST be supported [08:46:59] me: this is nonsense because if all CPEs had a public IPv4 address we wouldn' need all of this [08:47:12] marcelo: no changes in v4 nodes, possibly changes in v6 hosts [08:47:17] what about dual stack hosts? [08:47:43] thomas narten: are _some_ v4 changes possible? not stack, but maybe applications or IPsec [08:48:14] marcelo: approach in the document: basic requirements = no changes, the nice-to-haves may require changes [08:48:21] benno joins the room [08:48:23] (BTW, one could implement IPv6 entirely within an application which has only IPv4 access underneath it.) [08:48:39] thomas: stack changes are a non-starter, app changes may be reasonable [08:48:52] remi: about dual stack: yes for changes on those [08:48:56] thnetila joins the room [08:49:05] shep: Been there, done that. [08:49:38] dual stack = reachability, not whether it has the stacks [08:49:44] ljb leaves the room [08:49:55] nm leaves the room [08:49:59] dave: v4-only host can also be a dual stack capable host without ipv4 address [08:50:09] so this answers your question [08:51:08] must not require changes in stacks, period [08:51:11] my opinion: can't have changes in hosts that have both stacks because you don't know the connectivity in advance [08:51:17] nm joins the room [08:51:54] Ted Lemon joins the room [08:51:58] dave agrees with randy [08:52:15] remi: difference between changes and enhancements [08:52:20] fred: no difference [08:52:51] fred: take on faith that at some point in the future v4 goes away [08:52:58] keyajima1 joins the room [08:52:59] question if we can change v6? [08:53:02] if you are going 'enhace' v6 stacks then why screw around, let's fix it [08:53:14] it'll only take ten years [08:53:14] miyahiro joins the room [08:53:20] can other scribe take over? [08:53:36] Yeah, sorry I took so long to get online [08:53:51] keyajima1 leaves the room [08:54:42] Pekka: I guess this change implies code changes e g a requirement that each site must configure address selection policies [08:54:47] the reason NATs get deployed is because they don't require changes to anyone else [08:54:48] Presentor: that's a statement. [08:54:51] Pekka: that's a question. [08:55:13] so if you want anything here to get deployed, you should follow the same rule [08:55:27] ??: What is the reason for this requirement? Just to say we will not make protocol changes on host or some operational thing thtat it's very difficult to add software on the router? [08:55:32] Presenter: existing host should work with this. [08:55:48] far easier to change my cpe router than all my hosts [08:55:51] sts joins the room [08:55:54] ??: We seem to be going from no change to v6 stacks to something that's operational - difficult to upgrade existing hosts. [08:55:59] it's about deployment incentives (or lack thereof) [08:56:15] Iljitsch: what we're doing here is of you forget natpt because it's been deprecated, we're creating soemthing new, obviously we need to add stuff. [08:56:20] And if you add this stuff it may break some stuff. [08:56:27] So these changes requiersments are about what we can break. [08:57:00] yanick.pouffary leaves the room: Replaced by new connection [08:57:10] the agenda posted at http://www.ietf.org/proceedings/08jul/agenda/v6ops.html says "Monday, 28 July, 9:00-1:30 Irish Summer Time". Are we really planning on going four and a half hours here? [08:57:14] Can marcelo repeat questions/comments of others in the room? Hard to hear people other than Marcelo and Fred [08:57:17] for enterprises, forgettng nat-pt says more about ietf than it does about operational needs. [08:57:18] miyahiro leaves the room [08:57:29] :-) [08:57:30] E.g. can we break dnssec? [08:57:52] legacy hosts don't generally support dnssec either [08:57:54] benno leaves the room [08:58:00] so they won't notice if you do [08:58:00] benno joins the room [08:58:01] Marcelo: must support v6-initiated connection. [08:58:21] Thomas: why do we want to restrict addresses - does it simplify things? [08:58:28] marcelo: I don't know how to evaluate. [08:58:38] Chair: let's get specific. [08:58:41] the point being that DNSSEC isn't really deployed today, especially not on clients that would use these solutions, so the need to make changes to DNSSEC for these hosts wouldn't be a show stopper IMO [08:58:53] Jing Li's allows one-to-one, one-to-many [08:59:04] any IPv4 system can go to server that has directly mapped address, but not one to many [08:59:09] any IPv6 system can go to any IPv4. [08:59:17] So there is a restriction on putting servers in some places. [08:59:24] Addresses that are not mapped on the v6 side. [08:59:39] Marcelo: so we can have this question for each direction, may be okay to accept subset in one direction, not the other. [08:59:56] Thaler: this one is hard to understand without scenario pictures. Answer may vary greatly depending on the picrture we're talking about. [09:00:20] Rand: V6 initiated short-lived local handle. My stack doesn't know what a handle is. [09:00:27] Marcelo: have you read the draft? There's a defintiion. [09:00:37] ??: There are words, yes. The meaning is unclear. [09:00:58] Marcelo: you have client-server communication that lasts for restricted period in time, you will not use this address later on in the future. You don't have callbacks, don't have referrals. [09:01:04] Ted: that's Ran Atkinson [09:01:14] Ran: I have trouble translating this into code. [09:01:15] brabson leaves the room [09:01:20] Iljitsch: you free it when you're done. [09:01:30] john.zhao leaves the room: Computer went to sleep [09:01:34] Thaler: audience is a spec writer, not an implementation writer. [09:01:42] brabson joins the room [09:01:53] If you're writing a spec you have to support this case, regardless of whether you support referrals and callbacks. [09:02:01] keyajima1 joins the room [09:02:08] sts leaves the room [09:02:11] Thomas; so my take on this is that it's phrased in a strange way [09:02:34] : if there's a v6 node and v4 node, there is a way to communicated, if there are restrictions that's okay, but I need to know that there's a way. [09:02:52] Fred: communicate with or initiate connection to? [09:03:17] Iljistch: Can't encode arbitrary IPv6 address into v4 address so you can't specify arbitrary IPv6 destination in an IPv4 header. [09:03:28] Thomas: a number of assumptions I'm not ready to make. [09:03:41] Marcelo: this is for v6 initiate - v4 is next slide. [09:03:51] Any node must be able to initiate to v4. [09:04:01] matt joins the room [09:04:04] benno leaves the room [09:04:05] This is the other case - v4 nodes must be able to initiate to any v6 node. [09:04:08] any node in the any land must be abe to initiate comms to an node in any land [09:04:10] benno joins the room [09:04:15] this is the internet, not the balkans [09:04:16] brabson leaves the room [09:04:22] Ran: I understood what Tom was saying a lot better than I understood that. I find his wording a lot more readbale. [09:04:26] yanick.pouffary joins the room [09:04:43] There are two differences; whether v4 initiates to v6 or v6 initiates to v4. very different. Do we need to support one, or both? [09:04:48] randy: no solution can meet that without changes on the v4 end [09:04:51] pick your poison [09:04:55] this is the INTERnet. any node must be able to talk/initiate to anty other node [09:05:03] Second, what type of communication, initiates, or richer form of communications - initiate, wait for two hours, expect call back. [09:05:13] brabson joins the room [09:05:16] matt leaves the room [09:05:30] @iljitsch: wrong [09:05:36] jiangxingfeng leaves the room [09:05:39] randy: that's not the internet that we have today [09:05:46] (me) I don't understand why we can't upgrade stacks [09:05:52] if people felt strongly about that they'd be running v6 by now [09:05:55] Thomas: It's a requirement to support v4-initiated and v6-initiated. [09:06:03] randy: so how do we do this then? [09:06:08] @thomas: bingo! [09:06:17] aalain leaves the room: Replaced by new connection [09:06:19] thnetila leaves the room [09:06:22] Thaler: the reason you don't have consensus is that people have different pictures in their mind. [09:06:30] aalain joins the room [09:06:37] iljitsch: without changes to v4, v4 to v6 doesn't work whatever the picture. [09:06:42] If you can make it work please tell us. [09:06:55] Mark Townsley leaves the room [09:06:57] Marcelo: My reading is everybody agrees v6 to v4 is needed and can be made to work. [09:07:05] too many people who have pictures do not actualy deal with the realities of what these pictures supposedly represent. this is not theory, this is a real network. [09:07:08] Not so obvious that we need v4 toi v6, not clear that we can make it work. [09:07:21] Thomas: we know it's not going to work perfectly, but can we make it work good enough in a large number of cases? [09:07:49] randy: anyone who need to talk to v6 hosts is free to upgrade to v6 or dual stack [09:07:53] xiaodong.lee joins the room [09:07:54] we know how to solve that problem [09:08:04] people just don't care enough to do it [09:08:06] Thaler: one fo the pictures I mentioned is you have a v6 onloy conenctivyt to a particular set of servers in a network, need to talk to client that's v4 only, destinations that are v6 only are in a particular range, don't have to provide connectivity to entire v6 address space, only v4 only. [09:08:22] the part that still needs fixing is hosts that can't downgrade to v4 who what to talk to v4 hosts [09:08:25] Once you talk about the picture, maybe restricted cases might be solveable even though general case is not. [09:08:27] OatWillie joins the room [09:08:29] rdenisc joins the room [09:08:37] Is there a more constrained requirement that people can agree on? [09:08:44] pawal leaves the room [09:08:48] Jeff: I think he's mixing requirement with his idea of solubility. [09:09:03] I think it's reasonable to state what our goals are here, what we think could be done, recognizing that we might not be able to do it all. [09:09:20] If i"m trying to put burden on wrong side of connectivity, as you point out may not be soluble. That doesn't mean it's not desirable. [09:09:26] mc leaves the room [09:09:38] You're not going to get "every solution adheres to every requirement" But that doesn't mean youc shouldn't say what you want. [09:09:50] Marcelo: I like what Jeff is saying, we've had very many discussions on very specific scenarios. [09:10:06] Thaler: on opposite end of spectrum, gratuitous complexity for a case nobody cares about. [09:10:07] has everyone signed the blue sheets? we still end up with rooms that are too small most of the time... [09:10:12] benno leaves the room [09:10:18] Fred: what we're talking abotu will be important for a short period of time. [09:10:19] benno joins the room [09:10:34] Then move on to a scenario where we have a simpler and less cost network that's only running one or the other. [09:10:40] the transition will take a decade or more [09:10:46] I think we can spend a lot of time polishing the apple and forget that we're focusing on a short-term issue. [09:10:48] agree with Randy [09:10:55] some of the scenarios aren't short term [09:11:02] aalain leaves the room [09:11:09] i wish otherwise, but wishes do not move packets [09:11:10] Alain: I'd like to make two point, in terms of priorities, I've sent emails, maybe some of this requirement need to be yesterday, some for tomorrow or next month. [09:11:18] Matt Zekauskas joins the room [09:11:21] My perception, we are going to run out of 4 addresses, this is going to impact large deployments. [09:11:25] there will always be v4only nodes somewhere for a long time [09:11:28] not convinced the transition will ever be finished [09:11:34] it would be harmful to delay the thing we know we can reasonably solve because we try to figure out something that we probably can't [09:11:35] You can get smaller blocks longer than you can get larger blocks. [09:11:47] Fred: so your opinion is that this is a long term problem not a short term problem? [09:11:57] ted: we will run out of available v4 addresses [09:12:07] Alain: there are people who have decided to put themselves in this position, not clear to me that this community will need to support that. [09:12:24] roque leaves the room [09:12:29] Alain: this is going to be a short-term problem for fifteen years, this is going to stay in the architecture for a long time. [09:12:51] well, if only because dual-stack remains the mainstream solution to transition, we will have v4-capable nodes for a long time... [09:12:53] Fred: what I'm getting at in asking us to focus is that we can have defocused conversations that last a long time and don't help, or we can have focused conversationt hat help, and I would like to have the latter. [09:13:05] Ran: I'd like to follow up on Jeff's comment, this is opinion rather than question. [09:13:07] and many of them will do 169.254.0.0/16 if you disable v4 on the network :) [09:13:08] if you want to go from v4 to v6, you can do it today with extremely minor app changes for all TCP apps: http://www.muada.com/drafts/draft-van-beijnum-v6ops-connect-method-00.txt [http://www.muada.com/drafts/draft-van-beijnum-v6ops-connect-method-00.txt] [09:13:23] I think that requirements ought to be goals, and if it would work better for the community to say we have goals, not requirements, I would be down with that. [09:13:36] (4 pages including boilerplate) [09:13:46] nm leaves the room [09:13:53] I prefer Tom Narten's proposed phrasing over the text in the draft, because it seems that the goal ought to be that any v4 should be able to talk to any v6 node. [09:13:59] well yeah. reallistically, if you want v6 for HTTP servers, you're going to put a reverse proxy in front with v4 [09:14:03] same with many other protocols [09:14:21] I think the goal is that anybody can talk to anybody, I'm sensitive to Dave Thaler's concern that if we are not careful in ow we communicate this to behave, they will interpret this as don't ship anything unless you have everything. [09:14:35] I would rather have goals that are not met than detailed requirements that absolutely are not met. [09:14:40] pawal joins the room [09:14:43] We in BEHAVE are not that STUPID:-D [09:14:56] rdenisc: no, the point is that an HTTPS proxy is a generic TCP proxy so you can use it for ANY TCP app if you make the app work through proxies [09:14:59] Marcelo: could you send me some text? [09:15:16] iljitsch: yeah, though it typically only allos port 443 [09:15:24] Fred: I've got a meeting management break, I think we really need to get through this discussion, already spent half hour on first two slides. [09:15:28] you can use SOCKS too for that [09:15:35] rdenisc: yes, but that's something you can change easily [09:15:36] I think that's going to mean the RA guard stuff I'm going to have to move to Thursday. Sorry. [09:15:43] thnetila joins the room [09:16:02] that's something you do not want to change - when you do have a proxy, you typically have a strict corporate firewall [09:16:03] Hum on goals versus requirements: how many think we should stay with concept of requirements? [09:16:10] Iljitsch: not a clear question. [09:16:14] Ran: is it necessarily binary? [09:16:19] on unfirewalled networks, why bother - you can use dual-stack with NATv4 [09:16:24] benno leaves the room [09:16:30] benno joins the room [09:16:35] Marcelo: today we have MUST and SHOULD. [09:16:42] aalain joins the room [09:16:51] goals are requirements we plan on throwing out of the boat? [09:16:58] ??: I would prefer a bit more precise scenarios. [09:17:23] Vint: Just a thought, are the things that we already know how to requirements, and the things we don't know how to do goals? [09:17:46] It's probably the case that there will be some things we don't know how to do, can we parse them into those two categories? [09:18:00] There ought to be a set of things we do know how to do, if you don't even have that not sure why you're down in the weeds. [09:18:08] Marcelo: yes, that's it. [09:18:26] Ed: Both, obviously. T he goal is coexistence. It's hard to talk about requirements without the scenario. [09:18:45] The goal of coexistence is a network goal. Requirements on a particular device, it all depends. There's been some discussion on the list about sorting requirements. [09:18:57] Marcelo: I'm all for Dave's suggestion, make some scenarios. [09:19:27] Sam Sullivan: I think the question of the requirements is only valid when all the requirements are musts, if requirements already have support there's no point in trying to break it into ??? [09:19:32] we did the scenario thing five years ago [09:19:32] (sorry, couldn't really hear) [09:19:49] please not all sigh at the same time; we have limited oxygen [09:19:57] Heh [09:20:11] marijk joins the room [09:20:18] Marcelo: Legacy nodes must be able to tell which is the connectivity that they use. [09:20:21] sam sullivan = hesham soliman .. :-) [09:20:26] Sorry. :') [09:20:38] Thomas: should interfere with native traffic that may exist? [09:20:45] rfb joins the room [09:20:51] Fred: can we not play english teacher? [09:20:56] Thomas: it must use. [09:21:11] Fred: The RFC that defines that actually uses those. [09:21:13] rfb leaves the room [09:21:21] john.zhao joins the room [09:21:25] pawal leaves the room [09:21:27] Thomas: isn't this a thou shalt not do harm, if native is what they want to use and it works, don't screw it up. [09:21:31] Can't we just say it now? [09:21:31] pawal joins the room [09:21:45] brabson leaves the room [09:22:04] Marcelo: for unmodified v4 nodes? I understand possibel for v6 nodes. Required for unmodified v4 nodes? Just asking. [09:22:07] (Int he back: yes) [09:22:12] Marcelo: Okay, good luck doing that. [09:22:16] thnetila leaves the room [09:22:20] what is "it" in this context...? [09:22:23] Are we on slide with R3? [09:22:30] R4 [09:22:32] it's R4 now [09:22:32] benno leaves the room [09:22:33] brabson joins the room [09:22:33] r4 [09:22:34] thanks [09:22:38] nm joins the room [09:22:38] benno joins the room [09:22:48] Thomas: what does it mean for DNS to end up in the wrong context? [09:23:09] Marcelo: deprecate natpt assume DNS query and response go through same path as data packet. If go different way, useless. [09:23:14] no [09:23:20] The DNS query only make sense if you're going to send data on that path. [09:23:25] assumed that the paths all used same totd hack [09:23:41] Tom: I'm still not sure what this is supposed to mean here. [09:24:18] I can hear Iljitsch shouting ... ;) [09:24:20] Iljitsch: suppose a user of natpt or net64 asks for AAAA that doesn't exist, and that ends up in a recursive DNS server that serves people that aren't served by nat64 are going to see AAAA record. [09:24:42] ??: it's also unclear to me what he is trying to say, are you trying to improve over natpt, or to allow this failure mode? [09:24:42] NO! assumed that the paths all used same totd dns magic prefix hack. they do not have to be same path. [09:25:06] Marcelo: V6 is a must, v4 is a goal. [09:25:13] skipping r5 [09:25:21] back to dns [09:25:37] Alain: I think the fundamental question ehre is is it okay to have the DNS to lie or not? [09:25:41] Probably best to ask this question. [09:25:52] So far regardless of where you are you need to get the same answer. [09:26:01] Some proposals are essentially a violation of this principle. [09:26:14] Marcelo: if you synthesize records using a global prefix, this is the only one you can get. [09:26:23] bingo [09:26:25] Alain: you created a record that is visible in part of the universe, not visible elsewhere. [09:26:38] Marcelo: you will not get different records for this particular type of record. [09:26:39] bs. it is visible to the requestor [09:27:09] Alain: we are in solution space at this point. Fundamental discussion: is it okay to violate a fundamental pricinple that regardless of where you are in the internet, when you ask question to DNS, youg et the same answer? [09:27:13] Marcelo: that's stronger to this one. [09:27:30] Iljitsch: aren't you then saying that if this is not allowed, you have to say the same thing for all ALGs(?). [09:27:34] onakayu joins the room [09:27:35] Alain: DNS is something special. [09:27:44] Iljitsch: messing with my data worse than messing with my DNS. [09:27:57] Alain: messing with DNS is something you should not do lightly. [09:28:14] have the DNS lie? lie about what? [09:28:38] Peter Koch: the notion of validity in conjunction with modifying responses. Might be just the wording, but this requirement needs to be clarified, because ??? (don't mess with the DNS? can't hear) [09:28:38] @alain: designing a protocol that is incompatable on the wire is not something you should do lightly [09:28:46] :) [09:29:13] Marcelo: you're trying to connect to node using FQDN. You only can send packets towards an IPv6 address. Node only has IPv4 address. So you need to represent v4 address in v6. [09:29:15] ??: no. [09:29:19] in remote land the audio is terrible [09:29:24] that was Alain [09:29:27] Ity's pretty bad here too. [09:29:33] @ot: is this a bug or a feature? [09:29:36] roque joins the room [09:29:51] Dan: it's not clear that if you have translation you need to do this. [09:29:58] becarpenter joins the room [09:30:02] Marcelo: how are you going to send packet to v4? [09:30:39] Dan: One could imagine that if you made an FQDN query for an IP address, it would return a proxy address, and that would be a different thing. [09:30:53] Marcelo: don't change nodes. [09:30:56] is this going to make DNSSEC undeployable? [09:31:11] brabson leaves the room: Logged out [09:31:22] Dan: the requirements here are the skeleton of a protocol design, and what I thought we were trying to do was provide abstract requirements to BEHAVE. [09:31:30] brabson joins the room [09:31:42] s/Dan/Ran (Atkinson)/ [09:31:44] That is not "Dan" talking [09:31:45] If that's true, what's actualloy in this documeng is embedding a bunch of constraints on the protocol design rather than functional requirements on how users connect. [09:31:46] Sorry, Ran. [09:31:55] Ran: not clear to me that that's the objective of this WG charter. [09:32:11] Marcelo: when you start imposing requirements, this basically means that you are ruling out a set of the solution space. [09:32:32] Marcelo: important thing for me is that solution space that fits requirements is not a null set. [09:32:49] remnoving the part of the 'solution' space that does not solve real problems is a feature, not a bug [09:32:52] pawal leaves the room [09:32:58] pawal joins the room [09:33:21] Fred: what I heard Ran say which I agree with is that the ultimate requierments are that v4 nodes can talk to v6 nodes, not detail levels of ... Now that said, I think it is valid to ask whether one can add a proxy record to DNS and change clients to use it. Are we allowed to change softwarer o not? [09:33:38] note indeed that if you modify a dns response along the path, nodes that come later on the path are incapable of running dnssec [09:33:40] Ran: that goes back to Tom's point, distinguishing between stack and application layer. [09:33:44] Marcelo: nonononono [09:33:51] Ran: we didn't have conclusion. [09:34:08] xiaodong.lee leaves the room [09:34:23] Marcelo: if I have some type of communication that I need to change, that's okay, but the basic communication cannot allow changes on host. If you call DNS an application, you must change ... [09:34:25] xiaodong.lee joins the room [09:35:06] Tom: if you have a v4 onloy node running software, some is easier to upgrade than others. Making kernel soemthing youc an change relatively easily. DNS is in that grey area. You might be able to make code changes on a v4 only node in some cases, but you have to look at how it's updated and see if it's feasible or a non-starter. [09:35:31] My example, IPsec and IKE, a bunch of stuff in the kernel, may be possible to tweak IKE at application level. May not be possible to get other pieces of software upgraded. C an't generalize. [09:35:41] Who is "Tom"? [09:35:46] Thomas Narten [09:35:47] Narten [09:35:50] Thanks [09:36:31] Iljitsch: it is reasonable to say for the stuff that doesn't really care that you give it fake records and it works, and for stuff that does care, you need to make some changes. DNSSEC stuff does need upgraded resolver, but we don't require all resolvers to be upgraded. [09:36:48] Thomas: I don't have a clear answer on that. [09:36:57] benno leaves the room [09:37:01] Marcelo: my concern is that this basically implies that you would need changes to any node to be able to use this. [09:37:03] benno joins the room [09:37:17] Niel O'Reilly: problem with this particular reqirement is that it's too tight. [09:37:26] that's Niall [09:37:52] Tries to be independ of the various scenarios. In the example Iljitsch gave earlier where resolver sits in service area broader than service area of a particular gateway, for rest of people using resolver it may not be valid. [09:38:04] rdenisc leaves the room: Replaced by new connection [09:38:04] rdenisc joins the room [09:38:22] Only way to address that problem is at the deployment layer, taking care that you do your engineering so that you don't have overlapping service areas between what DNS is trying to do and what gateway must try to do. DNS already much more cantonized than that. [09:38:27] xiaodong.lee leaves the room [09:38:33] We must acknowledge those kinds of britleness. [09:38:51] ??: some folk believe that they're going to have to synthesize DNS responses. [09:38:54] Others disagree. [09:39:19] This requirement doesnt' say you must synthesize the DNS, but ti does say that if I choose to synthesize in a particular context, it is a requirement that if that response falls out of context, it must not be invalid. [09:39:40] Niall is saying if it leaks out of context, all bets are off. I'm inclined to agree. You can't go as far as saying invalid, because you haven't said what invalid is. [09:39:51] If false DNS information leaks, packets may flow in unintended directions. [09:40:00] That's something you jsut have to live with with synthesized responses. [09:40:23] There's a requirement that if you use DNS, there's a requirement that you not muck it up, and if you do muck it up, all bets are off. [09:40:32] please do not confuse transport from data... i can use v6 transport to ask for "A" records and v4 transport to ask for "A6" records. [09:40:37] Fred: suggest text. [09:41:22] Question to the Chair: Does v6OPS have to finalize the document today, or can BEHAVE work for a bit, and then come back to v6Ops and ask for comments, changes, etc? [09:41:24] Dave: if you ask for a AAAA record for a v4-only host, and you get one, then is the value associated with that record the same no matter where you are? That's different than what's being suggested here. [09:41:32] mohsen leaves the room [09:41:33] yanick.pouffary leaves the room: Replaced by new connection [09:42:01] ted: it will be, unless you are in a "walled-garden" [09:42:03] Fred: no way we're going to finalize it today. [09:42:18] OW:I'm just the scribe. :') [09:42:21] mohsen joins the room [09:42:41] Fred: If I have a v6 island and another v6 island with different gateways into v4, and they give the same information, one of those islands is going to be screwed. [09:42:56] Thanks for raising my question at the mike [09:42:58] @fred: core will be dual stack [09:43:00] Thaler: in SIIT for example it is true that you'll get the exact same v4-mapped address. In natpt you will get a different one. [09:43:01] np [09:43:05] benno leaves the room [09:43:09] Thaler: do you want to rule out natpt or not? [09:43:11] benno joins the room [09:43:35] natpt-like stuff [09:43:39] Iljitsch: in definition of natpt this was a really big issue, what I'm hearing now is that except for alain, I don't hear any arguments for one or the other direction. [09:43:57] Mark Andrews: a lot of our probelms coming from different prefixes in terms of doing translation. [09:44:14] roque leaves the room [09:44:17] Way back we decided not going to allow mapped Ipv4 addresses on the wire. That little decision there, if we put mapped addresses on the wire, we can do the translation. [09:44:21] Everybody gets the same address. [09:44:24] that's not true [09:44:28] From a v6 connection everybody sees the same thing. [09:44:36] webjabbergroup joins the room [09:44:37] Marcelo: don't have to use v4 mapped, can use another one from IANA. [09:44:41] SIIT is a Proposed Standard and uss v4mapped on the wire [09:44:45] Mark: no problem with other realms seeing different papped address. [09:44:59] anthony.baire joins the room [09:44:59] Dave: you could point that out... :") [09:45:03] (aloud) [09:45:08] Mark: people do it anyway. [09:45:21] that's not the point of this presentation (which space to use) [09:45:27] Niall: in terms of moving this document forward, do the caveats go as text in this document or in compation "how to interpret this document" document. [09:45:30] Marcelo: that would be bad. [09:45:32] that's for the NAT64 document discussion [09:45:40] Niall: my preference too. Caveats have to be explicit. [09:45:53] Now onto R6. [09:45:56] webjabbergroup leaves the room: STATUS_EXIT [09:46:23] We have included DCCP and SCTP on SHOULD part, I have heard some comment from ?? that this should work, must work. Should be in this list, rather than in should part? [09:46:52] s/??/ Magnus Westerlund/ [09:46:54] ??: My prefernece is for MUST. People who had argued I don't see it being I think it's about future safetyness for actually use the protocol. [09:47:11] ?? 2: leave it to BEHAVE, say to BEHAVE that whatever the state of the art is should work. [09:47:23] roque joins the room [09:47:37] rdenisc leaves the room [09:47:40] Let the list happen in BEHAVE. It's a balancing act between what is possible than what is important. [09:47:46] that's Mark Townsley [09:47:50] Thanks [09:47:51] I agree with "?? 2? BTW ... [09:48:14] Jan joins the room [09:48:20] Iljitsch: problem is behave has been mostly about what does work with NATs, not what should work with NATs. [09:48:42] So I'm nto sure if this is an easy solution to leave to BEHAVE, would be nice if we could do DCCP and ?, not sure we can. [09:48:52] Ran: are we trying to design the protocol here or figure out high-level requirements? [09:49:00] Marcelo: so I remove this one, the whole requirement (R6) [09:49:11] Thomas: if we don't support TCP and UDP, what's the point? [09:49:17] Marcelo: that was first iteration. [09:49:25] @thos: BINGO! [09:49:30] Fred: we're repeating ourselves. [09:49:59] Pekka: my understanding with BEHAVE is that they have a number of documetnst aht specify how it should work with respect to each protocol. [09:50:10] iljitsch leaves the room [09:50:11] From this document perspective, should ICMP work, traceroute through NATPT box. I say it must. [09:50:24] iljitsch joins the room [09:50:44] Mark: I agree WRT ICMP. Turn this into a such as ... kind of thing and not try to creat the list of MUSTS here. That's what I'm afraid of, to let the BEHAVE wg decide which ones they have time and energy to work on. [09:51:03] it is not clear icmp is a mandatory ops need. sure would be nice. but the transports users need are more critical. [09:51:05] Marcelo: what Pekka says is strictly true. I have a requirement that says you must comply to BEHAVE. Which requirements do we ask them to comply with? [09:51:27] Mark: if you mke this "such as TCP, UDP, etc" then we won't get endless questions. [09:51:48] ??: we've known about v6 for many years and they have chosen not to deal with it. [09:51:50] @randy: BEHAVE has a doc on ICMP requirements [09:51:53] ??: our charter does not allow us to do that. [09:52:08] ??: ads should have fix this. [09:52:10] benno leaves the room [09:52:16] benno joins the room [09:52:18] thats Dan Wing that said "our charter..." [09:52:30] Chair: we now have a second microphone, would you please line up? [09:52:44] Having trouble keeping up. [09:52:59] can folk here with the new mic? [09:53:05] Yes [09:53:05] hear that is... [09:53:21] Minos vesta? The whole deal with NATs is controversial, we can update the charter, recharter behave to do the work. we didn't have energy? not true, wasn't allowed to be done. [09:53:21] Great to have a second mic [09:53:22] yes, i think so [09:53:28] I can't chagne history. [09:53:29] Magnus Westerlund [09:53:37] bortzmeyer leaves the room [09:53:45] Marcelo: so ICMP is a must. All the rest is up to BEHAVE. [09:54:07] this is Mark Townsley speaking [09:54:10] Mark: what I was trying to get at is that ICMP is a must, whatever it's problematic that there is no one point to point to in BEHAVE that is the things that they thought were important between v4 and v4 nats. [09:54:19] That's what I look at as a starting point for v6 and v4. [09:54:49] Dan Wayne. So we don't have a document that says if you do these six protocols, congratulations, you're a nat. Already working on e.g. SCTP. Directors want those new protocols supported by new technologies like this. [09:54:58] s/Wayne/Wing/ [09:55:02] This is why Magnus and Lars and I think that it's important to do SCCP, etc. [09:55:30] Whast does it mean to be successful? ICMP, TCP, UDP, ??. I think we do need requirements, even if it's just "hit these protocols." [09:55:45] If we hit all these MUSTs, meet all these MUSTs, can we declare success and be happy? [09:55:51] So BEHAVE wants a list. [09:56:34] Thomas: my observation ehre is that I don't think we're ready to mandate SCCP and DCCP. As long as there are protocols that can be implemented obviously. What's needed varies in different cases. If we can cover 90%, that's great, we can do the rest when the market shows a need. [09:56:35] bortzmeyer joins the room [09:56:58] pawal leaves the room [09:57:03] ??: so if I'm going toput in must do IP. If you're trying to be transport-sensitive, we get into enumeration of characteristics. [09:57:05] pawal joins the room [09:57:12] You seem to be almost leaping into this assumption when you start enumerating that it's not IP. [09:57:19] that's geoff huston speaking [09:57:21] If you said must do IP, you don't have the rest of the issue. [09:57:39] Geoff: once you start going into transport sensitivity, find, let's open that up, but "must do IP" is the other option. [09:58:13] Geoff: if you do it at IP, you do not necessarily... If you do it with behaviors that are transport-sensitive, then you get into... If you said must do IP, that is another way of looking at this. [09:58:26] I'm just wondering if you do must do IP, I don't know if you have a solution for that. [09:58:31] (that was Marcelo) [09:59:01] ??: I think that's kind of theoretic, whetehter it's must or should, the question is will we implement, that's not something IETF can answer. I really think it won't make any difference. [09:59:16] That is Remi Denis-Courmont speaking [09:59:16] that was remi denis-courmont [09:59:44] Iljitsch: I do understand Geoff's desire to support straight IP, but I from teh perspective of not constraining the solution set, how would you like to demux on the ipv4 side if you don't look at the port numbers. If you don't do that you must do 1:1 mapping. We don't have enough addresses for that. [10:00:03] Obviously if we say TCP/UDP/ICMP, IP will nicely cover that. This is not about requirements, this is about the solution. [10:00:37] onakayu leaves the room [10:00:42] Mark: With respect to don't try to get magic list of protocols. Dan wants you to, hasn't been able to. If he tried, would never get proper list. What about PPTP? Where does the list begin? TCP, UDP, ICMP. Where does it end? I have no idea, and you don't either. [10:01:03] Must do IP is the big requirement. Now behave, any time you do this ALG thing, you have to decide which are important and which aren't, dependent on who's there to do the work. [10:01:32] Fred: I'm standing here capping the line; We've had a pretty good discussion, you've got more slides, we have more questions, I think we're going to have to take this tot he list. Look at assumptions in document, see if we can simplify. [10:01:45] What I do want to do now is bring up the CPE router discussion. [10:02:15] Oops, Alain first, it looks like. [10:02:31] What is up now? [10:02:36] Alain Durand [10:02:53] Post IPv4 "completion" [10:02:59] Ah. Thanks [10:03:09] http://www3.ietf.org/proceedings/08jul/slides/v6ops-4.ppt [10:03:10] Keeping the internet going. Not academia here. We are not here to solve every single problem. Here to make sure internet keeps going. [10:03:28] We have some priorities, tradeoffs between different approaches. Hope we go for simplest solution, complexity creates fragility. [10:03:40] My company has made no decision to implement any of the following technogies. [10:03:43] benno leaves the room [10:03:49] benno joins the room [10:04:06] At some point there will be no more IPv4 addresses. Not a D-Day. Things are allocated in blocks, if you go ask for 10m address, maybe will be denied way before you go and ask for 5 and are denied. [10:04:22] If you are in business of deploying very large networks, impacted before you would be if you had five IP addresses. [10:04:39] Are we are on slide 3? [10:04:45] I'm coming from broadband, edges are going to be v4 for long time, bunch of computers in customer networks, older version of windows and Mac OS [10:04:49] "post ipv4 completeion" [10:04:51] "Post IPv4 Completion" slide. [10:04:55] satoru.matsushima leaves the room [10:05:09] Most things will never go to v6. Customers rarely throw away the old stuff. Very long wait to get rid of old stuff. [10:05:13] that there will v4 at the edge for a long time does not mean that we should inhibit v6 at the egde [10:05:16] Yup, but which slide in Post IPv4 completion"? [10:05:17] Now almost no content available on V6. [10:05:27] "The "internet" edges will still be mostly IPv4" [10:05:36] thanks [10:05:42] Cell phone has new protocol, v6, but also has to roam into legacy networks with only v4. [10:05:48] This device very likely dual-stack. [10:05:55] Color code. [10:06:22] onakayu joins the room [10:06:23] Residential deployments [10:06:37] Thanks for the slide change info [10:06:42] onakayu leaves the room [10:07:12] We have been talking about two types of tech, multiple layers of IPv4 nat, or dual-stack lite, provisioning home gateways with IPv6. When nodes inside of home, datagrams instead of being translated by home gateway are shipped through v6 tunnel to some kind of NAT in middle of service provider that's going to share IP addresses. [10:07:30] Complexity Trade-off [10:07:32] danwing leaves the room: Replaced by new connection [10:07:37] You increase complexity with dual v4 nat. [10:07:54] Network is so large doesn't fit into RFC1918. Hard to debug. Have to figure out which Net 10 the customer is in. [10:07:56] roque leaves the room [10:08:00] Problems at boundaries between each Net 10. [10:08:16] When you put firewalls at boundaries, configuration really hard to debug. [10:08:19] Takes a week or more. [10:08:44] Even worse, you may have some customers who have own v4 address, coming to access router, at same time same access router, new customers may have private address. [10:08:59] So access router has to make routing decision based on source address. Possible, but adds a layer of complexity. [10:09:02] Andrew McGregor joins the room [10:09:10] This is one side of tradeoff. Other side is that we have new home gateway. [10:09:32] In some cases this is possible to do, in some cases difficult. So you may choose this complexity, or complexity of going to v6. [10:09:42] You have to think about complexity impact on provider. [10:09:46] "Wirelesws deployments" [10:09:53] benno leaves the room [10:09:59] benno joins the room [10:10:18] V6 nodes need to communicate to V4 internet. Two kinds of solutions, NAT-PT, NAT64, IVI. Everything that fits into problem statement. At some point there is a NAT that's going to translate this into v4. [10:10:40] Other way, dual stack lite. End device is dual-stack capable. If you want to send a v4 packet, you tunnel it over ipv6, v4-to-v4. [10:10:41] marijk leaves the room [10:10:50] Back to complexity trade-off slide. [10:11:26] If you start with something that's really v6, want something that is really v4, you have some DNS games to play. There is impact on DNSSEC. How do you know if you are talking to real v6 or translated v4 address? [10:11:35] pawal leaves the room [10:11:40] Fundamentally there is this notion of a DNS ALG in the net. [10:11:41] pawal joins the room [10:11:48] What they do is they lie, DNS lies. [10:11:58] My DNS experience in the past is that when you get DNS to lie, bad things happen. [10:11:59] fdupont leaves the room: Computer went to sleep [10:12:20] Secondly, ALGs have to look into the payload, they might be ?? addresses in the payload. V4-to-v4, it's a simple substitution. [10:12:42] In v6 nat, you replace 32-bit field with 128 bit field. That means you have to change the packet length, may have fragmentation. Complexity. [10:14:03] There is a NAT in the service provider network. Everyone is going to want port 80. If you are using UPnP, we've been looking at code for UPnP, typical application starts by saying "I want to use this port", if someone is using it, UPnP says "release it." Impolite. [10:14:08] Not acceptable other than in home. [10:14:34] Any of those situations that have been described here, this is not going tow ork. When we move to carrier grade NATs, all of those NATs are going to have problems. [10:15:07] In terms of requirements and non-requirements. When we go from v6 to v4, even those cell phones will most probably be dual stack, have not seen anything that's really pure v6, even cable modems. [10:15:39] So when you talk about communication, in my opinion, requirement is to have something that is dual stack but only v6 communicating to v4 internet. Don't ahve strong feeling on v4 requirement for devices with only v6 stack being able to communicate with v4 internet. [10:15:48] If you make this disctinction you open up solution space to a lot of other things. [10:15:54] IPv4-IPv6 [10:16:10] brabson leaves the room [10:16:18] there will be addresses in small quantities long after in large quantities. If you choose v6 only, you paint yourself into a corner. [10:16:47] Don't necessarily have to do it, and it's more difficult, so seems to me that finding a solution for going from v4 device to v6-only server is not my top priority. [10:17:11] whan the nat is not at the edge, the customer is no longer in charge of their own destiny [10:17:14] Thaler: one slide in presentation I didn't follow, you started off by saying homes have v4-only devices. [10:17:42] hirocomb leaves the room: Replaced by new connection [10:17:47] Wireless deployment seemed to show IPv6-only. I didn't follow how that can be deployed in a useful network outside of sensor networks. [10:18:06] hirocomb joins the room [10:18:07] randy: of their v4 destiny, that is. they can always start using v6 alongside, or tunnel v4 in v4 UDP (e.g. ICE, etc.) instead of doing uPNP etc hacks [10:18:09] marijk joins the room [10:18:24] Given that tehre's a lot of these legacy hosts, incentives for comcast to support existing hosts, why is it important for us to think abotu the case where you have only IPv6 addresses? [10:19:02] Alain: think about a company that we want to deploy a new wireless 4Gv4 service. New cell phones, new device. This device has to be able to go on legacy 2G, 3G wireless networks, also 4G. When in 2 and 3G networks probably only IPv4. So use v4 stack. [10:19:12] pawal leaves the room [10:19:18] pawal joins the room [10:19:26] @dt: my worry is an enterprise connecting and can not get v6 space [10:19:32] In 4G environment, may be the case that there is simply not enough v4 addresses to handle 100m devices. So wireless carrier may only give v6 address, will provide v4 connectivity without v4 address. [10:19:49] Thaler: thing you believe is requirement is for the case where there is a network that only allows new dual-stack devices connected to it. [10:19:58] randy: I have two /48s that I hardly use. want some? [10:20:01] You don't care if a legacy device works or not. This is a network intended only for new devices. [10:20:14] Wes Beebee. IPv6 CPE router draft. [10:20:29] @iljitsch: foad [10:20:46] what's a foad? (and someone has been on twitter too long...) [10:20:48] brabson joins the room [10:20:59] Meta-level comments. We're putting this document on as informational status, not standards track because we wanted to find not just minimal requirements for interoperability but also to give guidance for imp,ementors to be able to provide a consistent high-level architecture so taht users can know what to expect from such a device. [10:21:03] please re-open the windows, someone who is near them [10:21:07] On one hand, node requirements, minimal set of requirements. [10:21:07] my error: [10:21:16] my error [10:21:29] dt: my worry is an enterprise connecting and can ONLY get v6 space [10:21:39] Other hand, cable/DOCSIS e-router device. A particular implementation. We want to besomewhere in the middle where we're relevant to more than just one deployment pattern, but move beyond simple node requirements. [10:21:39] ah [10:21:43] that makes more sense [10:21:50] I'm going to talk about why we wrote this draft, description of device, work that needs to be done. [10:22:13] Last IETF it was pointed out that v6ops has draft for cpe router security but no specification for cpe router, so difficult to talk about security of a device that we had not defined. [10:22:31] cable standards have devined an E router but no-one has defined standalone IPv6 router, considered out of scope for cable. [10:22:42] I have difficulty seeing a scenario where an enterprise would not get even a single v4 public address, or at the very least private space v4 addresses. Whether these are sufficient for the purposes of the enterprise is another topic.. [10:22:51] Mainly focusing on DLS, will also add cellular. [10:22:55] DSL [10:23:05] Intended to be widely applicable while focusing mainly on IPv6 requirements. [10:23:18] Probably also IPv4 requirements, but IPv4 CPE router seems a well-understood concept. [10:23:27] (he's reading the slides) [10:23:33] psavola: is that a useful discussion? there are people who can't get what they would like today, this is going to get worse as we run out of v4 space [10:23:49] btw: last check: still 1008 million v4 addresses available [10:23:59] we're going to hit the 1 billion mark next week or so [10:24:19] Device Description slide [10:24:27] the point is that users are going to have a v4 connection that works for simple client-server use. the rest may or may not cost extra. [10:24:31] CPE router bridged to WAN, or plain CPE router device. [10:24:43] One possible assignment of addresses to box (Routing Domains and Address Assignment slide) [10:25:00] benno leaves the room [10:25:07] benno joins the room [10:25:08] WAN can get address by DHCP, or a delegation prefix. Loopback can be configured, LAN port can be configured, can dish out PDs for downstream. [10:25:20] pawal leaves the room [10:25:20] Numbered model: IPv6 global address on every interface. [10:25:26] pawal joins the room [10:25:35] what's a gua? [10:25:37] Unnumbered: there exists at least one interface for which there isno GUA configured, but at least one GUA somewhere. [10:25:39] GUA = globally unique address?? [10:25:44] Yeah [10:25:49] ugh [10:26:08] One case: L2 bridge between cable modem device and embedded CPE router, WAN interface is logical interface. [10:26:22] We need DHCPv6 server for downstream cascade rotuers, PMTU discovery, simple firewall, ACLs. [10:26:22] I didn't miss him explaining what the loopback address is good for, did I? [10:26:28] [and strictly, ULA is a proper subset of GUA] [10:26:30] better not open up that can of worms at the mike [10:26:45] Other security features beyond basic features. Cascading routers in the home, reference software ties (?) [10:26:49] "Pending Work..." [10:26:54] Add pictures, reorganize. [10:27:02] Change draft after consensus has been reached on addressing. [10:27:10] (reading slide again) [10:27:23] Brian Haberman leaves the room [10:27:32] Next pendign work slide [10:27:38] brabson leaves the room [10:27:46] Fred: what would MIB be? [10:27:59] Presenter: list of knobs to be configued on device. [10:28:05] Conclusion slide. [10:28:20] brabson joins the room [10:28:25] Alain: I think I would liek to change first bullet to conclusion slide. [10:28:41] john.zhao leaves the room: Computer went to sleep [10:28:49] Given volume of discussions, on what to do with ULA or not ULA, or what to do with dual mode of configuration, depending where you put the address. [10:28:54] I'm not seeing much convergence here. [10:29:13] One thing for ULAs, you could NDNS for instance to creat [10:29:21] in ipv4 you could use 192.168.0.1. [10:29:35] It looked like you could get a stable name out of MDNS and use ULA to back that. [10:29:40] The mike line is too long, but my question is: where is the open issues list for this draft, so we can quantify the non-consensus [10:29:44] nm leaves the room: Replaced by new connection [10:29:45] nm joins the room [10:29:47] Various people mentioned that ULAs seemed to be useful for configuring in the home, particularly before GUA has been assigned to the box. [10:30:02] We need to make sure end-user connectivity is stable if there is a renumbering after the GUA comes through. [10:30:07] Mkae sure connectivity isn't lost during that process. [10:30:18] So there are sort of higher level meta-requirements that it seems we are coming to some convergence on. [10:30:41] chairs: can you say something about making this a wg document? [10:30:44] If we end up with more than one solution, I would like to take a few of the most important or solutions and talk about the pros and cons so that somebody reading this draft can say hey wait, these set of requireemnts are mu must haves. [10:30:46] (I think it should be one) [10:31:00] These pieces are some possible choices we could have that we know work, and here are the pros and cons. [10:31:06] i think that is lined up after the microphone [10:31:09] benno leaves the room [10:31:14] So that's what I envision this document becoming. Alain: you are obviously much more optimistic than I am. [10:31:15] benno joins the room [10:31:28] pawal leaves the room [10:31:30] Shi Me Kyu from NT: still questions about application running on the ?? [10:31:34] pawal joins the room [10:31:39] That kind of things is not well defined on new draft. [10:31:45] Presenter: what is not well-defined? [10:31:46] swshin92 leaves the room [10:31:54] swshin92 joins the room [10:31:56] I am confused about if router is in host mode case for example. [10:32:09] brabson leaves the room [10:32:10] If you say that unnumbered model is needed, that means architecture is restricted to weak model. [10:32:19] Presenter: not saying each CPE must do eithermodel. [10:32:30] Shi: only weak model. [10:32:42] Presenter: in numbered case you could have strong model. [10:32:51] Microsoft's current requirements for IPv6-capable home routers are at http://www.microsoft.com/whdc/device/network/IPv6_IGD.mspx [10:33:10] Thomas: I am worried that you are being too optimistic about one document being able to satisfy all of the goals. [10:33:22] There are too many proscriptive words that are unjustified, and probably not warranted to mandate. [10:33:43] If this document is going to be useful, lay out "here's a technology you may find is useful." Don't make value judgements. [10:33:50] kikuyuta joins the room [10:34:02] Presenter: there are three different pieces, mandatory node requirements, if you don't have this you're not interoperable. [10:34:08] Next, we'd like to have this stuff, nice for user experience. [10:34:09] kikuyuta leaves the room [10:34:23] Then there's other stuff that we haven't worked out the details for yet, playign with different models, trying to figure out what works. [10:34:28] There's content that appears in all three categories. [10:34:39] We're trying to clearly delineate the boundaries between the three categories of stuff. [10:34:52] becarpenter leaves the room [10:35:07] narten leaves the room [10:35:09] nm leaves the room: Replaced by new connection [10:35:14] James from Apple: I just heard you say you have those three categories, but ti sounds like there's already a set of mandatory requirements for routers, CPE rotuers are routers, if you're not interoperable with routers, then you're not, don't see why we need this document. [10:35:14] jpc leaves the room [10:35:18] That leaves the other two categories. [10:35:28] If this document is just those two categories, why is it an IETF document? [10:35:30] nm joins the room [10:35:43] Presenter: first category, we're not going to duplicate existing RFCs. We're going to reference to that RFC. [10:35:48] jpc joins the room [10:35:56] But I think as we go along we've found that there are some holes. [10:36:01] Maybe Hemant wants to talk some more. [10:36:28] Hemant: this device has a bridge, combined with broadband cable/dsl, not a simple router that can be sitting in a node document. Very simple state, a bridge/router/switch combined. [10:36:47] There is no simple document for this. [10:36:55] We think that the doc has legs because of that. [10:37:16] Iljitsch: in a former lifetime I worked at ISPS it would be useful at ISPs to know what kind of service to provide so that customers can connect. [10:37:18] benno leaves the room [10:37:25] benno joins the room [10:37:36] pawal leaves the room [10:37:39] Even more important, if you have CPE that connects to cable/adsl, you can buy second CPE, replace first one, and it all works. [10:37:43] pawal joins the room [10:37:44] anthony.baire leaves the room [10:37:47] We have to make sure that we agree on how to do prefix delegation etc. [10:37:56] Not necessary to do here, but most of those people come here, so why not here. [10:38:11] jpc leaves the room [10:38:12] Agreed [10:38:32] ??: I think we can agree that there is some stuff that's required for CPE router that's not required for other routers. If it were a plain router, we wouldn't be doing this. [10:38:32] tvest leaves the room [10:38:47] James: don't know if you need to do that. [10:38:55] shep leaves the room [10:38:58] ??: we could discuss doing DHCPv6 server, but I think client is required anyway. [10:39:07] Alain: I'd like to address second bullet. [10:39:15] A lot of this driven by deployment model in Service Provider. [10:39:32] The doucment that somehow ?? to that goal is valuable. But I don't think current state of document is advanced enough to fit that goal. [10:39:44] kurtis@jabber.psg.com leaves the room [10:39:53] If it said these are some of the tradeoffs, maybe it would get closer to that point, but as of today would not support this document as a WG item. [10:39:57] Presenter: thank you [10:40:03] Fred: out of time [10:40:14] nov leaves the room [10:40:24] What do you think about this document? Content needs work. Do you want to have a CPE router recommendations document? [10:40:26] swshin92 leaves the room [10:40:27] ruri leaves the room [10:40:38] Show of hands. [10:40:41] aalain leaves the room [10:40:45] One hand for "not needed." [10:40:48] Exodus leaves the room [10:40:56] matthijs leaves the room [10:40:59] I think the general consensus is that we do want to have "a" document. This document needs a lot of work. [10:41:14] Question now, should we take this doc make it a wg item and work it, or wait for the fall meeting to make that decision? [10:41:29] Thomas: what do we think needs to happen to document before we could accept it? I don't think we have consensus. [10:41:32] nm leaves the room [10:41:34] Ran: discuss on list. [10:41:36] psavola leaves the room [10:41:44] Fred: okay fine done for today. [10:41:49] benno leaves the room [10:41:56] ruriham joins the room [10:41:57] hirocomb leaves the room [10:41:59] ruriham leaves the room [10:42:13] keyajima1 leaves the room [10:42:44] philip_matthews leaves the room [10:42:52] Matt Zekauskas leaves the room [10:43:23] Ted Lemon leaves the room [10:43:26] Jan leaves the room [10:43:41] mohsen leaves the room: Computer went to sleep [10:43:45] pawal leaves the room [10:43:51] pawal joins the room [10:45:18] magnus leaves the room [10:46:37] bortzmeyer leaves the room [10:49:27] tvest joins the room [10:50:47] iljitsch leaves the room [10:51:31] Suz@ISC leaves the room [10:51:49] tvest leaves the room [10:52:58] sohgo joins the room [10:53:06] Andrew McGregor leaves the room [10:54:29] WPM01906 leaves the room: Replaced by new connection [10:54:30] WPM01906 joins the room [10:54:40] WPM01906 leaves the room [10:55:07] sohgo leaves the room [10:57:37] john.zhao joins the room [10:59:29] atarashi leaves the room [11:01:36] DThaler leaves the room [11:02:48] bortzmeyer joins the room [11:03:43] lynch leaves the room [11:07:08] frodek leaves the room [11:10:33] OatWillie leaves the room [11:12:25] john.zhao leaves the room: Computer went to sleep [11:18:44] pawal leaves the room [11:21:38] randy leaves the room [11:23:02] kikuyuta joins the room [11:23:06] kikuyuta leaves the room [11:23:15] kikuyuta joins the room [11:24:03] kikuyuta leaves the room [11:24:08] kikuyuta joins the room [11:24:09] marijk leaves the room [11:24:10] kikuyuta leaves the room [11:26:07] kikuyuta joins the room [11:26:35] kikuyuta leaves the room [11:27:46] bortzmeyer leaves the room [11:33:48] bert joins the room [11:33:59] bert leaves the room [11:34:55] kikuyuta joins the room [11:35:13] kikuyuta leaves the room [11:35:56] bortzmeyer joins the room [11:38:15] tvest joins the room [11:40:26] frodek joins the room [11:44:11] mohsen joins the room [11:50:26] fdupont joins the room [11:50:46] fdupont leaves the room [11:54:49] tvest leaves the room [12:01:15] frodek leaves the room [12:02:53] nov joins the room [12:05:18] tvest joins the room [12:06:11] mohsen leaves the room [12:07:21] onakayu joins the room [12:10:58] hirocomb joins the room [12:11:13] hirocomb leaves the room [12:14:47] Mark Townsley joins the room [12:15:56] Mark Townsley leaves the room: Replaced by new connection [12:15:56] Mark Townsley joins the room [12:17:40] DThaler joins the room [12:17:53] Mark Townsley leaves the room [12:18:33] Mark Townsley joins the room [12:18:38] Mark Townsley leaves the room [12:29:25] bortzmeyer leaves the room [12:38:27] mohammed joins the room [12:39:32] mohammed leaves the room [12:42:40] Mark Townsley joins the room [12:53:50] Mark Townsley leaves the room [12:53:50] onakayu leaves the room [14:07:32] DThaler leaves the room: Replaced by new connection [14:07:35] nov leaves the room [14:07:45] DThaler joins the room [14:26:31] onakayu joins the room [14:28:52] tvest leaves the room [14:41:49] DThaler leaves the room: Replaced by new connection [14:42:44] DThaler joins the room [14:43:19] DThaler leaves the room [16:07:28] onakayu leaves the room [16:17:52] Exodus joins the room [16:18:06] Exodus leaves the room [16:18:29] Exodus joins the room [16:18:35] Exodus leaves the room [16:20:50] Exodus joins the room [16:21:59] Exodus leaves the room [16:23:16] Exodus joins the room [16:39:04] Exodus leaves the room [16:39:18] Exodus joins the room [16:39:22] Exodus leaves the room [17:00:04] Exodus joins the room [17:01:57] Exodus leaves the room [17:10:33] jpc joins the room [17:34:33] jpc leaves the room: Replaced by new connection [17:34:33] jpc joins the room [17:35:13] jpc leaves the room: Replaced by new connection [17:35:13] jpc joins the room [18:02:41] Exodus joins the room [18:03:03] Exodus leaves the room [18:03:10] Exodus joins the room [18:03:34] Exodus leaves the room [18:49:58] jpc leaves the room [20:26:33] jpc joins the room [22:04:44] jpc leaves the room: Replaced by new connection [22:04:45] jpc joins the room