Subject: Re: IPv6 networking: Bad news for small biz

From: John C Klensin <[email-masked]>
Date: Thu, 05 Apr 2012 11:46:15 -0400

--On Wednesday, April 04, 2012 21:31 -0400 Steven Bellovin
<[email-masked]> wrote:

> v6 is not the protocol I would have chosen.  For that matter,
> it's not the protocol I pushed for, as hard as I could, in the
> IPng directorate.  At this point -- with all of its technical
> mistakes, IETF omissions, and difficulty of converting, we're
> stuck with it; we simply do not have time -- even if we agreed
> now on what we should have done, way back when -- to start
> over. Do the arithmetic...  Assume we know, today, the basic
> structure of a perfect replacement for v4.  It would take a
> minimum of 3 years to get through the IETF, not because of
...
> By my arithmetic, it's a
> dozen years minimum, *after* we've agreed on the basic design.

I agree with Steve in almost all respects.  Also somewhat agree
with Dave Meyers: NATs were inevitable the moment we adopted
CIDR and effectively started encouraging the RIRs to push back
on allocating fragmented and/or small blocks, if not even
sooner.  Now we could (and I think did) reasonably assume
(perhaps as part of retrospectively less-reasonable assumptions
about how quickly IPng/IPv6 would be deployed and how CIDR would
disappear -- the latter assumption followed on the early
assumption that CIDR was mostly about address conservation
rather than about routing tables) that they would not become
associated with other issues and have a long life as a result.
The latter is, IMO, really key, not whether or not we would have
NATs.  

Because of the problems that Steve points out of timing to get
another solution out there (perhaps fortunately, that constraint
applies to anyone else who wanted to start on a new "next
generation" protocol suite too), I don't see a lot of point in
putting energy into asking "what if" or bemoaning the state we
find ourselves in except insofar as it actually helps us to move
forward.  I'm trying to avoid that except where understanding
how we got here seems useful to avoiding repeating prior
mistakes.   I do think it is worthwhile to look at where we are
today and, in particular, how we should balance trying to better
understand the real obstacles to IPv6 adoption and doing
something about them (obstacles that include the perceptions we
and others are continuing to create) against IPv6 Cheerleading
sessions that try to change perceptions in their own ways but do
nothing about those problems (or, IMO, worse, dismiss them as
unimportant).

In the message to which Steve responded, Noel included:

> Part of the real problem has been that the IETF failed to
> carefully study, and take to heart, the operational
> capabilities which NAT provided (such as avoidance of
> renumbering, etc, etc), 

Part of that really does have to do with the question of how we
move forward.  The "etc, etc" above covers a lot beyond NATs in
a renumbering context.   At least IMO, we failed to do the
comprehensive analysis on what those issues were. Consequently,
in a problem that seems to persist to this day, we haven't been
able to make a coherent "if you have situation X, you should do
Y" chart or tell a corresponding story.

I'm personally particularly sensitive to customer support issues
for relatively small end-networks that have no serious on-site
technical support capability (residential networks, SOHO
arrangements (where the office is either remote from a larger
facility or primary), relatively isolated branch offices, etc.).
I have been worrying for some time that NAT arrangements with
1918 space create an "almost all networks are the same, even
down to the addresses used" situation, which is hugely
convenient from the standpoint of support, especially if the
support personnel are not, themselves, experts.   I'm delighted
that we finally have a HOMENET WG but concerned that if we were
serious about IPv6 and understood that set of issues, we would
have had that WG a decade ago.  Worse, my inference from
discussion in the meeting of that WG last week is that a large
fraction of the participants _still_ don't understand the issues.

Others have worried more about renumbering and, well, etc., etc.

Unlike some others, I'm still not convinced that there is
anything fundamentally wrong with the IPv6 design although I
believe that we could have made it either easier to deploy or
that we could have offered more incentives for deployment.   But
I think we have done a terrible job until now of identifying,
organizing, and presenting realistic scenarios and corresponding
transition models.  

As an exercise, I'd like everyone to try to think about the
decision process of an IT executive who is trying to decide when
and how to deploy IPv6.  Let's make the problem easy by assuming
that she understands the broad issues and believes that she will
have to deploy IPv6 sooner or later (a belief that is by no
means universal).   She needs to deal with several complex
questions and tradeoffs among them including:

	(i) Networks grow, so conversion costs for existing (at
	the time) facilities will be larger in the future than
	they are now... probably worse yet if measured in
	constant dollars.
	
	(ii) Support costs and [re]training of people are an
	important part of the equation.  The end users who are
	being supported probably barely know how to work a web
	browser, believe a "route" is something they follow on
	the way to the grocery store, and understand "address"
	mostly as something their houses have exactly one of
	each.  Worse, it may be in the IT Department's interest
	to keep it that way -- users who know enough to start
	messing with machine or router configurations are often
	_very_ expensive to support.   As one of many
	consequences of this, equipment and configurations that
	are easy to support have a huge and continuing economic
	advantage over arrangements that provide more options
	and flexibility at the cost of complexity.  In many
	cases, judgments will get made about ease of support and
	training on one generation of equipment and, if the
	answers aren't right, it will make sense to wait for the
	next generation (possibly after trying to beat vendors
	up, possibly not).
	
	(iii) It is very dangerous to start deployment before
	all of the ducks are lined up.  If key concepts or
	equipment are not available, or not fully understood,
	after conversion works starts, the consequences are
	likely to be very nasty.  In particular, about the worst
	thing she can do (measured in job [in]security, if
	nothing else) is to start deployment and then stop or
	fail, having invested considerable resources with no ROI.

At least the third of these involves some speculation and
reading of omens (which is part of why she presumably gets paid
the big bucks).  But the signals the IETF sends are really
important in that regard.  Part of the signal we are sending now
(and have been sending for a long time) is that we are willing
to let a thousand flowers bloom wrt both transition strategies
and configuration decisions, that, inevitably, there are a lot
of weeds mixed in there with the flowers, and that if we know
how to tell a flower from a weed, we aren't telling.  That is
actually ironic given how outraged we get in other areas when a
non-standard solution (or a solution proposed by standardization
in another body) comes along that might confuse the marketplace
vis-a-vis IETF work).  But, to our hypothetical executive, it is
pretty easy to read the message we are sending as "the IETF
doesn't really understand how people in my situation should
deploy IPv6, so I should probably wait until they do".

