Re: [nznog] ISP's Natting customer pools
On 20-Feb-2007 Joe Abley wrote:
On 20-Feb-2007, at 17:16, Martin Kealey wrote:
Question: are there any (DSL?) CPE units for sale or in development that will do v6 to v4 translation, plus v6 pass-thru?
In practical terms (and I'm being only slightly pedantic) there *is* no v6 to v4 translation. There are tunnels, and there is native IPv6.
Are you saying that when a v6 host says "Connect to ::ffff:cfdb:2d24", the answer will invariably be "can't"? Otherwise we're talking about a third option that smells rather like SNAT, but running on steroids. Hence my using the term "translation". It makes sense for this "natting" to occur as far as possible from the v6 source host and as near as possible to the target v4 host, but in any case it can only go as far away as your v6 transit allows. Since we're only starting the game, that means the CPE border kit. Although I asked about doing both "translation and pass-thru", if the ISP at the other end is sensible it should only need to do one of those at a time. -Martin reference: http://xml.resource.org/public/rfc/html/rfc2373.html#anchor11
On 21-Feb-2007, at 03:16, Martin Kealey wrote:
On 20-Feb-2007 Joe Abley wrote:
On 20-Feb-2007, at 17:16, Martin Kealey wrote:
Question: are there any (DSL?) CPE units for sale or in development that will do v6 to v4 translation, plus v6 pass-thru?
In practical terms (and I'm being only slightly pedantic) there *is* no v6 to v4 translation. There are tunnels, and there is native IPv6.
Are you saying that when a v6 host says "Connect to ::ffff:cfdb: 2d24", the answer will invariably be "can't"?
That's exactly what I'm saying, yes. [tag:~]% ping6 www.isc.org PING6(56=40+8+8 bytes) 2001:4f8:4:d::236 --> 2001:4f8:0:2::d 16 bytes from 2001:4f8:0:2::d, icmp_seq=0 hlim=61 time=1.375 ms 16 bytes from 2001:4f8:0:2::d, icmp_seq=1 hlim=61 time=1.263 ms ^C --- www.isc.org ping6 statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 1.263/1.319/1.375/0.056 ms [tag:~]% ping6 www.kame.net PING6(56=40+8+8 bytes) 2001:4f8:4:d::236 --> 2001:200:0:8002:203:47ff:fea5:3085 16 bytes from 2001:200:0:8002:203:47ff:fea5:3085, icmp_seq=0 hlim=52 time=114.943 ms 16 bytes from 2001:200:0:8002:203:47ff:fea5:3085, icmp_seq=1 hlim=52 time=114.957 ms ^C --- www.kame.net ping6 statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 114.943/114.950/114.957/0.007 ms [tag:~]% ping6 ::ffff:cfdb:2d24 ping6: UDP connect: Network is unreachable [tag:~]% Joe
One of our client networks has been experiencing interference from a new 5.8Ghz radio source operating in the Hutt Valley. It appears to be a DFS radio seeking a clean channel so the interference comes and goes. Our client has been operating on 5756MHZ +/- 10Mhz Vert for 3+ years and about 2 weeks ago the interference commenced. The radio is operating from Tirohanga to Stokes Valley in order to avoid looking straight at Avalon Tower to Petone or Wellington paths. Having phoned around known radio operators last week with no clear response we re-engineered the radio with high gain antenna and did some spectral surveys to find a cleaner channel over the weekend. We changed our operating freq to 5776MHz +/- 10Mhz Vertical pole late Friday night. This was fine all sat/ sun until this morning when we appear to have the interference back. As Stokes Valley looks right Over Petone into Wellington CBD it maybe an over engineered radio in there causing the interference up the entire Hutt Valley. So please contact me if you have a new 5.8Ghz radio in the Hutt valley or wish to co-ordinate the spectrum a bit better in the Wellington region. OR Lock out either one of the Above channels from your DFS scan "go on its real easy to do". For anyone else out there running DFS radios Please use the radio's reporting tools to lock out what are obviously used channels within the first couple of days of installation. Then everyone gets to have an easier life. Thanks in advance Regards Ian Hastie LINKIT Ph +64 (0)21 75-5465 Fx +64 (0)4 905-5465 Skype: ian_hastie_mob PO Box 1661 Paraparaumu NEW ZEALAND www.linkit.co.nz Flexible Access Networks Disclaimer: The information in this email (including attachments) is confidential and may be legally privileged. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email and destroy the message. If you are not the intended recipient, any use, disclosure, copying or distribution is prohibited and may be unlawful
participants (3)
-
Ian Hastie -
Joe Abley -
Martin Kealey