I'm talking about using NAT-PT to allow a native ipv6 network to talk to an ipv4 network. Without some kind of protocol translation (aka PT) ipv6 can't talk to ipv4. The reason this has to be done is because you can't buy an ipv6 connection to an ISP in NZ yet. -----Original Message----- From: Cameron Kerr [mailto:cameron(a)humbledown.org] Sent: Saturday, 26 February 2005 2:27 p.m. To: Philip D'Ath Cc: nznog Subject: Re: [nznog] IPv6, NAT-PT On 26/02/2005, at 1:25 PM, Philip D'Ath wrote:
I'm trying to get NAT-PT support working on a Cisco DSL router to support native ipv6 clients behind it. I've done a lot of searching, and can't find the answers to what I'm doing wrong. I have two problems.
Why are you using NAT with IPv6? There is very little reason pros for using IPv6 with NAT, and many cons. Afterall, NAT is just a hack for IPv4 to prevent address exhaustion. IIRC, ISPs are not to give out single IP addresses, but rather /64 allocations. Anyone care to correct me on this? -- Cameron Kerr Telecommunications Teaching Fellow & SysAdmin ckerr(a)cs.otago.ac.nz
On 25 Feb 2005, at 20:39, Philip D'Ath wrote:
I'm talking about using NAT-PT to allow a native ipv6 network to talk to an ipv4 network. Without some kind of protocol translation (aka PT) ipv6 can't talk to ipv4. The reason this has to be done is because you can't buy an ipv6 connection to an ISP in NZ yet.
Most people running v6 are only using their v6 access to reach content served over v6. Most of the mechanisms suggested to allow a v6-only host to access v4 content remain undeployed. If you want to reach v6 content, the easiest thing to do is find an ISP who can give you v6 transit. In the absense of local carriers with dual-stack edge routers (i.e. in the case of most of the planet) the way you do this is terminate a tunnel somewhere. Joe
Joe Abley wrote:
If you want to reach v6 content, the easiest thing to do is find an ISP who can give you v6 transit. In the absense of local carriers with dual-stack edge routers (i.e. in the case of most of the planet) the way you do this is terminate a tunnel somewhere.
Why is there no IPv6 tunnel broker in NZ? -- Juha
On 25 Feb 2005, at 23:01, Juha Saarinen wrote:
Joe Abley wrote:
If you want to reach v6 content, the easiest thing to do is find an ISP who can give you v6 transit. In the absense of local carriers with dual-stack edge routers (i.e. in the case of most of the planet) the way you do this is terminate a tunnel somewhere.
Why is there no IPv6 tunnel broker in NZ?
Because nobody has set one up?
On Sat, 2005-02-26 at 17:01 +1300, Juha Saarinen wrote:
Why is there no IPv6 tunnel broker in NZ?
Citylink have been offering v6 tunnels to APE6 and WIX6 for over a year now. See http://citylink.co.nz/cgi-bin/ipv6tunnel.pl I guess we can't always rely on the journalists to keep us informed. Regards -- Matt Brown matt(a)mattb.net.nz Mob +64 275 611 544 www.mattb.net.nz
Matt Brown wrote:
Citylink have been offering v6 tunnels to APE6 and WIX6 for over a year now.
That looks very complicated and formal compared to overseas tunnel brokers.
I guess we can't always rely on the journalists to keep us informed.
Sometimes they take a break from the omniscience thing, unforgivable as that is. -- Juha
On Sat, 2005-02-26 at 17:14 +1300, Juha Saarinen wrote:
Matt Brown wrote:
Citylink have been offering v6 tunnels to APE6 and WIX6 for over a year now.
That looks very complicated and formal compared to overseas tunnel brokers.
I guess the other thing to point out is that unlike other tunnel brokers it also doesn't provide IPv6 transit, only connectivity between others also on APE6 or WIX6. Regards -- Matt Brown matt(a)mattb.net.nz Mob +64 275 611 544 www.mattb.net.nz
On 25 Feb 2005, at 23:14, Juha Saarinen wrote:
Matt Brown wrote:
Citylink have been offering v6 tunnels to APE6 and WIX6 for over a year now. See http://citylink.co.nz/cgi-bin/ipv6tunnel.pl
That looks very complicated and formal compared to overseas tunnel brokers.
Looks very reasonable to me. Joe
On 25 Feb 2005, at 23:08, Matt Brown wrote:
I guess we can't always rely on the journalists to keep us informed.
The Citylink tunnel brokers give access to a WIX+APE peering set of v6 routes. They don't provide a full set of global routes, unless I am dramatically misunderstanding their mission. The general problem with anybody providing a tunnel broker in New Zealand which provides global transit is that the operator of the tunnel broker is saddled with shipping the frames in and out of the country, which has a non-zero cost. Setting up a tunnel to a Citylink tunnel broker to allow local traffic to avoid trips over oceans and augmenting that with a foreign tunnel for the global table is probably the way to approach this, if you want the best facsimile of local v6 service. You will probably want your tunnel termination points in your network to be routers which speak BGP, and you'll probably want a globally-unique autonomous system number (the one you use for v4 will do just fine). You don't necessarily need to worry about address space; your global transit provider (tunnel broker overseas) should be able to assign address space to you (a /48 is usual for a non-trivial AS, which gives you sufficient numbers for 65536 subnets). Joe
Because that implies someone would have to pay the international v6 transit to other countries. That's expensive. In NZ especially, that would provide a mechanism for individuals to utilise national/wix/ape traffic to deliver stuff internationally. That's a big burden on the friendly tunnel broker. Of course you could have a NZ-only tunnel broker.... but that would basically just be a peering exchange. Telstra & Telecom are the ones who could perceivably afford to trial a broker service with international connectivity, but peering isn't their flavour of the decade I'm afraid. Problem is NZ doesn't really have a solid IP research network a-la aarnet who have the resources to do good things for the public good. WIX is natively v6 capable already for local transit, IIRC. Neil Juha Saarinen wrote:
Joe Abley wrote:
If you want to reach v6 content, the easiest thing to do is find an ISP who can give you v6 transit. In the absense of local carriers with dual-stack edge routers (i.e. in the case of most of the planet) the way you do this is terminate a tunnel somewhere.
Why is there no IPv6 tunnel broker in NZ?
Of course you could have a NZ-only tunnel broker.... but that would basically just be a peering exchange. Telstra & Telecom are the ones who could perceivably afford to trial a broker service with international connectivity, but peering isn't their flavour of the decade I'm afraid.
I've talked to a number of Carriers/Network Providers in NZ (in the past) and none of them can/would do Native IPV6 as of yet (I'm talking L3, not L2 such as Citylink) . I've only Found 1 (International Carrier) who will offer native multicast. Are there any carriers/network providers/ISP on this list want that can/want to comment on their IPV6/Multicast availability/future efforts on their networks? Thanks Craig
Joe Abley wrote:
On 25 Feb 2005, at 20:39, Philip D'Ath wrote:
I'm talking about using NAT-PT to allow a native ipv6 network to talk to an ipv4 network. Without some kind of protocol translation (aka PT) ipv6 can't talk to ipv4. The reason this has to be done is because you can't buy an ipv6 connection to an ISP in NZ yet.
In the absense of local carriers with dual-stack edge routers (i.e. in the case of most of the planet) the way you do this is terminate a tunnel somewhere.
I humbly disagree. My experience with public end user tunnel brokers is that none of them are "close" enough to NZ. No matter who you broker with you end up paying in huge (>3000ms in some cases!) RTT's, this is especially true of the large US tunnel brokers such as hurricane electric and freenet. A much more reliable way (IMHO) to play with IPv6 in New Zealand is to use 6to4. 6to4 gives you a /48 to play with for every IPv4 address you have, so it's a viable to run in conjunction with, or even instead of, IPv4 NAPT. If you are stuck behind a NAT device that doesn't support 6to4, you can also probably use Teredo to similar advantage. Both Teredo and 6to4 are built in to XP SP2 for those of you still clinging to the dark side <grin>. There is also nothing stopping you combining these (6to4 and a tunnel to a couple of providers) as having multiple IP's per interface is not only supported by IPv6, but is required, and interfaces tend to end up collecting IPv6 addresses like a stamp collector collects stamps. One thing to be wary of is that inadequacies in the Linux implementation make this suboptimal (Linux chooses the most recently added IPv6 address on an interface as the source for outgoing connections, which of course is the tunnel with the highest setup time (and therefore highest RTT)). ISP's could help encourage IPv6 adoption in New Zealand without having to run v6 throughout their entire network by running Teredo and 6to4 anycast servers with peering (via tunnels if necessary) to places like APE6/WIX6, Aarnet, and other networks that are topologically close to the ISP. (For those interested in v6, but never had the time to experiment: * http://www.wlug.org.nz/Teredo * http://www.wlug.org.nz/6to4 * http://www.wlug.org.nz/IPv6 Also the WLUG site has a dancing penguin if you're using IPv6 instead of the static one in the normal logo as an easy way to test IPv6 within New Zealand.)
On 26 Feb 2005, at 05:50, Perry Lorier wrote:
Joe Abley wrote:
On 25 Feb 2005, at 20:39, Philip D'Ath wrote:
I'm talking about using NAT-PT to allow a native ipv6 network to talk to an ipv4 network. Without some kind of protocol translation (aka PT) ipv6 can't talk to ipv4. The reason this has to be done is because you can't buy an ipv6 connection to an ISP in NZ yet.
In the absense of local carriers with dual-stack edge routers (i.e. in the case of most of the planet) the way you do this is terminate a tunnel somewhere.
I humbly disagree. My experience with public end user tunnel brokers is that none of them are "close" enough to NZ. No matter who you broker with you end up paying in huge (>3000ms in some cases!) RTT's, this is especially true of the large US tunnel brokers such as hurricane electric and freenet. A much more reliable way (IMHO) to play with IPv6 in New Zealand is to use 6to4.
There's a slight contradiction in your sentiments above -- 6to4 is a mechanism for tunnelling without manually specifying tunnel endpoints, not some kind of address translation mechanism, and so "6to4 is more reliable than tunnelling" doesn't seem to make a tremendous amount of sense. If you're using the rfc3068 6to4 relay router, 192.88.99.1, then your tunnel endpoint is probably outside NZ -- but unpredictably further away than a fixed tunnel broker, since 192.88.99.0/24 is anycast and you can never be completely sure which relay router you're going to reach at any particular time. From a router attached to ICONZ's network, 192.88.99.1 is in Poland, so your encapsulated packets are crossing two oceans. From a router attached to TCL's network, 192.88.99.1 is in Boston. Neither of these are obviously better choices than the usual suspects on the west coast of the US, or AARNet in Australia. [Having said that, I have heard that some of the prominent tunnel brokers have had scaling issues with their services, and it's possible some of the large RTTs you've seen have been due to lab 7200s running at 100% CPU, or under-sized circuits to tunnel routers running at capacity.] Running a 6to4 relay router in your network is a nice service to provide to your customers, incidentally, if you're an ISP; it'd be a nice way for the international carriers to atone for some of their de-peering antics, for example (hint hint) :-) I'm very happy to plumb tunnels to ISC's Junipers in California, if that satisfies a need. Since we do not provision them automatically, however, I'd far rather set a few tunnels up to ISPs (which could then run tunnels to their customers, Citylink tunnel brokers, etc) than many tunnels to individual nznog geeks' home networks. Joe
Joe Abley wrote:
On 26 Feb 2005, at 05:50, Perry Lorier wrote:
On 25 Feb 2005, at 20:39, Philip D'Ath wrote:
I'm talking about using NAT-PT to allow a native ipv6 network to talk to an ipv4 network. Without some kind of protocol translation (aka PT) ipv6 can't talk to ipv4. The reason this has to be done is because you can't buy an ipv6 connection to an ISP in NZ yet.
In the absense of local carriers with dual-stack edge routers (i.e. in the case of most of the planet) the way you do this is terminate a tunnel somewhere.
I humbly disagree. My experience with public end user tunnel brokers is that none of them are "close" enough to NZ. No matter who you broker with you end up paying in huge (>3000ms in some cases!) RTT's, this is especially true of the large US tunnel brokers such as hurricane electric and freenet. A much more reliable way (IMHO) to play with IPv6 in New Zealand is to use 6to4.
There's a slight contradiction in your sentiments above -- 6to4 is a mechanism for tunnelling without manually specifying tunnel endpoints, not some kind of address translation mechanism, and so "6to4 is more reliable than tunnelling" doesn't seem to make a tremendous amount of sense.
It's the public end user tunnel brokers that I have a problem with. Tunneling itself is fine (well, native v6 is better still). 6to4 does have the problem that you need to find the nearest anycast server, and often they can be all over the place, and they don't seem to be long term stable (they change from month to month). However if two people speak 6to4 then they can do so with the same routes as IPv4, and not introduce an extra detour out of the country and through some overloaded tunnel broker. If you are speaking to someone using "real" v6 addresses then you're probably going to have to leave the country one way or another if it's going to be via 6to4 anycast or a public end user tunnel broker. From my personal experience 6to4 is much more reliable than tunnel brokers which have a tendency to disappear for a few days at a time every now and again, with anycast it just hops on over to the next anycast server. Originally I tried to run 6to4 and a tunnel broker to try and get the best of both worlds, but ran into the problem I mentioned with Linux's source address selection policies.
If you're using the rfc3068 6to4 relay router, 192.88.99.1, then your tunnel endpoint is probably outside NZ -- but unpredictably further away than a fixed tunnel broker, since 192.88.99.0/24 is anycast and you can never be completely sure which relay router you're going to reach at any particular time.
Indeed. This is why I hope that ISP's in NZ will spend a little time and setup their own 6to4 relay routers, as (I believe, I don't work for an ISP) it should be fairly low impact on their current infrastructure and fairly trivial to setup. This service doesn't even have to be a critical service, since if the service fails, as long as the anycast route is removed, users will just be provided degraded service.
From a router attached to ICONZ's network, 192.88.99.1 is in Poland, so your encapsulated packets are crossing two oceans. From a router attached to TCL's network, 192.88.99.1 is in Boston. Neither of these are obviously better choices than the usual suspects on the west coast of the US, or AARNet in Australia.
[Having said that, I have heard that some of the prominent tunnel brokers have had scaling issues with their services, and it's possible some of the large RTTs you've seen have been due to lab 7200s running at 100% CPU, or under-sized circuits to tunnel routers running at capacity.]
This is my hypothesis as to what's going on too. While I have never directly spoken to someone who runs a tunnel broker, the wildly varying RTT's somewhere in the last couple of hops suggests that it's the tunnel broker, not the routes that is introducing the latency, however tunnel brokers being overseas doesn't help the situation any either. Everything is a trade off. Native v6 provides the best user experience, with mostly stable latency and routes, and all the extra magical features of IPv6 however native v6 requires finding equipment that supports native v6, it requires finding people to talk to that will also speak native v6 etc. End user tunnel brokers have stable latency and routes, but require some level of configuration by the end user, they are all outside the country, they have a history of high latency and/or jitter as well as not being the most reliable service in the world. 6to4 has the advantage of being more reliable, has lower latency and jitter to other 6to4 hosts, and is usually fairly trivial to configure, but when talking to v6 native hosts you have to go via an anycast end point which isn't necessarily stable, or topologically close. I presume *BSD, and Windows users can probably combine fixed tunnels and 6to4 to ameliorate their weaknesses. My experience with end user tunnel brokers is that they do not provide a good end user experience for people playing with IPv6 and lead to people deciding that IPv6 is far less usable than IPv4.
Running a 6to4 relay router in your network is a nice service to provide to your customers, incidentally, if you're an ISP; it'd be a nice way for the international carriers to atone for some of their de-peering antics, for example (hint hint) :-)
Having ISP's in New Zealand provide a 6to4 relay router in NZ would be great :)
From a router attached to ICONZ's network, 192.88.99.1 is in Poland, so your encapsulated packets are crossing two oceans. From a router attached to TCL's network, 192.88.99.1 is in Boston. Neither of these are obviously better choices than the usual suspects on the west coast of the US, or AARNet in Australia.
I was going to say in my previous email but forgot, I should pimp out tr some more: http://tr.meta.net.nz/output/2005-02-27_11:48_192.88.99.1.png That shows more or less where everyone ends up finding their favorite 6to4 anycast relay server. It's interesting that there is a /lot/ of variation as to who finds what. Also several places take quite a little tour to find their anycast routers. Usual disclaimers apply to tr graphs (AS# information is kinda quirky, I only have tr drones in some places, etc).
participants (7)
-
Craig Whitmore -
Joe Abley -
Juha Saarinen -
Matt Brown -
Neil Bertram -
Perry Lorier -
Philip D'Ath