My personal view is I personally doubt there will be much movement for the next 5+ years or even more unless the "killer v6" app comes out or something major happens like Facebook only supporting v6 from a certain date. There are fairly simple reasons why. Most ISPs have plenty of spare address space and the retail fixed broadband market is pretty static. Even the new players like bigpipe and myrepublic have managed to get v4 address space. And those two didn't launch with a dual stack. Why was that??? It's been shown that even the new players can survive with CGNat in the days of Section 92 without needing to log everything I presume. In the mobile space I can see it happening. But at the same time CGNat seems to be working for them too. Adding v6 you now need to think about how big the prefix you want to allocate to your customers. Probably a /64 will be fine for 98% of your customers but some geeks may want something larger for various reasons. Now that every device is addressable and no NAT involved it's a non trivial conversation about securing the customers network and / or making sure you have a capable firewall to only allow acknowledged connections. Companies like SNAP have now gone and switched off their v6 stack from non trivial issues. So we should really ask them why they turned it off. As that would really point to why the uptake has been so low. For the vast majority of broadband customers they just want to plug the modem in and it work. How is v6 going to have any impact on what they do? So my real question is. Where is the demand to uplift the whole provisioning, support and billing to support v6 where there isn't the demand in this country where wages on average and technology demands are low. On 25/01/2015 1:18 AM, "Sebastian Castro" wrote:

...

Thanks for putting this together Lindsay.

Anyone aware of a simular resource listing IPv6 for NZ’s major websites? I found some metrics and materials on http://www.ipv6.org.nz/, but

On 24/01/15 11:54 pm, Jethro Carr wrote: they’re a bit dated (2013) and focus more on the volumes, rather than a list of NZ sites with/without IPv6. Ideally something like https://httpswatch.nz/ for IPv6 would be fantastic :-)

As part of NZRS' research efforts, the regular .nz zone scan checks if a given domain name has nameservers, mail servers and web server with an IPv6 address.

The attached image shows the status up to October 2014, and we have data up to December 2014 when the last scan ran.

Cheers,

...

regards, Jethro

-- Jethro Carr www.jethrocarr.com

On 24 January 2015 at 16:35:56, Lindsay Hill (lindsay.k.hill(a)gmail.com)

...

...

After last year's IPv6 issues, I was wondering what the status is of IPv6 support across NZ ISPs. I couldn't find that data in any one place, so I've been pulling it together myself, into a Google Sheet:

https://docs.google.com/spreadsheets/d/1KmhVGN_vPzerUzhpya8lBxdgHc1rCyuWIsYF...

...

This is primarily focused around residential ISPs, and the status of

...

...

IPv6 support for 'regular' customers. I'm interested in three things:

* Is IPv6 supported - fully or trial? * What prefix lengths are given to customers * Are static allocations available?"

I've got data on 11 ISPs so far, with requests out for another 3. This covers the majority of end-user connections in NZ. There are of course many more niche ISPs, and I'm happy to add their info. You can see that support is generally poor, which is probably why Google says we're only doing ~0.6% IPv6 traffic.

Comments + Updates welcome. Once I've got a bit more data, this will probably go into a more permanent home. If we get enough data, we could break out into residential vs business vs co-location IPv6 support.

I am aware of at least a couple of ISPs that are doing IPv6 trials, and when they go live, it will significantly shift the overall IPv6

wrote: their penetration

...

...

rate in NZ. But those trials are still mostly internal only, and you can only get on them if you know the right people. If the regular public can't get onto those trials, then I think they should be listed as "Unsupported" - too many ISPs have made noises about running trials years ago, but never got around to actually launching. You know who you are. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

-- Sebastian Castro Technical Research Manager .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

On 25/01/2015 8:52 AM, "Brian E Carpenter" wrote:

On 25/01/2015 08:11, Peter Lambrechtsen wrote:

...

My personal view is I personally doubt there will be much movement for

the

...

next 5+ years or even more unless the "killer v6" app comes out or something major happens like Facebook only supporting v6 from a certain date. There are fairly simple reasons why.

There is no IPv6 killer app, why would there be? The question is when will operational convenience argue for v6. The large wireless carriers in the US are beginning to see that now, and eventually when that becomes standard practice (with IPv4 traffic treated as legacy carried over IPv6 infrastructure) the economics will shift here too, simply because products evolve in that direction.

...

