[ipv6hackers] "Stick to limited IPv6 deployments, businesses warned"

[Tomas Podermanski]

Hi Jim,
    tanks a lot for comments.

On 9/2/12 8:06 PM, Jim Small wrote:
> Hi Tomas,
>
>> Fore those who might be interested in our experience  with deploying
>> IPv6 within university campus we sum upt it in
>> http://ipv6.vutbr.cz/article/deploying-ipv6-practical-problems-from-the-
>> campus-perspective/
>> (and related presentation:
>> http://ipv6.vutbr.cz/wordpress/wp-
>> content/uploads/2012/05/tnc2012_slides_TncPresentation.pdf).
>> There are described some of the biggest troubles that we had during
>> deploying IPv6.
> I looked at your presentation, thanks for sharing.  A few questions/comments:
> 1)  Do you believe there is a compelling case for RDNSS/RFC 6106?  I personally like it but when I have spoken to vendors they pointed out that most things do or will support stateless DHCPv6 and they don't see any reason to add RDNSS support.  Can you give me some strong cases I can take back to vendors for RDNSS?  I want to emphasize that this is not an idle promise - any strong case will go straight to the parties who can effect change at the vendors.
I share your view. Personally I don't like SLAAC at all. However it is
very "explosive" topic where different people have very differed opinion
about that. Observing the current situation all important vendors (MS,
Apple) started supporting DHCPv6, so I expect that DHCPv6 will be a
dominant method of autoconfiguration.

> 2)  For privacy addresses, isn't stateful DHCPv6 the solution?

Yes. It is. But not all platforms supports DHCPv6 today. As I said
before - i hope that DHCPv6 will be widely used in the future.

> 3)  For end user accountability/host tracking the best solution is probably 802.1X, granted that likely is not workable in your situation.  That said there have been tremendous strides in this space and I have deployed some nice solutions that go a long way in facilitating this.

Not at all. 802.1X is the layer 2 authentication. That says nothing
about IP address used for communication. You have to deploy some
mechanism that allows somehow tie L2 information obtained from 802.1X
authentication process (user, MAC address) with a L3 IP address. What is
pretty difficult since DHCPv6 don't have MAC in the requests and it is
impossible to tie 802.1x authentication requests with DUIDs from DHCPv6.
As such some extra system that gathers neighbor cache on the router have
to be deployed. The absence of MAC address in DHCPv6 is really tragic
issue.

Some more about that is on
http://ipv6.vutbr.cz/article/flow-based-monitoring-of-ipv6/ (slide 6)
and more detailed description in the article
http://ipv6.vutbr.cz/article/design-of-data-retention-system-in-ipv6-network/.

> 4)  For stateless DHCPv6 support (slide 8), current Apple iOS versions support it.  It is still missing in Android as per this specific feature request:  http://code.google.com/p/android/issues/detail?id=32621  That is pretty sad, especially since Google has some major IPv6 advocates.  That said, as you know Apple iOS 6 will and Android 4.0+ does support IPv6 for cellular connections.  Expect some major progress in this area this fall.  T-Mobile USA for example has fully deployed IPv6 within their network and is looking to go IPv6 only.  This will bring a resurgence in interest to the mobile space.
>
> You're in a tough situation as you are almost stuck having to support everything - an impossible situation.  In general I advise people to try to support Apple iOS and Android.  That's the overwhelming majority of the mobile space.  You could also make an argument for RIM although I rarely hear one.  Anyone else (e.g. Windows Mobile) is insignificant in terms of Market share.  Can you put in your network support policy that we support this and this and anything else is limited best effort support?
>
> As for XP even Microsoft seems to have given up here for IPv6.  If you look at their latest Microsoft Press book, Understanding IPv6 3e, it discounts anything before Vista.  XP is totally unsupported in April of 2014, so if you have to support it for now it will be dual stack.  Not only does it not support DHCPv6, but I thought it wasn't capable of doing IPv6 DNS either?

You are right. The support for IPv6 in Win XP is in a minimal form.
However I expect that Win XP will disappear in a few next years. It is
one of the reason why we are just considering redesigning our SLAAC
environment to pure DHCPv6. Devices that doesn't support DHCPv6 won't
have access to IPv6 network. Users will have to either upgrade their
system or install additional software with a DHCPv6 client.

>
> 5)  First Hop Security Threats - there are some vendors who have solutions to all of these (though limited availability for some of them to a few high end products for now)

Many vendors have some solution for this kind of threads (at least some
of them), however the price of those devices is much bigger comparing to
the devices that have similar security features for IPv4. For example
Cisco have this features only in the "big boxes" (6xxx, 49xx, 45xx) that
are no suitable as the access switches. Wen we building a new
installations we are in very difficult position. It is tough decision
whether to buy much more expensive switches that supports IPv6 security
features. Another option is to buy cheaper switches that have this
features only for IPv4 and in case of massive attack just block whole
IPv6 traffic on the access ports.

> 6)  Slide 19 - I agree, this is very sad
>
> 7)  Slide 21 - rogue IPv6 routers (Vista ICS), can't you use port ACLs to deal with this or RA guard if available?  I thought every decent switch at least supports port ACLs - not the case?  You seem to imply this later but wondering why you don't mention here.

