Subject: Re: IPv4 depletion makes CNN

From: [email-masked] (Noel Chiappa)
Date: Fri, 28 May 2010 11:42:16 -0400 (EDT)

> From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>

    > As native IPv6 connections are compared more and more with IPv4 NAT:ed
    > connections, I think this will go quicker than what people think. Note
    > that most of the difference between the protocols are features and
    > operational experiences the ISPs have. For the end user...how much
    > difference is there really in how Google or Facebook works?
    > ...
    > The end user though, will not notice when IPv6 is in use. 

Really? As far as I can tell, there is still no general, defined, method to
allow an IPv6 host with a v6-only address (i.e. not an IPv4 address embedded
in an IPv6 address) to talk to an IPv4-only host.

So, for all that content which is IPv4 only, how does an IPv6-only host get
to it? And if there is no 'it just works' mechanism to do so, people will
definitely notice if their machines convert to IPv6.

(I'm not talking about ISPs which use IPv6 internally, but don't expose it to
the user: that just like ISPs which use ATM internally, but don't expose it to
the user - yet another internal technology. I'm talking about the _users_
using IPv6 as their service interface. CGNAT doesn't count either, that's just
a differently engineered NAT - i.e. existing IPv4 technology.)

I mean, for example, people go to lots and lots of web sites, so saying 'oh,
as long as the big top sites support IPv6 access to content, that's all we
need' won't cut it. Yes, the top content providers get the bulk of the
traffic, but the tail (even for an individual) is very long.

So are people really going to want to convert to IPv6, unless there's some
'it just works' mechanism that lets them get to basically everyone in that
long tail? Without having _all_ the content v6-accessible, I reckon there's a
_substantial_ actual disincentive for users to go v6-only. (Think Metcalfe's
Law.)

And without a lot of users who are v6-only, what's the incentive for
_everyone_ to make content available in v6? (Close loop, feed back.)

	Noel

---

From: Jari Arkko <[email-masked]>
Date: Fri, 28 May 2010 19:19:11 +0300

Noel ,

> definitely notice if their machines convert to IPv6.

For your specific problem there is NAT64 - 
http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework and related 
drafts (soon in IETF last call). This is an improved version of the old 
NAT-PT mechanism.

FWIW, I have been behind some of this stuff for some time. It generally 
"just works", largely for the same definition of "just works" that we 
have for plain old IPv4 NATs, i.e., its far from a perfect solution but 
still workable. There are a few additional issues though that get 
exposed when you turn your network into an IPv6-only network. There's 
generally very little operational experience of running IPv6-only 
networks, so you'll be likely to run into at least some issues, such as 
specific apps that fail to use IPv6-capable APIs, network detection tool 
confusion from lack of IPv4 connectivity, DNS configuration issues, and 
so on. Given all this, the general advice is still to run both IPv4 and 
IPv6. Some networks are going to try the IPv6-only model even now, 
however, and I hope that in a couple of years we can be there with a 
larger number of users. But it is going to take work, mostly operational 
and implementation work, perhaps also some minor standard changes. One 
example of the type of standard changes is what we are currently doing 
in 6MAN, bringing RFC 5006-based DNS discovery to a standard from an 
experimental specification.

Jari

---

From: Mark Andrews <[email-masked]>
Date: Sat, 29 May 2010 02:36:16 +1000

In message <[email-masked]>, Noel Chiappa write
> in an IPv6 address) to talk to an IPv4-only host.

A IPv6 only host has to have access to a IPv4 address to talk to IPv4 only
hosts.  The simplest way to do this is to actually stay dual stack and use
DS-lite.  The other way is to go through a NAT64 which will tend to break
more applications as it need to change more on the data streams.

> definitely notice if their machines convert to IPv6.

The are product which do DS-lite today.  There are products that do NAT64
today.

As for people noticing.  They won't generally notice IPv6 being turned on.
They will notice IPv4 being turned off.  But one does not imply the other.

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Fri, 28 May 2010 22:39:01 +0300

Mark,

> DS-lite.