Most ISPs have plenty of spare address space and the retail fixed broadband market is pretty static. Even the new players like bigpipe and myrepublic have managed to get v4 address space. And those two didn't launch with a dual stack. Why was that??? It's been shown that even the new players can survive with CGNat in the days of Section 92 without needing to log everything I presume.

In the mobile space I can see it happening. But at the same time CGNat seems to be working for them too.

That isn't what I hear from the seriously large carriers elsewhere in the world.

I am specifically talking about NZ as that is where the complaints are on the uptake of v6 by fixed broadband retail proviers. Where the scarcity of v4 doesn't apply as we have a small already saturated fixed Internet market. I can see it happening soon in NZ in the mobile space due to the rapid expansion of mobile devices and that all new devices are v6 compliant. Not so much in fixed broadband.

...

Adding v6 you now need to think about how big the prefix you want to allocate to your customers. Probably a /64 will be fine for 98% of your customers but some geeks may want something larger for various reasons.

That's a very short-sighted approach. Firstly, there's no shortage. Secondly, recommendations and industry practice are all in the /48 to /56 range. Thirdly, the day that multi-router home networks appear, which is unpredictable but not so far ahead, a /64 isn't enough.

I think it will need to wash out for a few years yet. But my bet would be sub 1% of customers would need more than a /64. Just went through a process of moving from sticky ip to truely dynamic ip for our customers. After months of migrations less than 0.01% of our customers noticed the change. And that was with 95%+ recovering in 15 mins. So considered the number of people who care about a static vs those who care about v6.....

...

Now that every device is addressable and no NAT involved it's a non

trivial

...

conversation about securing the customers network and / or making sure you have a capable firewall to only allow acknowledged connections.

Correct. A next-gen SOHO gateway will have to do that. Since NZ buys these boxes in, it's going to happen here as soon as it happens in the major economies.

...

Companies like SNAP have now gone and switched off their v6 stack from non trivial issues. So we should really ask them why they turned it off. As that would really point to why the uptake has been so low.

Well, it would help if their helpdesk was willing to talk in anything but baby talk about the issues. What I've been seeing is problems with any site accessed via Cloudflare (Sydney), and it looks like MTU or MSS size problems and possibly dropped ICMPv6 packets. I suspect there's a tunnel in there somewhere and probably a firewall misconfigured for ICMPv6 filtering, but it's hard to tell. There were also IPv6 serious problems with Google for a few days recently, not specific to SNAP. If they gave out a bit more information, it might make diagnosis and fix a bit easier.

I would be asking hard questions of my isp.. as the 2nd hand story I heard was rather interesting. Anyone from snap care to comment?

...

For the vast majority of broadband customers they just want to plug the modem in and it work. How is v6 going to have any impact on what they

do?

Hopefully, none. My wife didn't even know she was using IPv6 until the recent batch of problems with the SNAP service.

And the reverse argument it true as well I suspect she didn't notice when she went back to a pure v4 stack.

...

So my real question is. Where is the demand to uplift the whole provisioning, support and billing to support v6 where there isn't the demand in this country where wages on average and technology demands are low.

I could ask the same about UFB. All I can say is: get ready, so that when the economics shift towards IPv6 as the primary service and IPv4 as the legacy service, you don't get caught napping. That shift will come from outside NZ.

I agree here with ufb. The same /similar reason applies to the slow uptake. But when core infrastructure proviers or companies like Facebook warn about going pure v6... then the shift will occur. If DNS requests by volume are anything to judge by... I think the demands from customers to move to v6 here will be a slow one. The move internationally by large isps is primarily driven from lack of v4 to hand out to their customers. That problem doesn't exist here. Unless we suddenly had a population growth of 1+mil. It's not going to be a problem soon.

Brian

...

On 25/01/2015 1:18 AM, "Sebastian Castro"

wrote:

...

...

On 24/01/15 11:54 pm, Jethro Carr wrote:

...

Thanks for putting this together Lindsay.

Anyone aware of a simular resource listing IPv6 for NZ’s major

websites?

...

...

I found some metrics and materials on http://www.ipv6.org.nz/, but they’re a bit dated (2013) and focus more on the volumes, rather than a list of NZ sites with/without IPv6. Ideally something like https://httpswatch.nz/ for IPv6 would be fantastic :-)

As part of NZRS' research efforts, the regular .nz zone scan checks if a given domain name has nameservers, mail servers and web server with an IPv6 address.

The attached image shows the status up to October 2014, and we have data up to December 2014 when the last scan ran.

