Creating demand for IPv6, and saving the planet

Mailman List Mirror (Read Only)
21

Mark,

As far as I can tell, IPv6 is at least theoretically capable of
offering exactly two things that IPv4 does not offer and can't easily
be made to offer:

1. More addresses.
2. Provider independent addresses

At the customer level, #1 has been thoroughly mitigated by NAT,
eliminating demand. Indeed, the lack of IPv6 NAT creates a negative
demand: folks used to NAT don't want to give it up.

Those people don't know any better, because they probably haven't used a NAT free Internet.

It isn't that simple. The fact that NAT exists and is seen as useful by many people (whether or not they are even aware of it) means services and applications need to be aware of it. You cannot simply wave a magic wand and say "there shall be no NAT". Even if there weren't NAT, folks interested in security would argue and/or insist on stateful firewalls.

Have you used a NAT free Internet?

Yes, actually.

So if more addresses was "thoroughly mitigated by NAT", when were these problems that NAT creates fixed?

http://www.cs.utk.edu/~moore/what-nats-break.html

It would seem the market has determined that the issues Keith had concerns with were less important than the advantages NAT provided. And Beta was better than VHS, but VHS won. I will admit that at times it feels a bit like we're trying to push Super Beta.

Regards,
-drc

22

> During early phase of free pool exhaustion, when you can't deliver
> more IPv4 addresses to your customers you lose the customer to a
> hosting provider who still has addresses left. So sorry. Those will be
> some nasty years. Unless you're Cogent, Level3 or one of the others
> sitting pretty on a /8. They'll be in phat city.

this is a very real and significant problem. a very small fraction of
the arin membership holds the vast majority of the address space. it
would be interesting to ask arin to give us the cdf of this.

Randy,

It would be nice if it was that simple. Those /8's arise from legacy
assignments that fall more or less directly under IANA without any
form of agreement in place that could allow policy change. Barring
government action, they're effectively the unrecoverable property of
those organizations. They can even act as mini-registries and auction
addresses off to the highest bidder if they're so inclined.

given that, the scenario you present is likely to be very real.

but what do we do about it?

Unless something brilliant arrives out of left field, the only thing
we can do is deploy and get customers to deploy IPv6 -before- IPv4
free pool exhaustion starts to hit. That's really not on track right
now.

Some things which might help get it back on track are:

1. End the insanity of having software prefer IPv6 if available (AAAA
records over A records). That's a commonly cited reason that folks who
tried IPv6 stopped using it. I might make some of my stuff available
via 6to4 but 6to4 is pretty meager so there's no way I'd consider it
when stacks will prefer trying to communicate with IPv6.

2. Figure out a PI solution for IPv6 capable of scaling to the
equivalent of hundreds of millions of routes in the core at a
per-route cost two orders of magnitude less than it is today. RRG is
working on this but there aren't enough people involved, they're not
focused on a solution that delivers that degree of scalability,
they're not in a hurry and AFAIK they're not well funded. This seems
self-defeating given how much money rides on a useful answer coming
out of the IETF.

3. Produce IPv6 NAT. Folks are used to NAT. They're comfortable with
the security they believe NAT provides. They might eventually switch
away from NAT if some desirable new application requires it but they
won't refactor their network security policies as a prerequisite to
deploying IPv6.

Have you used a NAT free Internet?

Mark,

I maintain a /23 in the swamp and have since '94. For the record, I
didn't even like NAT back when it was still called "circuit level
proxying."

I'd love to have an Internet where all firewalls were packet filters.
But that's not my call. That's the call of hundreds of thousands of
network security officers who have NAT written in stone at the core of
their security process. Tying NAT's abandonment to IPv6's deployment
won't change their minds but it will doom IPv6.

So if more addresses was "thoroughly mitigated by NAT", when were these
problems that NAT creates fixed?
http://www.cs.utk.edu/~moore/what-nats-break.html

Many of those never were meaningful problems and most of the rest have
been obsoleted by the changing reality of network security on the
Internet. Things like controlling the source port meant something once
upon a time, but they have no place in a modern security
infrastructure. That would be true with or without NAT.

The -real- problems with NAT can be summed up in two statements:

1. NAT makes it more difficult to engage in certain popular activities
that strictly speaking are against the TOS.

2. NAT makes logging and accountability more difficult.

Regards,
Bill Herrin

23

During early phase of free pool exhaustion, when you can't deliver
more IPv4 addresses to your customers you lose the customer to a
hosting provider who still has addresses left. So sorry. Those will be
some nasty years. Unless you're Cogent, Level3 or one of the others
sitting pretty on a /8. They'll be in phat city.