... the simplest (and recommended) way to do this is to use dual stack 
(full stop). DS-Lite is needed in some situations, primarily if you want 
to enable a v6-only ISP network and want to share one IPv4 address among 
multiple subscribers. But regular dual stack works very well, too, and 
is often deployed in the NATted-IPv4 and routed IPv6 configuration.

Jari

---

From: Mark Andrews <[email-masked]>
Date: Sat, 29 May 2010 10:04:37 +1000

> is often deployed in the NATted-IPv4 and routed IPv6 configuration.

The simplest thing for the medium term is full dual stack, but at
some point one is going to need to share IPv4 addresses between
different customers and DS-lite will break less things than NAT64.
Any box that supports tunnelling IPv4 in IPv6 can be the B4 component
with a little bit of tweaking.  DS-lite also keeps all the internal
IPv4 legacy boxes working.

By tweaking I mean configuring the DHCPv6 client to request the
appropriate option then calling out to configure the tunnel and
IPv4 routing table.

If one is trying to reduced the size of the IP stack on the client
(e.g. in a phone) then NAT64 may be a better alternative but for
home users it really isn't.

Mark

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 29 May 2010 10:08:12 +0900

Jari Arkko wrote:

> (full stop).

Do you mean IPv6 deployment has fully stopped?

> DS-Lite is needed in some situations,

> But regular dual stack works very well, too,

Thank you for demonstration of self-inconsistency.

A problem of IPv6, among many, is that it can't properly handle hosts
with multiple (IPv4 and IPv6 or IPv6 and IPv6) addresses, a.k.a.
multihomed hosts.

As the proper support for multihoming needs careful and fundamental
design at the IP, transport and application layers, latter tweaking
of DS or DS-light can not be useful.

							Masataka Ohta

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 30 May 2010 12:20:05 +0200

On 28 maj 2010, at 21.39, Jari Arkko wrote:

> ... the simplest (and recommended) way to do this is to use dual stack (full stop).

Unfortunately on applications layer I do not see enough operational experience/best practice/actual implementations that handle this in a very good way. The number of people I talk with that are nervous the cost for customer support will be higher(!) for dual stack situations than IPv6 only. I.e. that there are some arguments in favor of "one day simply give the client an IPv6 address only instead of an IPv4 address only".

That I get the question, that people think in these terms, I think is "interesting".

   Patrik

---

From: Jari Arkko <[email-masked]>
Date: Sun, 30 May 2010 15:43:48 +0300

Patrik,

Unfortunately on applications layer I do not see enough operational experience/best practice/actual implementations that handle this in a very good way.

There are issues, of course.

The number of people I talk with that are nervous the cost for customer support will be higher(!) for dual stack situations than IPv6 only. I.e. that there are some arguments in favor of "one day simply give the client an IPv6 address only instead of an IPv4 address only".

It is interesting, and naturally there will be a day when IPv6-only is
the preferred model. The day comes at different times for different
people. I'm already there myself.

However, we have to understand this situation not merely from the point
of view of whether there are issues with dual stack. There are. But
there are also issues with IPv6 only. My personal experience is that in
today's world, dual stack works better due to its greater operational
experience, software availability, and other reasons. Others may have
their own experiences and may draw different conclusions. What I would
like to advocate, though, is making decisions on network architecture
based on actual operational experience as opposed to assumptions (e.g.,
"just one address implies no problems").

Jari

---

From: Mark Andrews <[email-masked]>
Date: Mon, 31 May 2010 11:39:07 +1000

In message <[email-masked]>, =?iso-8859-1?Q?Pat
rik_F=E4ltstr=F6m?= writes:
> Unfortunately on applications layer I do not see enough operational 
> experience/best practice/actual implementations that handle this in a 
> very good way. The number of people I talk with that are nervous the 
> cost for customer support will be higher(!) for dual stack situations 
> than IPv6 only. I.e. that there are some arguments in favor of "one day 
> simply give the client an IPv6 address only instead of an IPv4 address 
> only".