Cheers,

...

regards, Jethro

-- Jethro Carr www.jethrocarr.com

On 24 January 2015 at 16:35:56, Lindsay Hill (lindsay.k.hill(a)gmail.com

) wrote:

...

...

After last year's IPv6 issues, I was wondering what the status is of IPv6 support across NZ ISPs. I couldn't find that data in any one place, so I've been pulling it together myself, into a Google Sheet:

https://docs.google.com/spreadsheets/d/1KmhVGN_vPzerUzhpya8lBxdgHc1rCyuWIsYF...

...

...

...

This is primarily focused around residential ISPs, and the status of

...

IPv6 support for 'regular' customers. I'm interested in three things:

* Is IPv6 supported - fully or trial? * What prefix lengths are given to customers * Are static allocations available?"

I've got data on 11 ISPs so far, with requests out for another 3. This covers the majority of end-user connections in NZ. There are of course many more niche ISPs, and I'm happy to add their info. You can see that support is generally poor, which is probably why Google says we're only doing ~0.6% IPv6 traffic.

Comments + Updates welcome. Once I've got a bit more data, this will probably go into a more permanent home. If we get enough data, we could break out into residential vs business vs co-location IPv6 support.

I am aware of at least a couple of ISPs that are doing IPv6 trials, and when they go live, it will significantly shift the overall IPv6

their penetration

...

rate in NZ. But those trials are still mostly internal only, and you can only get on them if you know the right people. If the regular public can't get onto those trials, then I think they should be listed as "Unsupported" - too many ISPs have made noises about running trials years ago, but never got around to actually launching. You know who you are. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

-- Sebastian Castro Technical Research Manager .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

On 1/24/15 11:11 AM, Peter Lambrechtsen wrote:

My personal view is I personally doubt there will be much movement for the next 5+ years or even more unless the "killer v6" app comes out or something major happens like Facebook only supporting v6 from a certain date. There are fairly simple reasons why.

I find that a depressing view. There's no reason for most ISPs why IPv6 should not be delivered on broadband today, especially from new market entrants.

Most ISPs have plenty of spare address space and the retail fixed broadband market is pretty static. Even the new players like bigpipe and myrepublic have managed to get v4 address space. And those two didn't launch with a dual stack. Why was that??? It's been shown that even the new players can survive with CGNat in the days of Section 92 without needing to log everything I presume.

In the mobile space I can see it happening. But at the same time CGNat seems to be working for them too.

CGN will not save you, and will add significant capital and operational cost to any ISP, regardless of technology chosen. IPv6 has an up-front cost to complete the engineering to support it; CGN has costs forever. I do not think that is a wise long term investment - and as Brian pointed out, the world's largest operators seem to have agreed with that view. I have native IPv6 (dual stack) on my wireline connection in my US home; native IPv6 on my US LTE cellular device (dual stack w/ NAT IPv4). Many operators worldwide have completed the implementation, and IPv6 traffic is trending upward. AJ

On 1/24/15 4:03 PM, Peter Lambrechtsen wrote:

On 25/01/2015 10:28 AM, "Alastair Johnson" mailto:aj(a)sneep.net> wrote:

...

On 1/24/15 11:11 AM, Peter Lambrechtsen wrote:

...

My personal view is I personally doubt there will be much movement for the next 5+ years or even more unless the "killer v6" app comes out or something major happens like Facebook only supporting v6 from a certain date. There are fairly simple reasons why.

I find that a depressing view. There's no reason for most ISPs why

IPv6 should not be delivered on broadband today, especially from new market entrants.

I agree.. but how come bigpipe and Myrepublic both launched with a v4 only stack.

You would have to ask them. I'm particularly perplexed as I understand Bigpipe are in fact using CGN. For me it makes no sense as a new entrant to start without IPv6, as it is only incremental engineering over what you need to do to get the network online to begin with; and starting with CGN is obviously significantly impacting to the initial investment.

And how come trademe, nzherald, stuff, nbr, computerworld, xero don't have v6 enabled. In fact I struggled to find a mainstream site that was v6 enabled. These too are the main domestic providers of content in whatever form yet they haven't launched their service with a dual stack. Why are we not complaining they are not providing dual stack access to their sites.