this is a very real and significant problem. a very small fraction of
the arin membership holds the vast majority of the address space. it
would be interesting to ask arin to give us the cdf of this.

It would be nice if it was that simple. Those /8's arise from legacy
assignments that fall more or less directly under IANA without any
form of agreement in place that could allow policy change. Barring
government action, they're effectively the unrecoverable property of
those organizations. They can even act as mini-registries and auction
addresses off to the highest bidder if they're so inclined.\

and this prevents producing a cdf exactly how?

randy

24

drc@virtualized.org (David Conrad) writes:

... You cannot simply wave a magic wand and say "there shall be no NAT". ...

actually, you can. see RFC 4966. don't be fooled by the title, it's not just
damning NAT-PT, since it justifies doing so by stating that NAT is damned.

(of course, waving a magic wand and saying something doesn't make it so.)

25

I think CAIDA already did some similar analysis:
http://www.caida.org/research/id-consumption/ipv4/concentration.xml

Is there additional data that would help?
/John

26

1. End the insanity of having software prefer IPv6 if available (AAAA
records over A records).

Insanity?

Using IPv6 by default can lead to suboptimal results, but there's really no alternative: even in the IETF people think I'm a few bits short of a /128 when I talk about running IPv6-only. And as long as you have both IPv4 and IPv6 connectivity and prefer IPv4, you're never going to see if IPv6 even works, let alone how well.

2. Figure out a PI solution for IPv6 capable of scaling to the
equivalent of hundreds of millions of routes in the core at a
per-route cost two orders of magnitude less than it is today.

Sure:

http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt

3. Produce IPv6 NAT.

Believe it or not, there are already products that do IPv6 NAT.

27

Mark,

>> As far as I can tell, IPv6 is at least theoretically capable of
>> offering exactly two things that IPv4 does not offer and can't easily
>> be made to offer:
>>
>> 1. More addresses.
>> 2. Provider independent addresses
>>
>> At the customer level, #1 has been thoroughly mitigated by NAT,
>> eliminating demand. Indeed, the lack of IPv6 NAT creates a negative
>> demand: folks used to NAT don't want to give it up.
>
> Those people don't know any better, because they probably haven't
> used a NAT free Internet.

It isn't that simple. The fact that NAT exists and is seen as useful
by many people (whether or not they are even aware of it) means
services and applications need to be aware of it.

This is a hidden cost of NAT. Why hack many applications to work around
a network layer problem ?

The best place to fix a problem is where it actually exists. The
problem NAT tries to solve, but doesn't solve very well (see the
earlier list), exists in the network layer. IPv6 fixes the network
layer problem that IPv4 has, and it fixes it better than NAT does. IPv6
isn't perfect, but nothing ever is.

You cannot simply
wave a magic wand and say "there shall be no NAT".

Of course you can't. If I had that wand I'd have already waved it years
ago!

I think there has to be a "compelling" reason to adopt something. I
think the thing that will compel people to move to IPv6 will be the
eventual and inevitable squeeze on IPv4 public addresses. At a certain
point I think people will ask themselves "why are we going to such
effort (and maybe expense) to get a few IPv4 public addresses when we
could move to IPv6 and immediately get millions for the same or less
effort and cost?" The fact that nearly most of their networking
infrastructure will likely to have been IPv6 enabled in the preceeding
years will help it be compelling.

(We got a new colour photocopier at work today - it's IPv6 capable.
None of us techs asked for it as a feature, and I don't think any of us
actually got a look at the datasheet for it before it was bought. The
first we knew of it supporting IPv6 was when the photocopier tech asked
us if we wanted it enabled. I suspect the photocopier tech didn't even
quite appreciate what he was asking. To him, it was probably just
another photocopier networking option that the customer might want
turned on.)

Even if there
weren't NAT, folks interested in security would argue and/or insist
on stateful firewalls.

Who said anything about getting rid of stateful firewalls? I didn't and
never have.

> Have you used a NAT free Internet?

Yes, actually.

> So if more addresses was "thoroughly mitigated by NAT", when were
> these problems that NAT creates fixed?
>
> http://www.cs.utk.edu/~moore/what-nats-break.html

It would seem the market has determined that the issues Keith had
concerns with were less important than the advantages NAT provided.

I don't think the market was aware of the hidden costs of NAT. I
wasn't in 1995 when I first learned of it, implemented it and
recommended it as a solution. I, my employers and my customers over the
years have since paid those hidden costs on a number of occasions,
which caused me to start questioning why it was "such a great solution"
when the limitations it imposes didn't exist in a NAT free Internet. I
was fortunate enough to experience a few years of NAT free Internet
before NAT came along.