Worse, if some snake-oil purveyor (NAT or otherwise) then comes
along and says "I know how you can avoid converting with IPv4
until you are good and ready, if ever", she is getting a message
that is more clear, and more attractive under the circumstances,
than the one she is getting from the IETF.

And "decision-maker at ISP supporting small networks" or "small
business" can be substituted for "IT Executive" in the above
without significant other change.  The details are different and
the tradeoffs may be, but the fundamental issues aren't.

     john

---

From: Christian Huitema <[email-masked]>
Date: Sat, 7 Apr 2012 17:35:55 +0000

> Unlike some others, I'm still not convinced that there is anything fundamentally wrong with the IPv6 design 
> although I believe that we could have made it either easier to deploy or
> that we could have offered more incentives for deployment.

IPv6 is, fundamentally, IPv4 with bigger addresses. I am hearing two kinds of critics. On one hand, some regret the lost opportunity to break from the IPv4 design and do something more radical, e.g. ID/locator separation. On the other hand there are those who wish that IPv6 was even more like IPv4, including the use of NAT and other such practices, so network administrators could keep a familiar setting. Of course, the two critics are contradictory, as a radical change in design would indeed require administrators to learn radically new methods.

Thinking back, I do not regret the opportunity lost. The Internet grew tremendously between 1992 and 2012, and that very growth proves that the IPv4 design was pretty good. We could do much worse than keeping that design for IPv6. I have much more sympathy for the other side of the critic, that IPv6 is in some ways too different from IPv4. We may want to take a deep look there!

-- Christian Huitema

---

From: Yoav Nir <[email-masked]>
Date: Sat, 7 Apr 2012 21:00:34 +0300

On Apr 7, 2012, at 8:35 PM, Christian Huitema wrote:

