[ipv6hackers] my IPv6 insecurity slides

Wed Nov 30 20:19:13 CET 2011

>> 
>> There is a lot of content already dual-stacked, there is very little
>> reason not to. I have deployed dual stack without any issues, it
>> has been very easy and done with very little cost.
> 
> I know, Google pushed it already on some places, eg. some content of Youtube is also available with IPv6. But I do not get IPv6 addresses for the main site names like www.google.com or www.youtube.com. I use my own DNS server to resolve, which is running dual stacked on IPv4 and IPv6.
> 

Whitelisting sucks!

However, if you can convince Lorenzo to add your resolver, you do get:

baikal:owen (104) ~ % host www.google.com                                  2011/11/23 11:21:40
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 74.125.224.144
www.l.google.com has address 74.125.224.145
www.l.google.com has address 74.125.224.146
www.l.google.com has address 74.125.224.147
www.l.google.com has address 74.125.224.148
www.l.google.com has IPv6 address 2001:4860:4001:803::1011
0.004u 0.006s 0:00.12 0.0%	0+0k 2+3io 103pf+0w
baikal:owen (105) ~ % host www.youtube.com                                 2011/11/30 11:01:43
www.youtube.com is an alias for youtube-ui.l.google.com.
youtube-ui.l.google.com has address 74.125.224.136
youtube-ui.l.google.com has address 74.125.224.137
youtube-ui.l.google.com has address 74.125.224.138
youtube-ui.l.google.com has address 74.125.224.139
youtube-ui.l.google.com has address 74.125.224.140
youtube-ui.l.google.com has address 74.125.224.141
youtube-ui.l.google.com has address 74.125.224.142
youtube-ui.l.google.com has address 74.125.224.143
youtube-ui.l.google.com has address 74.125.224.128
youtube-ui.l.google.com has address 74.125.224.129
youtube-ui.l.google.com has address 74.125.224.130
youtube-ui.l.google.com has address 74.125.224.131
youtube-ui.l.google.com has address 74.125.224.132
youtube-ui.l.google.com has address 74.125.224.133
youtube-ui.l.google.com has address 74.125.224.134
youtube-ui.l.google.com has address 74.125.224.135
youtube-ui.l.google.com has IPv6 address 2001:4860:8005::be

The services do work dual-stack, just Google doesn't list their IPv6
addresses unless you jump through very unscalable hoops.

>> The so-called ISP's need to get their act together and deploy IPv6
>> to allow dual stacking before the entire IPv4 pool is depleted, that
>> will allow for a much more seamless transition than the
>> abomination known as NATxx(xxxx).
> 
> Sure, this would be the best solution for all. But I am wondering how for example the large cable ISP here in Switzerland (upc-cablecom) will do IPv6 assignments to their customers. Currently depending on the subscription plan (bandwidth) you get from 1 up to 5 dynamic public IPv4 addresses (which could even be in different sub networks, as the cable modem is just a transparent bridge). How would they do it with IPv6? To properly maintain your own local network with IPv6, they should assign a static /48 IPv6 subnet to the customer, so he can create his internal networks, eg. with LAN and WLAN separated (with IPv4 this is done behind NAT). But I am afraid, that they will do something else. Currently with IPv4, if you would like to have static IP addresses the only option is to use their business offer which costs around 3 times more (eg. for 100/7 Mbit/s consumer is 75.- CHF/mt [2] and with 16 static IPv4 address it is 225.- CHF/mt [3]). The same is with other (incl. DSL) ISPs, home users get dynamic IPv4 addresses, some offer 1 static IPv4 address and nothing else, others give you more addresses, but then again only with business subscriptions.
> 
>  [2] http://www.upc-cablecom.ch/en/b2c/internet/fiberpower100.htm (prices incl. VAT)
>  [3] http://www.upc-cablecom.biz/en/b2b/kmu_angebote/biz_kmu_internet/business_internet_fiber_power/internet_fiberpower100.htm (prices excl. VAT, add 8%)
> 

Hopefully IPv6 will remove this silly idea that the number of addresses you get is differentiated by how much you pay.

With IPv6, hopefully they will go to prefix delegation via DHCPv6 (as specified in DOCSIS 3, btw). Ideally they will allocate /48s to customers. Many providers are planning other prefix lengths mostly in the following values {48, 56, 60, 64}. The least useful is the /64. THe most useful is the /48. The ones in between come with varying tradeoffs. There is no real benefit to giving end-sites less than a /48.

>>> >  Content go to IPv6 to reach the users.
>>> 
>>> It will be needed.
>> 
>> Everyone seems to think that the Content or the Eyeballs need to
>> move first. The truth is both can and should move at the same time,
>> and for that matter should have started years ago. I have been
> 
> Sure, this would be the best. But as somebody else pointed out, the killer application (some hype thing like Facebook, Twitter or G+) which runs only on IPv6 is missing, which could push both content provider and ISPs to move forward. So most of them currently do not see the real need for the use of IPv6, as there is not enough pressure around from paying customers.
> 

And yet they buy insurance, even though the river above them is not flooding yet, the building is not yet on fire, the tornado has not yet removed the roof, and the earthquake has not yet caused the building to collapse.

