[plug] PLUG: Talk on IPv6 in March

[Adrian Woodley]

Provided you're receiving a non-RFC1918 address (public IP) within 
iiNet's range, iiNet's 6RD service should work for you.

Otherwise, you can use one of the many tunnel brokers; AARNet, Freenet6, 
Hurricane Electric and IPv6Now. Keep in mind that a remote broker can 
add hundreds of milliseconds of latency, which would further compound 
the issues associated with the 500ms of round-trip latency it takes to 
travel 36,000km twice. It's therefore important to find a broker which 
is as close to your ISP as possible.

Cheers,

Adrian

On 04/04/13 19:44, Tim White wrote:
> Thanks for sharing your understanding Adrian.
>
> Anyone know similar information about NBN Satellite (The Optus 
> satellite that links to Kalgoorlie I believe)
> Not using iinet for NBN Satellite at the moment, but am interested to 
> know if we'll ever see IPv6 on interim satellite or if there are 
> technical difficulties.
>
> Tim
>
> On 04/04/13 17:19, Adrian Woodley wrote:
>> My understanding is that iiNet's ADSL hardware lacks IPv6 support.
>>
>> Internode are still using the PPPoE model, which transports the PPP 
>> session back to a BBA/BRAS in the core network. The BBA/BRAS handles 
>> IPv6 over PPP, and all the DSLAM hardware sees is a stream of 
>> ethernet packets.
>>
>> iiNet's IPoDSL relies on the DSLAM hardware to hand out IP addresses 
>> to clients, from within the exchange. This hardware doesn't yet have 
>> IPv6 support, hence the need to use 6RD.
>>
>> I'm not intimately familiar with iiNet's current deployment, but it 
>> may be possible to drop an IPv6 router into each exchange which is 
>> able to hand out IPv6 prefixes to clients, over DSL. This model 
>> hasn't been deployed in Australia yet, so would be new to both iiNet 
>> and Internode. I'm not sure if they're even looking into it at this 
>> stage or not.
>>
>> Personally, I'd like to see them deploy a proper IPv6 Broker service. 
>> This could allow the static assignment of prefixes to individual 
>> accounts, removing the problem of network prefixes changing as IPv4 
>> addresses change (on re-connection). Unfortunately, this would be a 
>> more complex solution from a CPE perspective, although there exist 
>> good tunnel clients for all the major OSs. As far as over-heads are 
>> concerned, the packet structure is the same and the hardware 
>> infrastructure would be very similar, so performance is likely to be 
>> comparable to the existing 6RD service. Again, I don't believe 
>> they're actually looking into this yet.
>>
>> Adrian
>>
>> On 03/04/13 15:58, James Henstridge wrote:
>>>
>>> On Wed, Apr 3, 2013 at 8:09 AM, Tim White <weirdit at gmail.com 
>>> <mailto:weirdit at gmail.com>> wrote:
>>>
>>>     And why shouldn't it apply to the whole iinet/internode family?
>>>
>>> Because iiNet hasn't merged the two companies' plans yet.  For now, 
>>> the iiNet branded plans do not include IPv6.
>>>
>>> Presumably it'll become generally available when the operations are 
>>> fully integrated, but there isn't any public time frame for that.  
>>> If you can't wait, follow Adrian's advice.
>>>
>>> James.
>>>
>>>
>>> _______________________________________________
>>> PLUG discussion list:plug at plug.org.au
>>> http://lists.plug.org.au/mailman/listinfo/plug
>>> Committee e-mail:committee at plug.org.au
>>> PLUG Membership:http://www.plug.org.au/membership
>>
>>
>>
>> _______________________________________________
>> PLUG discussion list:plug at plug.org.au
>> http://lists.plug.org.au/mailman/listinfo/plug
>> Committee e-mail:committee at plug.org.au
>> PLUG Membership:http://www.plug.org.au/membership
>
>
>
> _______________________________________________
> PLUG discussion list: plug at plug.org.au
> http://lists.plug.org.au/mailman/listinfo/plug
> Committee e-mail: committee at plug.org.au
> PLUG Membership: http://www.plug.org.au/membership

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plug.org.au/pipermail/plug/attachments/20130404/a34fd0bf/attachment.html>