> IPv6 is, fundamentally, IPv4 with bigger addresses.

Not quite. IPv6 has multiple prefixes, link-local addresses, neighbor discovery. See section 3 of RFC 5739 for a discussion of how things break when you treat IPv6 as a drop-in replacement.

> I am hearing two kinds of critics. On one hand, some regret the lost opportunity to break from the IPv4 design and do something more radical, e.g. ID/locator separation. On the other hand there are those who wish that IPv6 was even more like IPv4, including the use of NAT and other such practices, so network administrators could keep a familiar setting. 

Changing the message from "you don't need NAT anywhere" to "sure, you can use RFC 4193 ULAs, just don't let us see them on the Internet" would be a big help.

Small businesses would have one or two networks, so nothing bad happens even if the router chooses the 40 random bits in a not-so-random fashion. Bigger businesses with multiple subnets in each site and VPNs between the sites would need to be more careful, but should have the appropriately-skilled operators. Just like they do now.

Yoav

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Sat, 7 Apr 2012 15:30:40 -0300

Sorry for arriving late at the party.

If people want NAT so badly, let them have it. It will be better to have a standardized NATv6 than the multiple, non-standard and sometimes downright bizarre implementations of NAT we have now. Just keep it in a way such as that the future Internet MUST be a place were NATs are OPTIONAL and not FORCED down one's throat like they are now.

I also believe that if ULAs hadn't been named ULAs but RFC1918 for IPv6 or "private IPv6 space" we wouldn't be having much of this conversation. Many, many people outside these IETF mailing lists just don't grok that ULAs are little more than that. I also tend to panic a little when people want to deprecate ULAs. I just don't see the point of doing this, while I keep seeing a lot of use cases for private space.

I hate NATs with port translation on single public IPs. Things break, many times inexplicably. People have this rather inexplicable warm feeling that they are somewhat 'safer' behind NATs. I picture them standing in front of a tornado with an umbrella in hand and feeling protected.

However, I can live with prefix translation, in fact, I believe it can be just the tool that small businesses need to save themselves renumbering efforts and keep some of the warm feeling as well.

Warm regards,

Carlos

---

From: Randy Bush <[email-masked]>
Date: Sun, 08 Apr 2012 05:43:08 +0900

> Changing the message from "you don't need NAT anywhere" to "sure, you
> can use RFC 4193 ULAs, just don't let us see them on the Internet"
> would be a big help.

in ipv4, rfc1918 space was needed because of address scarcity.  in ipv6,
you could use global space inside a nat, if you need a nat.  we do not
need to perpetuate the 1918 mess.

randy

---

From: Yoav Nir <[email-masked]>
Date: Sun, 8 Apr 2012 07:12:24 +0300

> need to perpetuate the 1918 mess.

Not having to "buy" address space, or "lease" it from whatever ISP you're using at a certain point in time is a feature, not a workaround. RFC 1918 is only a mess if you need to make sure multiple organizational networks do not overlap. With the amount of subnets available in ULAs this should not be hard.

Yoav

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 8 Apr 2012 00:34:03 -0400

> Not having to "buy" address space, or "lease" it from whatever ISP you're using at a certain point in time is a feature, not a workaround. RFC 1918 is only a mess if you need to make sure multiple…

s/should not be hard/should statistically not be a problem/

want to now bet your next billion dollar partnership on 'statistically
should not be a problem' ? (rhetorical question, your lawyers won't
let you anyway, so it doesn't matter what you want)

-chris

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 7 Apr 2012 22:01:43 -0700

> let you anyway, so it doesn't matter what you want)

Anyhow .... real operators who are really using ULAs have some real
use cases... which are not related to not having enough addresses.
draft-liu-v6ops-ula-usage-analysis-02 covers some of this.... since
this exact conversation keeps appearing over and over.

CB

---

From: Hector <[email-masked]>
Date: Sun, 08 Apr 2012 01:14:07 -0400

Hi,

Not to fall victim of oversimplifying the issue, I think the major 
problem was the general mindset of using (and forcing down people's 
throats) an "One Size Fits All" IPv6 solution across the board.