And have any of those that say this tried:

	1) tried dual stack
	2) tried IPv6 only through NAT64 (NAT-PT)

with a sample of customers or are they just talking without any
reference points.  There is a lot of legacy equipment that requires
IPv4 for something (e.g Windows XP for DNS servers, NFS support,
...) so you can't go to IPv6 only on the local net.  Dual-stack in
one form or another will be with us for a long time on the local
net.

Runing dual stack internally without external IPv4 connectivity is
just as bad as running dual stack internally without external IPv6
connectivity.  You just don't want to go down that path.

We are years away from being able to run IPv6 only networks locally.
There is way too much software that is not IPv6 ready.

Yes.  I've tried to run IPv6 only.  Real IPv6 only, IPv4 completely
disabled in the OS.  It wasn't fun.

Mark

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 31 May 2010 07:10:08 +0200

On 31 maj 2010, at 03.39, Mark Andrews wrote:

> reference points.

I am spending lots of my time trying to get some _real_data_, but I do not have it yet.

I am though running dual stack with native IPv4 and native IPv6 in my home office, on all my servers, and have quite some experience on dual stack. And that was not as fun as I expected.

I.e. my data is based on dual stack be worse than I expected, and having people asking me "would native IPv6 only be better", or "what about native IPv6 with NAT64/DNS64".

And I have also read various papers people in IETF have written on how to handle the quite normal case with SMTP where MX records are in use (which have been far from complete), and then maybe IP6 or IPv4, and IPv6 or IPv4 for DNS transport, and quite often search paths in DNS as well... The number of DNS lookups needed explode exponentially, you get timeouts on application layer, applications show timeout boxes as if the mail server is not responding when in reality multiple seconds are used for DNS lookups.

It is messy with dual stack. Messier than what I think many people think. Including me (and I thought I had quite good overview of how it worked).

> connectivity.  You just don't want to go down that path.

I claim it is worse than having IPv6 only.

> disabled in the OS.  It wasn't fun.

So have I. For example at the IETF in Anaheim one morning when IPv4 connectivity was broken.

For me it worked better than dual stack, when accessing things that was reachable over IPv6. But that was with my OS (MacOSX) that have relatively good IPv6 support.

So there are good things and bad things with both dual stack and IPv6 only. And no, we do not have any data, but we do not have good documents on how to run dual stack either.

   Patrik

---

From: Mark Andrews <[email-masked]>
Date: Mon, 31 May 2010 16:03:04 +1000

In message <[email-masked]>, =?iso-8859-1?Q?Pat
rik_F=E4ltstr=F6m?= writes:
> I am though running dual stack with native IPv4 and native IPv6 in my 
> home office, on all my servers, and have quite some experience on dual 
> stack. And that was not as fun as I expected.
> 
> I.e. my data is based on dual stack be worse than I expected, and having 
> people asking me "would native IPv6 only be better", or "what about 
> native IPv6 with NAT64/DNS64".
> 
> And I have also read various papers people in IETF have written on how 
> to handle the quite normal case with SMTP where MX records are in use 
> (which have been far from complete), and then maybe IP6 or IPv4, and 
> IPv6 or IPv4 for DNS transport, and quite often search paths in DNS as 
> well... The number of DNS lookups needed explode exponentially, you get 
> timeouts on application layer, applications show timeout boxes as if the 
> mail server is not responding when in reality multiple seconds are used 
> for DNS lookups.

MTAs should never search.  MX records are absolute (explict or
implicit).

MSAs should only search to qualify unqualified domains in user
submitted data.

Just curious.  What percentage addresses in your address book are
not fully qualified.  I know I gave up on unqualified address back
in the early '90s.  Also are all the search element served locally
or do you need to do a remote lookup for them?

And it shouldn't be exponential growth.  Double maybe.

> It is messy with dual stack. Messier than what I think many people 
> think. Including me (and I thought I had quite good overview of how it 
> worked).
>
> For me it worked better than dual stack, when accessing things that was 
> reachable over IPv6. But that was with my OS (MacOSX) that have 
> relatively good IPv6 support.

