Re: why same names, was Re: NANOG 40 agenda posted
For core networks I will suggest to use pure dual-stack or MPLS/6PE. In the worst case, if you can't do that, just use manually configured tunnels. For the upstream, dual-stack or again manually configured tunnels (6in4/protocol-41 or GRE). 6to4, in general, is useful for end users with a public IPv4 address. Teredo for those behind NAT. 6to4 and Teredo are already being used by users when their ISPs doesn't provide any IPv6 service at all. But they can also be used by ISPs as an easy and low-cost means while they can't offer dual-stack to the access, by deploying Teredo and 6to4 relays, in order to improve the availability of IPv6 in their access network w/o any major cost. As indicated a couple of days ago, I'm starting a thread about this in AfriNIC (English) and LACNIC (Spanish) in a very few days. I will drop a message here to remind about that in case people is interested to follow it (prefer to cross-post in several mail exploders). The thread will explain how to deploy those protocols and help to resolve any issues. For Teredo, we will use Miredo, the open source version. For 6to4, as it is supported in router vendors and hosts, we will explain both of them. Regarding how many boxes, I think it will be useful just staring with one in each network and monitor the traffic level. Then you will realize if it make sense to have more, such as in every PoP, or something similar. Those protocols work stand-alone, not special operational support required, and very low cost boxes can make it, at least at this stage. One more alternative, in terms of next steps planning, for access networks which can't, at the time being, deploy dual-stack (example DOCSIS 2.0, xDSL that can't be upgraded yet, etc.), is softwires (L2TP), but I'm not sure implementations are fully ready yet. I will bet that in 1-2 years, it will be the best choice and will be able to replace 6to4 and Teredo. Last, but not least, the major vendor (Microsoft) supports Teredo (as well as 6to4) in both XP and Vista. In Vista it gets enabled by default when no native IPv6 connectivity is available, but Microsoft own applications use Teredo only for peer-to-peer. If no native is present, then 6to4 is the 2nd choice for client-server apps. This is following the policy table for source/destination address selection. But other applications may use Terede as well for client-server. For example Teredo is not used by Internet Explorer if IPv4 connectivity is available, but if you use Opera, it prefers Teredo even if IPv4 is available, because is ignoring the policy table. The policy table can be manually configured. All the information about this is available at: About the policy table/XP: http://www.ipv6tf.org/index.php?page=using/connectivity/guides&id=2 About the policy table/Vista: http://www.ipv6tf.org/index.php?page=using/connectivity/guides&id=13 About 6to4: http://www.ipv6tf.org/index.php?page=using/connectivity/6to4 About Teredo: http://www.ipv6tf.org/index.php?page=using/connectivity/teredo LG at: http://www.ipv6tf.org/index.php?page=using/connectivity/looking_glass Config guides at: http://www.ipv6tf.org/index.php?page=using/connectivity/guides Hopefully all this is useful. I'm working in a tool to be able to measure all the IPv6 traffic in a network, even if it is using Teredo, 6to4, others, so we can realize, in a few months of measurements (if people different networks is volunteering fromto use this software and provide data) if IPv6 traffic (all, peer-to-peer and client-server) is growing. The tool will work EVEN if you don't support IPv6 in your network, so it will show if some transition traffic is passing thru. Regards, Jordi > De: <[EMAIL PROTECTED]> > Responder a: <[EMAIL PROTECTED]> > Fecha: Wed, 30 May 2007 12:41:17 +0100 > Para: > Conversación: why same names, was Re: NANOG 40 agenda posted > Asunto: RE: why same names, was Re: NANOG 40 agenda posted > > >> Before someone starts it, the debate between transition >> protocols to use is well and truely over. Teredo and 6to4 >> have been chosen for use by the software vendors of the end >> systems. (fine by me) > > This is misleading. You are using IPv6 jargon (transition protocol) > whose meaning is not obvious. For most ISPs, "transition" refers to the > entire series of steps up to running a ubiquitous IPv6 network where > IPv4 is a legacy support service. In that sense, Teredo and 6to4 are not > magic bullets because they merely deal with the first steps of such a > transition. > > I do agree that Teredo and 6to4 are very important right now, as far as > taking actions, but for planning, we need to look well beyond IPv6 > transition protocols. > > Since we are all collectively playing catchup at this point, it would be > very useful for some clear guidance on who needs to deploy Tered
Re: why same names, was Re: NANOG 40 agenda posted
On 30-mei-2007, at 13:23, Nathan Ward wrote: I can't seem to reach www.ietf.org over IPv6 these days and I have to wait 10 seconds before I fall back to IPv4. What browser are you using that falls back? Does it require hints (ie. unreachables, or similar) or does a timeout in TCP session establishment trigger it? Both Safari and Firefox on the Mac. The delay is actually more than a minute for Firefox and about the same for Safari, though. Too long to wait for for most people, but I can't be bothered to find a workaround... I think what's going on is that packets from www.ietf.org don't make it back to my ISP. A ping6 or traceroute6 doesn't show any ICMP errors and TCP sessions don't connect so it's not a PMTUD problem. So it's an actual timeout. The IETF meetings have had IPv6 connectivity for years, but IPv6 for www.ietf.org is fairly new. Not so long ago, I couldn't connect to www.ietf.org from the meeting network over IPv6 because the /48 that the web server was hosted in was filtered by the ISP providing the meeting IPv6 transit. In that case, an unreachable was returned and there was no delay. how many calls to your help desk will it take until your helpdesk staff says "turn off IPv6"? Not many. That's why we need to proceed with caution. But there is still time, making rash decisions based on the current situation would be a mistake. The IPv6 internet and applications grow more mature every year. The ball is in the ISP/NSP court at the moment. No, not really. End-users can get IPv6 connectivity without support from their ISP, and Windows Vista will result in a big bump in IPv6- active users. The next step that we need is more IPv6 content to flush out problems like the one I'm having and make it such that those don't persist like they sometimes do now. Here's why, which is really a really really brief summary of how I've read this thread, and my thoughts as it's progressed. a) Vista and other systems try IPv6. If they think they can get IPv6 they'll (often) prefer records to A records. Note that the latter only applies to "real" IPv6 connectivity. With 6to4 or Teredo, Windows will generally prefer IPv4. b) If (a) happens, and the endpoint referred to by the record isn't reachable, then the eyeball can't reach the content. Service is degraded. c) Because of (b), content providers aren't going to turn on records. They aren't going to turn on records because they're not reachable over IPv6. :-) So, it seems to me that the unreachable mentioned in (b) needs to be fixed. That's us, as network operators. Note that these are exceptions. The only remarkable part is that they aren't fixed as quickly as the same problems are when they happen with IPv4. Iljitsch
Re: why same names, was Re: NANOG 40 agenda posted
On 30/05/2007, at 11:41 PM, <[EMAIL PROTECTED]> wrote: Before someone starts it, the debate between transition protocols to use is well and truely over. Teredo and 6to4 have been chosen for use by the software vendors of the end systems. (fine by me) This is misleading. You are using IPv6 jargon (transition protocol) whose meaning is not obvious. For most ISPs, "transition" refers to the entire series of steps up to running a ubiquitous IPv6 network where IPv4 is a legacy support service. In that sense, Teredo and 6to4 are not magic bullets because they merely deal with the first steps of such a transition. Fair enough. Alternative suggestions? :-) I do agree that Teredo and 6to4 are very important right now, as far as taking actions, but for planning, we need to look well beyond IPv6 transition protocols. I don't think anyone would disagree with that. Since we are all collectively playing catchup at this point, it would be very useful for some clear guidance on who needs to deploy Teredo and 6to4 and where it needs to be deployed. Also, the benefits of deployment versus the problems caused by not having it. Should this be in every PoP or just somewhere on your network? Are there things that can be measured to tell you whether or not lack of Teredo/6to4 is causing user problems? A quick look through the NANOG historical slideware suggests very little mention of Teredo. Again, someone from Microsoft who can fill that gap might be useful. And probably someone who's using Miredo (an opensource/free implementation). I've been doing a lot of thinking/writing about deploying these things in the real world so I can knock up some pictures+notes, but again, better to hear from someone else who's done/doing it, rather than someone who's been playing/thinking. I assume there is someone.. -- Nathan Ward
RE: why same names, was Re: NANOG 40 agenda posted
> Before someone starts it, the debate between transition > protocols to use is well and truely over. Teredo and 6to4 > have been chosen for use by the software vendors of the end > systems. (fine by me) This is misleading. You are using IPv6 jargon (transition protocol) whose meaning is not obvious. For most ISPs, "transition" refers to the entire series of steps up to running a ubiquitous IPv6 network where IPv4 is a legacy support service. In that sense, Teredo and 6to4 are not magic bullets because they merely deal with the first steps of such a transition. I do agree that Teredo and 6to4 are very important right now, as far as taking actions, but for planning, we need to look well beyond IPv6 transition protocols. Since we are all collectively playing catchup at this point, it would be very useful for some clear guidance on who needs to deploy Teredo and 6to4 and where it needs to be deployed. Also, the benefits of deployment versus the problems caused by not having it. Should this be in every PoP or just somewhere on your network? Are there things that can be measured to tell you whether or not lack of Teredo/6to4 is causing user problems? --Michael Dillon
Re: why same names, was Re: NANOG 40 agenda posted
On 30/05/2007, at 8:00 PM, Iljitsch van Beijnum wrote: I can't seem to reach www.ietf.org over IPv6 these days and I have to wait 10 seconds before I fall back to IPv4. What browser are you using that falls back? Does it require hints (ie. unreachables, or similar) or does a timeout in TCP session establishment trigger it? Of course you can argue that the only way we'll be able to get to the ideal world is by forcing people to deal with the breakage so that it'll be fixed, but I'd point to Vijay's presentations. The problem is, if you're a large scale ISP, how many calls to your help desk will it take until your helpdesk staff says "turn off IPv6"? Not many. That's why we need to proceed with caution. But there is still time, making rash decisions based on the current situation would be a mistake. The IPv6 internet and applications grow more mature every year. The ball is in the ISP/NSP court at the moment. Here's why, which is really a really really brief summary of how I've read this thread, and my thoughts as it's progressed. a) Vista and other systems try IPv6. If they think they can get IPv6 they'll (often) prefer records to A records. That's good, on the surface. b) If (a) happens, and the endpoint referred to by the record isn't reachable, then the eyeball can't reach the content. Service is degraded. c) Because of (b), content providers aren't going to turn on records. So, it seems to me that the unreachable mentioned in (b) needs to be fixed. That's us, as network operators. Teredo relays/servers and 6to4 relays would be a good first step. Who here who runs an access network has either of these available for production use? If you do, what info can you share? Before someone starts it, the debate between transition protocols to use is well and truely over. Teredo and 6to4 have been chosen for use by the software vendors of the end systems. (fine by me) If I were attending NANOG, I'd be more than happy to run workshops on how to deploy Teredo and 6to4, however I'm in New Zealand and flights are expensive. I'm sure there are people who have more operational experience with these than I do currently. Microsoft run both, perhaps someone from there can say a few words? Vista points to their Teredo server by default, so they'll definitely have some learnings from that, I'm sure. -- Nathan Ward
Re: why same names, was Re: NANOG 40 agenda posted
On 29-mei-2007, at 21:53, David Conrad wrote: We have tried to overlay the same transport and presentation layer onto a new network layer, but have not engineered the new network layer to facilitate this. We have new APIs and new naming attributes, requiring applications to do the heavy lifting while at the same time, not providing any reasonable mechanism to relay information back to the applications when it turns out that heavy lifting is in vain. Yeah, this "unreliable datagram service" can never work, let's all stick with X.25. The transition from IPv4 to IPv6 is hard enough as it is. Having different DNS names tied to each protocol pretty much guarantees it's never going to happen, because you can't expose IPv4-only users to IPv6-only names. And clients figuring out whether they have working IPv6 reachability is exactly the part that you have a problem with, so you can't use that either. The problem with applications is that many of them still manage IP addresses "manually". In that case, it's unavoidable that the application must be updated for a new version of IP. But a Java app will never know the difference because the Java language simply redefined "IP address". It's now a superclass with IPv4 and IPv6 subclasses. Ain't object orientation grand? Most higher level languages can hide the difference between IPv4 and IPv6 from most applications, leaving just the implementation of protocols that require knowledge of IP addresses, such as SIP. I would agree that in the ideal world, an end user should be able to point their browser to a given URL and get back the same content irrespective of the underlying network layer protocol being used. However, in the world I live in, it doesn't work like this. Repeat after me: "don't block ICMP packet too big". That's 80% of your trouble right there. I've been living the IPv6 life for some years now, and occasionally, problems crop up. This seems to be a particularly bad month, because in addition to the long standing problem with www.apnic.net where sessions start but get slower and slower until they don't move any data any more (still have to talk to the APNIC NOC about that) I can't seem to reach www.ietf.org over IPv6 these days and I have to wait 10 seconds before I fall back to IPv4. By and large, it works well enough that I'm not tempted to turn off IPv6, but I wouldn't migrate millions of unsuspecting users just yet. If a few more content people can bring up IPv6 people like me will happily provide feedback about what doesn't work and in another year or two, things will be stable enough for a wider audience. Of course you can argue that the only way we'll be able to get to the ideal world is by forcing people to deal with the breakage so that it'll be fixed, but I'd point to Vijay's presentations. The problem is, if you're a large scale ISP, how many calls to your help desk will it take until your helpdesk staff says "turn off IPv6"? Not many. That's why we need to proceed with caution. But there is still time, making rash decisions based on the current situation would be a mistake. The IPv6 internet and applications grow more mature every year.
Re: why same names, was Re: NANOG 40 agenda posted
Ed, On May 29, 2007, at 12:11 PM, Edward Lewis wrote: If you want to read Dilbert on-line and I tell you that it is available at a certain URL, would you rather I give you "http:// www.dilbert.com" or that I send you "if you use IPv4 then http:// www.dilbert.com" else if you use IPv6 then http://www6.dilbert.com else buy a newspaper"? I would prefer you to give me a mechanism by which I can reach the URL. We have tried to overlay the same transport and presentation layer onto a new network layer, but have not engineered the new network layer to facilitate this. We have new APIs and new naming attributes, requiring applications to do the heavy lifting while at the same time, not providing any reasonable mechanism to relay information back to the applications when it turns out that heavy lifting is in vain. I would agree that in the ideal world, an end user should be able to point their browser to a given URL and get back the same content irrespective of the underlying network layer protocol being used. However, in the world I live in, it doesn't work like this. Of course you can argue that the only way we'll be able to get to the ideal world is by forcing people to deal with the breakage so that it'll be fixed, but I'd point to Vijay's presentations. The problem is, if you're a large scale ISP, how many calls to your help desk will it take until your helpdesk staff says "turn off IPv6"? Rgds, -drc
Re: why same names, was Re: NANOG 40 agenda posted
At 12:01 -0700 5/29/07, David Conrad wrote: What a horrible idea. Applications automatically pre- or appending crap to domain name labels shouldn't be done, period. I won't argue that, but it happens. And I do make use of it. When I am back from a trip I type in "dilbert" and see the comic appear. The next time I type in "d" and my browswer fills in the whole URL. The IPv6 Internet is a different network than the IPv4 Internet. Same names invites confusion and unhappiness. Hmmm, I draw the opposite conclusion. The network layers are different but the service ends are the same, so I would prefer the $same_name. If you want to read Dilbert on-line and I tell you that it is available at a certain URL, would you rather I give you "http://www.dilbert.com"; or that I send you "if you use IPv4 then http://www.dilbert.com"; else if you use IPv6 then http://www6.dilbert.com else buy a newspaper"? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Sarcasm doesn't scale.
Re: why same names, was Re: NANOG 40 agenda posted
Ed, On May 29, 2007, at 9:22 AM, Edward Lewis wrote: First - "the way you ask for names" is not different at the application level, it is different in the "layer" in which you find where to shoot packets. Right. The problem is, the methodology by which you shoot packets may or may not work. If the user types in the domain label (like "nanog") and the application then adds on TLDs and such, the application would have to try the likely set of IPv6 labels to pre-pend. What a horrible idea. Applications automatically pre- or appending crap to domain name labels shouldn't be done, period. As far as any other encoding of the name, whether IPv6 is working is something that the encoder cannot know as the code will probably be run from different points of the collective IP4 and IP6 network. Exactly. And since it is impossible to know whether or not there is actual IPv6 connectivity to a site that is advertising records, you get into situations where you get a connection attempt, timeout, retry, etc., resulting in people getting directives like the one Leo pointed to. The IPv6 Internet is a different network than the IPv4 Internet. Same names invites confusion and unhappiness. Rgds, -drc