When one is privy to work with unlimited resources, anything is 
possible. Everyone must agree and plus "our products and services will 
work better."   Unfortunately, it is not market reality  when 
resources are limited, which was the heart of the problem and the key 
point the OP reference article [1] hits home with,

-- 
Hector Santos, CTO
http://www.santronics.com
http://hector.wildcatblog.com

[1] http://www.theregister.co.uk/2012/03/31/ipv6_sucks_for_smes

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 08 Apr 2012 07:41:00 -0700

> need to perpetuate the 1918 mess.

you can also do it statelessly e.g. 1:1 because address expansion is
probably also not your  goal. That is unless your providers are morons
and you're stuck with a /128 /64 /60 or some other block that's rather
too small for the intended purpose.

in both the v4 and v6 cases expansion through address translation is
unilateral, it doesn't require coordination between the parties, even if
you have enough addresses, coordination is (still) expensive.

---

From: John C Klensin <[email-masked]>
Date: Sun, 08 Apr 2012 14:32:21 -0400

--On Sunday, April 08, 2012 07:12 +0300 Yoav Nir
<[email-masked]> wrote:

>>> Changing the message from "you don't need NAT anywhere" to
>>> "sure, you can use RFC 4193 ULAs, just don't let us see them
>>> on the Internet" would be a big help.
>> 
>> in ipv4, rfc1918 space was needed because of address
>> scarcity.  in ipv6, you could use global space inside a nat,
>> if you need a nat.  we do not need to perpetuate the 1918
>> mess.

> Not having to "buy" address space, or "lease" it from whatever
> ISP you're using at a certain point in time is a feature, not
> a workaround. RFC 1918 is only a mess if you need to make sure
> multiple organizational networks do not overlap. With the
> amount of subnets available in ULAs this should not be hard.

But, Yoav, that particular cost is a policy cost, not a
technology one.  First of all, what Randy rather politely calls
the "1918 mess" is actually three separate messes.  One of those
messes was the need to have one public address for a LAN serve
multiple addresses/ host/interfaces on that LAN.  That
necessitated the second mess, which was having different
addresses "inside" and "outside".  There are reasons for having
separate addresses "inside" and  "outside" even if one has
enough "outside" addresses to map some of all of them
one-to-one.    Neither the scarcity of "outside" addresses nor a
desire for separate "inside" ones requires that the internal
addresses by reused in multiple LANs (1918 addresses aren't
really "private", they are just explicitly reusable), and it the
notion of reusable addresses that are the third mess.   If "we"
(for some very broad definition that includes the IETF and the
RIRs) permit the business of charging for individual addresses
to persist into the IPv6 world (it would be relatively easy to
describe policy decisions and recommendations to regulators that
would end that particular charging game... of course it might be
replaced by something you'd like less), the first mess would
remain, but there is no inherent reason while reusable addresses
would be required.

As just one example of mess-removal, note that, for an
enterprise or activity that needs at least one external/public
DNS name, the use of global addresses for internal hosts just
means "address that isn't globally routable" while 1918
addresses just about require split-horizon DNS.

    john

---

From: Steven Bellovin <[email-masked]>
Date: Sun, 8 Apr 2012 18:54:04 -0400

> If people want NAT so badly, let them have it. It will be better to have a standardized NATv6 than the multiple, non-standard and sometimes downright bizarre implementations of NAT we have now. Jus…

The problem is that protocol designs these days have to account for NAT, which often makes things far more complicated than necessary.
> However, I can live with prefix translation, in fact, I believe it can be just the tool that small businesses need to save themselves renumbering efforts and keep some of the warm feeling as well.

That's locator/ID split -- too bad v6 wasn't designed for that...

		--Steve Bellovin, https://www.cs.columbia.edu/~smb

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 08 Apr 2012 17:41:44 -0700

On 4/8/12 15:54 , Steven Bellovin wrote:
> That's locator/ID split

it's not unilateral either, the party that wants to reach me a lisp
overlay also needs to have it available.

Which gets you to the problem of incentives.