And problems with its resolver trying to be too smart. :-)

> So there are good things and bad things with both dual stack and IPv6 
> only. And no, we do not have any data, but we do not have good documents 
> on how to run dual stack either.
> 
>    Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 31 May 2010 08:07:30 +0200

> MTAs should never search.  MX records are absolute (explict or

Agree.

> MSAs should only search to qualify unqualified domains in user

I agree with this as well.

These are just two details that have not been clear in some drafty-draft documents I have seen on "SMTP and IPv6".

> or do you need to do a remote lookup for them?

I really think we should "get rid of" the search path in resolvers.

> And it shouldn't be exponential growth.  Double maybe.

If you have search path, and then choice of IPv4 and IPv6 transport for DNS, and then A and AAAA to look up for the MTA you connect to, that at least multiplies the number of choices.

The best is double. Then in some cases it is worse.

It all works pretty well if the client have IPv4 and IPv6 _AND_ both works. But to some degree the functionality and user experience goes down if either of IPv4 or IPv6 have problems.

Anyway, the biggest problem is still, as you say, that we do not really know...

> And problems with its resolver trying to be too smart. :-)

You bet!

   Patrik

---

From: Mark Andrews <[email-masked]>
Date: Mon, 31 May 2010 16:25:01 +1000

In message <[email-masked]>, =?iso-8859-1?Q?Pat
rik_F=E4ltstr=F6m?= writes:
> These are just two details that have not been clear in some drafty-draft =
> documents I have seen on "SMTP and IPv6".
> 
> If you have search path, and then choice of IPv4 and IPv6 transport for =
> DNS, and then A and AAAA to look up for the MTA you connect to, that at =
> least multiplies the number of choices.
> 

You have qualification searchs.
MX (1 + search), A (1 + search),  AAAA (1 + search)

Delivery (A + AAAA) * MX targets (implict or explict).  If it's
more than that then the MTA is broken and is a security incident
waiting to happen.

> It all works pretty well if the client have IPv4 and IPv6 _AND_ both
> works. But to some degree the functionality and user experience goes
> down if either of IPv4 or IPv6 have problems.

SMTP is store and forward.  Your MSA should just accept and queue.
The actual delivery should be done in the background or do you have
debugging turned on where you are trying to see the delivery step?

> Anyway, the biggest problem is still, as you say, that we do not really =
> know...
> 
> >> For me it worked better than dual stack, when accessing things that =
> was

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 31 May 2010 16:02:48 +0900

paf wrote:

> It all works pretty well if the client have IPv4 and IPv6
> _AND_ both works. But to some degree the functionality and
> user experience goes down if either of IPv4 or IPv6 have
> problems.

Same is true for a host with two IPv4 addresses and either of
the IPv4 addresses have problems.

Same is true for a host with two IPv6 addresses and either of
the IPv6 addresses have problems.

The problem can be solved by carefully designing connection
establishment protocols to support multiple addresses of a
host, which means no solution exists at the connectionless
layer of IP.

Modified TCP, which send multiple SYN to several addresses
of a peer helps a lot to reduce timeout.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 01 Jun 2010 06:45:04 +0900

> I am pretty sure we can fix the problem if we are prepared to adapt
> the stack somewhat.

FYI, modified socket API and TCP with multiple IPv4 and/or IPv6
(optionally with ID/locator separation) addresses was designed
and implemented several years ago.

It's not very hard unless you desperately try to solve the problem
at the connectionless IP layer.

But, I see no point to insist on IPv6 with a lot of wrong design
choices.

> The alternative is to do nothing and let various people hack the stack
> up completely with meat axes and then we will be working round the
> consequences for decades.

The alternative is to live with IPv4 with port restriction, which
is a lot more realistic because we can continue to use the
current backbone.

> But really, the challenge is that carrier grade NAT works just fine
> for the ISPs who have the decision making power here.

While legacy NAT is a form of port restricted IP, lack of end to
end transparency is still a problem.

						Masataka Ohta