+1 One IP per device will almost most likely be the preference and implementation in corporate/enterprise deployments. Too much procedure, regulation and other roadblocks prevent any other solution. Authentication, Authorization, Accounting, ACLS, NMS, IDS, IP management, custom software, and other roadblocks will certainly stall if not stop IPv6 deployments in enterprises if there isn’t at least the choice of static, single IPv6 addresses per device. SLAAC will probably be a complete non-starter in many corporate environments. It is in ours. The more ideologues preach about restoring peer-to-peer connectivity, dynamic IPs, privacy addresses, etc… the less penetration IPv6 will happen in corporate networks.
On Jun 10, 2015, at 2:11 PM, Ray Soucy <rps@maine.edu> wrote:
I've already written systems to do this kind of thing, but the logging requirements quickly go through the roof for a non-trivial network; especially in the case of temporary addressing now default on many systems. That isn't so much the issue as operational consistency and supportability.
The requirement for hosts to be dual stack will exist for some time.
For the sanity of IT workers and users alike (most of which don't really know the details of IPv6 and barely understand address scopes let alone multiple addresses) there needs to be some level of consistency between how hosts are addressed and communicate between the two protocols. Saying we'll develop one system for IPv4 and one for IPv6 ultimate results in "Let's not deploy IPv6 just yet".
This rings especially true when security concerns come up. Consistency between IPv4 and IPv6 needs to be possible in this transition period, or people simply decide to not deploy. Consistency in addressing and maintaining a one host one address model has major implications for policy construction, flow analysis and incident response, denial of service mitigation, etc. If the consistency isn't there, you need to "re-invent the wheel" for every aspect, then maintain different systems for IPv4 and IPv6 along side one another.
Even worse, if we keep seeing adoption held up by inconsistent client implementations I fear we'll start seeing commercial products which NAT or proxy IPv4 to IPv6 to avoid using IPv6 internally. It's very ugly and requires some DNS magic to work, but it's not impossible. We're already seeing this in terms of cloud computing and virtualization. Servers have IPv4 addresses and only a load balancer with an external IPv6 address.
We absolutely need to make it possible for people to adopt IPv6 before we can reach a point where IPv4 can go away, and for some organizations the answer of "Just use SLAAC" is simply not acceptable.
They just won't do it.
Preventing IPv6 adoption hurts us all. And Android not supporting a MAJOR part of IPv6 like DHCPv6 is preventing adoption.
On Wed, Jun 10, 2015 at 1:42 PM, Sander Steffann <sander@steffann.nl> wrote:
It's not the *only* option. There are large networks - O(100k) IPv6
nodes - that do ND monitoring for accountability, and it does work for them. Many devices support this via syslog, even. As you can imagine, my Android device gets IPv6 at work, even though it doesn't support DHCPv6. Other universities, too. It's obviously not your chosen or preferred mechanism, but it does work.
/me starts to write that whitepaper that educates people on how to do this
Cheers, Sander
-- Ray Patrick Soucy Network Engineer University of Maine System
T: 207-561-3526 F: 207-561-3531
MaineREN, Maine's Research and Education Network www.maineren.net