RE: New TransPacific Cable Projects:
Make sense what you said, I'm just pretty sure that eventually they'll come up with a way to put 100 to 500 waves on it. Frank -Original Message- From: Rod Beck [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 1:57 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; nanog@merit.edu Subject: RE: New TransPacific Cable Projects: Here is a TeleGeography news article worth a quick read: http://www.telegeography.com/cu/article.php?article_id=19783&email=html It appears that that article assumes that capacity will not be increased by WDM products...have those that been applied on those links already reached the cables' maximum capabilities based on current technology? Frank I think you are going to find that the numbe of waves that can put on an undersea fiber is a function of the distance between the landing stations. Obviously most TransPacific cables traverse greater distances and hence probably cannot carry as many waves as TransAtlantic cables. There is also a need for cables that are diverse from the existing cables. So lighting more capacity will not solve the physical diversity problems that were highlighted by the December earthquakes. Most modern undersea cables have four fiber pairs per cable. And each of those fiber pairs can handle from 24 to 80 10 gig waves. Hibernia can do 80 10 gig waves, but only becuase we replaced the undersea DWDM kit deployed at our landing stations. Regards, - Roderick.
RE: New TransPacific Cable Projects:
Here is a TeleGeography news article worth a quick read: http://www.telegeography.com/cu/article.php?article_id=19783&email=html It appears that that article assumes that capacity will not be increased by WDM products...have those that been applied on those links already reached the cables' maximum capabilities based on current technology? Frank I think you are going to find that the numbe of waves that can put on an undersea fiber is a function of the distance between the landing stations. Obviously most TransPacific cables traverse greater distances and hence probably cannot carry as many waves as TransAtlantic cables. There is also a need for cables that are diverse from the existing cables. So lighting more capacity will not solve the physical diversity problems that were highlighted by the December earthquakes. Most modern undersea cables have four fiber pairs per cable. And each of those fiber pairs can handle from 24 to 80 10 gig waves. Hibernia can do 80 10 gig waves, but only becuase we replaced the undersea DWDM kit deployed at our landing stations. Regards, - Roderick. This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Atlantic has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
> Date: Mon, 24 Sep 2007 12:41:12 +0200 > From: JORDI PALET MARTINEZ <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > > Unfortunately, Juniper doesn't support 6to4, only in Netscreen boxes. This > is ridiculous and I already asked Juniper several times about this ..., but > never got a positive feedback about when it will be supported. Unfortunately, IPv6 support in almost any network hardware is pretty lame. Yes, both C and J support IPv6, but that is often pretty slim support, especially in terms of management and accounting. And they have the nerve to charge extra for IPv6 capability that is missing most features needed to provide true, production quality support. It's even worse in areas like security products and various network application, monitoring, and analysis devices. About the only things that is pretty likely fully IPv6 capable is the end system. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpQJwSHy3ESq.pgp Description: PGP signature
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
>> Probably doesn't work so well if you have 6k people behind the same >> NAT, and they all try and use proto-41, though. > If you have 6,000 people behind a single NAT, proto-41 is probably the > least of your concerns, and Randy Bush may or may not be thinking of > awarding you an Innovative Engineering Award. :) the problem with these hokey things to show ipv6 works, or to get ipv6 to a home user, is that they don't really scale. they're good for marketing but not for long run real operations. and that would be ok, in a sense; it's just marketing. the problem is when the marketing flack obscures getting real work done on making ipv6 scalable and deployable. randy
Rings done right (was: Re: Bee attack, fiber cut, 7-hour outage)
>Has anyone calculated what the cost of doing this correctly once vs the >ongoing support/SLA/etc issues of repairing it when it goes boom is? I've >gotta believe that for >90% of the situations where diverse routes exist, just >being used as dual linear paths, its cheaper in the long term to do it "right" >and cut the size of your outside plant crew (assigned to break/fix) by 90%. :) It is definitely cheaper to "do it right" the first time, but to "keep it right", the operator needs to pay very close attention to each and every circuit groom that they perform, less they end up with a degenerate loop somewhere. Depending on the state of their circuit routing database(s), the exercise of checking for overlap against "the other half" of the ring can anywhere from trivial to impossible. I don't think operators intentionally foul this up, but it's real easy to get wrong, particular in the fallout after accumulating a bunch of different companies fiber plants and circuit route systems and trying to consolidate everything for savings. I'm just providing this in answer to "why can't telcos get this right", as there's no reason to think that grooming activity was at all involved in why this particular carrier got stung... ;-) /John
Re: New TransPacific Cable Projects:
[michael dillon] > And the other cable, which Google is involved in, is connecting > the USA and Australia, a country that has always had connectivity > issues, especially pricing issues. This has led to a much higher > use of web proxies in Australia to reduce international traffic > levels and this may be the key to why, Google, an application > developer and ASP/SaaS operator, is trying to build a cable link > to the major English language market in Asia-Pacific. Correcting: Google's in Sydney. Australians don't use web proxies, even though (sans google) they still save ~30% byte hit rates to decent size populations. Web proxies can be taught to cache stuff like updates and flash media (think "youtube"); and no amount of intercontinental bandwidth can fix the current issues AU ISPs face - throwing bandwidth between their aggregation point and the DSL DSLAMs in exchanges. Try again! Adrian
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On Mon, Sep 24, 2007, JORDI PALET MARTINEZ wrote: > > Yes, that's clear, I was assuming we are talking about "end boxes" such as a > CPE. You'd be surprised how many Cisco 827's there are out there in strange places without a sane NAT config (with all the 12.4T NAT twiddles set appropriately.) Max NAT session before running out of RAM? ~8k or so? What kills it? Trackerless P2P. Lovely. And lets not discuss the default cisco IOS firewall and its tracking state + throttling stuff.. Adrian
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 24-sep-2007, at 13:55, Nathan Ward wrote: The other thing to note - 6to4 kicks in on Vista if it has a non- RFC1918 IPv4 address, so we're talking about people NATing large numbers of non-RFC1918 space. Regardless of how crazy they might seem, these networks exist [...] when those networks become few enough that we can turn on records for production stuff, they'll be forced to sort their stuff out). How far can one bend over backwards before breaking said back?
RE: New TransPacific Cable Projects:
Here is a TeleGeography news article worth a quick read: http://www.telegeography.com/cu/article.php?article_id=19783&email=html It appears that that article assumes that capacity will not be increased by WDM products...have those that been applied on those links already reached the cables' maximum capabilities based on current technology? Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, September 23, 2007 9:11 AM To: nanog@merit.edu Subject: RE: New TransPacific Cable Projects: > Not to mention that the Taiwan straits earthquake showed a > clear lack of physical diversity on a number of important > Pacific routes, which I know some companies are laying fiber > to address. Anyone who took the trouble to read the two articles knows that one of the two cables is a USA-to-China direct cable that does not hop through Japan. This is really part of a larger connectivity story for the People's Republic of China along with the trans-Russia cable being built by Russia's railway-backed TTC and China Unicom. http://europe.tmcnet.com/news/2007/09/20/2954870.htm I wouldn't be surprised if this is somehow connected with GLORIAD as well. In any case, the USA-China direct route is clearly avoiding the Taiwan Straits weak point. And the other cable, which Google is involved in, is connecting the USA and Australia, a country that has always had connectivity issues, especially pricing issues. This has led to a much higher use of web proxies in Australia to reduce international traffic levels and this may be the key to why, Google, an application developer and ASP/SaaS operator, is trying to build a cable link to the major English language market in Asia-Pacific. Seems to me both builds are adressing diversity issues in different ways, and if this results in a bandwidth glut to the region, that may be part of the plan. --Michael Dillon
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
Yes, that's clear, I was assuming we are talking about "end boxes" such as a CPE. Regards, Jordi > De: Nathan Ward <[EMAIL PROTECTED]> > Responder a: <[EMAIL PROTECTED]> > Fecha: Mon, 24 Sep 2007 23:35:12 +1200 > Para: NANOG > Asunto: Re: Going dual-stack, how do apps behave and what to do as an > operator (Was: Apple Airport Extreme IPv6 problems?) > > > On 24/09/2007, at 10:46 PM, JORDI PALET MARTINEZ wrote: >> There is something not correct here ... Proto-41 is supported by >> many boxes, >> even NAT boxes, I guess by mistake from de vendor/implementation ... >> >> Basically many boxes just understand TCP and UDP and they decide to >> "pass-thru" other unknown protocols, instead of discarding them. > > Probably doesn't work so well if you have 6k people behind the same > NAT, and they all try and use proto-41, though. > > -- > Nathan Ward > ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 24/09/2007, at 11:48 PM, [EMAIL PROTECTED] wrote: On Mon, 24 Sep 2007 23:35:12 +1200, Nathan Ward said: Probably doesn't work so well if you have 6k people behind the same NAT, and they all try and use proto-41, though. If you have 6,000 people behind a single NAT, proto-41 is probably the least of your concerns, and Randy Bush may or may not be thinking of awarding you an Innovative Engineering Award. :) Don't worry, /I/ don't do this. Some large enterprise/campus networks do, though. Let's revise my number to "2". Just as much as a problem if they're both trying to do proto-41 :-) The other thing to note - 6to4 kicks in on Vista if it has a non- RFC1918 IPv4 address, so we're talking about people NATing large numbers of non-RFC1918 space. Regardless of how crazy they might seem, these networks exist, and they're preventing people from rolling out IPv6 () to production stuff. It's annoying, because they're often the same people who say "I'm not going to pay attention to IPv6, I've got enough addresses.", and we all lose because of it. (That, or when those networks become few enough that we can turn on records for production stuff, they'll be forced to sort their stuff out). -- Nathan Ward
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On Mon, 24 Sep 2007 23:35:12 +1200, Nathan Ward said: > Probably doesn't work so well if you have 6k people behind the same > NAT, and they all try and use proto-41, though. If you have 6,000 people behind a single NAT, proto-41 is probably the least of your concerns, and Randy Bush may or may not be thinking of awarding you an Innovative Engineering Award. :) pgpmLKqZ6571Z.pgp Description: PGP signature
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 20/09/2007, at 4:08 AM, Seth Mattinen wrote: Adrian Chadd wrote: On Wed, Sep 19, 2007, Iljitsch van Beijnum wrote: location would be enough. If I had some old 7200s lying around I'd use those, in locations where replacing drives isn't a huge deal a BSD box (Linux if you insist) would be a good choice because they give you a bigger CPU for your money. As someone who is building little compact flash and USB flash based BSD boxes for various tasks, I can quite happily say its entirely possible to build diskless based Linux/BSD routers which are upgraded about as easy as upgrading a Cisco router (ie, copy over new image, run "save-config" script, reboot.) Its been that way for quite some time. If there's interest I'll hack up a FreeBSD nanobsd image with ipv6 support, a routing daemon (whatever people think is good enough) and whatever other stuff is "enough" to act as a 6to4 gateway. You too can build diskless core2duo software routers for USD $1k. What about Soekris hardware? I don't have any personal experience with it, but it looks very appealing to build load balancers/ routers out of, and quite inexpensive. Adrian, Seth, anyone else interested. I've almost got a Soekris FreeBSD image going, working just as Adrian describes RE upgrades, running Miredo and 6to4 relays. I'll release for testing within a couple weeks, drop me an email if you'd like to play. I'm doing both NET4801 and NET4501, as that's what I've got here right now. The only stuff left to do is put some basic configs on there, and test Miredo some. 6to4 etc. all functions fine, it just needs some hand holding. -- Nathan Ward
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 24/09/2007, at 10:46 PM, JORDI PALET MARTINEZ wrote: There is something not correct here ... Proto-41 is supported by many boxes, even NAT boxes, I guess by mistake from de vendor/implementation ... Basically many boxes just understand TCP and UDP and they decide to "pass-thru" other unknown protocols, instead of discarding them. Probably doesn't work so well if you have 6k people behind the same NAT, and they all try and use proto-41, though. -- Nathan Ward
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
There is something not correct here ... Proto-41 is supported by many boxes, even NAT boxes, I guess by mistake from de vendor/implementation ... Basically many boxes just understand TCP and UDP and they decide to "pass-thru" other unknown protocols, instead of discarding them. I've document that long time ago: http://tools.ietf.org/html/draft-palet-v6ops-proto41-nat-03 There is a PDF document also linked into the ID which may be interesting to read for an specific example. I use many times proto-41 (even with 6to4) even when I get private (behind NAT) addresses for my laptop via my 3G phone. Regards, Jordi De: Nathan Ward <[EMAIL PROTECTED]> Responder a: <[EMAIL PROTECTED]> Fecha: Mon, 17 Sep 2007 01:17:24 +1200 Para: NANOG Asunto: Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?) On 16/09/2007, at 8:03 AM, Jeroen Massar wrote: > - IPv6 native (anything not 2002::/16 + 2003::/32) > - IPv4 native > - IPv6 6to4 (2002::/16) > - IPv6 Teredo (2003::/32 Incase anyone is using this for reference purposes, Jaroen really means 2001::/32, not 2003::/32. Teredo was also previously on 3ffe:831f::/32, for those of you on older Windows XP machines. This prefix no longer works - upgrade. > Now the really BIG problem there is though is that when network > connectivity is broken. TCP connect will be sent, but no response comes > back or MTU is broken, then the session first has to time out. > 6to4 and Teredo are a big problem here, especially from an operator > viewpoint. Yes. Infact, especially if you have users on Vista. It does this IPv6 tunnelling thing that on the surface appears really cool. When you try and talk IPv6 to something other than link-local: (in order) - If you have a non-RFC1918 (ie. 'public') address, it fires up 6to4. - If you have an RFC1918 address, it fires up Teredo. Seems cool in theory, and you'd think that it would really help global IPv6 deployment - I'm sure that's how it was intended, and I applaud MS for taking a first step. But in practice, however, this has essentially halted any IPv6 /content/ deployment that people want to do, as user experience is destroyed. You can help, though - here's the problem: 6to4 uses protocol 41 over IP. This doesn't go through NAT, or stateful firewalls (generally). Much like GRE. Because of this, if you're a enterprise-esque network operator who runs non-RFC1918 addresses internally and do NAT, or you do stateful firewalling, PLEASE, run a 6to4 relay on 192.88.99.1 internally, but return ICMPv6 unreachable/admin denied/whatever to anything that tries to send data out through it. Better yet, tell your firewall vendor to allow you to inspect the contents of 6to4 packets, and optionally run your own 6to4 relay, so outgoing traffic is fast. Even if you don't want to deploy IPv6 for some time, do this at the very least RIGHT NOW, or you're preventing those of us who want to deploy records alongside our A records from doing so. If you need configs for , let me know and I'll write some templates. I see this sort of IPv4 network quite commonly at universities, where students take their personal laptops and throw them on the campus 802.11 network. While disabling the various IPv6 things in Vista at an enterprise policy level might work for some networks, it doesn't for for a university with many external machines visiting. So, if you're a university with a network like this (ie. most universities here in NZ, for example), please spend a day or two to fix this problem in your network - or better yet, do a full IPv6 deployment. I'd like to get some work done to get some 'qualification' testing of the availability of 6to4 from a 'client' POV standardised, so this problem can go away. Moving city+job has hindered such things as of late. > As such, if you, as an ACCESS operator want to have full control over > where your users IPv6 traffic goes to you might want to do a couple of > things to get it at least a bit in your control: > - setup a 6to4 relay + route 192.88.99.1 + 2002::/16 > - setup a Teredo Server + Relay and make available the > server information to your users and inform them of it. For those not on v6ops, I've got a draft right now that explains why you should (as an access provider) run a Teredo server, and proposes a standard to allow you to direct your users to your local Teredo server. I should be pushing out an update to it shortly. See above RE. moving life around. Also, Relays are only useful if you have native IPv6 somewhere, OR if you run a 6to4 relay (which probably means you have native IPv6..). Note the distinct usage of 'servers' and 'relays', for the uninitiated. I'm building some embedded system images that run Teredo and 6to4 relays, with pretty much zero configuration. It runs on Soekris hardware right now (ie. sub $USD300), but if people are interested I can port it to regular x86 hardware. All you need is an IPv6 tunnel from a broker s
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
Unfortunately, Juniper doesn't support 6to4, only in Netscreen boxes. This is ridiculous and I already asked Juniper several times about this ..., but never got a positive feedback about when it will be supported. Regards, Jordi > De: <[EMAIL PROTECTED]> > Responder a: <[EMAIL PROTECTED]> > Fecha: Tue, 18 Sep 2007 14:54:11 +0100 > Para: > Conversación: Going dual-stack, how do apps behave and what to do as an > operator (Was: Apple Airport Extreme IPv6 problems?) > Asunto: RE: Going dual-stack, how do apps behave and what to do as an operator > (Was: Apple Airport Extreme IPv6 problems?) > > - setup a 6to4 relay + route 192.88.99.1 + 2002::/16 >>> >>> How? >> >> This is reasonably well documented for a Cisco but here's a >> minimal sample >> config: > > Thanks. I used your info, and other sources, to put up a page at > http://www.getipv6.info/index.php/First_Steps_for_ISPs which describes > how to set up 6to4 relay on Cisco, where to get Teredo relay software > that you can run, and where to get tunnel broker software. > > There are a couple of gaps. I can find no info on how to set up 6to4 > relay services on Juniper routers. Does JUNOS support this at all? If > you know, go to the above page, click on Juniper, and tell us what needs > to be done. In addition, CSELT in Italy distributed an IPv6 tunnel > broker package at one time. I cannot find this anywhere. If you know > where this software can be acquired or if you know of better IPv6 tunnel > broker software, add it to the above page. > > I now know why people are so quick to give advice on what to do without > explaining how to do it. It just is not easy to find out how to setup > 6to4 relay services, Teredo relay services and IPv6 tunnel broker > services. No doubt you can hire a consultant to do this for you, but if > we want to get significant deployment we cannot rely on consultants who > keep their toolkits secret. > > --Michael Dillon ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: Apple Airport Extreme IPv6 problems?
For a production service, I will never use dual naming for IPv4 and IPv6, is ridiculous ask the users to understand if they want to use one or the other to use a different name. For a testing, not an issue. Regards, Jordi > De: Martin Hannigan <[EMAIL PROTECTED]> > Responder a: <[EMAIL PROTECTED]> > Fecha: Mon, 17 Sep 2007 13:06:25 -0400 > Para: Iljitsch van Beijnum <[EMAIL PROTECTED]> > CC: Barrett Lyon <[EMAIL PROTECTED]>, > Asunto: Re: Apple Airport Extreme IPv6 problems? > > > On 9/15/07, Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote: >> On 15-sep-2007, at 21:25, Barrett Lyon wrote: >> >>> The other thought that occurred to me, does FF/Safari/IE have any >>> ability to default back to v4 if v6 is not working or behaving >>> badly? This could be a helpful transition feature but may be more >>> trouble than it's worth. >> >> Browsers are pretty good at falling back on a different address in >> general / IPv4 in particular when the initial try doesn't work, but >> it does take too long if the packet is silently dropped somewhere. If >> there is an ICMP unreachable there is no real delay. Worst case is a >> path MTU discovery black hole, then browsers generally don't fall back. > > Getting back to my original discussion with Barrett, what should we do > about naming? I initially though that segregating v6 in a subdomain > was a good idea, but if this is truly a migration, v4 should be the > interface segregated. > > I have also read Jordi? saying that no dual naming should occur, but > I think this is unrealistic. (Sorry if I misquoted you, Jordi) > >> It would be good if more ISPs deployed 6to4 gateways so the 6to4 >> experience would be better. > > We are. There are an unending supply of small details that are in the > way at the moment. :-) > > Best, > > Marty ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: Apple Airport Extreme IPv6 problems?
Some months ago I already circulated in this list instructions that I've provided in other IPv6 related exploder for doing so ... Introduction to 6to4 https://lists.afrinic.net/pipermail/afripv6-discuss/2007/61.html Configuring 6to4 Relay in Cisco https://lists.afrinic.net/pipermail/afripv6-discuss/2007/66.html Configuring 6to4 Relay in Linux https://lists.afrinic.net/pipermail/afripv6-discuss/2007/67.html Configuring 6to4 Relay in BSD https://lists.afrinic.net/pipermail/afripv6-discuss/2007/68.html Configuring 6to4 Relay in Windows https://lists.afrinic.net/pipermail/afripv6-discuss/2007/74.html Configuring Teredo Server/Relay in Linux/BSD https://lists.afrinic.net/pipermail/afripv6-discuss/2007/80.html Regards, Jordi > De: <[EMAIL PROTECTED]> > Responder a: <[EMAIL PROTECTED]> > Fecha: Sun, 16 Sep 2007 15:38:21 +0100 > Para: > Conversación: Apple Airport Extreme IPv6 problems? > Asunto: RE: Apple Airport Extreme IPv6 problems? > > >> I think we will never move to IPv6 if vendors don't do things >> like the one in the Airport. However, in order to make this >> "transition" phase where there may be a possible degradation >> of the RTT, we need to cooperation of the operators, for >> example deploying 6to4 relays in their networks. > > And just what should operators do to cooperate? > > Are you aware of any documents that describe how to set up 6to4 relays > in an ISP network? > > --Michael Dillon ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