I have a vague recollection that Trademe indicated they were doing something about IPv6 a few years ago. As to why the content sources in NZ aren't doing it, I guess it's something to do with chicken-and-eyeballs, no? This of course was one of the reasons behind ISOC and the World IPv6 Days, to actually give people attention for enabling IPv6 and getting it done. On the other hand, major NZ content sources like Facebook, YouTube, Google, Mega.co.nz, and so forth. There's some interesting statistics available at https://www.vyncke.org/ipv6status/detailed.php?country=nz. It would certainly be nicer if there was more green.

...

I have native IPv6 (dual stack) on my wireline connection in my US home; native IPv6 on my US LTE cellular device (dual stack w/ NAT IPv4). Many operators worldwide have completed the implementation, and IPv6 traffic is trending upward.

Not disagreeing with you at all. All of my international hosted VPSs are dual stack with v6 preference.

But my main point about v4 scarcity is the main driver for the comcasts of this world to move to dual stack or pure v6. And that scarcity doesn't apply as much in NZ. So for that reason adoption here I suspect will continue to be slow.

It's not necessarily IPv4 scarcity. As you suggest, mature markets aren't seeing significant subscriber growth (although it is there: multiple connections) that would drive immediate IPv4 exhaustion - it's typically several compounding factors like less-than-ideal decision making with initial address pool design, the complexity and operational overhead of shifting IPv4 address pools around, and in many cases, management-plane connectivity (e.g. managing 100M STBs in the private network was more of an issue than 20M HSI subscribers). In-home device management becomes complex when you have to traverse subscriber-side NAT instead of directly manage the device. However, scarcity does continue to impact but usually in less straight-forward ways: the number of connections does continue to grow; the margin pressure on residential broadband services that versus more business oriented high margin services (cloud/VPS, business internet access, etc) that consume more IPv4 addresses - leading to businesses to consider removing IPv4 resources from low margin products. This in turn drives CGN deployment, which in turn drives cost. IPv6 doesn't make any of this go away entirely - although IPv6 overlays like 464XLAT that Brian mentions go some way toward mitigating the issues - it does improve network flexibility and ensure that you only NAT the least traffic possible.

V6 was something I was pushing for with some vigor at my employer a few years ago. But then I saw the spare address space most ISPs have means the priority is not there.

General disagreement here. I've worked with many service providers that don't have immediate exhaustion issues but are deploying IPv6 as part of having a short, medium, and long term technology and network strategy. They are all seeing it as the smart - and obvious - choice.

I still believe the main issue facing our country will be with the Chorus ATM and BUBA issue for our rural folks. That's not something that is going to be solved any time soon with the tighter budgets Chorus faces. That will have a greater impact on our economy for a longer time the longer it takes to get sorted. V6 is IMHO quite far down the priority list.

Access technology and L3 technology are mostly unrelated. Luckily IPv6 works quite nicely over most L1/L2 technologies; so I don't see your point here. AJ

It's a bit disingenuous to say that their network supports v6 if they're unable to allocate it to customers. That's just saying "we're running code on our routers built compiled within the last decade." Doesn't say much about whether their provisioning + accounting is set up for it. And the "customer demand" line is a bit nonsense. How are they measuring it? How would customers go about showing their demand? On Mon, Jan 26, 2015 at 5:08 PM, Jonathan Brewer wrote:

On Sun, Jan 25, 2015 at 1:03 PM, Peter Lambrechtsen wrote:

...

On 25/01/2015 10:28 AM, "Alastair Johnson" wrote:

...

I find that a depressing view. There's no reason for most ISPs why IPv6

should not be delivered on broadband today, especially from new market entrants.

I agree.. but how come bigpipe and Myrepublic both launched with a v4 only stack.

Via Twitter, Thomas Salmen comments that BigBipe's network supports v6 and they have the space set aside, but are not allocating to customers.

https://twitter.com/tsalmen/status/559561091127058434

No eta, but "if customer demand is there we'd likely roll it out sooner":

https://twitter.com/tsalmen/status/559562173836324865

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

On Sat, Jan 24, 2015 at 01:27:53PM -0800, Alastair Johnson wrote:

On 1/24/15 11:11 AM, Peter Lambrechtsen wrote:

...

My personal view is I personally doubt there will be much movement for the next 5+ years or even more unless the "killer v6" app comes out or something major happens like Facebook only supporting v6 from a certain date. There are fairly simple reasons why. I find that a depressing view. There's no reason for most ISPs why IPv6 should not be delivered on broadband today, especially from new market entrants.

