[17:13:31] Dave Thaler joins the room [17:13:51] test [17:23:41] spencerdawkins joins the room [17:24:36] fred posted webex coordinates for monday in the 3gv6 mailing list [17:27:06] I wasn't on the list until just now [17:29:01] jariarkko joins the room [17:30:04] I just sent email to the 3gv6 mailing list about this jabber room [17:30:10] great, thanks [17:30:34] marc.blanchet.qc joins the room [17:32:43] Hui joins the room [17:34:03] Dave Thaler has set the subject to: IETF/3GPP workshop on IPv4-IPv6 migration [17:35:07] tsavo joins the room [17:35:15] what's the location of the agenda location he just mentioned? I can't find it [17:36:07] I see nothing recent at ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF [17:37:44] Scott Brim joins the room [17:39:05] Phil Roberts joins the room [17:39:10] doc he's talking about now is ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100007.zip [17:40:53] the agenda doesn't seem to be online. The agenda attachment has a link to an agenda doc that contains no real content [17:41:06] rdroms joins the room [17:41:44] ok an agenda URL is http://www.ietf.org/mail-archive/web/3gv6/current/msg00327.html (click on attachment) [17:41:56] ietfdbh joins the room [17:44:03] I think the next preso is http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100036.zip [17:47:12] tsavo leaves the room [17:47:32] tsavo joins the room [17:47:43] dwing joins the room [17:50:12] do IPv6 link-local addresses work normally on such a link? [17:50:18] Magnus Westerlund joins the room [17:50:57] sureshk joins the room [17:50:57] IPv6 link-local address is not the same as IEEE 802.3 [17:51:15] they don't have those link local address in 3GPP [17:51:16] in IPv6, all interfaces must have IPv6 link local addresses per RFC [17:51:30] so does 3gpp violate the IPv6 RFCs? [17:51:33] normally 3GPP assign link interface recommendation to MN [17:51:56] it doesn't conflict with ipv6 rfc, I believe [17:53:31] RFC 4291 section 2.1: "All interfaces are required to have at least one Link-Local unicast address (see Section 2.8 for additional required addresses)." [17:53:45] sounds like you're saying 3GPP does not conform to that [17:53:53] RFC 4291 is the IPv6 addressing architecture [17:54:23] that link local address should be uniqe , recommended from the network [17:54:42] ok so there are link-local addresses? (if so, that's good) [17:54:52] not necessraily link local unicast address? [17:55:07] let's assume that is link local unicast address [17:55:28] @dave, 3GPP conforms to that [17:55:46] so the /64 is in addition to the link-local prefix yes? [17:55:53] This is Teemu Savolainen. Indeed theres link local [17:55:57] yes [17:56:04] ok thanks suresh [17:56:22] the /64 is from normal unicast space in addition to the fe80 [17:56:30] What is interesting is that PDN GW gives UE one IID that is guaramteed not to conflict [17:56:59] So dad is not absolutely necessary if that iid is used [17:57:28] yes it is [17:57:41] Dave - the idiom "/64 is assigned to the UE" is a little imprecise. The /64 is assigned to the link to the UE, and the UE assigns itself SLAAC and "privacy" addresses from the /64. [17:58:00] the RFCs clarify you still do DAD, since 1 nod emight use that IID with link-local prefix and another node might use it with the global prefix, and use other IIDs for the other addresses [17:58:23] But on 3gpp there is only ue and pdn gw [17:58:35] yes, the PDN GW has addresses too [17:59:00] so you can have a collision between those 2 nodes [17:59:01] Dave, this situation is very similar to a PPP IPv6 link [17:59:06] Yes but this iid given to ue guaranteed unique. But of course dad is allowed [17:59:10] the other node on the link that could collide [17:59:16] is the one giving you the iid [17:59:22] tethering? [17:59:28] Thats different [18:00:00] please say more. Architecture is fundamentally different when tethering? [18:00:01] true, if the UE conceptually bridges the IPv6 link then there's more IPv6 nodes [18:00:03] Dan - so the /64 is bridged through the UE to downstream/tethered devices? [18:00:23] Ralph, I dunno. I'm asking [18:00:31] @suresh: yes on a PPP IPv6 link, you still must do DAD for the same reasons [18:00:42] @dave, agree with you [18:00:51] Yes sometimes the /64 will be bridged [18:01:01] I was just pointing out the similarity [18:01:08] E.g. If network does not support dhcpv6 pd [18:01:16] I think the right solution to nodes behind the UE is DHCPv6 prefix delegation [18:02:00] Yes suresh, but how can you guarantee all 3gpp network will doåeploy it [18:02:12] Or allow for all ues [18:02:16] @teemu,I have no idea :-) [18:02:24] Make it a requirement? [18:02:42] @ralph, that is the goal [18:02:48] I don't see these slides in the file [18:03:09] but there are some PCC issues that need to be taken care of [18:03:16] "PCC"?? [18:03:30] From UE point of view nd proxy is pretty much mandatory if you want to provide tethering but cant trust all 3gpp networks support or allow dhcpv6 pd [18:04:04] PCC is Policy and Charging Control [18:04:06] it's in the 48.zip file [18:04:08] sorry abt that [18:04:50] ok thanks Phil http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100048.zip [18:05:12] the current 3GPP PCC architecture allows for only 1 IPv6 prefix per IP session (called a IP-CAN session) [18:06:45] So, this ND-proxy/bridging architecture is fundamentally limiting. Suppose the UE is a residential or mobile gateway with more than a single link behind it? [18:07:10] This is going to be an issue [18:07:28] We have a proposal to address this in http://tools.ietf.org/html/draft-krishnan-intarea-pd-epc-00 [18:08:04] as suresh said, the UE could be a router [18:08:09] the goal is to reserve a shorter than /64 (e.g. /56) for each UE irrespective of whether it needs a delegation [18:08:14] (IPv4 NAT, and IPv6 PD box) [18:08:37] Ralph (and others): a good example of when you would want a 'real network' behind a wireless endpoint is when normal wired communications are down (e.g., after an earthquake), and wireless communications need to be established for things like credit card processing, store inventory, etc. Consider for example a hardware store that is selling new windows, new doors, and new roofing supplies. [18:08:39] when the UE becomes a router it will request the shorter prefix using RFC3633 [18:08:46] RIght...all of those architectural features make sense. I just don't see them referred to. [18:09:25] @dave: exactly that. Not only that, DSL replacement is an explicit business a lot of operators are targeting [18:09:30] e.g. 3 in sweden [18:09:42] @ralph: They do not exist yet in the specs [18:09:53] These are just proposals [18:10:05] OK. [18:10:14] We are presenting them to IETF as drafts and change requests to 3GPP [18:10:53] trying to follow: so the main problem is that DHCP-PD is missing from the 3GPP specs? [18:11:36] dwing leaves the room [18:11:56] Dan Wing joins the room [18:12:05] For this UE as a router use case, yes.this is the major problem [18:12:13] That's what I'm hearing ... not just DHCP-PD; also provisioning shorted than /64 prefix, full routing and other IPv6 support in UE (looks like v6ops-router-reqts), etc. [18:12:13] we want the PDN-GW to support DHCP-PD, and they don't today, correct? [18:12:47] @dave: Some of them can, but it is not mandated functionality [18:13:21] ok well that's not that different from the non-3gpp world. [18:13:34] If the UE gets a *public* IPv4 address, the UE router can do 6to4. [18:13:38] (or 6RD) [18:14:02] and if not, then the hosts behind it have to do Teredo or tunnel broker [18:14:04] or nat64 ;-) [18:14:20] :) [18:15:44] Problem is the UE is currently spec'ed to do the quick-and-dirty ND-proxy/bridging. That solution will be OK RGs for a little while - 1-link-per-subscriber works today in IPv4 - regrettably that will entrench ND-proxy/bridging and make a transition to full routing difficult. [18:16:48] or they will do nat66 [18:16:52] on the ue... [18:16:54] Ralph, I think you just said NAPT66? [18:16:55] What are the objections to supporting fully routing capable UEs today? Wireline standards bodies are going directly to DHCP-PD, etc., today. [18:16:56] jlaganie joins the room [18:17:32] Marc: NAT66 doesn't allow multiple hosts to share one IPv6 address. NAT66 is 1:1 mapping. [18:18:03] sorry. I meant napt66... [18:18:05] @ralph: I am not very sure, but I think it was left out for expediency's sake [18:18:06] I haven't heard about objectiosn, just that PD has not been needed by 3gpp hosts or scenarios and thats why is missing from spec.. [18:18:19] to get Release 8 out in time [18:18:45] IIRC PD was in some Rel-8 doc but was then removed [18:19:05] Yes it 3gpp had to finish rel-8 [18:19:17] No time to sort out dhcpv6 pd then [18:19:23] and adding this would have meant missing the deadlines on Rel 8 [18:20:17] ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100044.zip [18:21:37] behcet.sarikaya joins the room [18:21:54] I like slide é =0 [18:22:01] slide 2 [18:22:09] =) [18:22:14] previous 33 [18:23:24] does APN support IDNs? [18:24:41] I think it is explained in this slide [18:24:53] my question isn't [18:26:03] @dave: I don't think so [18:26:37] idn is a matter of UI stack. [18:26:47] josoinin joins the room [18:27:06] the 3gpp dns internal would support idn since idn is just regular dns names with special prefixes. [18:27:34] mark: who does the DNS lookup? the UE or the SGSN? [18:27:40] (marc) [18:27:52] SGSN [18:28:00] sgsn [18:28:03] Internal DNS [18:28:04] then it's not just a UE issue, it's an SGSN issue [18:28:12] SGSN [18:28:15] Exactly. [18:28:34] So the UE hands the APN name string to the SGSN which does the lookup? After adding some local additional domains? [18:28:46] yep. [18:28:54] thanks... [18:29:07] so can the APN contain non-ascii characters? (given that it's not the DNS protocol it's passed in from the UE to the SGSN) [18:29:18] Currently not. [18:29:22] but the APN is not typically visible to a user right? [18:29:27] Yes. [18:29:34] @phil: it is visible to the user [18:29:37] Oh, sorry - it can be. [18:29:49] However, it can be preset by the operator. [18:29:56] it is one of the configuration parameters on your UE [18:29:57] @jonne: exactly [18:30:06] so is this saying china mobile should use ascii, or should they use an A-label (xn--... punycode encoded string) [18:30:23] Currently only ascii is supported. [18:30:39] @dave: yes [18:30:43] that must make them happy... [18:30:47] I don't think the IDNs within the operator's internal network has hit the 3GPP, yet. [18:31:11] well, if the ue converts as a browser, then it would send xn-- to the sgsn as a name to resolve. [18:32:32] However, this is not something that your browser typically sees. [18:32:57] rdroms leaves the room [18:32:58] It is something that the phone OS takes care, or the 3G card device driver. [18:33:11] If I'm roaming do I use a local APN? [18:33:40] @josoinin: I was taking the browser as an example of a UI which handles the conversion from the native script to the xn--. [18:33:47] @scott: you can do both (local and back home) [18:34:04] depends on the APN name that is configured on your UE [18:34:11] aha [18:34:43] Actually roaming APN comes also to the user profile. [18:34:46] up to now, changing the APN is often difficult for end users if not almost impossible (lock down into internals of the config) [18:35:26] The operator can set in the subscription if local or home APN should be used. [18:35:43] Most of the world (if not all) uses home APN while roaming. [18:36:07] satoru.matsushima joins the room [18:36:34] right, I tested that many times (home APN used while roaming). [18:37:09] Phil Roberts leaves the room [18:37:11] satoru.matsushima leaves the room [18:54:09] for those on the site, what is happening? break time? [18:55:45] satoru.matsushima joins the room [18:58:43] Phil Roberts joins the room [19:00:06] Marc: Yes, coffee break. Theoretically it's now over, but half the room is still empty. [19:00:10] Lots of meetings in the halls. [19:01:02] @scott: right. the penalty for the ones who can't be there! [19:01:24] we now have audio on the phone bridge! yeah! [19:06:26] IPW100037 [19:06:37] bnsmith joins the room [19:06:42] http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100037.zip [19:08:14] is stateless DHCPv6 supported for getting other configuration info? [19:08:42] I'm noting this slide has DNS info passed in the link layer protocol :( [19:08:43] Can be used, yes. [19:09:27] Stateless DHCP can be used also for other info like the SIP proxy address. [19:09:38] and DNS server addresses? [19:10:01] Well, there is no restriction not to do that. However, deployment depends on operator. [19:10:22] ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100035.zip [19:10:27] Remember that originally passing the DNS information was done at a time where IETF was still in denial that DNS is needed in IPv6... ;) [19:11:40] So what would you do now? All the arguments about DHCP in the Internet in general also hold in this environment. [19:12:19] I'd expect folks to NOT pass dns server IPs in the link layer protocol, and to just do DHCP stateless. [19:12:27] would be nice [19:12:40] WEll, the deployments we have now use the link-layer model. [19:12:45] Lars joins the room [19:13:14] see RFC 5505 [19:13:51] what about RFC5006? [19:14:18] that's experimental. [19:14:26] and? [19:14:37] see RFC 5505 section 2.3 [19:14:47] "The number of host configuration mechanisms should be minimized." [19:15:20] ;-) [19:16:15] to me, better to pass on dns addresses in RA than in layer 2... [19:17:37] IMHO for dns addresses: DHCPv6 > RA > L2 [19:18:29] Well, the original specs on the 3GPP IPv6 support was written in year 2000. [19:18:30] well, that is a long discussion we had... not related to 3gpp... but I'm seeing other places where RA is just the right place... [19:19:09] @jonne: understood, we've learned some things since then [19:19:22] webex showed one slide with "current definitions" for about 5 minutes. what this the one presented on site? [19:19:23] http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100010.zip [19:22:13] @dave: Right, but on the other hand there is the thing about installed base, and used processes. [19:22:28] Doing the L2 thing is the same as for IPV4. [19:22:33] yep [19:22:41] However, it doesn't mean that things couldn't change. [19:22:52] PPPv6 did the same thing [19:23:01] (as did IPsec tunnels I think) [19:23:16] And yet surprisingly they are similar... ;) [19:23:30] yes, that's what led to RFC 5505 [19:23:53] at least telling people to not do that in new things [19:24:03] Right. [19:29:06] is the "native dual stack" model at all controversial outside the IETF? [19:29:52] in enterprise networks, just make sense. [19:31:02] T-Mobile wants to support IPv6 only UEs, they consider DS UE is something special [19:31:30] rdroms joins the room [19:31:40] odd that this slide references Teredo and not other ones (6to4, 6rd) [19:31:53] the more time pass, the more providers will consider ipv6-only. [19:34:57] jouni.korhonen joins the room [19:36:39] rdroms leaves the room [19:36:48] is IPv6-only core actually being pursued by any 3GPP folks? I saw Cameron posting that it's not interesting to 3GPP [19:38:25] should I ask at the mic? [19:38:46] I think it is because they want to continue doing same things as well as supporting IPv6 [19:39:04] Cameron posted: "There is 0% probability that any mobile provider, especially 3GPP provider, would ever deploy DS-lite. The 3GPP standards (GPRS / UMTS / LTE) have supported dual-stack configurations for a very long time. There is no need for DS-lite to facilitate the deployment of IPv6 in mobile wireless networks. Mobile providers have a great deal more flexibility in terms of the service offering, the supported hardware and software, as well as transport infrastructure. All mobile data is tunneled in GTP tunnels across the mobile core network today, so DS-lite tunnels do not add anything new but complexity and overhead. DS-lite is particularly not applicable to 3GPP since all the data transport and mobility functions in 3GPP architectures is based on the idea of mobility tunnels using GTP. So, all data traffic in GSM / UMTS goes via a tunnel already. These tunnels today are normally IPv4-only tunnels, but IPv6-tunnels are supported today in the production systems. Having both tunnels up is a standard dual-stack configuration. There is no need for DS-lite in 3GPP.” [19:39:10] @Dave: yes, yoou should ask [19:39:25] that was what was behind my question also [19:39:25] jouni.korhonen leaves the room [19:39:34] T-mobile is a 3gpp operator [19:40:24] Also DS-lite provides very minor savings for them [19:40:27] https://fit.nokia.com/lars/meter/ipv6.html [19:41:01] jouni.korhonen joins the room [19:43:47] @lars are you going to update this page regularly? [19:44:10] @dave: There are other ways to do DS-lite like mechanisms in 3GPP networks [19:44:47] it would be nice if operators would answer the question.... [19:44:59] one example is http://tools.ietf.org/html/draft-arkko-dual-stack-extra-lite-00 [19:45:12] I think your question is operational, not what an SDO says? [19:45:28] @ [19:45:37] @behcet: it's updated every day automatically [19:46:00] since 2007 [19:46:02] it utilizes existing tunnels in order to avoid the extra layer of tunneling [19:46:40] jlaganie leaves the room [19:46:58] If anyone answered my question, I didn't catch it. [19:47:49] @dave, which question was that? [19:48:21] is any 3GPP operator planning an IPv6-only core [19:48:42] (i.e. no IPv4) [19:49:10] or does Cameron's quote above reflect the consensus of the 3GPP community [19:49:13] @dave: yes. [19:49:16] davet, that's what i saw - no answer [19:49:20] but not using ds-lite [19:49:41] The thing is the word "core" [19:50:00] ok thanks suresh (would like to hear more, but that at least is an answer to my question) [19:50:13] "core" means in 3GPP language the network between the Base station and the Gateway (GGSN). [19:50:27] Doesn't however mean that you couldn't give native IPv4 PDP Contexts. [19:50:37] The same way that IPv6 is provided today. [19:50:49] over ipv4 I mean. [19:51:05] but I think that what cameron is asserting is that he's doing IPv6 only from the UE to the GGSN for devices [19:51:14] I don't know about the infrastructure underneath that [19:51:47] and I haven't quite sorted out whether it is for all new devices (but that is what I thought he said he wanted to do) [19:52:25] what file number are we on now? [19:52:57] @phil: The infrastructure (transport)IP protocol and the user plane IP protocol are orthogonal to each other [19:53:23] agree [19:53:32] 16 [19:53:57] i don't know the slide [19:53:58] 16 only contains an I-D, no slides [19:56:26] I can't figure out whixh slides we are looking at. sorry. [19:57:10] ftp://10.30.2.60/WORKSHOP/INBOX/DRAFTS/IPv6-Mobile-Networks-Cisco.zip [19:57:47] thanks behcet [19:58:21] rdroms joins the room [19:58:43] I am amused with the RFC1918 address literal in that URL. [19:59:29] @dan, sorry it is local link [19:59:35] @dan: I think this is a "meeting-only" network [19:59:53] I figured as much. But I can't get there with my VPN up. [20:00:26] Amusing that we're talking about NAT and passing around private addresses using Jabber chat as our rendezvous protocol. [20:00:40] ryuji@mt.view joins the room [20:00:53] And who said irony is dead? [20:01:03] :-) [20:01:16] we need GROBJ [20:11:56] @dan and it's an ftp:// url :-) [20:12:05] go alg [20:12:19] can you access it from an IPv6-only node? :) [20:12:35] does it like EPSV? [20:18:51] Jonne Soininen joins the room [20:23:47] Dan Wing leaves the room [20:24:01] Jonne Soininen leaves the room: Replaced by new connection [20:24:01] Jonne Soininen joins the room [20:24:11] Dan Wing joins the room [20:25:14] Dan Wing leaves the room [20:25:16] ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100013.zip [20:25:37] thanks dave to provide pointers to presentation. very useful remotely! [20:25:48] Dan Wing joins the room [20:26:26] I just checked (now that my VPN dropped). That FTP server isn't IPv6-friendly -- it doesn't support EPSV. [20:27:10] Phil Roberts leaves the room [20:33:16] Phil Roberts joins the room [20:34:01] Dan Wing leaves the room [20:34:15] josoinin leaves the room [20:34:18] what's PLMN? [20:34:23] Dan Wing joins the room [20:35:00] public land mobile network [20:35:02] she just said it [20:35:02] ;-) [20:37:25] "The mobile device may access local breakout services and home routed services in parallel. " means separate connections visible at layer 3, yes? [20:38:46] yes.. separate pdp contexts to different gateways [20:39:18] wmhaddad joins the room [20:39:55] IPhone does this without going thru 3GPP network [20:45:05] http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100027.zip [20:46:44] I must have misunderstood scenario 1 then, since 1 talked about NAT44 [20:46:57] did 1 assign public IPv4 addresses to UEs? [20:47:27] 1 assigned ipv4 address to UE [20:47:34] solution could be nat44 [20:47:48] 2 assigns ipv4 addresses to ue too, what's the difference? [20:48:00] 2 assign private ipv4 to ue [20:48:10] 1 assign public ipv4 to ue [20:49:27] sce 2 is basically to address 1918 address shortage? [20:49:31] slide 6 of scenario 1 says "To overcome the challenge of public IPv4 address depletion, the operator assigns private IPv4 addresses (for example, the RFC 1918 addresses) to the mobile devices and deploys NAT44 to provide access to external packet data networks. " [20:49:39] how is that not scenario 2? [20:50:34] tsavo leaves the room [20:51:21] but I suspect Hui is correct and the scenario 1 slides are misleading [20:54:07] so each GGSN is a NAT with its own RFC 1918 space, yes? [20:54:19] in some scenarios yes [20:54:35] tsavo joins the room [20:54:39] it is called distributed NAT [20:55:00] @behcet: yes, I saw that on the terminology slides earlier [20:56:44] so in the distributed NAT model, is a subscriber always associated with the same GGSN? or could it vary over time? [20:56:50] i thought i knew of carriers in both China and North America who have run out of NAT 10 addresses - does anyone doubt this? but I'm wondering why lars/jari's questions weren't answered. [20:57:14] @dave having a NAT in a GGSN is an implementation option. Usually a GGSN can handle overlapping address spaces per APN. So it depends what your box allows and provides. There is no 3GPP mandates on this topic [20:57:45] one solution could be use 192/ also [20:58:28] behcet - sure, but net 10 is more than an order of magnitude too small for china mobile, right? [20:58:49] jouni: in the distributed NAT model, is a subscriber always associated with the same GGSN? or could it vary over time? [20:59:02] That's what I understood from the China Mobile presentation. [20:59:53] I'm remembering a conversation about three levels of NATting into/out of one of the large Chinese networks. I'm not sure I can say which one, even if I could remember, and I'm not sure that the reason is exhausting net-10... [21:00:30] dave: subscribers may or may not be associated with a specific GGSN. depends again how operator designs their network and what their preferred vendor is able to give to them [21:00:47] I didn't hear an answer to Jari/Lars's question either [21:01:38] they don't want to give an answer [21:02:11] is there some layer 2 context id? seems like there ought to be a simple answer [21:02:21] Yeah. [21:02:22] for subscriber identification [21:02:34] But where does that identification have to take place - inside the carrier network or in the Internet? [21:02:35] IMSI - International Mobile Subscriber Identity. [21:02:36] L2? [21:02:56] In operator's network. [21:02:56] thanks Jonne, so why isn't IMSI the answer to Lars/Jari's question? [21:03:01] IMSI is like MAC address [21:03:12] Lars leaves the room [21:03:13] Jonne Soininen leaves the room [21:03:20] But they still need a binding between the IMSI (or other identifier) and a location. [21:03:23] dave: some vendors allow making extern router as the first hop router in IP sense. the GGSN does not need to be the first hop router. there are plenty of choices there how to desin networks [21:03:30] ryuji@mt.view leaves the room [21:03:34] lagter [21:03:38] behcet.sarikaya leaves the room [21:03:40] Hui leaves the room [21:03:40] Phil Roberts leaves the room [21:03:50] ietfdbh leaves the room [21:04:00] satoru.matsushima leaves the room [21:04:01] Dan Wing leaves the room [21:04:04] jouni.korhonen leaves the room [21:04:05] rdroms leaves the room [21:04:07] spencerdawkins leaves the room [21:04:08] for anyone remote (Marc...) Lunch Break! [21:05:06] thanks! [21:05:40] Scott Brim leaves the room [21:05:46] will be back in 1 hour [21:06:28] ietfdbh joins the room [21:07:02] ietfdbh leaves the room [21:08:40] sureshk leaves the room [21:12:39] Magnus Westerlund leaves the room [21:14:11] Dave Thaler leaves the room [21:15:11] jariarkko leaves the room [21:31:55] marc.blanchet.qc leaves the room [21:41:32] Phil Roberts joins the room [21:43:32] ryuji@mt.view joins the room [21:43:42] Phil Roberts leaves the room [21:53:30] Phil Roberts joins the room [21:56:33] Scott Brim joins the room [22:04:55] marc.blanchet.qc joins the room [22:06:14] jlaganie joins the room [22:06:28] Dave Thaler joins the room [22:10:59] rdroms joins the room [22:15:42] Dan Wing joins the room [22:16:50] tsavo leaves the room [22:18:09] *blinks [22:18:25] about to resume... [22:19:05] http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100028.zip [22:19:22] satoru.matsushima joins the room [22:19:26] Dan Wing leaves the room [22:19:39] Dan Wing joins the room [22:20:46] Dan Wing leaves the room [22:21:20] behcet.sarikaya joins the room [22:21:42] HUI joins the room [22:21:49] sureshk joins the room [22:23:50] Are the slides and/or doc available? [22:24:02] ietfdbh joins the room [22:24:06] dont' know [22:24:24] Dan Wing joins the room [22:25:00] Yes, look in INBOX [22:25:03] ftp://10.30.2.60/WORKSHOP/INBOX/IPW100041.zip [22:25:22] The RFC1918 ftp server strikes again :-) [22:25:23] again local link [22:26:03] Hmph. OK, I'll drop my VPN so I can access that server. [22:26:09] ssh is your friend [22:26:14] rdroms leaves the room [22:27:34] what does "non-3gpp access" mean (blue line)? [22:27:40] If the app is accessing IPv4 services, then the self-assigned v4 address cannot be meaningless. [22:27:48] Magnus Westerlund joins the room [22:28:07] what would you explain to dual stack lite, that's the same? [22:28:14] even gi-ds-lite [22:28:18] @dave: anything other than 3GPP networks [22:28:22] e.g BBF fixed networks [22:28:24] non-3gpp means wifi [22:28:28] CDMA wireless networks [22:28:32] @suresh: thx [22:28:36] rdroms joins the room [22:28:41] thanks... [22:29:01] so BBF fixed networks still go through the GGSN?? [22:29:23] Yes. This is for a 3GPP dual mode UE [22:29:30] e.g. phone with WLAN/LTE [22:29:41] when it enters its home [22:29:44] Phil Roberts leaves the room [22:30:08] @scott: they seem to have a model where the network assigns the UE an IPv4 address that can't be used on the network [22:30:25] NAT at the edge? [22:30:26] but they haven't expained why that's useful for anything [22:30:31] Phil Roberts joins the room [22:30:33] or rather … where is the NAT [22:30:38] yes NAT in the UE [22:30:52] in UE ah [22:32:10] i think we need to decouple the basic scenario of IPv4 legacy apps talking over an IPv6-only core [22:32:19] from some network-assigned IPv4 address [22:32:23] jouni.korhonen joins the room [22:32:26] +1 [22:32:38] slide 3 does seem to be an IPv6-only core (referring back to my question before lunch) [22:35:03] I suspect everyone understands these slides differently [22:35:10] rdroms leaves the room [22:35:24] The Black Eyed Peas have a song, "Where is the NAT" [22:36:28] i'm getting kinda claustrophobic here close to the mic [22:38:35] Lars joins the room [22:40:59] Jonne Soininen joins the room [22:41:40] I don' t know a legacy application where UE sends packets directly to another UE without a rendezvous point somewhere... if there is rendezvous outside, traffic goes thru NAT44, and UEs do not see each others private addresses... [22:42:19] there is no NAT44 labelled on slide 5 (which was Scott's point...) [22:42:26] sure [22:42:39] so if thereś not NAT44 one needs a PNAT I guess [22:42:51] Scenario 4 does not support legacy applications doing UE-to-UE communication. [22:43:08] then what's the blue line on slide 5 referring to? [22:43:32] It is UE-to-UE communication. But it is not a legacy application doing UE-to-UE. [22:43:43] @Dan +1 [22:43:50] It is, rather, a new application, which does a gethostbyname() query to find its peer. [22:43:55] the left side is labelled "Legacy/third party IPv4 applications" [22:44:01] connectbyname() [22:44:03] are you saying the slide is wrong? [22:44:03] I hope [22:44:23] the slide does not reflect what's in the 3GPP TR... [22:44:26] The slide does not concur with the specifications nor mailing list discussion. [22:45:26] The slide is made up with a scenario that we hadn't discussed before and for which we obviously couldn't conclude that it works with current tools [22:46:40] Finally somebody from 3GPP speaks up [22:48:35] (the TR referred to is at http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100007.zip ) [22:49:34] the TR just says: "5.4 Scenario 4: IPv4 applications running on a Dual-stack host with an assigned IPv6 prefix and a shared IPv4 address and having to access IPv4 services In this scenario an IPv4 application running on a dual-stack UE requires to access IPv4 services without the operator having to allocate a unique non-shared (private or public) IPv4 address to the UE. The dual-stack UE running these applications uses an IPv4 address that is shared amongst many other UEs, and uses an IPv6 prefix. " [22:51:30] wmhaddad leaves the room [22:53:27] So scneario 4 as captured in the TR is a sub-case of scenario 2 where only IPv4 applications are considered, as opposed to scenraio 2 where both v4 and v6 applications are considered [22:53:41] Scenario 2: "This migration scenario is based on the Dual stack model: The operator assigns both an IPv6 prefix and an IPv4 address to UEs in order to ensure that both IPv4 and IPv6 capable applications can be utilised. The IPv4 addresses assigned to UEs are taken from one of the private address ranges as specified in RFC 1918. To enable global connectivity, network address translation (NAT) is performed on the (S)Gi interface for IPv4 packets originated from or destined to the UEs. " [22:53:57] rdroms joins the room [22:54:14] the phrase "an IPv4 address that is shared amongs many other UEs" in the TR secton 5.4 is very confusing. I haven't seen this phrase explained by anyone. [22:54:59] my guess is all UEs, for example, get 192.168.1.1 [22:55:06] it means that the GGSN/PGW possibly assigns the same address to different UEs [22:55:12] right [22:55:13] Yes. A "worked example" showing IP address assignments, location(s) of NAT(s), etc. would be helpful. [22:55:14] then it's the same as scenario #2 as jlaganie implies [22:55:29] ryuji@mt.view leaves the room [22:55:36] which isn't a problem per se as long as the NAT binding is bound to a given GTP tunnel [22:55:51] agreed [22:56:21] as described in Jari's draft, per-interface NAT [22:56:45] I think the key difference/issue is on slide 3 "the network may only provide IPv6 connection through assigning IPv6 prefix" [22:56:46] http://tools.ietf.org/html/draft-arkko-dual-stack-extra-lite-00 [22:57:08] "Scalable Operation of Address Translators with Per-Interface Bindings", J.Arkko, L. Eggert [22:57:09] which I think they interpret as "no IPv4 connectivity" [23:01:31] jlaganie leaves the room [23:01:44] Phil Roberts leaves the room [23:01:44] kehong joins the room [23:04:08] current slide set (scenario4) seems to be IPW100041.zip , as suresh pointed. However, this one is not available on the 3gpp ftp server. any way to get a copy? [23:05:01] He put it in INBOX on the local server. I don't know how often the administration here puts things on the external server. [23:07:05] Scott, email it to me and I can throw it on an Internet-connected server. [23:07:08] someone pointed out to me I was using the wrong term regarding "core" [23:08:08] I meant "IPv4 connectivity across the PDP context", does it exist in this scenario or not. The TR and others imply Yes. Hui says maybe no. That's the key point of discussion I think. (And I'm saying if the answer is no, then the term "shared IPv4 address" makes no sense to me) [23:10:14] kehong leaves the room: Disconnected. [23:11:15] unless it is tunnelled over v6 [23:12:16] ok fair, but it's still "across" the PDP context, just not directly. [23:12:57] kehong joins the room [23:13:27] Hmmm, not sure what you mean by "across" [23:13:44] "over" :) [23:14:02] right, layered … v4 over a v6 only environment [23:14:07] can you send an IPv4 packet (possibly encapsualted) [23:14:31] kehong leaves the room: Disconnected. [23:15:08]