[16:05:37] stevey joins the room [16:05:38] Dave Thaler joins the room [16:05:46] Dave Thaler has set the subject to: 6AI BOF - IETF 74 [16:06:00] stevey leaves the room [16:06:12] DDD joins the room [16:06:16] momose joins the room [16:06:16] karen.s.seo joins the room [16:06:56] iljitsch joins the room [16:06:58] ruriham joins the room [16:07:05] mlepinski joins the room [16:07:09] hirocomb12 joins the room [16:07:12] jcossio joins the room [16:07:25] Doug Otis joins the room [16:07:30] csp joins the room [16:07:37] Doug Otis leaves the room [16:07:38] karen.s.seo leaves the room [16:07:39] ruriham leaves the room [16:07:47] jjones joins the room [16:08:18] eliot.lear joins the room [16:08:21] Bob joins the room [16:08:26] Li-Fan WU joins the room [16:08:56] Bernie joins the room [16:09:02] shep joins the room [16:09:06] kanda joins the room [16:09:08] bruce joins the room [16:09:08] suz joins the room [16:09:16] We need a scribe [16:09:19] satoru.matsushima joins the room [16:09:22] behcet joins the room [16:09:23] Margaret Wasserman joins the room [16:09:28] Mark Townsley joins the room [16:09:31] is it me or is dave really quiet? [16:09:34] Eadson.zhangdong joins the room [16:09:35] slblake joins the room [16:10:08] mikemlb joins the room [16:10:09] eliot: a short mic-handling primer was given to dave, better now? [16:10:09] hyperfeng joins the room [16:10:34] better thanks! [16:10:42] dave is on the architechtural principles slide - not sure where the online version is. [16:10:47] karen.s.seo joins the room [16:10:53] karen.s.seo leaves the room [16:11:13] fujisaki joins the room [16:11:26] solution space then global PI addresses slide [16:11:29] Doug_Otis joins the room [16:11:33] Wes Beebee joins the room [16:11:51] please speak closely to mic [16:11:53] ruriham joins the room [16:11:55] are the slides online? [16:12:05] eliot.lear leaves the room [16:12:07] Yes, all slides are online [16:12:17] Slides: http://www.ietf.org/proceedings/09mar/slides/6ai-0.pdf [16:12:21] Dave is on slide 6 [16:12:23] thanks! [16:12:35] mikemlb leaves the room [16:12:50] slide native local, and tunneled global addresses (7) [16:14:12] becarpenter joins the room [16:14:33] wmhaddad joins the room [16:14:41] slide local addresses with NAT in the network (8) [16:14:45] teemu joins the room [16:15:16] mikemlb joins the room [16:15:50] JonathanLennox joins the room [16:15:53] DDD leaves the room [16:15:55] slide end-to-end transparency [16:17:02] slide recommendations [16:17:38] (from the slide) 'consider end-to-end transparency a requirement for any solution' [16:17:42] arifumi joins the room [16:18:02] eric n at the mic [16:18:26] (eric) might take a while to get community consensus, was there discussion on timeframes? [16:18:51] (dave) yes, see slide 6 [16:19:07] margaret wasserman (?) at the mic [16:19:43] eliot.lear joins the room [16:20:01] (margaret) how does it connect in? beying able to deploy without coordination with anyone else is a market requirement [16:20:20] Ole Troan joins the room [16:20:21] ? at the mic [16:21:05] Jari Arrko [16:21:12] now Ran A. [16:21:16] randall atkinson at the mic [16:21:44] (randall) not obvious to me that there is a single market for this, different markets for this capability with different requirements [16:22:13] Mark Townsley leaves the room: Replaced by new connection [16:22:14] Mark Townsley joins the room [16:22:24] margaret wasserman up presenting NAT66 - draft-mrw-behave-nat-02.txt [16:22:52] slide why do people deploy NAT (2) [16:23:05] jishac joins the room [16:23:40] Atarashi Yoshifumi joins the room [16:24:54] http://www.ietf.org/proceedings/09mar/slides/6ai-3.pdf - now up to slide address independence [16:25:11] DDD joins the room [16:26:06] shamus joins the room [16:26:35] slide topology hiding - mentioning that it is out-of-scope for this bof [16:26:43] slide so what is NAT66 [16:27:17] slide simple nat66 example [16:27:39] Which slideset is it please? [16:27:44] #6 [16:28:22] the example covers just changing the address, not the ports and thus no state being maintained on the NAT device. [16:28:38] hyperfeng leaves the room [16:28:48] jari jumping in to comment that as presented, the example breaks tcp checksums. [16:28:52] 6ai-6.pdf? [16:28:56] Antonio Moreiras joins the room [16:29:00] oh, sorry. [16:29:03] ddd: http://www.ietf.org/proceedings/09mar/slides/6ai-3.pdf [16:29:12] #6 now #7 of that file [16:29:26] slide business to business vpn (8) [16:30:07] mikemlb leaves the room: Replaced by new connection [16:30:14] thanks [16:30:45] keith warran was at the mic [16:30:53] now fred baker at the mic [16:31:32] Doug_Otis leaves the room [16:31:41] (fred) what really wanted to have is a host identifier that can be used on both sides of the nat [16:31:46] (thats a poor paraphrasing) [16:32:20] greg daly was at the mic [16:32:21] Doug_Otis joins the room [16:32:37] mikemlb joins the room [16:32:42] james woodhouse at the mic asking whether this is the Q&A phase [16:33:08] more questions will be at the end. [16:33:17] back to the presentation - slide simple multihoming (9) [16:34:15] lebobits joins the room [16:34:34] slide two-way algorithmic mapping (10) [16:35:03] maybe we could get the requirements for that private netowrk to private networking conenctivity example in detail and see if there isn't a better solution? [16:35:28] didn't catch the name of the guy who stood to make that comment (the one after Keith) [16:35:28] See Fred Baker's draft; I think there is a discussion there. [16:35:40] which of fred's many? [16:35:51] He also talked about it in his Behave slides in Minn. [16:35:56] this slide answers jari's earlier comment about checksums breaking. [16:36:04] http://tools.ietf.org/id/draft-baker-v6ops-b2b-private-routing [16:36:54] slide two-way mapping example (11) [16:37:27] matsuri ? at the mic [16:37:38] marcelo [16:37:57] do you need state for the mapping - answered is essentially stateless (configuration on the nat device) [16:38:02] matsuri is a festival. [16:38:24] you need state if you want to reverse the mapping at the destination NAT66 [16:38:26] heh - ok, marcelo bagnulo according to attendees list. [16:38:50] slide ipv4 na(p)t vs nat66 (13) [16:38:55] @slblake: you need the configuration information (but not any per-flow state) [16:39:06] (or per-address state) [16:39:24] @slblake: thx for the ref [16:39:59] slide decomposition of an IPv4 NAT (14) [16:40:19] Dave: if I send you a packet, and my NAT66 changes my source prefix, if you want your hosts to see the source prefix I originally put in my packet, your NAT66 needs some state about my network at least. [16:41:38] slblake: slide 10/11 of http://www.ietf.org/proceedings/09mar/slides/6ai-3.pdf covers what state is required. [16:42:13] Atarashi Yoshifumi leaves the room [16:42:27] agree but I prefer a different model which I'm talking about in the SAF presentation which doesn't impact the other guy's host. The problem with the model you're referring to is that it does not avoid impact to others if you choose to deploy NAT66 in your network. [16:42:39] ? at the mic - if you want to hide the topology, you don't want machines to be accessible from the outside. [16:42:41] James Kempf [16:42:45] now james kent at the mic [16:42:54] kempf [16:42:58] Atarashi Yoshifumi joins the room [16:43:01] Dave: agreed [16:43:22] james woodhouse at the mic [16:43:43] ooo james kempf used the "C" word [16:43:51] no more clarifying questions, back to the presentation. [16:44:02] everyone want his question clariified [16:44:05] jcossio leaves the room [16:44:11] slide decomposition of an IPv4 NAT #2 - #15 [16:44:35] bruce will settle for name and question being clearly pronounced. [16:45:01] slide decomposition etc #3 ( 16) [16:45:01] ?: we already have technology that will reject incoming packets, a NAT66 wouldn't have to provide that functionality [16:45:22] jpcerezo joins the room [16:45:39] karen.s.seo joins the room [16:46:33] slide: decomposition etc #4 - 17 [16:47:24] slide decomposition of an IPv4 NAT #5 - 18 [16:48:46] keith at the mic [16:49:10] what about we call it NAT666? [16:49:19] (keith) its not the case that dns names solve the problem (split view either side of the nat/firewall divide) [16:49:22] behcet leaves the room [16:50:23] eric at the mic [16:50:50] karen.s.seo leaves the room [16:51:02] karen.s.seo joins the room [16:51:14] Erik Nordmark [16:51:16] greg daly at the mic - isn't stun done in the application? [16:51:20] Greg Daley [16:51:36] slide side-by-side comparison - 19 [16:52:09] slide why publish nat66 - 20 [16:54:26] suggestion is to document ipv6 nat before manufacturers come up with a range of solutions [16:55:42] gregory lebovitz at the mic - reconfirming iab comments [16:55:53] ? at the mic [16:55:58] Tim Chown [16:56:21] We need a requirements traceability from IAB to Margaret's NAT66 proposal... [16:56:23] (tim) are we limiting nat66 to address translation [16:56:26] (Dave Thaler & Stuart Cheshire indicated agreement with Greg on Greg accurately representing the IAB's view) [16:56:47] stuart cheshire at the mic [16:57:11] spefically what I said was the IAB statement currently in draft does not prohibit this work. What is says is that IF such work moves forward it needs to adhere to some principles [16:57:12] Hemant Singh joins the room [16:57:22] (stuart) NAT is not a firewall - its an address sharing mechanism - much simpler ways of blocking connections [16:57:37] tinnami joins the room [16:57:39] and make statements clearly about how it adheres to those principles [16:58:10] erik kline at the mic [16:58:14] and any short term elements that will be done away with long term and how they will be done away with [16:58:31] I know that's general, but I don't want to rewrite the draft here [16:58:33] (erik) is address hiding considered in-scope for any potential WG? [16:58:36] read it at: [16:58:41] (reply was yes) [16:59:17] greg daley at the mic again [16:59:26] ok, I've missed the question as asked [17:00:23] http://tools.ietf.org/html/draft-iab-ipv6-nat-00 [17:00:28] clarifying how I interpreted... Erik Kline's question was whether it's _potentially_ in scope so I took Bob's reply as saying it's possible to consider (rather than a definite in scope, or definite out of scope). your interpreation may vary. [17:00:32] and it is only a -00 [17:00:56] greg daley's comment: [17:01:01] tony hain now presenting http://www.ietf.org/proceedings/09mar/slides/6ai-1.pdf [17:01:14] slide engineering trade-offs [17:01:14] there is state in the enterprise edge no matter what, because they filter (Firewall) there. [17:01:43] Whether there is or isn't stateless NAT66, there will be state there. Greg Daley just wanted to clarify that [17:02:11] and, as a Juniper FW architect, well familiar with both NATs and FW's, Greg's statement is 100% true [17:02:17] Can you get closer to the mic? [17:02:33] behcet.sarikaya joins the room [17:02:41] Tony apparently has not read SAF (same answer as to slblake in jabber...) [17:04:35] becarpenter leaves the room [17:04:50] becarpenter joins the room [17:05:22] stuart cheshire at the mic after that round of confusion [17:06:08] (stuart) since its a 1:1 mapping, its essentially stateless. [17:06:28] margaret's slide #6 up on the screen - example of NAT66 [17:06:51] jcossio joins the room [17:07:14] dave thaler at the mic. [17:07:41] (dave) agree with tony's rephrasing - will cover some other stuff later during my presentation [17:08:13] back to presentation, still on engineering trade-offs [17:08:14] the incorrect statement was something like "the notion you can get e2e transparency with nat66 is disingenuous" [17:08:30] talking about point 2 under long-term impacts - destroys security audit trail [17:09:38] is tony still at cisco? [17:09:43] yes [17:10:01] Item 5 on the slides for Long term impact [17:10:13] one cannot remove NAT66 over time [17:10:28] because if Fred's one application that was used to justify NAT66 [17:10:42] was two Enterprises sharing machines and data betrween them [17:10:55] such use case won't disappear over time - there are here to stay [17:11:06] Tony has not read the same version of GSE as I have... In the version of GSE I read, the address writing only happens within and at the edges of the end-domain. [17:11:18] sklvarjo joins the room [17:11:31] slide trade-offs - long term impact vs short term [17:12:04] essential point is that any document resulting is tagged as experimental, not as standards track [17:13:20] Margaret: you are right [17:13:20] christian vogt with http://www.ietf.org/proceedings/09mar/slides/6ai-6.pdf [17:13:42] note that the online version of that differs slightly from what is being presented. [17:13:56] As far as I can tell, Tony started his presentation by saying that people will implement and deploy IPv6 NAT whether we document it or not. At the end, he said that if we document an IPv6 NAT, people will implement what we write. That is exactly my point. Although, apparently Tony and I see those two facts and reach different conclusions about what the IETF should do. [17:13:56] cmadson-ietf joins the room [17:14:17] qualifying the harmfulness of address translation - draft-vogt-address-translation-harmfulness [17:14:48] slide classic many to 1 nat [17:17:07] slide classic many to 1 nat - diagram has changed to emphasis in red overloading and rewriting components [17:18:16] slide 1 to 1 nat without address overloading [17:18:40] (a 1:1 NAT being essentially stateless) [17:19:06] Fred Baker joins the room [17:19:10] gregory at the mic - if there is a 1:1 mapping, how does that provide topology concealment? [17:19:35] (christian) one way to do that would be to scramble the mapping in some way [17:19:38] JonathanLennox leaves the room: Computer went to sleep [17:20:08] david at the mic - property your talking about is a local not global property [17:20:21] NAT66 hides the subnet bits unless you know the config data [17:20:54] (david) if I have two NAT boxes, and they have different external prefixes, they would have two internal addresses [17:21:37] margaret at the mic - possible with NAT66 to do it either way - [17:21:39] mohsen joins the room [17:21:56] (david) if you can configure it differently your architecture is different [17:22:48] jpcerezo leaves the room [17:22:55] greg daley at the mic - if we are just changing the prefix, can it not be argued that we're not hiding the topology? [17:23:22] (christian) it depends on how you do this 1:1 mapping [17:23:52] (greg) unless you maintain state, whatever you do would eventually be mapped out (paraphrased) [17:24:02] jari at the mic - lets not do the design here [17:24:51] ? at the mic - not hiding the number of hosts you have [17:24:53] remi [17:25:17] remi Denis-Courmont says the attendee list [17:25:18] shamus leaves the room [17:25:27] let me be clear: if there is a well known algorithm, AND [17:25:39] margaret at the mic - multihoming case is something we can consider seperately. [17:25:49] multple devices from different vendors can take a return path pkt from outside, headed inward, AND [17:26:07] correctly map it from the ouside addr to the inside addr, THEN [17:26:07] back to presentation - slide impacts [17:26:13] a hacker can do the same [17:26:19] so there is NO topology hiding [17:26:26] we need to all agree on that fact [17:26:50] I'm not saying there needs to be top hiding [17:27:09] If you do any type of NAT, you have to deal the concept that a single host may use two different addresses (its internal address in some cases, and its external address in others). Of course, if you have hosts with two interfaces, you also have to deal with the fact that the same host will use two addresses. [17:27:13] just that we don't want to believe falsely that this does something when in fact it does not [17:27:36] Greg: 1:1 NAT means that host counting is possible. I'm not sure that every conceivable scheme would allow you to determine whether two hosts were on the same link (NAT66 allows you to do so, since you can see the transport checksums). [17:27:36] lebobits: some people might think that giving external people a different idea of the topology is better than letting them know the actual topology [17:27:50] keith moore at the mic [17:28:23] great point, Keith [17:28:31] (keith) NAT doesn't include the cost of lost opportunity [17:28:37] If you describe the typical NAT66 as many:1 and NAT66 (no multihoming) as 1:1, then a multihoming situation where you have a host with one internal host that has two external addresses would be 1:many. [17:29:18] jishac leaves the room [17:29:21] teemu leaves the room: Replaced by new connection [17:29:21] teemu joins the room [17:29:31] @ slblake: if you can deterministically understand the out-to-in mappings after seeing the outbound mapping, then you KNOW the internal address [17:29:46] The one (host):many (addresses) case happens all of the time even in networks that don't use NAT. [17:29:51] teemu leaves the room [17:29:52] unless there is a private salt/seed that is cryptographically mixed in [17:29:57] dave thaler up with http://www.ietf.org/proceedings/09mar/slides/6ai-2.pdf - source address finding Finding (SAF) for IPv6 Translation Mechanisms draft-thaler-ipv6-saf-01.txt [17:30:08] that is kept private from anyone outside this domain [17:30:24] slide unilateral self-address fixing (unsaf) - 2 (pun intended) [17:30:47] ref rfc3424 [17:30:53] HEY, that's a good idea!! [17:31:12] Gor an external node to infer the internal address in NAT66, it would need to now what internal prefix was in use. If the internal network uses a ULA, that means knowing what ULA prefix is in use. If the internal network uses provider independent IPv6 addresses, that might mean looking them up on the IANA site. [17:31:20] one way to get top hiding (if we care to solve that problem, which I'm not sure we are, but if we were...) [17:31:20] Or doing whois or equivalent. [17:31:54] slide saf - source address finding - 3 [17:31:59] is to use a local secret, mixed into the mapping algo, and that would make knowing the reversible xlat unknown to ousiders [17:32:06] We could certainly put the right information to do a reverse mapping in the DNS, for example. That would allow folks who want to reverse to do it, without stopping NAT66 from working as usual when the other end doesn't know, or doesn't care, about reversing it. [17:32:19] lebobits: and cycling the secret periodically? [17:32:41] Updated slides for Christian's slides will be posted to the proceedings after the session. [17:32:49] you'd have to cycle, in order to keep the secrecy [17:32:50] Margeret: that is very similar to Christian's Six/One proposal. [17:33:00] would take an MSEK-like key server [17:33:01] slide incremental deployment (1/2) [17:33:35] lebobits: My topology hiding mapping did something along those lines, but there was no agreement about how cryptographically secure topology hiding had to be. Also, whether it needed to hide the IID bits. Some people thought letting the ports go through could give hints about topology. Some people want to overwrite the TTL field. None of them seem to care about the cookies in HTTP sessions, though, which I found weird. [17:34:03] margaret: cookies are user tracking, not host tracking [17:34:24] well, machine tracking, at least [17:35:04] JonathanLennox joins the room [17:35:28] lebobits: for a session, possibly. eg, my work environment has distributed home directories - I can run my web browser on multiple machines using the same cookie cache. [17:35:39] slide incremental deployment (2/2) [17:35:47] margaret at the mic [17:35:47] I just want to be happy [17:35:53] not sad [17:36:05] tsavo_work@jabber.org/Meebo joins the room [17:36:06] finally, we are simplifying things [17:36:19] [17:37:31] keith moore at the mic [17:38:26] tim chown at the mic [17:40:27] suresh was at the mic [17:40:50] james woodyatt at the mic [17:41:03] (I mistakenly typed 'woodhouse' earlier) [17:41:19] mikemlb leaves the room [17:41:26] jari at the mic [17:41:47] what happens if not all of the hosts in an site net have deployed the NAT Vif? [17:42:07] mikemlb joins the room [17:42:13] slblake: a mixture of happy and sad hosts I guess. [17:42:21] slblake: is that a question for the mic? [17:42:26] you revert to non-SAF behvior [17:42:29] Yes please [17:42:42] The ones that haven't use only local addresses. If they send to a destination that is not on the local network, their traffic will be translated and there will be no end-to-end transparency for them. [17:43:30] Ok, if both translations are checksum neutral, the having one or two translations doens't break the checksum. Understood. [17:43:33] The trick is how you communicate internally. You need to do something to make sure that internal communication happens using internal addresses, even on the machines that have NAT Vif. [17:43:58] slblake : so not any longer? [17:44:34] MRW: isn't that what ULAs are for? [17:44:44] slide saf mechanisms [17:44:51] The idea is that the service provider has a locally optimal choice deploy a NAT. Given that choice, the host has another choice to "undo" it in their stack that is a locally optimal choice for the host and doesn't require service provider intervention other than finding out about the configuration details... [17:44:55] If they don't, though, hairpinning in the NAT66 box will translate that traffic. But, basically, you'd be sacrificing end-to-end transparency in your site (between Vif and non-Vif) to obtain end-to-end transparency when communicating with external hosts (only from Vif nodes). There are some complext trade-offs there, and I can't really predict what administrators would choose. [17:45:04] slide requirements for saf mechanisms [17:45:46] Wes Beebee: The only configuration detail the host needs to find is his external address. If that is semi-constant, that's fine. [17:45:58] :) [17:46:18] slblake: dave's answer was a mixture of happy/sad [17:46:24] Margaret: agreed [17:46:24] keith moor at the mic [17:46:32] Yes, no need to ask. [17:46:39] don't worry, be happy... [17:46:55] tony hain at the mic [17:47:21] christian vogt at the mic [17:48:48] fnumber joins the room [17:49:12] margaret wasserman at the mic [17:50:27] suresh krishnan at the mic [17:51:09] MRW: there are also apparently deployment scenarios where hairpinning is compulsory, in some broadband deployments [17:51:44] bob hinden with http://www.ietf.org/proceedings/09mar/slides/6ai-4.pdf [17:52:00] slide (not in online version) re the lesser of two weevils [17:52:24] lesser of two evils - slide background [17:54:40] fnumber leaves the room [17:55:19] keith moore at the mic [17:56:14] slide question to the BOF (missed a few) [17:56:40] there is a large queue at the mic [17:56:44] lebobits leaves the room [17:56:50] Which leads to another question - are SP's actually going to hand out /48's to customers... but that's not a question the IETF can answer... [17:57:45] only if RIRs hand out /24s to SPs [17:58:14] tony hain at the mic [17:58:30] Dave Thaler leaves the room: Replaced by new connection [17:58:46] Dave Thaler joins the room [17:58:55] (tony) talking about generic here - at a higher level, name of bofh is address independence, but presentations are on translation functions. which is it? [17:59:39] (jari) I think the idea here is that we have a specific proposal looking at (concept of nat66, not nat66 specifically), this bof is looking at the concept of address independence [18:00:02] (tony) if talking about AI, and topology hiding is off the table, why are we going down this path? [18:00:41] (gregory) terminology clarification, started with 1:1 NAT, then NAPT - when comparing v4 NAPT to v6 (1:1) NAT - not same comparision [18:01:14] (gegory) I think my customers want from a NAT is topology hiding - want protection from host fingerprinting. [18:01:37] (gregory) I will write/have it written [18:02:02] Fred Baker leaves the room [18:02:18] (gregory) NAPTs today are plug'n'play - is it a problem we want to solve again? [18:02:31] jpcerezo joins the room [18:02:31] jjones leaves the room [18:02:50] jjones joins the room [18:03:09] (brian carpenter) if we do nothing, ipv6 NAPT boxes will propagate - we should produce the simpliest form of ipv6 NAT as quickly as possible. [18:03:27] lebobits joins the room [18:03:28] (keith moore) want an understanding of how much we can help the situation [18:03:35] sorry, everyone [18:03:48] greg, great comments. [18:03:54] sorry, i should have said one thing and gotten back in line [18:04:02] sorry for mic hogging [18:04:12] (keith moore) even if we publish, won't vendors do something else anyway? can we expect to get out of this a world where applications have the same view of the world [18:04:51] recap my comments for jabber archive and notes: [18:05:08] mikemlb leaves the room [18:05:14] we have been comparing NAPT v4 to 1:1 NAT in v6 [18:05:23] (jari) I'm not sure that the history repeating itself comment is actually true - more reasons for doing NA(P)T in ipv4 than v6. I'd like to see vendors [18:05:23] slblake: the RIRs give the SPs as much space as they need, so if you run out of that initial /32 after 65k /48 customers you get a new block no questions asked [18:05:29] that was just a terminology clarification [18:05:56] 2 - people want to do two security things with NATs: [18:06:03] a) topology hiding [18:06:21] then why are SPs talking about allocating /56s or /60s to residential customers? [18:06:27] wmhaddad leaves the room [18:06:27] b) host fingerprinting, e.g. don't want people to be able to ID the finance server and direct attacks at it [18:06:49] greg, i do have one concern about your comment - which is that finger-print obscuring is a separate function from topology isolation. i posit that the level of fingerprint obscuring will depend on which NAT proposal is adopted. [18:07:01] (jonne soininen) - people will do NATs if there is market demand for it with or without us. can we solve the problems in v6 without NAT? if we start to write a spec, is that the [18:07:12] mikemlb joins the room [18:07:23] is that the right way to do stuff? [18:07:24] @lebobits: v6 has another solution to the fingerprinting pb, no need for NAT for this [18:07:45] slblake: either because they're still working under a scarseness regime or because they don't think the users need a /48 or they want to be able to differentiate between business and consumer acocunts. the rirs are perfectly ok with giving everyone a /48 [18:07:54] @lebobits: why is topology hiding useful? [18:08:13] (tim chown) if we move forward, can we say 'thats the minimum pain we want to deal with'? may also be need for address sharing - can we avoid those situations? [18:08:38] brian, topology hiding is useful because you don't embed PA addresses in your configurations, and are thus not tied to a single provider [18:08:41] but you knew that, right? [18:08:44] if people really want to hide their internal stuff that HAS to break apps, I don't think we can accommodate that perceived need in a reasonable way [18:08:48] 3) people like that they don't have to ask anyone to put a bunch of hosts on the network, they just put a box with NAPT up with dhcp on one interface, the network gives them an IP thinking it's a host, and then they can connect up their 30 hosts. This demand may not go away. If it doesn't, NAPT will rear its ugly head again. Point: we may not be able to satiate the requirements w/ stateless 1:1 NAT66 [18:09:13] (eric) we should move forward and work out the address independence part - heres a short-term unilateral single-sided solution - just focus on that little problem. get feedback over time. [18:09:17] I agree w/ you eliot [18:09:34] @lebobits, point 3: that's why we invented stateless autoconfig. [18:10:02] lebobits: with recursive prefix delegation this is also possible although it does require more coordination/cooperation from people upstream [18:10:04] Ted Hardie joins the room [18:10:15] ping [18:10:18] ! [18:10:22] lebobits leaves the room [18:10:22] lebobits joins the room [18:10:22] pong [18:10:28] (margaret) I believe that we can influence what happens by writing a proposal on how to do it instead of saying nothing or saying to not do it. re network administrators, its very hard to get them to come to the ietf. [18:10:36] ping6 [18:10:43] @iljitsch: why? even if you have a /64 you can still run SLAAC [18:10:52] lebobits leaves the room [18:10:52] lebobits joins the room [18:10:56] lebobits leaves the room: Logging off [18:10:57] becarpenter: why what? [18:11:07] why coordination? [18:11:30] suppose I get a /60 (or /32...) from my ISP to my CPE [18:11:38] (suresh) is there going to be guidance when nat66 should be used? without that, equip is going to be in place forever. just changing the addresses from v4 to v6 is very easy thing to do [18:12:03] if I then want to put in another home router, then my CPE would have to delegate at least a /64 to that other home router [18:12:14] (stuart) who wants IPv6 nat on their networks and would use it? (3 who want it and 1 who would be forced to) [18:12:38] themrdns: with 1-to-1 NAT you can always simply disable it, not so much with many-to-1 [18:12:38] (stuart) if the nat66 equipment had it on by default, who would turn it off? (larger show of hands) [18:12:58] (stuart) it would be nice to find out who wants this and get some better requirements [18:13:31] (greg daley) demand for v6 nat might be requests for feature parity with v4. [18:13:32] themrdns: we are not doing this work for those who want it, but for those who don't. different requirements. :-) [18:13:46] sorry, to stuart [18:13:47] Ted Hardie leaves the room [18:14:13] (greg daley) re provider independence - current solution for v6 is identical for v4. if you're not multihomed, no PI space for you. [18:15:06] (greg daley) adoption of v6 wouldn't have any more of an impact on routing table than v4 (?) [18:15:24] (james woodyatt) 'no', 'no', and 'hell no'. [18:16:01] actually v6 is worse because there's no longer any need to show you need at least a /24 or /22, everyone qualifies for a /48 worth of space even with 1 host [18:16:50] (james woodyatt) don't think ISPs will hand out sufficient addresses to customers, so the need for address sharing will still be there. [18:16:55] lebo joins the room [18:17:13] lebo = lebobits [18:17:16] james: sorry, but planning for address scarcity in IPv6 is insane [18:17:34] sklvarjo leaves the room [18:17:36] that would truly be epic failure [18:17:36] momose leaves the room [18:17:38] @eliot: I think u r correct [18:17:40] jjones leaves the room: Disconnected [18:17:59] jjones joins the room [18:18:08] James Woodyatt: (when you get back) You can get at least 8 (maybe 12) bits of address amplification without NAT using port sharing. [18:18:23] (james woodyatt) is it better to specify v6 NAT than letting the vendors do it themselves? think it will be an encouragement more than anything [18:18:38] So, you'd do port mapping but keep the address translation 1:1. There are some advantages to that over a many:1 address translating NAT. [18:18:39] my third point: one thing people try to do with NAPT is quickly put a bunch of hosts on a network w/o anyone's permission. They do this by putting a NAPT v4 box in, with DHCP on an interface, and boom, they're on. [18:19:14] For that pt 3, maybe even if we specify a 1:1 v6 NAT, people may still build/use NAPT v6 [18:19:21] bummer [18:19:32] (phil matthews) experiental means less considered within the IETF. outside the IETF, people don't care about the status. [18:20:00] @ greg daley: great point about mult homing and the size of the route table. VERY salient [18:20:10] (phil matthews) am concerned about solutions that try to make v6 world beautiful without consideration towards interoperability with current v4. [18:20:18] lebo: but why not simply connect at layer 2 rather than 3 ? with v4 that doesn't work because you'd use up more addresses but assuming a /64 this is never an issue if you connect at layer 2 [18:21:05] @ iljitsch: sorry, can u define "connect at L2" better? [18:21:07] momose joins the room [18:21:20] (remi) re need for WG for v6 NAT, 'no'. if group for address independence, multihoming etc, yes. [18:21:41] lebo: like if I have a provider provided cpe and I want to put in my own base station [18:21:53] or if I want to put in my own wifi base station in the office [18:22:19] In v4 I can run NAT and only use 1 address at the original LAN [18:22:38] (erik kline) want to echo remi - want a group focused on addressing problems raise by nat66 problem. re v6 deployment issues, not aware of any need for v6 NAT. we shouldn't devolve v6 to v4 [18:22:39] or run in bridge mode and the two networks are connected at layer 2 [18:23:02] let me clarify to people, I wasn't arguing that my point 3 is a healthy thing, I was just providing a data point for explanative purposes [18:23:05] first remi above is Remi Despres [18:23:10] mic now is Remi Denis [18:23:33] we should address it in docs, and then say it's unhealthy, thats my opinion [18:24:26] (tim shepherd) not sure if erik's comment re no need, not sure if its completely true (for all deployments) [18:24:36] remote participants, are there any questions to be asked? [18:25:34] (tim) would be good to write down something like what margaret described. wouldn't object to proceeding [18:26:24] (christian vogt) one of the issues with standards track is that it tends to be better (?) with the ietf - phrase it as last resort? [18:26:42] momose leaves the room [18:26:49] becarpenter leaves the room [18:28:03] (remi despres) want to say that the rationale as presented is very interesting [18:28:40] (keith moore) which problems (are being solved by nat66)? [18:29:21] satoru.matsushima leaves the room [18:29:23] (keith moore) important that the WG solve the right problems [18:29:36] btw, sorry for hogging the mic > 30 sec earlier. [18:29:55] lebo: if you want I can explain in person if you have a few minutes [18:30:00] I should have given one point, then gone back into queue [18:30:20] iljitsch: I get it [18:30:24] thx [18:30:35] momose joins the room [18:30:52] poll to the room - see if there is a rough consensus to form a WG to do a limited form of NAT for ipv6 that focuses on address independence, but we don't try to solve all the problems of NAT for v6 [18:30:58] but in enterprises, you have to open a help desk ticket to get that to work, and that can take weeks in some orgs [18:31:06] iljitsch leaves the room [18:31:14] Why won't people let him actually ask the questions? [18:31:20] that's why people "cheat" w/ a NAPT [18:31:21] (greg daley) I'm not inclined to do a nat66 solution, but want to examine the problem [18:31:39] By listening to the long winded people who already spoke for several minutes (like me) he is not listening to everyone else who hasn't spoken. [18:32:13] behcet.sarikaya leaves the room [18:32:17] (the mentioned poll hasn't been taken btw) [18:32:34] What poll, Bruce? [18:32:40] (tony hain) I don't think the question as asked is not answerable [18:33:33] Let him ask if we want to do NAT66! If we say 'no', that's fine. But why not ask the question? [18:34:55] various people quibbling over the question to be asked [18:35:25] If we do a requirements effort and explore the whole solution space, it will take 2+ years before we _start_ documenting NAT. [18:35:42] (?) worried about getting into a WG that doesn't deliver for a very long time [18:35:56] That was Thomas Narten. [18:36:20] (keith moor) we could get something out the door as experimental in a very short period of time without the (time) costs associated with starting a WG etc [18:36:35] So we should wait 4 months to ask the questions?!? [18:36:47] first question to the room - should we just go home? [18:37:10] (lots of people thinking that we should do something, vs very few who think we should go home) [18:37:10] mlepinski leaves the room [18:37:24] should we do a NAT solution for IPv6? [18:37:45] (more no than yes for that one, quite split on that) [18:38:05] repeat of question [18:38:26] mikemlb leaves the room [18:38:31] (still slightly more no than yes) [18:38:51] ...if you count everyone who raised two hands twice. [18:39:35] question - should we prioritize and close open issues with ipv6 that are met by today's ipv4 napt? [18:39:46] (more yes than no) [18:39:58] Fred Baker joins the room [18:39:58] Atarashi Yoshifumi leaves the room [18:39:58] Ole Troan leaves the room [18:40:01] momose leaves the room [18:40:05] suz leaves the room [18:40:07] Fred Baker leaves the room [18:40:10] I think they said there was consesus within the room for yes on the last one. [18:40:14] arifumi leaves the room [18:40:16] Mark Townsley leaves the room [18:40:17] s/consesus/consensus [18:40:19] Margaret Wasserman leaves the room [18:40:25] Li-Fan WU leaves the room [18:40:28] hirocomb12 leaves the room [18:40:32] end of session, people heading out to lunch. [18:40:41] csp leaves the room [18:40:42] slblake leaves the room [18:40:42] Bob leaves the room [18:40:49] Hemant Singh leaves the room [18:40:51] jjones leaves the room: Disconnected [18:40:53] Thanks to the jabber scribe [18:41:12] Wes Beebee leaves the room [18:41:36] shep leaves the room [18:41:41] np [18:41:44] ruriham leaves the room [18:41:55] mohsen leaves the room: Computer went to sleep [18:41:57] Eadson.zhangdong leaves the room [18:42:10] karen.s.seo leaves the room [18:42:13] bruce leaves the room [18:42:26] Dave Thaler leaves the room [18:43:02] kanda leaves the room [18:43:10] JonathanLennox leaves the room: Computer went to sleep [18:44:00] cmadson-ietf leaves the room [18:44:36] tsavo_work@jabber.org/Meebo leaves the room [18:46:25] tinnami leaves the room [18:47:44] Doug_Otis leaves the room [18:48:03] jcossio leaves the room [18:48:17] Antonio Moreiras leaves the room: Computer went to sleep [18:48:28] jpcerezo leaves the room [18:56:17] Doug_Otis joins the room [18:57:26] Bernie leaves the room [18:57:31] eliot.lear leaves the room [18:59:00] Antonio Moreiras joins the room [18:59:44] fujisaki leaves the room [19:01:06] Doug_Otis leaves the room [19:05:39] lebo leaves the room [19:16:52] Ole Troan joins the room [19:18:34] Ole Troan leaves the room [19:28:19] Doug_Otis joins the room [19:31:03] Antonio Moreiras leaves the room [19:49:05] Doug_Otis leaves the room [20:01:31] kanda joins the room [20:01:46] kanda leaves the room [20:04:54] Bernie joins the room [20:05:10] mikemlb joins the room [20:05:34] mikemlb leaves the room [20:08:32] DDD leaves the room [20:21:20] Bernie leaves the room [20:23:29] jjones joins the room [20:27:36] jjones leaves the room [20:39:46] Fred Baker joins the room [20:40:20] Fred Baker leaves the room [20:40:22] Fred Baker joins the room [20:44:11] Fred Baker leaves the room [20:46:15] jjones joins the room [20:47:33] jjones leaves the room [21:08:37] jjones joins the room [21:17:38] jjones leaves the room [21:59:50] arifumi joins the room [22:00:10] arifumi leaves the room [23:39:12] jjones joins the room [23:43:13] jjones leaves the room