You only need a few sites with IPv6 issues to make it a deficit rather than a bonus. I personally tried using IPv6 for a while, but I found it reduced CDN performance, and it broke Facebook for a while. (there's some thread on Nanog about the Facebook breakage.. although I see more than one of them, and can't remember which it was) There is little benefit for users when hole punching fixed most NAT peer to peer communications, and applications like Skype still don't support it.

...

Most ISPs have plenty of spare address space and the retail fixed broadband market is pretty static. Even the new players like bigpipe and myrepublic have managed to get v4 address space. And those two didn't launch with a dual stack. Why was that??? It's been shown that even the new players can survive with CGNat in the days of Section 92 without needing to log everything I presume.

In the mobile space I can see it happening. But at the same time CGNat seems to be working for them too.

CGN will not save you, and will add significant capital and operational cost to any ISP, regardless of technology chosen.

There's not much choice if more IPv4 addresses aren't available. If you run out of IP addreses you need CGN regardless of whether you have IPv6 support or not, and IPv6 may decrease the load on the CGN but not remove the necessity of such.

IPv6 has an up-front cost to complete the engineering to support it; CGN has costs forever. I do not think that is a wise long term investment - and as Brian pointed out, the world's largest operators seem to have agreed with that view.

You can't go IPv6 only though. So you still need some level of CGN now or in the future.

I have native IPv6 (dual stack) on my wireline connection in my US home; native IPv6 on my US LTE cellular device (dual stack w/ NAT IPv4). Many operators worldwide have completed the implementation, and IPv6 traffic is trending upward.

And NZ being part of APNIC has level IP addresses available. You'd think people would be supporting it quicker... I'm not against IPv6. But I think it's fine to not be in a huge rush to implement it. I'd much rather have 4G coverage on my cellphone than IPv6, even if IPv4 is natted. And so I'd rather cellphone providers focus on their 4G rollouts. Ben.

On 26 January 2015 at 07:52:59, Brian E Carpenter (brian.e.carpenter(a)gmail.com(mailto:brian.e.carpenter(a)gmail.com)) wrote:

On 25/01/2015 22:33, Ben wrote: ...

...

...

CGN will not save you, and will add significant capital and operational cost to any ISP, regardless of technology chosen.

There's not much choice if more IPv4 addresses aren't available. If you run out of IP addreses you need CGN regardless of whether you have IPv6 support or not, and IPv6 may decrease the load on the CGN but not remove the necessity of such.

