Re: ipv6 transit over tunneled connection
----- Original Message ----- From: "Christopher Morrow" <morrowc.lists@gmail.com> To: "Michael Ulitskiy" <mulitskiy@acedsl.com> Cc: nanog@nanog.org Sent: Thursday, 13 May, 2010 6:39:28 PM Subject: Re: ipv6 transit over tunneled connection On Thu, May 13, 2010 at 6:18 PM, Michael Ulitskiy <mulitskiy@acedsl.com> wrote:
Hello,
We're in the early stage of planning ipv6 deployment - learning/labbing/experimenting/etc. We've got to the point when we're also planning to request initial ipv6 allocation from ARIN. So I wonder what ipv6 transit options I have if my upstreams do not support native ipv6 connectivity? I see Hurricane Electric tunnel broker BGP tunnel. Is there anything else? Either free or commercial?
1) see gblx/ntt/sprint/twt/vzb for transit-v6 2) tunnel inside your domain (your control, your MTU issues, your alternate pathing of tunnels vs pipe) 3) don't tunnel beyond your borders, really just don't tunnels are bad, always. -chris I see so many times, that tunnels are bad for IPv6, but this is the way IPv6 has been designed to work when you cannot get direct IPv6. So I would not say tunnels are bad, but direct IPv6 is better (OECD document on IPv6 states the use of tunnels). If the issue with tunnel is MTU, then a non-negligible part of IPv4 does not work well with MTU different of 1500. With IPv6 we bring the concept of jumbo packets, with large MTU. If we cannot work with non standard MTUs in IPv6 tunnels, how will we work with jumbo packets?
I agree - if you can get native v6 transit then more power to you. But tunnels are sure better than no IPv6 connectivity in my mind. Aside from slight performance/efficiency issues, I've never had an issue. -Jack Carrozzo On Fri, May 14, 2010 at 2:29 PM, Franck Martin <franck@genius.com> wrote:
----- Original Message ----- From: "Christopher Morrow" <morrowc.lists@gmail.com> To: "Michael Ulitskiy" <mulitskiy@acedsl.com> Cc: nanog@nanog.org Sent: Thursday, 13 May, 2010 6:39:28 PM Subject: Re: ipv6 transit over tunneled connection
On Thu, May 13, 2010 at 6:18 PM, Michael Ulitskiy <mulitskiy@acedsl.com> wrote:
Hello,
We're in the early stage of planning ipv6 deployment - learning/labbing/experimenting/etc. We've got to the point when we're also planning to request initial ipv6 allocation from ARIN. So I wonder what ipv6 transit options I have if my upstreams do not support native ipv6 connectivity? I see Hurricane Electric tunnel broker BGP tunnel. Is there anything else? Either free or commercial?
1) see gblx/ntt/sprint/twt/vzb for transit-v6 2) tunnel inside your domain (your control, your MTU issues, your alternate pathing of tunnels vs pipe) 3) don't tunnel beyond your borders, really just don't
tunnels are bad, always. -chris
I see so many times, that tunnels are bad for IPv6, but this is the way IPv6 has been designed to work when you cannot get direct IPv6. So I would not say tunnels are bad, but direct IPv6 is better (OECD document on IPv6 states the use of tunnels).
If the issue with tunnel is MTU, then a non-negligible part of IPv4 does not work well with MTU different of 1500. With IPv6 we bring the concept of jumbo packets, with large MTU. If we cannot work with non standard MTUs in IPv6 tunnels, how will we work with jumbo packets?
I'm curious what providers have not gotten their IPv6 plans/networks/customer ports enabled. I know that Comcast is doing their trials now (Thanks John!) and will be presenting at the upcoming NANOG about their experiences. What parts of the big "I" Internet are not enabled or ready? - Jared On May 14, 2010, at 2:43 PM, Jack Carrozzo wrote:
I agree - if you can get native v6 transit then more power to you. But tunnels are sure better than no IPv6 connectivity in my mind. Aside from slight performance/efficiency issues, I've never had an issue.
-Jack Carrozzo
On 5/14/2010 11:49, Jared Mauch wrote:
I'm curious what providers have not gotten their IPv6 plans/networks/customer ports enabled.
I know that Comcast is doing their trials now (Thanks John!) and will be presenting at the upcoming NANOG about their experiences.
What parts of the big "I" Internet are not enabled or ready?
Verizon has POPs that aren't IPv6 enabled making it a pain in the ass if you're closer to one of those (currently on month 11 of waiting, I'm just letting it go because I'm curious how long it'll take), Sprint isn't doing native IPv6 with their GSR's yet, Cogent's IPv6 visibility is poor, Level3 isn't accepting new IPv6 "beta" connections, and AT&T simply told me not available yet. Tunnels are still a necessity. ~Seth
On Fri, May 14, 2010 at 3:00 PM, Seth Mattinen <sethm@rollernet.us> wrote:
On 5/14/2010 11:49, Jared Mauch wrote:
I'm curious what providers have not gotten their IPv6 plans/networks/customer ports enabled.
I know that Comcast is doing their trials now (Thanks John!) and will be presenting at the upcoming NANOG about their experiences.
What parts of the big "I" Internet are not enabled or ready?
Verizon has POPs that aren't IPv6 enabled making it a pain in the ass if you're closer to one of those (currently on month 11 of waiting, I'm just letting it go because I'm curious how long it'll take), Sprint isn't doing native IPv6 with their GSR's yet, Cogent's IPv6 visibility is poor, Level3 isn't accepting new IPv6 "beta" connections, and AT&T simply told me not available yet.
Tunnels are still a necessity.
twt, ntt, gblx, telia all have presence in the US, and all do v6 to customer links. vote with wallet.
On 5/14/2010 12:44, Christopher Morrow wrote:
On Fri, May 14, 2010 at 3:00 PM, Seth Mattinen <sethm@rollernet.us> wrote:
On 5/14/2010 11:49, Jared Mauch wrote:
I'm curious what providers have not gotten their IPv6 plans/networks/customer ports enabled.
I know that Comcast is doing their trials now (Thanks John!) and will be presenting at the upcoming NANOG about their experiences.
What parts of the big "I" Internet are not enabled or ready?
Verizon has POPs that aren't IPv6 enabled making it a pain in the ass if you're closer to one of those (currently on month 11 of waiting, I'm just letting it go because I'm curious how long it'll take), Sprint isn't doing native IPv6 with their GSR's yet, Cogent's IPv6 visibility is poor, Level3 isn't accepting new IPv6 "beta" connections, and AT&T simply told me not available yet.
Tunnels are still a necessity.
twt, ntt, gblx, telia all have presence in the US, and all do v6 to customer links. vote with wallet.
Yeah I hear that a lot, but out of those four the only one that will serve my area is global crossing. ~Seth
-----Original Message----- From: Jared Mauch [mailto:jared@puck.nether.net] Sent: Friday, May 14, 2010 2:49 PM To: Jack Carrozzo Cc: nanog@nanog.org Subject: Re: ipv6 transit over tunneled connection
I'm curious what providers have not gotten their IPv6 plans/networks/customer ports enabled.
I know that Comcast is doing their trials now (Thanks John!) and will be presenting at the upcoming NANOG about their experiences.
What parts of the big "I" Internet are not enabled or ready?
We don't see Savvis, Level3, or AboveNet with IPv6 capabilities in our region (DC). Two years ago, neither Verizon or AT&T had IPv6, either. Not sure about them now, as we no longer use them for transit. One would think everyone would have v6 capabilities in the heart of government territory, but okay. For whatever reason, Verio actually charges (or used to) for their IPv6 separately from IPv4 and to top it all off, it wasn't significantly discounted. -evt
We pick up v6 from HE currently (like the rest of the world). L3 offered us dual stack also, but they wanted money to set it up plus MRC. None of our Bits That Matter (tm) go over v6 anyhow. (I guess the right phrase would be "revenue producing bits"). -Jack Carrozzo On Mon, May 17, 2010 at 9:51 AM, Eric Van Tol <eric@atlantech.net> wrote:
-----Original Message----- From: Jared Mauch [mailto:jared@puck.nether.net] Sent: Friday, May 14, 2010 2:49 PM To: Jack Carrozzo Cc: nanog@nanog.org Subject: Re: ipv6 transit over tunneled connection
I'm curious what providers have not gotten their IPv6 plans/networks/customer ports enabled.
I know that Comcast is doing their trials now (Thanks John!) and will be presenting at the upcoming NANOG about their experiences.
What parts of the big "I" Internet are not enabled or ready?
We don't see Savvis, Level3, or AboveNet with IPv6 capabilities in our region (DC). Two years ago, neither Verizon or AT&T had IPv6, either. Not sure about them now, as we no longer use them for transit. One would think everyone would have v6 capabilities in the heart of government territory, but okay.
For whatever reason, Verio actually charges (or used to) for their IPv6 separately from IPv4 and to top it all off, it wasn't significantly discounted.
-evt
-----Original Message----- From: Jared Mauch [mailto:jared@puck.nether.net] Sent: Friday, May 14, 2010 2:49 PM To: Jack Carrozzo Cc: nanog@nanog.org Subject: Re: ipv6 transit over tunneled connection
I'm curious what providers have not gotten their IPv6 plans/networks/customer ports enabled.
I know that Comcast is doing their trials now (Thanks John!) and will be presenting at the upcoming NANOG about their experiences.
What parts of the big "I" Internet are not enabled or ready?
We don't see Savvis, Level3, or AboveNet with IPv6 capabilities in our region (DC). Two years ago, neither Verizon or AT&T had IPv6, either. Not sure about them now, as we no longer use them for transit. One would
AT&T has told us that they will have IPv6 on their MIS circuits Q2 2011. Deltacom has told us the same. We will be testing native IPv6 with both these carriers on GE Internet circuits sometime around Q3. -Hammer- "I was a normal American nerd." -Jack Herer -----Original Message----- From: Jack Carrozzo [mailto:jack@crepinc.com] Sent: Thursday, February 17, 2011 9:01 PM To: Eric Van Tol Cc: nanog@nanog.org Subject: Re: ipv6 transit over tunneled connection We pick up v6 from HE currently (like the rest of the world). L3 offered us dual stack also, but they wanted money to set it up plus MRC. None of our Bits That Matter (tm) go over v6 anyhow. (I guess the right phrase would be "revenue producing bits"). -Jack Carrozzo On Mon, May 17, 2010 at 9:51 AM, Eric Van Tol <eric@atlantech.net> wrote: think
everyone would have v6 capabilities in the heart of government territory, but okay.
For whatever reason, Verio actually charges (or used to) for their IPv6 separately from IPv4 and to top it all off, it wasn't significantly discounted.
-evt
I have both Level3 and NTT v6 connections and there are no additional charges for the service. I recall NTT had one a few years ago, but I think that's fallen by the wayside. Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith@adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) On 2/17/11 7:01 PM, "Jack Carrozzo" <jack@crepinc.com> wrote:
We pick up v6 from HE currently (like the rest of the world). L3 offered us dual stack also, but they wanted money to set it up plus MRC. None of our Bits That Matter (tm) go over v6 anyhow. (I guess the right phrase would be "revenue producing bits").
-Jack Carrozzo
On Mon, May 17, 2010 at 9:51 AM, Eric Van Tol <eric@atlantech.net> wrote:
-----Original Message----- From: Jared Mauch [mailto:jared@puck.nether.net] Sent: Friday, May 14, 2010 2:49 PM To: Jack Carrozzo Cc: nanog@nanog.org Subject: Re: ipv6 transit over tunneled connection
I'm curious what providers have not gotten their IPv6 plans/networks/customer ports enabled.
I know that Comcast is doing their trials now (Thanks John!) and will be presenting at the upcoming NANOG about their experiences.
What parts of the big "I" Internet are not enabled or ready?
We don't see Savvis, Level3, or AboveNet with IPv6 capabilities in our region (DC). Two years ago, neither Verizon or AT&T had IPv6, either. Not sure about them now, as we no longer use them for transit. One would think everyone would have v6 capabilities in the heart of government territory, but okay.
For whatever reason, Verio actually charges (or used to) for their IPv6 separately from IPv4 and to top it all off, it wasn't significantly discounted.
-evt
On Fri, May 14, 2010 at 2:29 PM, Franck Martin <franck@genius.com> wrote:
I said somewhere in here... wierd quoting happened. On Thu, May 13, 2010 at 6:18 PM, Michael Ulitskiy <mulitskiy@acedsl.com> wrote:
Hello,
We're in the early stage of planning ipv6 deployment - learning/labbing/experimenting/etc. We've got to the point when we're also planning to request initial ipv6 allocation from ARIN. So I wonder what ipv6 transit options I have if my upstreams do not support native ipv6 connectivity? I see Hurricane Electric tunnel broker BGP tunnel. Is there anything else? Either free or commercial?
1) see gblx/ntt/sprint/twt/vzb for transit-v6 2) tunnel inside your domain (your control, your MTU issues, your alternate pathing of tunnels vs pipe) 3) don't tunnel beyond your borders, really just don't
tunnels are bad, always. -chris
I see so many times, that tunnels are bad for IPv6, but this is the way IPv6 has been designed to work when you cannot get direct IPv6. So I would not say tunnels are bad, but direct IPv6 is better (OECD document on IPv6 states the use of tunnels).
Tunnels promote poor paths, they bring along LOTS of issues wrt PMTUD, asymmetry of paths, improper/inefficient paths (see example paths from several ripe preso's by jereon/others), longer latency. If the tunnel exits your border you can't control what happens and you can't affect that tunnels performance characteristics. it's 2010, get native v6.
If the issue with tunnel is MTU, then a non-negligible part of IPv4 does not work well with MTU different of 1500. With IPv6 we bring the concept of jumbo packets, with large MTU. If we cannot work with non standard MTUs in IPv6 tunnels, how will we work with jumbo packets?
a non-negligible part of the ipv6 internet doesn't work at all with
1280 mtu... due to tunnels and some other hackery :( jumbo packets are a fiction, everyone should stop 10 years ago believing they will ever work end-to-end between random sites.
-Chris
On Fri, 2010-05-14 at 14:57 -0400, Christopher Morrow wrote:
Tunnels promote poor paths
"promote"? Tunnel topology does not (necessarily) match the underlying topology, especially if you choose (or are forced to accept) a distant broker. But "promote"?
, they bring along LOTS of issues wrt PMTUD,
PMTUD that doesn't work on v6 probably doesn't work on v4. I agree that a bad PMTU can wreak more havoc on v6 than v4, but most of the issues are workaroundable.
asymmetry of paths, improper/inefficient paths (see example paths from several ripe preso's by jereon/others), longer latency.
All relating to the above. I suspect you really mean paths in the underlying topology, which is a "by definition" issue. None of these are necessary features of tunnels. Given the relatively low number of tunnel terminating services, and the fairly low level of choice available to people who want tunnels, these are bigger problems than they need to be. More demand will see these problems (as with so many transitional issues) lessen substantially.
If the tunnel exits your border you can't control what happens and you can't affect that tunnels performance characteristics.
Whereas with IPv4 you have complete control over everything that happens once packets exit your border? This is no different with IPv6 than with IPv4, except that you have fewer choices at present, so must make more drastic compromises.
it's 2010, get native v6.
Easily said :-( If you can't get native IPv6, then using a tunnel lets you get started; it lets you begin educating, testing and even delivering IPv6-based services. If, on the other hand, you wait until everything is perfect, you will be waaaay behind the eight-ball. Oh - and tunnels are usually way cheaper than native connectivity, so it's easier to get the idea of going v6 past the bean-counters. So: Yep, native IPv6 if you can get it. Otherwise, take tunnels. But whichever you do, do it now. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
er... if I may - this whining about the evils of tunnels rings a bit hollow, esp for those who think that a VPN is the right thing to do. --bill On Sat, May 15, 2010 at 08:44:53AM +1000, Karl Auer wrote:
On Fri, 2010-05-14 at 14:57 -0400, Christopher Morrow wrote:
Tunnels promote poor paths
"promote"? Tunnel topology does not (necessarily) match the underlying topology, especially if you choose (or are forced to accept) a distant broker. But "promote"?
, they bring along LOTS of issues wrt PMTUD,
PMTUD that doesn't work on v6 probably doesn't work on v4. I agree that a bad PMTU can wreak more havoc on v6 than v4, but most of the issues are workaroundable.
asymmetry of paths, improper/inefficient paths (see example paths from several ripe preso's by jereon/others), longer latency.
All relating to the above. I suspect you really mean paths in the underlying topology, which is a "by definition" issue. None of these are necessary features of tunnels.
Given the relatively low number of tunnel terminating services, and the fairly low level of choice available to people who want tunnels, these are bigger problems than they need to be. More demand will see these problems (as with so many transitional issues) lessen substantially.
If the tunnel exits your border you can't control what happens and you can't affect that tunnels performance characteristics.
Whereas with IPv4 you have complete control over everything that happens once packets exit your border? This is no different with IPv6 than with IPv4, except that you have fewer choices at present, so must make more drastic compromises.
it's 2010, get native v6.
Easily said :-(
If you can't get native IPv6, then using a tunnel lets you get started; it lets you begin educating, testing and even delivering IPv6-based services. If, on the other hand, you wait until everything is perfect, you will be waaaay behind the eight-ball.
Oh - and tunnels are usually way cheaper than native connectivity, so it's easier to get the idea of going v6 past the bean-counters.
So: Yep, native IPv6 if you can get it. Otherwise, take tunnels. But whichever you do, do it now.
Regards, K.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob)
GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
On May 14, 2010, at 11:57 AM, Christopher Morrow wrote:
On Fri, May 14, 2010 at 2:29 PM, Franck Martin <franck@genius.com> wrote:
I said somewhere in here... wierd quoting happened. On Thu, May 13, 2010 at 6:18 PM, Michael Ulitskiy <mulitskiy@acedsl.com> wrote:
Hello,
We're in the early stage of planning ipv6 deployment - learning/labbing/experimenting/etc. We've got to the point when we're also planning to request initial ipv6 allocation from ARIN. So I wonder what ipv6 transit options I have if my upstreams do not support native ipv6 connectivity? I see Hurricane Electric tunnel broker BGP tunnel. Is there anything else? Either free or commercial?
1) see gblx/ntt/sprint/twt/vzb for transit-v6 2) tunnel inside your domain (your control, your MTU issues, your alternate pathing of tunnels vs pipe) 3) don't tunnel beyond your borders, really just don't
tunnels are bad, always. -chris
I see so many times, that tunnels are bad for IPv6, but this is the way IPv6 has been designed to work when you cannot get direct IPv6. So I would not say tunnels are bad, but direct IPv6 is better (OECD document on IPv6 states the use of tunnels).
Tunnels promote poor paths, they bring along LOTS of issues wrt PMTUD, asymmetry of paths, improper/inefficient paths (see example paths from several ripe preso's by jereon/others), longer latency. If the tunnel exits your border you can't control what happens and you can't affect that tunnels performance characteristics. it's 2010, get native v6.
I will point out that most of these issues apply to 6to4 and Teredo auto- tunnels and not as much to GRE or 6in4 statically configured tunnels. There is a juniper bug which makes PMTU-D a problem if your tunnel is Juniper<->Juniper.
If the issue with tunnel is MTU, then a non-negligible part of IPv4 does not work well with MTU different of 1500. With IPv6 we bring the concept of jumbo packets, with large MTU. If we cannot work with non standard MTUs in IPv6 tunnels, how will we work with jumbo packets?
a non-negligible part of the ipv6 internet doesn't work at all with
1280 mtu... due to tunnels and some other hackery :( jumbo packets are a fiction, everyone should stop 10 years ago believing they will ever work end-to-end between random sites.
Jumbo packets do work end to end in some random cases and PMTU-D works in most others. All of the tunnels I am using have at least a 1280 MTU, so, I'm not sure why you would think a tunnel wouldn't support 1280. Owen
participants (11)
-
-Hammer- -
bmanning＠vacation.karoshi.com -
Christopher Morrow -
Eric Van Tol -
Franck Martin -
Jack Carrozzo -
Jared Mauch -
Karl Auer -
Michael K. Smith - Adhost -
Owen DeLong -
Seth Mattinen