[15:56:27] --- Dan York has joined
[15:58:43] --- ruri_hiromi@chat.gizmoproject.com has joined
[15:59:07] --- TJ has joined
[15:59:54] --- dthaler has joined
[16:00:11] --- bkhabs@jabber.org has joined
[16:00:11] * dthaler has changed the subject to: v6ops WG IETF 70
[16:00:52] --- nm has joined
[16:01:52] --- BillC has joined
[16:02:49] --- raj has joined
[16:03:08] <TJ> WG Starting
[16:03:14] <TJ> Going to spend some time on prepared slides, then have an hour discussion
[16:03:14] <Dan York> If someone could scribe that would be appreciated. (Thanks)
[16:03:33] * Dan York notices that TJ just did - thanks!
[16:03:34] <TJ> Alain Durand: This week we run a DHCPv6 bake-off. If you are interested, please contact me.
[16:03:49] --- mohsen has joined
[16:03:53] --- tom5760@gmail.com has joined
[16:04:00] <TJ> Hiroshimi: I'm wrong a document regarding translator. Please commend
[16:04:00] --- trond has joined
[16:04:02] <TJ> comment
[16:04:04] --- iljitsch has joined
[16:04:09] <TJ> FB = Fred Baker
[16:04:19] --- jronan has joined
[16:04:25] <TJ> (Agenda bashing - description of documents right now)
[16:04:50] --- nm has left: Replaced by new connection
[16:04:50] <TJ> First talk - Jordi Palet
[16:04:50] --- nm has joined
[16:05:06] <TJ> 6meter: Measuring Real Global IPv6 Traffic
[16:05:12] <dthaler> are slides online?
[16:05:33] <TJ> Maximum that providers say they have of IPv6 traffic in their network.. 2-6%
[16:05:44] <TJ> But they are counting only IPv6-native traffic.
[16:06:21] <TJ> Developed a tool that allows them to look at the real traffic on an interface (port mirroring). Native IPv4, v6, 6to4, Teredo, GRE, Protocol 41
[16:06:35] <TJ> Also multicast. Look at source address to understand which region the traffic is coming from.
[16:06:39] --- fdupont has joined
[16:07:06] --- arifumi has joined
[16:07:22] <iljitsch> this is a combination of my own slides and Brian's in the order I'm actually going to present them later: http://www.bgpexpert.com/presentations/ivb-v6ops6dec2007.pdf [http://www.bgpexpert.com/presentations/ivb-v6ops6dec2007.pdf]
[16:07:22] <TJ> Started real measurement in August - end of November. 67% of packets were IPv6; 45% of bytes were IPv6.
[16:07:54] <TJ> (Types of Traffic slide - pie charts)
[16:08:09] --- rhe has joined
[16:08:16] <TJ> Origin of Source Address slide
[16:08:17] --- andrewsullivan has joined
[16:08:20] <BillC> i found the ripe presentation at www.ripe.net/ripe/meetings/ripe-55/presentations/palet-v6.pdf
[16:08:44] <TJ> (81% from RIPE. 11% from ARIN.. This was only 6% at the beginning but was increasing)
[16:09:15] --- frodek has joined
[16:09:20] <TJ> (Question on types of traffic.. clarifying color)
[16:09:47] <TJ> Native v. Transition slide
[16:10:02] <TJ> Weekly Stats slide
[16:10:16] <iljitsch> I think he meant to say "transition" is ~90%, not native
[16:10:21] <TJ> First 2-3 weeks of August, everyone was on vacation.. then it increased
[16:10:26] --- narten has joined
[16:10:26] --- tom5760@gmail.com has left
[16:10:31] <TJ> Yes I believe he had it backwards, most is non-native
[16:11:00] <iljitsch> that being the point of the presentation :-)
[16:11:21] <TJ> Right...
[16:11:28] --- Doug Hantula has joined
[16:11:34] <TJ> Monthly Stats slide.
[16:12:05] <TJ> Next steps.. now that the tools is stable, we'll look for 2-3 ISPs in every region.
[16:12:25] <Dan York> dthaler: there are slides on https://datatracker.ietf.org/meeting/70/materials.html down under "V6OPS"
[16:12:32] --- lars.eggert@googlemail.com has joined
[16:12:37] <TJ> Believes the stats will be about the same in different regions. Important consideration.. they run 6to4 and Teredo relays, which attracts some traffic.
[16:13:31] <TJ> Another consideration: bittorrent, MSN with Vista support v6, and use it by default if IPv6 is enabled. Doesn't believe his network is that different... Hosts web sites for customers that are not telecom related. 85%+ of his traffic is P2P
[16:14:27] <dthaler> (Dan: yes but this presentation isn't there, that's why I asked)
[16:14:36] <TJ> Joel Jaeggli: This is the traffic mix for your own network.. Doesn't tell me about IPv6 deployment anywhere except your network, where you host a relay
[16:14:45] <dthaler> (thanks to BillC for the pointer to ripe55)
[16:15:06] <TJ> JP: Yes, but if I didn't host the relay, it would go somewhere else.
[16:15:20] --- mrw has joined
[16:15:27] <TJ> Joel: Yes, but I can't draw any conclusions about this. Your business is IPv6-related
[16:15:32] <BillC> the ripe55 presentation has apparently been updated because number don't match perfectly :-(
[16:15:45] <BillC> s/number/numbers/
[16:15:45] --- falk has joined
[16:15:58] <TJ> Remi Denis-Courmount: I wrote the SW that you use, and I have to agree with Joel here. It would be different if you run it on a real ISP.
[16:15:58] <falk> slides are here: xmpp:v6ops@jabber.ietf.org
[16:16:02] <falk> oops.
[16:16:03] <TJ> JP: We see 1000's of addresses.
[16:16:15] <falk> http://www.ripe.net/ripe/meetings/ripe-55/presentations/palet-v6.pdf [http://www.ripe.net/ripe/meetings/ripe-55/presentations/palet-v6.pdf]
[16:16:15] <TJ> JP: We have to wait for a couple of months when we have more of this testing.
[16:16:41] <TJ> ?: If you stop running the relay, this 100Mb traffic goes elsewhere. This is not 67% of traffic in no small ISP in the world.
[16:16:49] <TJ> JP: I don't have more traffic because my pipes are already full.
[16:17:02] <TJ> ?: This will make sense only if you run this on an IPv6 end site that doesn't have a relay.
[16:17:09] --- gnaik has joined
[16:17:15] --- Suzanne has joined
[16:17:23] <TJ> JP: I don't agree. We have to measure where we can capture P2P traffic (w/ relay) otherwise you can't see it.
[16:17:27] <TJ> Next presentation:
[16:17:42] <TJ> Marcelo Bagnulo -- IPv6-v4 Translator Problem Statement / Analysis
[16:18:32] <TJ> Goal of the draft slide
[16:18:49] <TJ> Supported App behavior slide
[16:19:49] <TJ> First type of application he wants to support is for a v6 node to initiate a short-lived connection to the other (v4) side..w/o any address information in the payload.
[16:19:55] <BillC> this presentation appears to be in datatracker as http://www3.ietf.org/proceedings/07dec/slides/v6ops-9.pdf
[16:20:02] <TJ> Supported App behavior (III)
[16:20:31] <TJ> Host on v4 side creates a bunch of connections to the v6 side. Address retained at the app layer.
[16:20:40] <TJ> Suuported App behavior (V)
[16:20:41] <TJ> slide
[16:21:40] <TJ> v4 side initiates comm to v6, v6 receives source address of v4 host, and later goes back.
[16:21:40] <TJ> (VI): same thing initiated from v6 side.
[16:21:40] <TJ> (VII)
[16:21:40] --- TJ has left
[16:21:44] --- TJ has joined
[16:21:59] <TJ> hmm
[16:22:12] <TJ> ok I just got disconnected and 9 minutes of stuff is gone frm my screen.
[16:22:23] <TJ> Criteria to decide what applicatoin support goal? sllide
[16:23:01] <TJ> NAT64 required mods (I) slide
[16:23:29] <TJ> Other considerations slide
[16:23:40] --- magnus has joined
[16:25:22] <TJ> Ed Jankwitz: This creates a useful taxonomy on the various vectors you pointed out. Are we ready to rule out certain things, or just create the taxonomy to evaluate? Let's not jump to that conclusion already. Just because it requires a change on the v6 box, some might like that solution and others would not. I support devleoping these ideas in an open minded way.
[16:25:36] --- nm has left: Replaced by new connection
[16:25:39] <TJ> Erik Nordmark: The transparency and what box you need to change have a lot of overlap. Is there a difference between them?
[16:25:43] --- nm has joined
[16:25:54] <TJ> MB: You may need an update on the box, but you don't have an explicit communication with the box.
[16:26:24] <TJ> EN: There's another axis along here. The v6 world had only v6 in it, but things get trickier if you have e.g. an old v4 printer in there. It's simpler if you can say anything v4 is external, send it out.
[16:26:51] <TJ> FB: He wasn't drawing pictures of networks there...
[16:27:09] --- john.zhao has joined
[16:27:12] <TJ> FB: If you a device that does both v6 and v4, it lives in both of those domains. He was talking about when xlation occurs.
[16:27:59] <TJ> Shin Matsuyama? from NTT: We already identified that for general purpose NAT64, it can not be acceptable in the backbone/core of ISP. If we have status in the middle network, this would be a potential risk for DoS.
[16:28:39] <narten> Shin Miyakawa
[16:28:39] <TJ> - but some advanced ISPs would go to dual-stack. Some app-specific NAT64 for dedicated service may be needed in the ISP.
[16:28:45] <TJ> Ah, thanks
[16:29:53] <TJ> Geoff Huston - I'm uncomfortable with what I heard. Apart from the name, what does this have in common with NATs as we understand them? Where's the asymmetry in a v4 conventional NAT? Are we sucked into a false dichotomy? Behaviors that we know and understand, but applying them to a completely different problem. First law of holes applies - stop digging.
[16:30:12] <TJ> - It is a protocol translation with state. But that's it -- it's not a NAT as we knew it.
[16:30:22] --- atarashi has joined
[16:30:31] <TJ> MB: I agree it has not much to do with a NAT in the v4 world, but terminology is inherited by NATPT
[16:30:48] <TJ> - Maybe it is the case, but all the app behavior comes from a completely different world
[16:31:18] <TJ> GH: I didn't see anything about Rendezvous vs. Payload. From an app point of view, you're using a different paradigm -- using a packet transfer.... I want these things to work across v4/v6 but how?
[16:32:26] <TJ> Hirosimi - I agree to define the goal with Miyakawa, we need the goal, which should depend on the deployment scenario. I want to describe a document to address how to approach the translation issue. The analysis should be conducted in the (trend?) model, which may be possible...
[16:32:55] <TJ> Jordi Palet - End site is not good terminology. Instead of an end site in the ISP, I would say "in the ISP" , "in the CP?", "in the host"
[16:33:11] <TJ> - in the ISP you have security and scalability problems.
[16:33:55] <TJ> Magnus W. - Application with embedded addresses. Did you include them in your referral cases? When you're trying to learn about your parallel streams, you will also go through the translator.
[16:34:09] <TJ> - You have a number of protocols that do signal exchange and try to open a parallel stream.
[16:34:28] <TJ> MB:: That's called a callback in this case (app behavior V slide)
[16:34:35] <TJ> MW: You have a need for a long-lived state.
[16:34:38] <iljitsch> we are way behind schedule, people
[16:34:48] <TJ> MB: This is what we usually think of as FTP
[16:35:08] <TJ> MW: You have a SIP registrar... you can split this into short- and long-lived callbacks.
[16:35:36] <TJ> FB: Why did I cap the line? 1st 20 minutes of this session has now taken 40. We can't have the last hour of discussion at the mic if we spend it between talks.
[16:36:15] <TJ> Next presentation - Alain Durand - Reviving NAT-PT - two proposals
[16:36:24] <TJ> Oops...
[16:36:59] <TJ> Next presentation - Alain Durand - Sharing a single IPv4 address among many broadband customers
[16:37:31] <TJ> ...can someone take over Jabber for a minute??
[16:37:48] <TJ> Problem Statement slide
[16:38:01] <iljitsch> for a minute, ook
[16:38:19] <iljitsch> alain: the real problem is that the edges are v4: the stuff that customers have in their home, look at this first
[16:38:32] <iljitsch> customers keep stuff around for a long time, computers 5 or 6 years
[16:38:38] <BillC> Presentation appears to be in datatracker as http://www3.ietf.org/proceedings/07dec/slides/v6ops-5.ppt
[16:39:19] <iljitsch> things people bought one or two years ago like Windows XP don't support IPv6 (sufficiently) and these things are going to be around for several more years
[16:39:34] <iljitsch> all the content that people try to reach is on v4 servers
[16:39:46] <iljitsch> some of it moves to v6 but this takes a long time, there is a lot of content
[16:39:58] <iljitsch> we won't have IPv4 addresses left soon
[16:40:03] <iljitsch> we ISPs are in the middle
[16:40:19] <iljitsch> the idea is to reduce customers' IPv4 footprint
[16:40:27] <iljitsch> share one IP address over many customers
[16:40:38] <TJ> ok back, thanks
[16:40:43] <iljitsch> deploy IPv6 for new devices etc
[16:40:45] <TJ> How to Implement This? slide
[16:41:11] <TJ> only provision customers with v6 address on home GW.. different tier of service if you really want v4 for VPN, but you have to pay more.
[16:41:33] <TJ> --assumes you can upgrade the home gw device.
[16:41:57] <TJ> You have a NAT, to v6. Becuase what you're trying to reach is v4, we'll NAT it again to v4.
[16:42:07] <TJ> So it reduces the footprint and shares the address with many customers.
[16:42:17] <TJ> Arch. Overview: Double NAT slide
[16:42:24] --- Bob has joined
[16:43:10] <TJ> v4 packets are translated to v6 in the home gw, then sent back to a v6-> v4 translator in the core of the ISP's network.
[16:43:27] <TJ> Scalability is a big issue.
[16:43:39] <TJ> ISP NAT 6->4 discovery: DHCPv6 Config slide
[16:43:49] <TJ> DHCP can be used to give the translator address.
[16:44:08] <TJ> How do you map a v6 into a v4 address? (example mapping given on slide)
[16:44:31] <TJ> A prefix is delegated to you that you use for this mapping.
[16:44:55] <TJ> A mapping prefix (M) identifies the prefix translator you're using in the ISP network.
[16:45:24] <TJ> Special Considerations slide
[16:45:28] --- marc.blanchet.qc has joined
[16:45:49] <TJ> How does this work with DNS? DNS is just another protocol; we translate it exactly the same way. Or, you send the DNS request to the home GW, which does the resolution of v6.
[16:46:05] <TJ> MTU is a bit more tricky -- v6 header is longer, so we have to reduce the MTU. So the v4 MTUs must be a bit smaller.
[16:46:19] <TJ> Will not work for all apps, but no worse than a normal NAT.
[16:46:23] <TJ> FAQ slide
[16:47:13] <iljitsch> FAQ slide - love it!
[16:47:20] <TJ> :-)
[16:47:25] --- apn has joined
[16:48:19] --- nm has left: Replaced by new connection
[16:48:19] --- nm has joined
[16:48:38] <TJ> Shin M.: Bullet 2 - why not simply use double v4 NAT? We already decided to do that, because today's equipment is already mature. We can also divide region to region, and use the same single private address space. So I don't think it's a serious problem. What we do is the same as what you're doing.
[16:49:29] <TJ> - Also.. JPNIC has already proposed to APNIC to define another private IP space just for that purpose. Because we can't assume which private address space is now used in customer sites. So we ask to IANA to define another private IP address space for providers. Or use global IPv4 addresses just for private use.
[16:49:36] --- Doug Hantula has left
[16:49:58] <mrw> I would like to ask the following question: Why is it better to use an IPv4 to IPv6 NAT in this situation, rather than using an existing IPv4 to IPv4 NAT from private IPv4 space to a single public IPv4 address, and then tunneling the IPv4 traffic to the IPv4 Internet?
[16:50:10] <mrw> Is there someone here who can relay my question?
[16:50:13] <TJ> AD: We have been looking at that very seriously in our network. We spent 3 years to come from a network of islands, to make one single network. We gain a lot with visibility in our network. We lose visibility
[16:50:23] <TJ> Yes I can relay it in a minute.
[16:50:29] <mrw> Thanks!
[16:50:30] <iljitsch> mrw: that's on the faq slide:
[16:50:39] <TJ> SM: We don't have any control on CP (customer premises), but you do. That's the difference.
[16:51:01] <TJ> Eric Cline: Question about 1st point. Why don't you just encapsulate in v6 tunnel?
[16:51:03] <mrw> Thanks, Iljitsch. Let me look at that before relaying the question.
[16:51:07] <iljitsch> Comcast has so many customers that they can't even number them all out of 10/8 without using addresses multiple times
[16:51:07] <TJ> AD: You need source address of v4 packet
[16:51:34] <TJ> AD: We ran out of space in net-10 2 years ago
[16:51:43] <marc.blanchet.qc> but losing visibility is not an issue, since if they are deploying ipv6, they could do the netw mng with ipv6...
[16:51:44] <mrw> Why not get one via v4 to v4 NAT? That is my question, too.
[16:51:50] <TJ> EC: So home 1918 address is not id'able by which tunnel it came in?
[16:53:02] <mrw> Is the idea that they can't even afford enough public v4 addresses to allow even one per connected location?
[16:53:06] <TJ> Jim bound: clarification. Thanks for sharing your opinion. WG has done a lot of work on 3574 and 3750. 4779 4029. We understand the clarification in that work. This doesn't apply to 4057 and 4852 which is work on enterprise. Clearly identify this for broadband providers
[16:53:08] <TJ> yes.
[16:53:15] <TJ> (to mrw: yes.)
[16:53:38] <TJ> Erik N: Do you have requirements on NAT in the middle of the network? Does it need to be stateless?
[16:53:47] <mrw> Hmmm... interesting. I didn't think we were anywhere close to that point.
[16:53:54] <TJ> AD: We want it to be as close as possible to the 1st hop router.
[16:54:21] <TJ> - For a technical reason I can't talk about, we can't do it on the 1st hop router. One translator for 20k - 50k customers.
[16:54:35] <mrw> Question: If we could solve the tunnel identification issue, would that be a superior/preferred solution?
[16:55:33] <TJ> Ralph Droms: Erik anticipated my question.. It seems that this is a deployment of 6to4 nats that we're talking about as part of transition. Is it a particular deployment of the translator we're talking about, or are there other features of the translators? If it's just a different way of deploying them, it is interesting and informational. If there are add'l features, it has an impact on the WG discussions.
[16:56:24] <TJ> AD: There are 2 pieces in the diagram - 2 translators. It's completely stateless in the home GW. The second one (in the core of ISP), I hope it will be exactly the same as what others are talking about - generic translator from v6 to v4. The question is what the format / encapsulation will be.
[16:56:25] --- klensin has joined
[16:57:54] <TJ> Next presentation - Elwyn Davies - Requirements (and other considerations) for nat-pt replacement from rfc 4966
[16:58:09] <TJ> RFC 4966 slide
[16:58:24] <falk> schlides?
[16:58:50] <TJ> He is presenting off his laptop, don't know if they're online yet. Did you check the proceedings directory?
[16:59:05] <mrw> They don't seem to be there. I am looking at it right now.
[16:59:06] <falk> i checked the annotated agenda
[16:59:06] <TJ> Interactions with DNS slide
[16:59:24] <mrw> Unless I am missing something...
[16:59:34] <TJ> DNS ALG is major problem of NAT-PT
[16:59:37] <mrw> No, none of these are Elwyn's slides.
[16:59:46] <dthaler> not on the site
[16:59:51] <dthaler> (not in the directory)
[16:59:52] <TJ> R1: Any modifications to DNS responses associated with translation MUST NOT violate standard DNS semantics.
[17:00:07] <TJ> Possible approaches: - Tranlate A records in host
[17:00:19] <TJ> - Translating DNS resolver - issue with applications that have own resolver
[17:00:24] <TJ> Host/Application Awareness slide
[17:00:38] <TJ> RFC 2766 aims for transparency and autonomous operation
[17:00:50] <TJ> - New solution options (combinations possible):
[17:00:55] <TJ> - Stick with transparency
[17:01:03] <TJ> - Allow host stack awareness of translation
[17:01:08] <TJ> - Require host stack awareness
[17:01:10] <mrw> Question for this group: If we are assuming that we need this type of solution because we can't upgrade old Windows machines to include dual stack, how could we upgrade them to include DNS changes?
[17:01:12] <TJ> - Allow application awareness
[17:01:17] <TJ> - Require application awareness
[17:01:22] <TJ> - Awareness is not a binary value
[17:01:38] --- behcet.sarikaya has joined
[17:01:42] <iljitsch> mrw: if you can't do the former you don't need the latter. :-)
[17:01:59] <TJ> To be frank, I can't see that changing IPv4 stack is feasible, so we're talking about v6 only.
[17:02:05] <TJ> (that's a comment from ED)
[17:02:13] <mrw> Ah, he gets that, too.
[17:02:17] <mrw> That's good.
[17:02:40] <TJ> ED: You can move up the chain and consider whether the applications on the host can be allowed/required to be aware of the translation.
[17:02:41] --- andrewsullivan has left
[17:02:42] --- frodek has left
[17:02:56] <TJ> Awareness Might Enable... slide
[17:03:01] <TJ> - ALG free translator
[17:03:12] <TJ> - Using optimum netowrk (native IPv6 vs. translation) when there is a choice
[17:03:23] <TJ> - Using IPv6 capabilities when they are available but not when translating
[17:03:40] <TJ> - Unawareness promotes Lowest Common Denom situation and IPv6 stasis
[17:03:45] <TJ> - Control connection from host to gateway
[17:03:55] <TJ> - Dynamic authentication and authorization of gateways
[17:04:07] <TJ> - Reduced need for NAT(-PT) traversal help
[17:04:22] <TJ> Is it useful for me to type out the slides like this?
[17:04:27] <TJ> How many people are participating remotely?
[17:04:33] <mrw> I am.
[17:04:33] <TJ> Awarenes cons slide
[17:04:40] <TJ> - Deployability
[17:04:43] <mrw> I am in the hotel, but not feeling that great. So, I am hiding in my room.
[17:04:47] <TJ> - if host and/or applications are REQUIRED
[17:04:51] <TJ> - More work in converting applications
[17:05:02] <TJ> - Portential need to modify multiple DNS resovlers in one node (see above)
[17:05:18] <TJ> - Some RFC 2766 issues can be fixed up with minimal 'awareness'
[17:05:25] <TJ> -e.g., better address selection algorithm
[17:05:40] <TJ> Are you listening to the audio stream? Because he's reading most of the points from the slides.
[17:05:43] <TJ> Referrals slide
[17:05:49] <mrw> Yes, I am listening.
[17:05:56] <TJ> - Is there a way to provide a universal ID that can work across IPv4 and IPv6?
[17:06:01] <mrw> You don't need to type the slides. He is being clear enough, I think.
[17:06:02] <TJ> - Existence proof: See SHANTI proposal
[17:06:06] --- cdl@jabber.org has joined
[17:06:21] <TJ> ok. I am trying to avoid getting carpal tunnel syndrome... :-P
[17:06:21] <mrw> Thanks for doing it, though!
[17:06:31] <TJ> Multicase slide
[17:06:36] <TJ> *Multicast
[17:06:55] <TJ> Mobile IP slide
[17:07:18] <TJ> Scalability slide
[17:08:25] <TJ> Comment from Bob: Can you make sure slides are posted
[17:08:35] <TJ> FB: These slides were just given to me...
[17:08:51] <mohsen> I'm the neighbor of I TJ and I can whitness he's working very hard to get the most of the slides and of the talk written in jabber. Good job!
[17:08:54] <TJ> Next presentation - Dave Thaler - A Transition Scenario Caused by IPv4 Address Scarcity
[17:08:57] --- john.zhao has left: Computer went to sleep
[17:09:08] <TJ> TRansitioning to IPv6 slide
[17:09:30] <TJ> Transition solution space today slide
[17:09:45] <TJ> (I don't think I'm going to be able to transcribe Dave Thaler... he speaks very fast..)
[17:09:46] --- apn has left
[17:11:15] <TJ> Scenario caused by Iv4 address scarcity slide
[17:11:19] <TJ> *IPv4
[17:12:21] <TJ> The case we've looked at most is where the Dual stack host is initiator and v4-only host is on outside..
[17:12:46] <TJ> But this is the case where there is the most pain.. where the well-behaving dual-stack host is on an IPv6-only network, it can not get a v4 address.
[17:13:10] <TJ> There are currently no recommendations for this, except maybe NAT-PT which was deprecated. The IETF should be looking at this.
[17:15:13] <iljitsch> this is a combination of my own slides and Brian's in the order I'm actually going to present them later: http://www.bgpexpert.com/presentations/ivb-v6ops6dec2007.pdf [http://www.bgpexpert.com/presentations/ivb-v6ops6dec2007.pdf]
[17:15:21] --- iljitsch has left
[17:15:34] <TJ> Tony Hain: Alain's description has the problem space where the client's local network is going to v6-only.
[17:15:42] <TJ> DT: The scenario he showed and what I show are different.
[17:15:53] --- frodek has joined
[17:15:59] <TJ> TH: When we develop list of things to pay attention to, your picture does a good point.
[17:16:20] <TJ> DT: There may not be a one-size-fits-all solution.
[17:16:38] --- john.zhao has joined
[17:16:59] <TJ> David Henkins?: I think you chose a bad example. HTTP has a host header. So it's easy to put a little box that listens to port 80 on one IPv4 address and looks up the v6 address on the back side.
[17:17:16] <TJ> DT: Web maybe is not the best example, but maybe something that's general for what other application types should do.
[17:17:35] <TJ> Alain D: On the right, are you looking at this as an enterprise deployment? Or in a home scenario?
[17:18:11] <TJ> DT: it's ambiguous because there are multiple types of this scenario. Could be a server farm, ISP with customers, P2P app that's attached to an ISP
[17:18:35] <TJ> AD: It's important to make a distinction, because if it's P2P in a BB enviornment you would need many Iv4 addresses.
[17:18:46] <TJ> AD: If it's enterprise, you would need much less addresses.
[17:19:31] <TJ> Ralph Droms: The IAB asked you to look at this?
[17:19:43] <TJ> DT: The IAB suggested to the IESG that the IETF should look at it
[17:19:53] <TJ> DB: I.E. They asked us
[17:20:15] <TJ> DT: This is increasingly likely, it is not a charter item in any group, and it's a gap.
[17:20:46] <TJ> ?: I don't think the IETF's job should be to figure out whether it's an enterprise scenario or someone's home. These are IETF end nodes.
[17:21:06] <TJ> [Personal comment: This is not irrelevant to Comcast.. they don't want you running servers in your home.]
[17:21:18] <cdl@jabber.org> That was the point of the comment
[17:21:19] <cdl@jabber.org> :)
[17:22:16] <mohsen> Isn't is a paranoid assumption?
[17:22:23] <dthaler> Thanks Ralph for asking about the scenario I meant to say something... the main point was not that this is THE scenario, but when the IETF is looking at scenarios, please consider this one too... as it seems to be a gap in the list today.
[17:22:26] <TJ> Next presentation - Iljitsch vB - Reviving NAT-PT - two proposals
[17:22:30] <dthaler> and it's becoming increasingly likely.
[17:22:41] <cdl@jabber.org> ? = Chris Liljenstolpe
[17:22:43] <mrw> I'm pretty sure my agreement with comcast says I'm not allowed to run servers in my home... At least some version did.
[17:22:54] <mrw> (I have comcast as a home ISP)
[17:22:56] --- behcet.sarikaya has left
[17:23:15] <TJ> [Right.. which is why my experiment of whether I could switch from DSL to Comcast was a failure.)
[17:23:40] <TJ> (You can run servers at home... as long as you are willing to be a Business customer.)
[17:23:44] <TJ> (and $$)
[17:23:55] <TJ> The dual stack problem slide
[17:24:01] <mrw> Well, yes. I assumed I could pay more for different service, but I don't need a different services right now.
[17:24:39] <TJ> (Yes this is an interesting discussion.. whether a "normal" residential Internet user should be allowed to serve information or just be a client.. maybe we can talk about it later)
[17:24:44] <TJ> Dual Stack slide
[17:24:52] <TJ> RFC 2766 NAT-PT slide
[17:24:59] <TJ> (fire)
[17:25:24] <TJ> Fake AAAA records made from A record
[17:25:33] <TJ> Shimmed .... presentation from Brian
[17:25:45] --- behcet.sarikaya has joined
[17:26:16] <TJ> Model: one IPv4 address represents many IPv6 addresses slide
[17:27:13] <TJ> Upper-layer protocol (TCP,UDP,..) wants to talk on an IPv6 host to an IPv4 host, it goes through a shim layer that makes IPv6 stuff happen, goes to translator, then goes to IPv4. Whole thing between shim boxes is a distributed IPv4 stack.
[17:27:29] <TJ> What the shim does slide
[17:28:31] <TJ> DNS slide
[17:28:42] <TJ> NAT-PT issues from RFC 4966 slide
[17:28:53] <TJ> (Back to Modified NAT-PT slide)
[17:29:06] <TJ> remove fake AAAA record and replace with real A record
[17:29:29] <TJ> MNAT-PT slide
[17:29:54] --- behcet.sarikaya has left
[17:29:57] <TJ> v4-v6-v4 MNAT-PT slide
[17:30:11] <TJ> .. (2) slide
[17:30:17] <TJ> IPv4-to-IPv6 slide
[17:30:29] <TJ> Pros of MNAT-PT slide
[17:30:39] <TJ> ..
[17:30:40] --- behcet.sarikaya has joined
[17:30:41] <TJ> My opinion slide
[17:31:09] <TJ> Let's not fight whether this is a good thing to do in general. If the market needs it, let's make it as good as we can and let the market decide whether to deploy it.
[17:31:46] <TJ> Alain Durant: The SHANTI proposal is very interesting, but it's attaching itself to the shim6 bandwagon.
[17:32:01] <TJ> IvB: It doesn't use shim6 proper, but uses the concepts. will use 20% of shim6 and rip out 80%.
[17:32:13] <TJ> AD: You still have to have it implemented on IPv4 side, isn't it a non-starter?
[17:32:21] <TJ> IvB: No, only between translator and IPv6 side.
[17:32:28] <TJ> AD: It doesn't require changes on server running v4?
[17:32:33] <TJ> IvB: correct.
[17:32:52] <mrw> If someone could get in "line" for me, I have a comment and a question.
[17:32:54] <TJ> David Miles: I don't disagree with what you proposed for v4-to-v6, but implementations on the host should be considered. This might require host modifications.
[17:33:09] <TJ> - I believe you use 0.xxx entries for A records
[17:33:17] <TJ> IvB: if it's a problem, we'll use something else.
[17:34:18] <TJ> Curtis Lindqvist: Reason we're using translators is because people are deploying v6 in the first place. Thinking people will be faster rolling out new code to the edges is naive.
[17:34:46] <dthaler> both of these are primarily for v6only initiators connecting out to v4-only listeners. The other direction isn't solved by either other than by manual config of port forwarding essentially
[17:34:52] <TJ> IvB: True, but if you don't roll out new software, you're not oging to do anything new on your computer. Having the CPE (gateway) do translation, you only need to update the CPE, not win98 boxes.
[17:35:12] <TJ> Erik N: Brian used a bunch of terminology in IPv6, but there's nothing relating to shim6 protocols.. just a clever combination.
[17:35:25] <mrw> Comment: Based on the presentations from Alain and Dave Thaler, it appears that we have two separate-but-related problems, both of which involve an IPv4-to-IPv4 connection where one (or both?) sides do not have public addresses available. I do understand how translating to/from IPv6 *could* be used to solve this, but I wonder if it is the right way to solve this.
[17:35:33] --- rdenisc has joined
[17:35:34] <TJ> EN: Has anyone looked at double-translation between v4 and v6, and whether that would get us into more trouble than tunneling?
[17:36:21] <dthaler> mrw: right. I said the same thing... whether it's translation, encapsulation, or whatever else... my point was just to have *a* story where none exists today.
[17:36:26] <mrw> Question: What is the plan to get these scenarios documented in a problem statement, so that we can evaluate different solutions? The current problem statement doesn't seem to match these scenarios.
[17:36:54] <dthaler> that's a great question for the discussion period :)
[17:37:10] <TJ> IvB: I haven't looked in so much detail to ICMP messages etc., but the reason to do translation is 1) if you have an IPv4 header, you need a source address and there are issues with not having addresses such as what Alain talked about, and 2) In my system, there are different ways to arrive at the translator. If you start inserting an IPv4 header, you will need more use cases
[17:37:18] <mrw> I agree Dave. I personally might prefer a tunneling solution if we can come up with a way to do it, but I don't have religion on that point. I just think we need to know what we're trying to solve, rather than just defining a translator without knowing what it will be used for...
[17:37:24] --- klensin has left: Replaced by new connection
[17:37:46] <dthaler> yup
[17:38:06] --- lars.eggert@googlemail.com has left
[17:38:10] <TJ> Harald Alvestrand: Is it possible to describe these solutions in different terminology? I think you're building distributed IPv4 stacks, and making the interface part (NATPT translator) a simple/cheap device. I think it's a good idea, but if we use that terminology, it's obvious there's a relationship between the box and the stack on the host, and nobody else has to care what they do -- they're consenting adults.
[17:38:14] <mrw> Not because it would be bad to define one, but because there are an awful lot of tradeoffs that we might make differently for different scenarios.
[17:38:19] <TJ> - So how do we build distributed v4 stacks?
[17:38:52] <TJ> Christian Vogt: This concept of addr translation is also considered in routing research group for transitioning to multihoming. It would be great to come up with one solution that fits requirements in both fora.
[17:39:25] <TJ> - The LISP people use it for making a LISP site reachable from legacy sites. Basically, the very same techniques are used in these groups, and the goals are quite similar.
[17:40:17] <TJ> Alain Durant: I like the mapping you create between v4 and v6 address, which could work well for v6-v4 case, and v4-v6-v4, so we could have the same form of translator for new native v6 clients, as well as double-NATed v4-v6-v4 clients.
[17:40:40] <TJ> DB: Now we'll move on to the meat of the meeting, with 20 minutes left.
[17:40:45] --- nm has left: Replaced by new connection
[17:40:46] --- nm has joined
[17:40:56] --- falk has left
[17:41:21] --- iljitsch has joined
[17:41:28] <TJ> Jari wants to know where we as the IETF should be going. This work probably would not be done in v6ops, but other locations. v6ops is being asked should this work be done, what problems should we solve, not solve, .. ADs want to know how the room would like to move forward.
[17:41:36] <TJ> Some Important questions slide
[17:41:56] <TJ> (This is FB... Don't know where DB came from)
[17:42:31] <TJ> DB: This should be something we can deploy quickly using existing technology and tweaks if needed, but let's not define IPv12.
[17:42:37] <TJ> Ack.. FB again
[17:42:40] --- BillC has left: Computer went to sleep
[17:43:06] <mrw> Could someone make my comment and ask my question (from above)?
[17:43:27] <TJ> ?: Which direction is needed? Answer I would give you is yes. Criteria that could be useful: either party should be able to extend reach, so other party can communicate, whether they are in v4/v6 world.
[17:44:18] <TJ> Tony Hain: There is a fundamental flaw: you've opened the question with a solution space: NAT. There is nothing about tunneling.
[17:45:14] <mrw> I agree with Tony.
[17:45:18] <TJ> [mrw: I don't really get your question.. you're asking whether IPv6 is the right solution for cases where IPv4-to-IPv4 is not feasible because of lack of addresses, as I understand it. The answer would be: yes.]
[17:46:16] <TJ> Kurt Lindquist: Would you agree that solutions should be timely to market?
[17:46:30] <mrw> No, I am saying what Tony is saying, so you can skip my comment.
[17:46:34] <TJ> Jordi Palet: I believe the case that Alain D. was talking about is sorted out in softwires
[17:46:57] <mrw> I would like to know how we get to a problem statement that matches the problems, though,
[17:47:17] <TJ> JP:Maybe we need to have something else in the only new case, which is IPv6-only servers, which is the only real case where we need to use translation. We can use softwires with private addresses.
[17:47:35] <TJ> FB: You can make an IPv6-only host easily by turning off IPv4 or putting it in a network without v4
[17:48:11] <TJ> AD: Are we going to end up in a world which is worse than now, or is it helping us to move forward?
[17:48:31] <TJ> -v4 translation gets us deeper and deeper into translation, and I don't see any light at the end of the tunnel
[17:49:30] <TJ> - Customers could have two paths to go to content: v4 translated twice, or v6 path. So this gives content providers a reason to go to v6, because they provide a better experience. So I think this will help us in the long run.
[17:49:35] --- jronan has left
[17:50:01] <TJ> Marc Blanchett: Rouighly same content as Tony. Define the use cases then apply the technology we have now, with deployment tricks. Before doing multiple translations and other protocol ways.
[17:50:28] --- klensin has joined
[17:51:25] <TJ> Hiroshi Miyata: In the long term, according to 2nd bullet, any direction should be required. Double, triple translation could be required even though we don't expect it. Translator vendor point of view: it should work even now. I believe nobody has tried it, so we should try and see if it will work or not.
[17:51:38] <TJ> HM: From TAHI project, we could offer a bake-off of translator products.
[17:52:05] <mrw> If the IETF does need to define an IPv4-IPv6 NAT solution, is there a reason why it wouldn't happen in the Transport area, where we do all of our other NAT work? I don't guess it is useful to ask that in the meeting, but I wonder why we think of this as an IPv6-specific issues.
[17:52:11] <mrw> s/issues/issue
[17:52:26] <TJ> Erik N: Sounds like a good idea to have some operational, or test experience. So in addition to looking at tunnels, what have people tried? Reverse proxy should not be dismissed. There are other tools in this toolbox, but what have people actually tried?
[17:52:42] <TJ> mrw: FB already said the work would not be done in this group.
[17:53:05] <TJ> EN: It seems a no-brainer that removing DNS ALG from NATPT and querying for A records could be a useful tool.
[17:53:16] <mrw> Oh, I know that. But the assumption has seemed to be that it would move to 6man. I'll send my comments about that to the pertinent ADs, since they'd be the ones to decide, anyway.
[17:54:16] --- miyahiro has joined
[17:54:22] <TJ> David Miles: From operator's perspective, desire to change CPE is a big problem. We need to consider CPE in a static state. Hosts do v4, hosts do v6.. we need to allow both to co-exist. We can't change IPv4 hosts to make them work better. v6 hosts won't change either. This is about timing. We can deploy dual-stack, service provider NAT, BEHAVE P2P w/o ALGs, ..
[17:54:47] --- mg has joined
[17:55:00] <TJ> DM: Long-term challenge is dual-stack device running service behind NAT, we're in the world of reserved ports, .. SSL breaks all of that.
[17:55:38] <mg> Quick question: Are there proposals which suggest rewriting DNS responses and/or creating "fake" AAAA records for A responses?
[17:56:06] <TJ> IvB: I agree with Erik. It's useful to look at different things in parallel and start doing what seems doable without 2 yr requirement/dev/deployment cycles.
[17:56:26] --- jabley has joined
[17:56:36] --- jabley has left
[17:56:44] <TJ> IvB: Tunneling vs. Translation .. I believe tunneling will be harder. Even if you can do it, you probably need to modify the v6 host anyway. But you should treat that decision as a design detail rather than a huge difference.
[17:56:47] --- jabley has joined
[17:57:32] <TJ> IvB: About proxying .. https proxy is a generic tcp proxy. It's in every web server. You can implement/deploy in any tcp application today.
[17:58:20] <TJ> Hiro...? : We need to reconsider this from a more basic, fundamental viewpoint. Simpler is better. A complicated system can be made, but will never be used. Erik already mentioned, no translator systems exist without penalties.
[17:58:45] --- florent.parent@gmail.com has joined
[18:00:13] <TJ> Jari Arkko: The first order of business is worrying about the scenarios. I like Dave T's classification into 3 buckets. We should ask whether we do work for buckets 2&3. I found Alain's presentation convincing. I'm not sure whether his solution is correct, but we should do something for that. In general, the tunneling, translation solutions come later. I would like to worry about what we actually need to do. But one detail does worry me: constraints. Which nodes have to be modified? It's obvious that v4 will not be, so the only alternative is the v6 host.
[18:01:29] <TJ> Gabriel Montenegro: On peer v6 host talking to v4 world scenario, I thought this is deprecated to a future item. But this may become more relevant for 6lowpan devices. There is a new RFC, and products may start appearing. And these devices will most probably be v6-only, not dual-stack.
[18:01:36] --- mg has left
[18:01:36] <TJ> FB: We're already seeing that with toy sensors.
[18:01:53] <TJ> Hiroshi M: I agree DNS ALG should be separated from translation technology.
[18:02:15] --- marc.blanchet.qc has left
[18:02:16] <mrw> You did an amazing job, TJ!!
[18:02:21] <mrw> Thank you!
[18:02:21] <TJ> FB: We're out of time. We haven't come to a consensus in the room, but we've had an airing of opinions....
[18:02:23] <TJ> Thanks :-)
[18:02:25] --- Bob has left
[18:02:38] --- trond has left
[18:02:44] <TJ> Jari A: Focus on the scenarios, that has to be solved first. Details of solution can come later
[18:02:47] <TJ> Bye!
[18:02:48] --- nm has left
[18:02:54] --- fdupont has left
[18:02:56] <TJ> (Discussion continues on v6ops ML)
[18:03:01] --- iljitsch has left
[18:03:04] --- klensin has left
[18:03:07] --- klensin has joined
[18:03:09] --- klensin has left
[18:03:13] --- bkhabs@jabber.org has left
[18:03:14] --- jabley has left
[18:03:14] --- mrw has left
[18:03:46] --- ruri_hiromi@chat.gizmoproject.com has left
[18:04:05] --- TJ has left
[18:04:54] --- cdl@jabber.org has left
[18:05:03] --- miyahiro has left
[18:05:31] --- florent.parent@gmail.com has left
[18:07:14] --- behcet.sarikaya has left
[18:08:44] --- Suzanne has left
[18:08:55] --- gnaik has left
[18:10:50] --- dthaler has left
[18:12:55] --- frodek has left: Replaced by new connection
[18:12:55] --- frodek has joined
[18:17:43] --- rdenisc has left
[18:20:46] --- atarashi has left
[18:22:35] --- magnus has left
[18:23:24] --- john.zhao has left
[18:26:35] --- rdenisc has joined
[18:27:03] --- mohsen has left
[18:30:54] --- rdenisc has left
[18:31:15] --- narten has left
[18:44:04] --- raj has left
[19:01:18] --- arifumi has left: Disconnected
[19:02:52] --- Dan York has left: Computer went to sleep
[19:37:45] --- frodek has left: Replaced by new connection
[20:05:17] --- Dan York has joined
[20:14:45] --- mohsen has joined
[20:15:18] --- mohsen has left
[22:15:45] --- Dan York has left: Computer went to sleep