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
On Wed, Jul 21, 2010 at 3:18 AM, Fred Baker <fred@cisco.com> wrote:
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
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
On Wed, 2010-07-21 at 20:37 -0700, Owen DeLong wrote:
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.
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. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
----- Original Message -----
From: "Karl Auer" <kauer@biplane.com.au> To: nanog@nanog.org Sent: Thursday, 22 July, 2010 4:24:59 PM Subject: Re: Looking for comments On Wed, 2010-07-21 at 20:37 -0700, Owen DeLong wrote:
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.
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.
On Mac Airport Extreme it is "disallow outside to access internal machines", tick and it is done!
On Jul 21, 2010, at 9:58 PM, Franck Martin wrote:
----- Original Message -----
From: "Karl Auer" <kauer@biplane.com.au> To: nanog@nanog.org Sent: Thursday, 22 July, 2010 4:24:59 PM Subject: Re: Looking for comments On Wed, 2010-07-21 at 20:37 -0700, Owen DeLong wrote:
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.
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
----- Original Message -----
From: "Owen DeLong" <owen@delong.com> To: "Franck Martin" <franck@genius.com> Cc: "Karl Auer" <kauer@biplane.com.au>, nanog@nanog.org Sent: Thursday, 22 July, 2010 5:35:24 PM Subject: Re: Looking for comments On Jul 21, 2010, at 9:58 PM, Franck Martin wrote:
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.
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...
On Wed, Jul 21, 2010 at 5:37 PM, Owen DeLong <owen@delong.com> wrote:
http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines 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?
Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Jul 22, 2010, at 12:49 AM, William Herrin wrote:
On Wed, Jul 21, 2010 at 5:37 PM, Owen DeLong <owen@delong.com> wrote:
http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines 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?
No, merely resignation to the fact that you don't get it. Owen
On Thu, Jul 22, 2010 at 3:02 AM, Owen DeLong <owen@delong.com> wrote:
On Jul 22, 2010, at 12:49 AM, William Herrin wrote:
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?
No, merely resignation to the fact that you don't get it.
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Bill, On 2010-07-22 19:49, William Herrin wrote:
On Wed, Jul 21, 2010 at 5:37 PM, Owen DeLong <owen@delong.com> wrote:
http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines 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
On 22/07/2010 22:38, Brian E Carpenter wrote:
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. 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
On Thu, 22 Jul 2010 23:57:22 +0100 Nick Hilliard <nick@foobar.org> wrote:
On 22/07/2010 22:38, Brian E Carpenter wrote:
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-...
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
----- Original Message -----
From: "Mark Smith" <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> To: "Nick Hilliard" <nick@foobar.org> Cc: "NANOG list" <nanog@nanog.org>, "Brian E Carpenter" <brian.e.carpenter@gmail.com> Sent: Friday, 23 July, 2010 12:17:21 PM Subject: Re: Looking for comments On Thu, 22 Jul 2010 23:57:22 +0100 Nick Hilliard <nick@foobar.org> wrote:
On 22/07/2010 22:38, Brian E Carpenter wrote:
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-...
In the USA too, see netflix
On 23/07/2010 01:17, Mark Smith wrote:
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-...
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
On Fri, 23 Jul 2010 11:18:39 +0100 Nick Hilliard <nick@foobar.org> wrote:
On 23/07/2010 01:17, Mark Smith wrote:
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-...
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.
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.
Nick
On Thu, Jul 22, 2010 at 11:38 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
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
participants (9)
-
Brian E Carpenter -
Franck Martin -
Fred Baker -
Karl Auer -
Lee Howard -
Mark Smith -
Nick Hilliard -
Owen DeLong -
William Herrin