The support for IPv6 ACLs is related to support for filtering functions
in hardware. Switches that support IPv6 ACLs/PACLs usually have
implemented some kind of RA-Guard and related security features. So the
result - today, there are just no access switches on the market with
support IPv6 filtering (PACL, RA-Guard) for a good price.

> 8)  Slide 27 - first hop security countermeasures:
> SeND - will probably never happen.  Microsoft and Apple have no interest in doing this and that pretty much kills it.
> RA-Guard/PACLs - these work.  It's true you can use a tool to defeat these with fragmentation but that requires actively attacking the infrastructure with an attack tool (would never be by accident which is mostly what you run into).  If I look at the IPv4 world, it is rare that people deploy DHCP snooping/DAI/IPSG because it can break protocols that can't deal with security (e.g. Apple's).  Therefore while I would like to see a solution to this I wonder how many people will actually use it.

I can't agree that features like DHCP snooping are used very rare. In
our environment it is basic requirement and every switch that is bought
must support it. In a past few years the worms like Flush.M or
DNSChanger has appeared quite often. Specially within environment where
users connects their own devices (computer, laptops). Agree that this
features are not necessary, lets say, in the office network or within
the network where you have control over the devices that are connected
to. But is not always the case. At the beginning we started without this
features as well. But as the network connectivity is essential for every
staff and worms are more aggressive the requirements for this features
are more often. I expect that importance of first hop security will grow
up in the future.

> 9)  slide 28 - SeND is not the only way to deal with malicious RAs.  There will be improved versions of RA Guard coming thanks to Fernando and there are ways to block the fragmentation attacks now.  That said, I'm not sure if blocking the fragmentation attacks breaks other things - it may.

I have doubts that anybody would use RA-Guard based on SeND. From my
point configuring one command (to enable RA-Guard) is much easier  them
configuring RA-Guard to work with send an periodically replace
certificates on the router switches etc. I personally don't expect that
send will by widely developed or used.

> 10)  Slide 38 - Implied message is no business case for IPv6.  I think this is leaving out some important details.  Since this is a very technical list I will get to the point - we have < 141 million IPv4 addresses left at a burn rate of around 200 million IPv4 addresses/year.  Everyone on this list agrees CGN sucks.  In addition, it has been clearly shown that it is cheaper for an ISP to deploy IPv6 then CGN.  Therefore the future of the Internet is clearly IPv6.  So let's ask this question - how many of your users value having Internet connectivity?  If you look at it from this vantage point I think everything else on that list pales in comparison.  In Europe RIPE enters depletion this month or next - this is not some far off event.  It's here now.

I didn't want to implicate that message. That slide just says the there
is always something more important than IPv6 in many organizations  That
is the reason why IPv6 deployment is going so slow. I completely agree
that CGN as any kind of NAT sucks, but I also can see many ISPs having
no other choice than deploy CGN. NATs are used by many smaller providers
for years, so it is not a brand new technology comparing to IPv6. Btw.
you hit some interesting topic. Do you have some statistics or documents
proving that IPv6 is cheaper then deploying CGN ? I am not sure about that.

The fact is that less than 0.7% of clients are able to use IPv6 today
and less that 4% of content providers have content available over IPv6.
Such numbers also means that there are approximately 99.6% of clients
that are not able to reach IPv6 content and 94% of content (lets say web
sites) is not available for IPv6 only clients. It doesn't look good on
both sides and I really don't know what to do about it.


> 11)  Slide 41 - IPv6 is a massive topic.  We're talking about the underpinnings of global communication.  I think it's important to split IPv6 up into different areas such as Internet of Things, Internet connectivity, Business/Organization Internal, Consumer Internal.  For some things like the Internet of Things, SmartGrid and other solutions in this category there is no IPv4, but only IPv6.  So even with saying IPv6 is something for the future is only true in certain contexts.  If you're an ISP for example and haven't started deploying IPv6 you're in trouble.  Specifically for the Internet connectivity area, the compelling case is business continuity.  Most of your users probably don't understand IPv4/IPv6 and don't want to.  But if they need to get somewhere on the Internet and have poor performance (CGN) or can't reach it (IPv6 only) they will be incensed.  There are some Internet applications that are IPv4 only but this will change in the next few years as usage ramps up.
I hope it will happen. We will see in next 10 years :-).

>    As for internal applications that don't use the Internet, I agree with you that support is lacking.  However, for this area I don't see a big demand or need yet.
>
> 12)  Slide 44 - this is awesome.  There has to be a better way to track issues.  What about a Wiki page to track IPv6 operational and security issues along with progress in the IETF and with vendors.  What gets measured gets done - what do you think?

Maybe it is something to think about. However it seem that process is a
"log distance run". Having practical experience the problems that we
tried to solve 4-5 years ago aren't solved yet or a very little progress
has been done. But there is still hope that progress will speed up
before all ISPs deploy CGNs.



Thanks a lot for your comments. I really appreciated it.

Tomas