Even today, you look at current technical network training materials,
when they describe NAT, very rarely do they list the draw backs.

I happen to be currently reading the quite well known book, "Diffusion
of Innovations". From what I've read the "market" doesn't seem to be all
that good at selecting the best solution (Heard of 100baseVG aka. 100VG
Anylan? Technically much better than 100BASE-T from what I remember,
but even the technical field of networking didn't choose the best
technical solution. For many years I've wondered why). The majority of
it are followers who base their opinions on what others within the
market/social system say. "Change Agents" introduce new innovations,
and "Opinion Leaders" influence whether and how that innovation is
diffused. I think the change agents were the NAT equipment vendors.
With the Internet being a relatively new thing in the mid 90s, when NAT
came along, the opinion leaders ended up just assuming that the change
agents/vendors, who commonly knew far more about the Internet, were
making good and trustworthy recommendations. Maybe even the change
agents/vendors thought they were too, at the time.

Regards,
Mark.

28

> > During early phase of free pool exhaustion, when you can't deliver
> > more IPv4 addresses to your customers you lose the customer to a
> > hosting provider who still has addresses left. So sorry. Those will be
> > some nasty years. Unless you're Cogent, Level3 or one of the others
> > sitting pretty on a /8. They'll be in phat city.
>
> this is a very real and significant problem. a very small fraction of
> the arin membership holds the vast majority of the address space. it
> would be interesting to ask arin to give us the cdf of this.

<snip>

I'd love to have an Internet where all firewalls were packet filters.
But that's not my call. That's the call of hundreds of thousands of
network security officers who have NAT written in stone at the core of
their security process. Tying NAT's abandonment to IPv6's deployment
won't change their minds but it will doom IPv6.

The value of network perimeterisation as a security measure, of which
NAT is a method, is being questioned significantly by network security
people. The obvious example of why it is being questioned is when the
CEO brings their laptop inside the "gooey" centre, bypassing the "hard
shell" corporate firewalling/NAT box, and infecting all the devices on
the corporate network with the malware they've caught from their home
broadband connection.

"The de-perimeterization solution Solution

While traditional security solutions like network boundary technology
will continue to have their roles, we must respond to their
limitations. In a fully de-perimeterized network, every component will
be independently secure, requiring systems and data protection on
multiple levels, using a mixture of

    * encryption
    * inherently-secure computer protocols
    * inherently-secure computer systems
    * data-level authentication"

http://www.opengroup.org/jericho/

Having found out about this project, I spoke to a friend of mine in the
local state government (around 10 000+ public servants) i.e. not a big
one, not a prominent one, and not likely to be a early adopter of
different IT security models. They're moving to this model in the very
near future, because they have to.

29

The value of network perimeterisation as a security measure, of which
NAT is a method, is being questioned significantly by network security
people.

Mark,

The discussion at hand is whether the absence of NAT creates a drag on
IPv6 deployment. and how much of a drag it creates. Your points about
the relative merits of NAT as a security mechanism are entirely
irrelevant to that discussion.

> 1. End the insanity of having software prefer IPv6 if available (AAAA
> records over A records).

Insanity?

Yes, Iljitsch, insanity.

Trying IPv6 first is asking folks to disable it on their PCs the
second or third time they can't get to a web site because the IPv6
path isn't working. Its also asking web site operators not to offer
IPv6 addresses in the first place so as not to inconvenience folks who
have Ipv6 turned on without a reliable connection.

That's counterproductive. We want people on both sides to turn it on
and leave it on.

We don't need every PC in the world to be a beta tester for our new
Internet. We do need them to turn it on.

Regards,
Bill

30

I am increasingly of the opinion that the insanity is not in the stub resolver API, but in the decision to deploy dual stack towards end users in the first place.

Deploying both IPv4 and IPv6 towards end systems means increased opex, increased support costs, and often reduced performance for users. As a bonus, it does nothing to reduce IPv4 resource consumption. In the absence of any IPv6-only content, it's hard to see what problem this solves. Perhaps this helps explain the lack of deployment.

However, if there was a reasonable translation mechanism available which allowed IPv6-only end systems to access IPv4-only content, I think the picture would look quite different. Connecting users with IPv6 only might represent a cost saving (since the addresses are easier to acquire, and easier to manage; there's greatly reduced need to engage in protracted justification exercises in order to give someone a block of addresses.)

If the translation mechanism was such that IPv4 content could be consumed, but IPv6 content could be reached more quickly/reliably, then a groundswell in translated IPv6-only end users would provide incentive for content providers to listen on IPv6 as well as IPv4.

The translation mechanism doesn't currently exist (although the document that deprecated NAT-PT suggested that it should be created). Designing a universally-general translation mechanism seems hard, and seems likely to suffer from many of the same problems as IPv4-IPv4 NAT; perhaps as an interim measure, however, for the millions of Internet users for whom the network mainly means 80/tcp, the mechanism doesn't have to be universally-general. Perhaps it just has to be good enough.

Perhaps the assignment of IPv4 addresses to end users could become a premium service available to those who need them, leaving cheaper, IPv6-only service for everybody else.

If there was significant price incentive for users to choose IPv6-only access over IPv4-only or dual stack, perhaps the translation mechanism could be a real, interim measure (as opposed to the kinds of interim measures that hang around smelling bad for 30 years).

Perhaps, perhaps. :slight_smile:

Joe

31

However, if there was a reasonable translation mechanism
available which allowed IPv6-only end systems to access
IPv4-only content, I think the picture would look quite
different.

Doesn't deploying a 6to4 relay in the content provider network, along
with IPv6 access to the content provider network, exactly meet this
requirement?

I agree that it is better if the mechanism can be installed in the
eyeball ISP's network, but the fact is that the majority of content
providers connect to the Internet via an ISP, so if there was a
concerted effort to get content-hosting ISPs to install this mechanism,
we would have solved much of this problem.

Designing a universally-general translation mechanism seems
hard, and seems likely to suffer from many of the same
problems as IPv4-IPv4 NAT; perhaps as an interim measure,
however, for the millions of Internet users for whom the
network mainly means 80/tcp, the mechanism doesn't have to be
universally-general. Perhaps it just has to be good enough.

Agreed. Good enough might be a bit more than port 80, i.e. some more
popular IM and P2P ports, but we already have all the pieces needed for
this type of ALG to run on a Linux or BSD system. It's just a matter of
someone putting together a good HowTo document which could be posted
here <http://www.getipv6.info>.

Perhaps the assignment of IPv4 addresses to end users could
become a premium service available to those who need them,
leaving cheaper, IPv6-only service for everybody else.

I'm quite sure that this WILL happen within a year or so. Lots of ISPs
have already gotten their IPv6 through the trial phase and already offer
IPv6 access service, or are about to offer it.

The difference between today, and 1995 when the Internet went
exponential, is that in 1995 there were lots and lots of people with
IPv4 networking experience, and IPv4 server experience. Out of that set
of people, the early adopters and pioneers naturally formed a critical
mass which created new ISPs and new Internet services. But today, we are
still struggling to get enough people up to speed on IPv6. A lot of IPv4
people have so little IPv6 knowledge that we continually see the "Three
Blind Men and an Elephant" syndrome. We have got to get beyond that
which is why I urge everybody on this list to check this ARIN page

Either use it to further your own education, or add some advice/resource
that will be of use to others. Every contribution of information, no
matter how small, is useful.

--Michael Dillon

32

No. An end system who only has IPv6 addresses has no way to access IPv4-only content, regardless of whether the IPv6 address is constructed within 2002::/16.

(and it's a bit of a stretch to imagine an end-system that has IPv4 close enough for a 6to4 prefix to be constructed, but far enough away for it not also to have an IPv4 address)

Joe

33

Oh, now that I actually *read* your text, you're talking about use of 6to4 in content providers, not end systems. Sorry for not noticing that when I replied just now :slight_smile:

6to4 (for content- or access-focussed networks) is surely a solution to the problem of "I have no good way to acquire IPv6 transit"; it's not a solution to the problem of deploying dual-stack across content-serving infrastructure, or the problem of there being near zero demand for IPv6 content, given that the number of existing IPv6-only clients is effectively zero.

Joe

34

> However, if there was a reasonable translation mechanism
> available which allowed IPv6-only end systems to access
> IPv4-only content, I think the picture would look quite
> different.

Doesn't deploying a 6to4 relay in the content provider network, along
with IPv6 access to the content provider network, exactly meet this
requirement?

Michael,

Not in any way, shape or form, no.

6to4 allows folks whose upstream provider is IPv4 only to connect
their IPv6 hosts to other IPv6 hosts via IPv6. It does exactly that
and nothing else.

If you run a web site and only have IPv6 access via 6to4, you SHOULD
NOT publish a AAAA record. 6to4 has very few gateways and they get
clogged at various times of the day. If you publish a AAAA record,
every user who has IPv6 will first try to connect to you via IPv6 and
experience a -long- delay.

> Perhaps the assignment of IPv4 addresses to end users could
> become a premium service available to those who need them,
> leaving cheaper, IPv6-only service for everybody else.

I'm quite sure that this WILL happen within a year or so. Lots of ISPs
have already gotten their IPv6 through the trial phase and already offer
IPv6 access service, or are about to offer it.

If you care to wager, I'll take some of that action. Without a
relatively transparent mechanism for IPv6-only hosts to access
IPv4-only sites this isn't going to happen. We don't have such a
mechanism built and won't have it deployed in 12 months.

Regards,
Bill Herrin

35

Universities have understood this for many years, with the termly influx
of infected student computers.

Tony.

36

If you run a web site and only have IPv6 access via 6to4, you
SHOULD NOT publish a AAAA record. 6to4 has very few gateways
and they get clogged at various times of the day. If you
publish a AAAA record, every user who has IPv6 will first try
to connect to you via IPv6 and experience a -long- delay.

This is precisely why someone else on the list suggested that the
content provider should run their own 6to4 relay and anounce 2002::/16
to their IPv6 peers. That way, the IPv6 packets take the direct IPv6
route to the content provider, and the IPv4 path is just a stub in the
content provider's network. Admittedly, if the IPv6 path itself has
issues due to poor peering, poor bandwidth, neglected routing, that will
rear its ugly head.

If you care to wager, I'll take some of that action. Without
a relatively transparent mechanism for IPv6-only hosts to
access IPv4-only sites this isn't going to happen. We don't
have such a mechanism built and won't have it deployed in 12 months.

What about these two?

Have you tried both of these yourself?

--Michael Dillon

37

jabley@ca.afilias.info (Joe Abley) wrote:

6to4 (for content- or access-focussed networks) is surely a solution
to the problem of "I have no good way to acquire IPv6 transit";

It solves another problem as well, like "I cannot go v6 to
my servers because my load balancing and packet filtering
black boxes don't do it yet".

Elmar.

38

I'm not sure how it solves that problem. 6to4 is not a translation mechanism -- it's a tunnelling mechanism. 6to4 does not provide any way for an IPv4-only host to talk to an IPv6-only host.

In order to make use of 6to4, surely servers and load balancers still need to support IPv6 -- they just get loaded with addresses covered by a 6to4 prefix rather than a prefix assigned by an RIR or an IPv6 transit provider.

Joe

39

> If you care to wager, I'll take some of that action. Without
> a relatively transparent mechanism for IPv6-only hosts to
> access IPv4-only sites this isn't going to happen. We don't
> have such a mechanism built and won't have it deployed in 12 months.

What about these two?
ARIN IPv6 Wiki - ARIN's Vault

Michael,

As mentioned, 6to4 doesn't do what you seem to think it does. Its not
a solution to the problem of IPv6 endpoints trying to talk to IPv4
endpoints.

ARIN IPv6 Wiki - ARIN's Vault

Looks interesting. There's some version 0.4 user-space software for
Linux which claims to do it and Cisco claims to do it in IOS 12.4
advanced enterprise.

Let me know how it works out for you when you try it in "many to one"
mode. That is, many IPv6 addresses behind 1 IPv4 address, what Cisco
still insists on calling port address translation.

Regards,
Bill Herrin

40

> It solves another problem as well, like "I cannot go v6 to
my servers
> because my load balancing and packet filtering black boxes
don't do it
> yet".

For this you need an ALG. This could be something like Squid on a box
with both v6 and v4 interfaces. Basically, we now have such fast servers
available with such high-speed networking, that anybody can build
whatever middle-box they need using Linux and BSD. Ten years or so ago
this was not nearly so easy to do which is why vendors stepped in with
their blackbox products. But today, the situation is different. If the
vendors are lagging behind, cut them out of the equation. Eventually new
vendors will step up to the plate and you may decide to replace your
home-built boxes with something commercial at around the time IPv6
traffic growth goes exponential.

Or maybe you will follow Google's example and stick with the commodity
hardware and tweak your software package into a well-opiled machine.

In order to make use of 6to4, surely servers and load
balancers still need to support IPv6 -- they just get loaded
with addresses covered by a 6to4 prefix rather than a prefix
assigned by an RIR or an IPv6 transit provider.

IPv6 transition has a lot more wrinkles than just choosing which one of
the IETF transition mechanisms is your favorite.

--Michael Dillon