<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Thanks for sharing your understanding
      Adrian.<br>
      <br>
      Anyone know similar information about NBN Satellite (The Optus
      satellite that links to Kalgoorlie I believe)<br>
      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.<br>
      <br>
      Tim<br>
      <br>
      On 04/04/13 17:19, Adrian Woodley wrote:<br>
    </div>
    <blockquote cite="mid:515D296B.4060104@Diskworld.com.au" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">My understanding is that iiNet's ADSL
        hardware lacks IPv6 support.<br>
        <br>
        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.<br>
        <br>
        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.<br>
        <br>
        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.<br>
        <br>
        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.<br>
        <br>
        Adrian<br>
        <br>
        On 03/04/13 15:58, James Henstridge wrote:<br>
      </div>
      <blockquote
cite="mid:CALcaVO=q38_ruFc29stC5V8eMhvVr-XLnHR+yxBXAO-pEEgCyg@mail.gmail.com"
        type="cite">
        <div dir="ltr"><br>
          <div class="gmail_extra">
            <div class="gmail_quote">On Wed, Apr 3, 2013 at 8:09 AM, Tim
              White <span dir="ltr"><<a moz-do-not-send="true"
                  href="mailto:weirdit@gmail.com" target="_blank">weirdit@gmail.com</a>></span>
              wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">And
                why shouldn't it apply to the whole iinet/internode
                family?<br>
              </blockquote>
              <div>Because iiNet hasn't merged the two companies' plans
                yet.  For now, the iiNet branded plans do not include
                IPv6.<br>
                <br>
              </div>
              <div>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.<br>
                <br>
                James.<br>
              </div>
            </div>
          </div>
        </div>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
PLUG discussion list: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:plug@plug.org.au">plug@plug.org.au</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.plug.org.au/mailman/listinfo/plug">http://lists.plug.org.au/mailman/listinfo/plug</a>
Committee e-mail: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:committee@plug.org.au">committee@plug.org.au</a>
PLUG Membership: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.plug.org.au/membership">http://www.plug.org.au/membership</a></pre>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
PLUG discussion list: <a class="moz-txt-link-abbreviated" href="mailto:plug@plug.org.au">plug@plug.org.au</a>
<a class="moz-txt-link-freetext" href="http://lists.plug.org.au/mailman/listinfo/plug">http://lists.plug.org.au/mailman/listinfo/plug</a>
Committee e-mail: <a class="moz-txt-link-abbreviated" href="mailto:committee@plug.org.au">committee@plug.org.au</a>
PLUG Membership: <a class="moz-txt-link-freetext" href="http://www.plug.org.au/membership">http://www.plug.org.au/membership</a></pre>
    </blockquote>
    <br>
  </body>
</html>