Agreed (http://tools.ietf.org/html/rfc6264).

This also seems to be why 464XLAT (http://tools.ietf.org/html/rfc6877) is attracting a lot of attention. Since consumer IPv4 is in practice a translated service today, just provide it as a translated service running over an IPv6 substrate.

464XLAT is, from what I can see, impacted by the same flaws as DS-Lite. I haven’t followed it as closely as I did DS-Lite though, I’ll admit. My understanding is that both require support on CPE, and neither reduce the CGN requirements in the ISP. The benefit seems to be that you only need to run IPv6 in your access network. I’d be surprised if any providers in NZ have so much trouble running dual stack that running v6 only is worth having to have CPE support. The hard bit about NZ is that a large number of people own their own CPE, so upgrading software/replacing them with devices with support for new protocols is hard. If you decide to roll 464XLAT or DS-Lite, you have an interim state where you have some customers on the current native v4, and some on the translated/tunnelled v4. How long that interim state persists is anyone’s guess, and certainly sounds more complicated than just running v6 along side your existing native v4. 464XLAT might have a way to solve that better than DS-Lite, but like I say, I’m not super well versed so corrections are welcome. --  Nathan Ward 

On 27 January 2015 at 16:14:31, Dave Taht (dave.taht(a)gmail.com(mailto:dave.taht(a)gmail.com)) wrote:

On Tue, Jan 27, 2015 at 4:01 PM, Nathan Ward wrote:

...

464XLAT is, from what I can see, impacted by the same flaws as DS-Lite. I haven’t followed it as closely as I did DS-Lite though, I’ll admit.

My understanding is that both require support on CPE, and neither reduce the CGN requirements in the ISP.

The benefit seems to be that you only need to run IPv6 in your access network.

I’d be surprised if any providers in NZ have so much trouble running dual stack that running v6 only is worth having to have CPE support.

The hard bit about NZ is that a large number of people own their own CPE, so upgrading software/replacing them with devices with support for new protocols is hard. If you decide to roll 464XLAT or DS-Lite, you have an interim state where you have some customers on the current native v4, and some on the translated/tunnelled v4. How long that interim state persists is anyone’s guess, and certainly sounds more complicated than just running v6 along side your existing native v4.

I note that over the past 2 years openwrt added support for nearly every IPv6 acquisition method out there, dslite, dhcpv6, 6over4 6to4, etc, etc. Did we miss one? The improvements are in Barrier Breaker and later.

Native IPv6 support for cable "just works", in particular. The biggest pita is that comcast, at least, wants to give out prefixes with short lifetimes, and a lot of client gear, when used with ipv6, has been expecting permanent IP6 addrs. IPv6 prefix distribution, not so much ready for prime time yet, although the homenet working group converged on hnetd for a in-home prefix distribution protocol, it's still kind of rough.

You get stable addressing (for internal use) from running ULA. Worth noting that the HNCP draft proposes just that. Do you have devices that have IPv6 stacks that break when prefix lifetimes expire? What sort of devices are these? It will be interesting to see how HNCP interacts with non-HNCP capable routers re. prefix delegation. Hopefully vendors can get implementations out there soon enough that any problems here won’t be too widespread, but maybe HNCP needs some thing to support delegating multiple prefixes to downstream non-HNCP devices. I wonder how common home networks with multiple broadcast domains are, apart from those situation where the customer is provided with a “modem” and then goes and buys a “wireless router” to go on the back of it. Given the number of in-home applications that work with some sort of multicast/broadcast discovery these days, I imagine putting devices on separate broadcast domains doesn’t happen so much. -- Nathan Ward

On 27 January 2015 at 17:04:49, Dave Taht (dave.taht(a)gmail.com(mailto:dave.taht(a)gmail.com)) wrote:

On Tue, Jan 27, 2015 at 4:39 PM, Nathan Ward wrote: 

...

  You get stable addressing (for internal use) from running ULA. Worth noting  that the HNCP draft proposes just that.    Have you actually tried it? Adding ipv6 ulas to a network makes  applications that  aren't smart about it, try making ula based connections to everywhere  at some point or another. 

I have been using ULA in my home network for years, without issue. I’m on native now, was previously on 6to4, worked great both times. Selecting to use ULA addresses is not an application thing, the IPv6 stack in the OS should handle this for the applications. I assume you have devices that don’t have, or don’t have well configured, support for RFC6724 (or RFC3484)? Or, maybe some applications that don’t use it for some reason?

...

Do you have devices that have IPv6 stacks that break when prefix lifetimes  expire? What sort of devices are these?    Nearly everything I have tried has some problem or another. Biggest problem  is in retracting prefixes after a cpe reboots and gets a new ipv6 range. Devices  downstream just "don't get it", and keep the old ipv6s around either  forever or for  the prefix lifetime and apps aren't smart about what to pick, either. 

Again, this isn’t an application thing, though I can imagine you might see some problems if your CPE reboots so doesn’t know what prefix it had previously, and so can’t deprecate the address. Perhaps your CPE could use a shorter preferred lifetime to reduce the impact of a reboot. Deprecated addresses (i.e. preferred lifetime has expired but valid lifetime has not) are still usable if no preferred address in the same scope is available, so setting short timers here shouldn’t cause too many problems for you.

prefix acquisition of anything other than a /64 is broken in most  isc-dhcp dhclient users,  dibber's latest release candidate almost sort of kind of works, and  only the latest chaos calmer releases of openwrt are working  even-semi-correctly with multiple odd cable modems. 

I've been running the WIDE DHCPv6 client on my OpenWRT router I've got at home for about 18 months and I haven't touched it, it's worked great. Is there something I'm missing?

hnetd as currently written wants to own - dynamically - all the ip  distribution (4, 6, and ula) on the router presently and that's not  what people are used to. Dynamically renumbering people's internal  networks was to me, always a non-starter - I'd hoped that geo oriented 

I don't think people other than geeks really care what their addresses are, provided it works as well as it always has. We are sort of getting off topic below - Maybe we should take further discussion of this off-list, or, if you're at NZNOG the next few days perhaps we can talk in person?

...

I wonder how common home networks with multiple broadcast domains are, apart    It is a good question. I have no doubt that many double and triple  natted home networks exist, merely because that's how the user plugged  everything in. Setting up everything to bridge, or route, requires  expertise that I'd hoped that a homenet standard would limit. 

You can easily get data on this - capture packets outbound from your customers at your BNG/BRAS, and look at TTL. It's easy to infer initial TTL, and so you can get number of router hops. Let's assume all routers in a home are also NATing - or at least a very very large % of them. I looked at this with some other folks during a conference in 2008, and we saw about 17% of outbound packets looked like they were behind 2 or more routers (which I assume to be NAT devices). I haven't looked at data since, but I'd like to.

...

from those situation where the customer is provided with a “modem” and then  goes and buys a “wireless router” to go on the back of it.    Instant double nat in most environments. 

Yes, and very common, and causes far less issues than many suppose - applications have evolved to work around "broken" networks like that, see above.

...

Given the number  of in-home applications that work with some sort of multicast/broadcast  discovery these days, I imagine putting devices on separate broadcast  domains doesn’t happen so much.    I do wish we had better data on this. Nearly every multicast/mdns  capable app I have on my android doesn't work worth a damn with  discovery, and has an option to manually enter the (ipv4) address.  Apple is doing it's damndest to make mdns unusable for anything, also.    http://arstechnica.com/apple/2015/01/why-dns-in-os-x-10-10-is-broken-and-wha... 

I'm not sure that that's a fair assessment, given many of their protocols rely on multicast DNS - why would they intentionally break it? I haven't had any of the problems that Iljitsch has had, and from memory that article is mostly about resolving names rather than services. Some of the conclusions he draws in the article are pretty flawed and poorly researched, but, I'm sure it got plenty of hits. I don't have any experience with service discovery on Android devices. -- Nathan Ward

I'm not a big fan of any of those mechanisms, but I think that 464XLAT makes some sense when used the way T-Mobile's done it, with Android tablets/handsets they controlled. This was an interesting podcast about it: http://www.gogo6.com/14 On Tue, Jan 27, 2015 at 4:01 PM, Nathan Ward wrote:

On 26 January 2015 at 07:52:59, Brian E Carpenter ( brian.e.carpenter(a)gmail.com(mailto:brian.e.carpenter(a)gmail.com)) wrote:

...

On 25/01/2015 22:33, Ben wrote: ...

...

...

CGN will not save you, and will add significant capital and

operational cost

...

to any ISP, regardless of technology chosen.

There's not much choice if more IPv4 addresses aren't available. If you run out of IP addreses you need CGN regardless of whether you have IPv6 support or not, and IPv6 may decrease the load on the CGN but not remove the necessity of such.

Agreed (http://tools.ietf.org/html/rfc6264).

This also seems to be why 464XLAT (http://tools.ietf.org/html/rfc6877) is attracting a lot of attention. Since consumer IPv4 is in practice a translated service today, just provide it as a translated service running over an IPv6 substrate.

464XLAT is, from what I can see, impacted by the same flaws as DS-Lite. I haven’t followed it as closely as I did DS-Lite though, I’ll admit.

My understanding is that both require support on CPE, and neither reduce the CGN requirements in the ISP.

The benefit seems to be that you only need to run IPv6 in your access network.

I’d be surprised if any providers in NZ have so much trouble running dual stack that running v6 only is worth having to have CPE support.

The hard bit about NZ is that a large number of people own their own CPE, so upgrading software/replacing them with devices with support for new protocols is hard. If you decide to roll 464XLAT or DS-Lite, you have an interim state where you have some customers on the current native v4, and some on the translated/tunnelled v4. How long that interim state persists is anyone’s guess, and certainly sounds more complicated than just running v6 along side your existing native v4.

464XLAT might have a way to solve that better than DS-Lite, but like I say, I’m not super well versed so corrections are welcome.

-- Nathan Ward

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

  On 27 January 2015 at 16:43:31, Brian E Carpenter (brian.e.carpenter(a)gmail.com(mailto:brian.e.carpenter(a)gmail.com)) wrote:

On 27/01/2015 16:16, Lindsay Hill wrote:

...

I'm not a big fan of any of those mechanisms, but I think that 464XLAT makes some sense when used the way T-Mobile's done it, with Android tablets/handsets they controlled.

Exactly. There is no one-size-fits-all here, and that's where 464XLAT seems to hit the sweet spot. (I agree with Nathan that if you can roll out dual stack, it's the cleanest thing to do, but as the EUBA thread and the recent SNAP saga show, it isn't always as clean as all that.)

Not that 464XLAT would help in those situations of course, as it’d still be IPv6 over the access network, which wouldn’t work for the EUBA case. I’m not sure exactly what the Snap problem was, but I don’t imagine 464XLAT helping much there either. --  Nathan Ward

(addressing Peter here, mostly, but expanding on AJ’s points) On 25 January 2015 at 10:28:19, Alastair Johnson (aj(a)sneep.net(mailto:aj(a)sneep.net)) wrote:

On 1/24/15 11:11 AM, Peter Lambrechtsen wrote:

...

My personal view is I personally doubt there will be much movement for the next 5+ years or even more unless the "killer v6" app comes out or something major happens like Facebook only supporting v6 from a certain date. There are fairly simple reasons why.

I find that a depressing view. There's no reason for most ISPs why IPv6 should not be delivered on broadband today, especially from new market entrants. 

The killer app is reducing cost of operating an IPv4 network, as AJ covers and as I talk about some below.

...

Most ISPs have plenty of spare address space and the retail fixed broadband market is pretty static. Even the new players like bigpipe and myrepublic have managed to get v4 address space. And those two didn't launch with a dual stack. Why was that??? It's been shown that even the new players can survive with CGNat in the days of Section 92 without needing to log everything I presume. 

There are various solutions for this that are in use by operators I’ve worked with, the main being relying on allocating blocks of ports, rather than a port per connection etc. This makes logging easier, so that S.92 obligations can be met. You have to be careful to choose a block size that balances logging capacity with public address:customer ratios, but that’s not too hard. Having said that, logging all connections is actually not that difficult if you’re not afraid to cut a bit of code, just don’t do what someone will inevitably suggest and stick it all in to Splunk :-)

...

In the mobile space I can see it happening. But at the same time CGNat seems to be working for them too.

CGN will not save you, and will add significant capital and operational cost to any ISP, regardless of technology chosen.

IPv6 has an up-front cost to complete the engineering to support it; CGN has costs forever. I do not think that is a wise long term investment - and as Brian pointed out, the world's largest operators seem to have agreed with that view.

This is the basis of how I help people justify IPv6 in their org. IPv6 puts a cap, albeit an unknown cap, on CGN costs. Without IPv6 the CGN cost/demand/etc. will grow with Internet usage. With IPv6 the CGN cost will grow with IPv4 usage only, and so in theory will stop growing at some point as IPv6 content becomes a larger % of total traffic. Additionally, as large amounts of traffic for NZ providers comes off CDNs that support IPv6, that CDN traffic never has to be NATed (Akamai, Google both support IPv6, if you’ve got them in your network I’m sure you already know this). This is also a driver to encourage customer adoption, of course - the more customers pushing v6 packets, the less NAT you have to do. This is I suppose not such an issue if you feel you have enough IPv4 addresses, and so never need to NAT. Given all the mobile carriers (I’m excluding MVNOs here, as I don’t know) in NZ NAT their customers by default, we can infer that having enough addresses simply isn’t true. I would be surprised if these sort of considerations are not on Spark’s radar, given CGN can be quite costly and complicated at scale. It would be interesting to get stats on number of handsets that support IPv6 on your network. These numbers wouldn’t be hard to get, and you should with a bit more work be able to figure out how much traffic these devices do to IPv6 capable CGNs, and then translate the lack of running IPv6 in to $ value based on CGN capacity. Do that every month and start plotting a lines, along with cost to roll out IPv6. The sooner you do it, the better, but at some point the roll out will pay for itself in CGN costs so quickly that you can easily put together a business case. -- Nathan Ward

On 1/25/15 1:35 PM, Blair Harrison wrote:

For what it's worth, FX has been doing IPv6 natively on pretty much all customer connections for several years, both the WAN product and the ISP product. Standard prefix allocation of /56, static allocations.

As part of that we have native V6 enabled DNS servers and NTP servers available as well if you want to use em.

Nice work by FX. Keep it up. (and good work to the others that are offering IPv6 as compiled by Lindsay's list - also good work) AJ

On 2015-01-26 08:35, Blair Harrison wrote:

Statistics wise I don't have solid numbers, but it's a non-trivial amount of v6 traffic passing over the various networks. There are a few graphs I can see which have peaked briefly over 100Mbit/s of V6 in the last week.

This is a depressingly low amount for an ISP.

On 26/01/2015 22:27, Ray Taylor wrote: ...

Not sure what size subnets we will use – from the light reading I have done on the subject so far, there is a standardised or suggested size for isp subscribers.

Not so much. It used to be /48 but http://tools.ietf.org/html/rfc6177 leaves it open. Some operators prefer /56. Brian