Why is it that they can see the business continuity issues with not having insurance, but, we have not been able to properly convey the very same issues with failing to deploy IPv6?

>> running dual stack in a Content environment for well over a year,
>> and even longer in an Eyeball environment. My networks are fairly
> 
> I do the same on my home network since many years. But compared to the whole internet user base, we are probably a very small fraction.
> 

I do the same at both my home and business networks. Currently we may be a small fraction, but, we are definitely a growing fraction. We just have to continue until the fraction becomes larger. It's accelerating rapidly at this point.

>> small so there is obviously a scale difference which I do understand
>> exists and influences things. I have not encountered very many
>> issues on either end with being dual stacked. In fact, I have
>> encountered more issues with NAT in the Eyeball environment than
>> I ever have with IPv6.
> 
> I did see some strange behavior with IPv6. One just recently with sending e-mails to an other dual stacked mail server. And the second with the IDLE function between my mail client and my IMAP server. As far as I know, the version of Thunderbird (3.1.16) I am using fails, so I force it to IPv4. It is fixed in newer versions, but I do not like to upgrade to the fast release cycle of TB and I am waiting until the Extended Support Release is available.
> 

Care to provide any details on the server side email issue?

>> have not been resolved in the IPv4 Internet so why would anyone
>> expect a IP version change to magically fix the problem. SPAM,
>> Botnets etc. will still exist in the IPv6. NAT has done nothing to
>> help
>> fix those problems, but it has made it harder to trace the source of
>> the problem, yet people still want NAT in the IPv6 world.
> 
> Who thinks that IPv6 will fix basic problems like spam and botnets? I do not thinks so, why should this fix it? It even will not fix phishing and other social engineering tricks done nowadays. They will also move to IPv6 as soon as they see enough business there.
> 

In fact, IPv6 may make it harder to combat spam and botnets in some ways
due to the vast amount of address space and commensurate complication
of maintaining useful reputation systems due to database size issues and rapid
address mobility.

>>> Currently there is nothing out there, which gives enough pressure to
>> content
>>> providers or / and ISPs to move forward with IPv6. At the current
>> point it just
>>> costs money and effort without any real benefit (without looking at
>> Asia).
>> 
>> With 13 years (RFC2460 is dated December 1998) to replace
>> equipment to haveIPv6 capabilities there really should not be a huge
>> capital cost. Most providers on either end will have replaced a lot of
>> equipment in that time (in some cases several times). As I recalled
> 
> In Europe most ISPs provide the ADSL/VDSL/cable router/modem to their customer, almost non of them can run IPv6. I do remember many years back when ZyXEL had an IPv6 capable ADSL router in their product line, but they canceled it, as it could not be sold, because back then non of the ISPs supported IPv6 on the ADSL network.
> 

I bet they bring it back in a newer product soon if they haven't already. Yes, CPE is lagging and DSL is the worst offender here. The cost of maintaining IPv4 for one year after runout, however, will exceed the $40/customer that it might cost to replace all the CPE. The cost of maintaining IPv4 is recurring. The cost for replacing CPE is a one-time charge. Most people would regard this choice of costs as a "no-brainer".

>> planning ahead the natural upgrade process could have most gear
>> being IPv6 capable today without huge extra capital expenses. Did
>> they do that? It certainly does not look that way. Yes, there is a
> 
> I even see new devices sold today, which are not able to run IPv6. Modern home cinema equipment (eg. A/V receiver, TV, media player) come with WLAN or LAN, but are not able to use IPv6. I am happy that my internal network also does support IPv4 behind NAT. :)
> 

The question is do you buy them? I have started telling vendors of such equipment that I will not buy their product until it includes IPv6 support. In a few cases, making this statement and waiting a year has yielded an IPv6-capable product. The more people who start telling vendors this, the more products we will see get updated with IPv6 support.

>> cost
>> to rolling it out in the terms of man power etc., but I suspect that
>> that cost will need to be incurred at some point whether now or
>> next year or 5 years from now. You cannot tell me that the CGN's
>> will pop into existence without both capital and operating costs. The
>> pressure goes both ways. Eyeballs need content, content needs
>> eyeballs. So if the question is the "chicken or egg", the easy answer
>> is do both. Dual stacking does not break IPv4 so the current
>> functionality continues to happy chug along.
> 
> Sure it is both, but when non of the two move forward, which could create enough pressure on the other, we will stay much longer with IPv4 only then we would like to. And it even takes longer until bugs will be fixed in IPv6. Everything depends on the others, but no one will take the first step and go forward. "Lets wait and see what the others are doing."
> 

Many people have already taken the step forward. I think that once we start seeing large deployments of CGN in areas where consumers are already used to receiving full internet service, CGN will prove an abysmal failure. The reason it is accepted in the current test cases is that they are largely places where customers already expect a degraded internet experience (mobile phones, India, etc.) and so CGN is just a little bit worse than what they are used to. For users that are used to having uPNP and other dependent NAT traversal strategies work, CGN is going to cause quite a bit of upheaval and the support calls will represent a significant and mounting cost to the ISPs that choose not to deploy IPv6.

All of the ISPs I know that have actually considered these issues are deploying IPv6 and will support CGN only to the extent absolutely necessary to cope with customers that have IPv4-only devices and/or need to reach IPv4-only content.

Owen