[AusNOG] IPv4 Exhaustion date changed to December.

[Mark Andrews]

In message <5BC5686B-1897-4935-A49A-BECFFCDE2E7D at apnic.net>, Geoff Huston writes:
> 
> On 22/06/2010, at 9:37 AM, Mark Andrews wrote:
> >>> 
> >> 
> >> I disagree, with the added latency, overhead and resulting poor speed 
> I
> >> personally think tunnels are only good for testing and a "hey I am on 
> the
> >> v6 net!". I think a poor experience with tunnels would taint the view 
> of
> >> IPv6 from an end user point of view.
> > 
> > Hogwash.  NAT vs encapsulation is about equal cost in the CPE device.
> > You only have to size/distribute the tunnel endpoints on the ISP's
> > side.  The extra 20 bytes per packet is nothing.
> 
> 
> In theory this is true. In practice the world is not quite so 
> straightforward.
> 
> We've added fine-grained timers to the web server and we've started 
> timing the delivery of extremely small gif images comparing the delivery 
> times of IPv4 to IPv6. The results are interesting, in that while the 
> time to deliver the IPv6 object has been comparable to IPv4 when the 
> client has a conventional unicast IPv6 address, when the client is using 
> a source address that identifies it as using a 6to4 tunnel, or when the 
> client uses a source address that identifies it as a Teredo based 
> client, then the server-side measurement of the object delivery time 
> shows the tunnel IPv6 delivery times as being, on average, slower.
> 
> http://www.potaroo.net/stats/1x1/6uv6typesdiff.png

And where was the 6to4/Terado traffic being relayed?  Did you see
any significant difference in traffic from free.fr where the endpoints
of the tunnels are topologically close to each other as they use 6rd.

> >> Really I think native transit is the best way to bring it out to the
> >> consumer. Someone like an Internode (or another large ISPs) providing 
> CPEs
> >> with native IPv6 enabled by default (on the wan and lan) (correct me 
> if I
> >> am wrong and this is already happening) would be an excellent way to
> >> improve IPv6 adoption, probably without the end user even knowing it!
> > 
> > Native is better if only because there is likely to be less 
> configuration.
> 
> Or less opportunity to get the 6to4 tunnel relay addresses confused.
> 
> The relatively longer delivery times for 6to4 clients are interesting 
> because the reverse path of the server to client is V4 all the way, as 
> the server has a 6tf interface and it routes 2002::/16 down that tunnel 
> interface. So the longer time to deliver an object to a 6to4 client may 
> well be because they are using a remote 6to4 relay server and the path 
> of client -> relay server -> V6 web server is far longer than the direct 
> client -> web server path using V4.

Yep.

>   Geoff
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org