Hi
IETF IPv6 Operations WG is looking at this draft, and we're interested in any comments you might have as well.
http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines
"Guidelines for Using IPv6 Transition Mechanisms", Jari Arkko, Fred
Baker, 12-Jul-10
Hi Fred,
Some feedback:
In section 4.1, you kind of gloss over the challenges with native dual
stack. You do state them, but if I didn't already know, I'd miss the
significance of what you wrote.
The significance is this:
1. The IPv6 Internet is not yet operating at the same availability
standard as the IPv4 Internet and for reasons obvious to those of us
who maintain operational systems, won't operate at the same standard
until the networking emphasis (and funding!) moves from Ipv4 to Ipv6.
2. Connections to a dual stacked IPv6 host where the IPv6 path isn't
working are much like connections to an IPv4 host with two IP
addresses where one isn't working. With the added bonus that all
assigned IPv6 addresses are tried first.
The document is a little short on mitigations. Whitelisting between
providers? Somehow in the name lookup? In what DNS software? And what
about the folks who don't resolve names locally?
There is a third major challenge to dual-stack that isn't addressed in
the document: differing network security models that must deliver the
same result for the same collection of hosts regardless of whether
Ipv4 or v6 is selected. I can throw a COTS d-link box with
address-overloaded NAT on a connection and have reasonably effective
network security and anonymity in IPv4. Achieving comparable results
in the IPv6 portion of the dual stack on each of those hosts is
complicated at best.
While interesting, 4.3 remains too deep in theory to seriously
consider it for a short-term transition strategy.
While 4.4 may be useful in the waning days of IPv4, it doesn't seem
credible in the waxing days of IPv6. I'm going to make the vast
majority of my customers pass through how many additional points of
failure? That I have to pay extra to maintain?
Regards,
Bill Herrin
There is a third major challenge to dual-stack that isn't addressed in
the document: differing network security models that must deliver the
same result for the same collection of hosts regardless of whether
Ipv4 or v6 is selected. I can throw a COTS d-link box with
address-overloaded NAT on a connection and have reasonably effective
network security and anonymity in IPv4. Achieving comparable results
in the IPv6 portion of the dual stack on each of those hosts is
complicated at best.
Actually, it isn't particularly hard at all... Turn on privacy addressing
on each of the hosts (if it isn't on by default) and then put a linux
firewall in front of them with a relatively simple ip6tables configuration
for outbound only.
(The linux firewall could be as simple as a WRT-54G running
dd-wrt or such).
Owen
All respect to someone that knows his stuff, and I do realise that the
OP mentioned small-scale hardware, but in the wider world (and even the
world of home users as seen from the carrier side) any solution that
says "do <whatever> on every host" is just not workable. As for the
Linux packet filter, that's an exercise for the advanced home user.
Outside the home environment - well, most people here have traffic rates
that would leave a Linux firewall a melted puddle of slag. It has to be
a standards based solution, implemented in silicon.
That said, you get 99% of everything worth having out of NAT with a
packet filter that says "allow established and related in, allow
anything out, block everything else". That can be implemented trivially
on just about any router from the tiniest piece of CPE up to the Cisco
and Juniper refrigerator boxes, and I would expect to see it the default
in any IPv6 CPE (when they at last begin appearing).
While there are people who want anonymity (by which they mean not
exposing actual addresses to the Internet), I am of the opinion that
this is little more than another version of security through obscurity,
and that the very minor benefit it may confer is massively outweighed by
the operational impost.
Some people don't want their MAC addresses exposed to the Internet, so
they don't want to use IPv6 autoconf addresses. I feel pretty much the
same way about that idea as I do about the other, but at least there is
a simple, standard solution for it - DHCP. DHCP is far less obstructive
to troubleshooting and logging than privacy addresses.
Regards, K.
On Mac Airport Extreme it is "disallow outside to access internal machines", tick and it is done!
From: "Karl Auer" <kauer@biplane.com.au>
To: nanog@nanog.org
Sent: Thursday, 22 July, 2010 4:24:59 PM
Subject: Re: Looking for commentsI can throw a COTS d-link box with
address-overloaded NAT on a connection and have reasonably
effective
network security and anonymity in IPv4. Achieving comparable
results
in the IPv6 portion of the dual stack on each of those hosts is
complicated at best.Actually, it isn't particularly hard at all... Turn on privacy
addressing
on each of the hosts (if it isn't on by default) and then put a
linux
firewall in front of them with a relatively simple ip6tables
configuration
for outbound only.All respect to someone that knows his stuff, and I do realise that the
OP mentioned small-scale hardware, but in the wider world (and even
the
world of home users as seen from the carrier side) any solution that
says "do <whatever> on every host" is just not workable. As for the
Linux packet filter, that's an exercise for the advanced home user.
In a home environment where do X on every host isn't workable, it's
rare that every is more than 1, so, it's do X on THE host most of the
time.
Windows defaults to privacy addresses on by default, so, that also
takes care of most of the environments where people have minimal
understanding of technology.
It takes some effort (minimal) on Linux. I haven't investigated what
it takes on Mac.
Again, this only matters if you care about address obfuscation anyway,
which isn't really security, but, does provide some (minimal and ineffective)
aspects of privacy.
The packet filter doesn't have to be done on every host, just the gateway.
On Mac Airport Extreme it is "disallow outside to access internal machines", tick and it is done!
That takes care of the packet filter, but, it doesn't handle the stated
requirement for address obfuscation.
I question the value of address obfuscation, but, the people with that
religion will not give it up so I attempted to address the problem as
stated.
Owen
Yes I understand that part, but all the people have already given away their privacy on Facebook, so why bother?
If you are really worried about your privacy, then you will find the setting...
I'm not sure in a corporate environment you will want address obfuscation for internal/legal reasons, so it would apply at home? but then I already know your network, and it does not matter if it is the computer of your wife, kids,... You are still responsible...
May be in an open Wifi environment you will want to do that...
my comments wrt mitigations for the "one of my addresses doesn't work"
problem and the impracticality of the document's section 4.3 and 4.4
for wide scale Ipv6 deployment?
Regards,
Bill Herrin
No, merely resignation to the fact that you don't get it.
Owen
I see. Well, you want to engage in a genuine discussion of the
challenges which obstruct *my* deployment of Ipv6, you let me know.
Regards,
Bill Herrin
Bill,
There is a third major challenge to dual-stack that isn't addressed in
the document: differing network security models that must deliver the
same result for the same collection of hosts regardless of whether
Ipv4 or v6 is selected. I can throw a COTS d-link box with
address-overloaded NAT on a connection and have reasonably effective
network security and anonymity in IPv4. Achieving comparable results
in the IPv6 portion of the dual stack on each of those hosts is
complicated at best.Actually, it isn't particularly hard at all... Turn on privacy addressing
on each of the hosts (if it isn't on by default) and then put a linux
firewall in front of them with a relatively simple ip6tables configuration
for outbound only.From the lack of dispute, can I infer agreement with the remainder of
my comments wrt mitigations for the "one of my addresses doesn't work"
problem and the impracticality of the document's section 4.3 and 4.4
for wide scale Ipv6 deployment?
As for those two scenarios (IPv6-only ISPs and IPv6-only clients, to simplify
them), the document doesn't place them as first preference solutions.
However, the fact is that various *extremely* large operators find themselves
more or less forced into these scenarios by IPv4 exhaustion. I think it's
more reasonable to describe solutions for them than to rule their
problem out of order.
Brian
Some of the extremely large operators have found themselves having to deploy ipv6 extensively in order to manage CPE devices and their infrastructure networks. However, I'm not aware of any large provider which is deploying ipv6-only customer access products, either due to a shortage of ipv4 space or any other reason. If you can supply names of providers doing this, I'd be very interested to hear.
That's not to say that they won't start doing this relatively shortly. And you correctly point out that we need to create solutions _now_ so that access providers will have feature equivalence when they start deploying ipv6 in anger on access / hosted networks.
This is a cue to get people on this list to shout at their vendors for ipv6 feature equivalence on their favourite kit.
Nick
> As for those two scenarios (IPv6-only ISPs and IPv6-only clients, to simplify
> them), the document doesn't place them as first preference solutions.
> However, the fact is that various *extremely* large operators find themselves
> more or less forced into these scenarios by IPv4 exhaustion.Some of the extremely large operators have found themselves having to
deploy ipv6 extensively in order to manage CPE devices and their
infrastructure networks. However, I'm not aware of any large provider
which is deploying ipv6-only customer access products, either due to a
shortage of ipv4 space or any other reason. If you can supply names of
providers doing this, I'd be very interested to hear.
Does this qualify? What the customer sees is delivered over IPv6,
unlike the CPE management problem, where the ISP is the "IPv6 customer".
"IPv6: The Future of IPTV? In Japan it isn't the future, it's now."
http://www.internetnews.com/dev-news/article.php/3795086/IPv6-The-Future-of-IPTV.htm
In the USA too, see netflix
Does this qualify? What the customer sees is delivered over IPv6,
unlike the CPE management problem, where the ISP is the "IPv6 customer"."IPv6: The Future of IPTV? In Japan it isn't the future, it's now."
http://www.internetnews.com/dev-news/article.php/3795086/IPv6-The-Future-of-IPTV.htm
I understand that there are several networks doing this; the STB - like the CPE modem - is managed by the service provider and the customer has no management / control access over it. The customer stays on ipv4 for their regular access product.
Someone offline pointed me at the Google IPv6 Implementors 2010 conference, at which:
This is genuinely interesting.
Nick
However, the fact is that various *extremely* large operators find themselves
more or less forced into these scenarios by IPv4 exhaustion.
Hi Brian,
Respectfully, anyone betting on what the ISPs will be "forced" to do
is betting to lose. The operators, large and small, have a number of
options for dealing with free pool exhaustion. NAT, aggressive address
recovery, transfer markets, dual stack of course, and others.
That having been said, I don't want to stray from the point of your
document -- offering practical advice to folks for whom IPv6 plays a
role in their plans for dealing with free pool depletion. I
respectfully submit that a silent assumption that ISPs will be forced
kicking and screaming to adopt one of the strategies you've outlined
does not make for a healthy foundation for the document. Assume
they'll have other options than IPv6, dual stack or otherwise. Assume
they'll abandon dual stack for the other options if dual stack proves
too challenging.
Then figure out the mitigations and go in to technical detail citing examples.
I think it's
more reasonable to describe solutions for them than to rule their
problem out of order.
In that, you are surely correct. But frankly, having read 4.3 I have a
hard time taking it seriously as an early-stage IPv6 transition
mechanism. It reads to me like pie in the sky.
I can see 4.4 as a late stage mechanism when we're slowly dismantling
our IPv4 networks... I can also see it as an under-the-hood mechanism
for deploying new integrated technologies (utility meters, IPTV, etc).
As a replacement for general-purpose IPv4 access in the stages before
Ipv6 is ubiquitous? I welcome you to prove me wrong, but sitting here
looking forward it just doesn't seem credible to me.
If I was writing your document, I think I'd describe it that way:
potentially valuable for deployments of new technologies such as
[list] so that their roll out and operation doesn't get caught up in
the expensive free pool exhaustion issues, but unlikely to be
acceptable for general purpose Internet access.
Regards,
Bill Herrin
> I think it's
> more reasonable to describe solutions for them than to rule their
> problem out of order.In that, you are surely correct. But frankly, having read 4.3 I have a
hard time taking it seriously as an early-stage IPv6 transition
mechanism. It reads to me like pie in the sky.
Section 4.3 (IPv6-only core) makes sense, if you define "core" as
"customer edge to peering edge." ISPs won't save much IPv4 address
space by numbering their core routers into IPv6, but if they assign IPv6
addresses to Dual-stack Lite routers and LSNs, they have a transition
plan. I can't say whether it's a viable plan, but it's a plan.
I can see 4.4 as a late stage mechanism when we're slowly dismantling
our IPv4 networks... I can also see it as an under-the-hood mechanism
for deploying new integrated technologies (utility meters, IPTV, etc).
I think that's exactly the scenario it describes. IPv6 plus an
IPv4-stretcher (NAT444, DS-Lite) is the crustimony proseedcake.
Lee
> Does this qualify? What the customer sees is delivered over IPv6,
> unlike the CPE management problem, where the ISP is the "IPv6 customer".
>
> "IPv6: The Future of IPTV? In Japan it isn't the future, it's now."
> http://www.internetnews.com/dev-news/article.php/3795086/IPv6-The-Future-of-IPTV.htmI understand that there are several networks doing this; the STB - like the
CPE modem - is managed by the service provider and the customer has no
management / control access over it. The customer stays on ipv4 for their
regular access product.Someone offline pointed me at the Google IPv6 Implementors 2010 conference,
at which:This is genuinely interesting.
Certainly is. I've generally classified mobile operators as people who
are heavily on the side of walled gardens. It's refreshing to see one
advocating e2e and global reachability.