Subject: Re: Last Call: <draft-weil-shared-transition-space-request-14.txt> (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

From: [email-masked] (Noel Chiappa)
Date: Mon, 13 Feb 2012 11:51:21 -0500 (EST)

> From: Arturo Servin <[email-masked]>

    >> Are you volunteering to buy everyone on earth a new CPE? If not, who
    >> do you suggest will?

    > I suggest the ISPs, they are charging for the service, right?

Lots of CPE is actually owned by the customers, not the ISPs. E.g. in our
house, both our cable modem and the router attached to it are ours.

(Not quite sure how CGN would work in such an ISP - I guess they'd assign
the customer's IP address, on our side of the cable modem, out of the CGN
block? 'traceroute' say our cable box has a 10. address on the far side,
even now.)

But, anyway, telling such ISPs 'go buy new CPE' just isn't an option.

    > Errors cost money. They decided not to invest in IPv6, now there is
    > time to pay.

Again, it's made cystal clear that the real goal of the opponents here is
to punish people for not adopting IPv6.

Don't you think this casts IPv6 in a really bad light - that the only way
to get people to adopt it is to force them into it, using whatever whips
and chains are available?

But I'll stop there, since we're not supposed to be getting de-railed into
IPv6.

	Noel

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Feb 2012 09:13:01 +1300

> house, both our cable modem and the router attached to it are ours.

Sure, that's very common, but these devices are consumer electronics and
will get gradually replaced by IPv6-supporting boxes as time goes on.
(That is not hand-waving, the generation of boxes with IPv6 support is
starting to appear.) Nobody, I think, is denying that there will be a long
period of coexistence as a result.

That is a separate question from this draft, which gives ISPs space for
*growing* their IPv4 customer base. I think that is what upsets people.

   Brian

---

From: Martin Rex <[email-masked]>
Date: Mon, 13 Feb 2012 21:46:01 +0100 (MET)

> *growing* their IPv4 customer base. I think that is what upsets people.

The problem of ISP not newly shipping CPE that is not IPv6 capable
needs to be addressed by regulatory power (legistation), rather than
by ignorance of the part of the IETF.

ISPs *growing* their IPv4 customer base is a natural side effect
whenever ISPs allow customers to use equipment that they already
have (and might have been using with a different ISP before).

The vast majority of customers does not know or care about not having IPv6,
because there is _very_ few equipment that is vitally dependent on IPv6,
vs. huge amounts of equiment that requires IPv4.  If I had a CPE that
supported IPv6 (mine is from early 2006 an IPv4-only), my concern would
be how to reliably switch IPv6 off, because of the unsolved security and
privacy problems that IPv6 brings along.

It was the IETFs very own decision to build IPv6 in a fashion that it is
not transparently backwards compatible with IPv4.  If the is anyone to
blame for the current situation, than it is the IETF, not the consumers
or the ISPs (except for those folks at ISPs who participated in the
development of IPv6).

-Martin

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 14 Feb 2012 06:51:41 +0900

Martin Rex wrote:

> needs to be addressed by regulatory power (legistation),

That's how OSI failed.

> rather than by ignorance of the part of the IETF.

So will be IPv6 by IETF as a regulatory power to prohibit
address space allocation.

					Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Tue, 14 Feb 2012 09:06:26 +1100

In message <[email-masked]>, Martin Rex writes
> have (and might have been using with a different ISP before).

You grow your IPv4 customer base by having new customers independent
of whether they are IPv6 customers as well.  I don't think there
is a customer that only wants to connect to IPv6 sites.

Having IPv6 doesn't even cut down on needing to supply IPv4 unless
you have bleeding edge IPv6 equipment.  People still need to connect
to IPv4 literals and that will, for a quite a while yet, mean
supplying a dual stack service.

NAT64 doesn't have a way to inform the CPE on the mapping needed.
It would be simple to do with DHCP but know one had written what
needs to be in the option.

Similarly 464XLAT doesn't provide a way for the CPE to find the
prefix.  Blindly performing 464XLAT has similar issues to blindly
performing 6to4.

DS-Lite only became a RFC in the second half of 2011.  It will take
some time for IPv6 equipment vendors to add support (hosts and
routers).

> _______________________________________________
> 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: Cameron Byrne <[email-masked]>
Date: Mon, 13 Feb 2012 14:12:53 -0800

On Mon, Feb 13, 2012 at 2:06 PM, Mark Andrews <[email-masked]> wrote:
>> > >     > From: Arturo Servin <[email-masked]>
>> > >
>> > >     >> Are you volunteering to buy everyone on earth a new CPE? If not, w
>> ho
>> > >     >> do you suggest will?
>> > >
>> > >     > I suggest the ISPs, they are charging for the service, right?
>> > >

464XLAT may indeed discover the PREF64 using
http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-05

Running code says 464XLAT works with IPv4 literals, IPv4 referrals,
and IPv4 socket APIs.

CB

---

From: Mark Andrews <[email-masked]>
Date: Tue, 14 Feb 2012 10:10:12 +1100

In message <CAD6AjGS1SQz9ns0epA+ysiwHO4EG=[email-masked]>
, Cameron Byrne writes:
> > In message <[email-masked]>, Martin Rex =
> writes
> > :
> >> Brian E Carpenter wrote:
> >> >
> >> > > =A0 =A0 > From: Arturo Servin <[email-masked]>
> >> > >
> >> > > =A0 =A0 >> Are you volunteering to buy everyone on earth a new CPE? =
> If not, w
> >> ho
> >> > > =A0 =A0 >> do you suggest will?
> >> > >
> >> > > =A0 =A0 > I suggest the ISPs, they are charging for the service, rig=
> ht?
> >> > >
> >> > > Lots of CPE is actually owned by the customers, not the ISPs. E.g. i=
> n our
> >> > Sure, that's very common, but these devices are consumer electronics a=
> nd
> >> > starting to appear.) Nobody, I think, is denying that there will be a =
> long
> >> > That is a separate question from this draft, which gives ISPs space fo=
> r
> >> > *growing* their IPv4 customer base. I think that is what upsets people=
> .
> >>
> >>
> > of whether they are IPv6 customers as well. =A0I don't think there
> > you have bleeding edge IPv6 equipment. =A0People still need to connect
> > prefix. =A0Blindly performing 464XLAT has similar issues to blindly
> > performing 6to4.
> >
> 

draft-ietf-behave-nat64-discovery-heuristic-05 really isn't a solution.

It doesn't say anything about choosing the A records such that there
is no abmiguity when look for the embedded address.

It doesn't have the exceptions which are part of DNS64.  This means
you can't use it reliably with dual stack internal and IPv6-only
external.

Below is the DNS64 configuration elements from named.

dns64 <netprefix> {
	break-dnssec <boolean>;
	clients { <address_match_element>; ... };
	exclude { <address_match_element>; ... };
	mapped { <address_match_element>; ... };
	recursive-only <boolean>;
	suffix <ipv6_address>;
};

While not all of them are required for IPv4 literals more than netprefix and
suffix are required which is all draft-ietf-behave-nat64-discovery-heuristic-05
delivers. 

> CB
> 
> > DS-Lite only became a RFC in the second half of 2011. =A0It will take
> >> The vast majority of customers does not know or care about not having IP=
> v6,
> >> vs. huge amounts of equiment that requires IPv4. =A0If I had a CPE that
> >> not transparently backwards compatible with IPv4. =A0If the is anyone to
> > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is=
> c.org

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Feb 2012 13:17:30 +1300

Martin Rex wrote:
...
>> or the ISPs (except for those folks at ISPs who participated in the

People say this from time to time, but it's a complete myth.

IPv4 provides no mechanism whatever for addresses greater than 32 bits.
Therefore, mathematically, there is no possible design for an IP with
bigger addresses that is transparently backwards compatible. We've known
that since at least 1992.

The design error was made in the late 1970s, when Louis Pouzin's advice
that catenet addresses should be variable length, with a format prefix,
was not taken during the design of IPv4.

(There were advocates of variable length addresses for IPng, but the
128 bit choice won on the grounds that it is enough for anything, which
32 bits clearly wasn't.)

   Brian (donning flameproof clothing)

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 13 Feb 2012 16:32:00 -0800

> People say this from time to time, but it's a complete myth.

well, not completely...

> that since at least 1992.

The path that the IETF followed ensured the maximum amount of incompatibility. 
Really a completely independent stack.

In contrast, the IETF could easily have chose a path toward minimizing 
incompatibility that would have allowed IPv6 to interwork with IPv4, within the 
limitations of the v4 address space.

That is, the IETF could begun IPv6 by assigning to it IPv4 addresses, reserving 
the remainder for latter definition and allocation.  It could have targeted 
simple, basic reformatting at the IP level to permit early IPv6 adoption to 
require a minimal gateway for interworking with the IPv4 world.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Feb 2012 13:38:41 +1300

On 2012-02-14 13:32, Dave CROCKER wrote:
> The path that the IETF followed ensured the maximum amount of
> incompatibility. Really a completely independent stack.
> 
> incompatibility that would have allowed IPv6 to interwork with IPv4,
> within the limitations of the v4 address space.
> 
> That is, the IETF could begun IPv6 by assigning to it IPv4 addresses,
> reserving the remainder for latter definition and allocation.  It could
> have targeted simple, basic reformatting at the IP level to permit early
> IPv6 adoption to require a minimal gateway for interworking with the
> IPv4 world.

There were very specific reasons why this was not done. And it doesn't
change the fact that an old-IP-only host cannot talk to a new-IP-only host
without a translator. It is that fact that causes our difficulties today.

    Brian

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 13 Feb 2012 16:42:37 -0800

On 2/13/2012 4:38 PM, Brian E Carpenter wrote:
> There were very specific reasons why this was not done.

Is there a useful citation that covers this strategic decision?

Given that that decision was an essential part of what caused a roughly 15 year 
delay, it would be helpful to have it documented.

> And it doesn't

The translator needed today is a complete gateway between two entirely 
incompatible protocols.  The one that I'm describing would have been a trivial 
re-formatter.

The development, deployment and interoperability differences between these is 
massive.

d/
-- 

   Dave Crocker

---

From: Randy Bush <[email-masked]>
Date: Mon, 13 Feb 2012 16:49:47 -0800

> that since at least 1992.

i guess you forget the discussion of variable length.  i hope we don't
have to rehash it here.

decisions were made.  some were quite bad.  v6 had some real zingers.
remember tla/nla?  no feature parity, such as dhcp (a war which has not
finished)?  it is almost as if it was designed to fail.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Feb 2012 16:09:22 +1300

> Is there a useful citation that covers this strategic decision?

You may recall that at the time, we were very concerned about the
pre-CIDR growth rate in BGP and there was, iirc, a generalised
aversion to anything that would import the entire IPv4 BGP4 table
into IPv6. I don't recall without a lot of archive grepping whether
this was explicit in the IPng decision or whether it came a bit later.

> 
> Given that that decision was an essential part of what caused a roughly
> 15 year delay, it would be helpful to have it documented.
> 
> 
>> And it doesn't
> incompatible protocols.  The one that I'm describing would have been a
> trivial re-formatter.
> 
> The development, deployment and interoperability differences between
> these is massive.

Honestly, having had an MSc student who benchmarked translation vs
application proxying vs native, I don't think so. The mechanics of
packet translation are trivial. The hard part is exactly the same as
with NAT44, caused by the shortage of IPv4 addresses and all the state
that goes with sharing the pool of transport ports for a single address.

> i guess you forget the discussion of variable length.  i hope we don't

I haven't forgotten. The worst row I ever had at an IETF meeting was
on that topic.

> finished)?  it is almost as if it was designed to fail.

DHCP for v4 was still wet behind the ears at that time, so this
wasn't as obvious then as it is now; there's a bit of 20/20 hindsight
here. But yes, we could of course have done better. Unfortunately my
time machine is broken.

    Brian

---

From: Martin Rex <[email-masked]>
Date: Tue, 14 Feb 2012 04:29:29 +0100 (MET)

Brian E Carpenter wrote:
>Dave CROCKER wrote:

With the result that you have two independent routing tables
describing the entire internet instead of just one.  I do not see
a size benefit, only the possibility for seperate code so that
during development of IPv6, the old IPv4 code that carries the larger part
of the Internet traffic is subject to less changes and therefore
less new bugs.

> that goes with sharing the pool of transport ports for a single address.

the difference in connection setup seems to huge, that folks
came up with the happy eyeballs proposal -- at an enormous cost
of change for apps that aren't multi-threaded or async multi-connect yet,
and extra load for the network and Server OS.

-Martin

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 14 Feb 2012 13:42:26 +0900

> without a translator. It is that fact that causes our difficulties today.

The fact is that an old-IP-only host can talk to a new-IP-only
host without a translator, if the new IP uses port numbers for
addressing/routing.

Though NAT is doing similar thing with translation, the
translation is not essential and can be reversed at end
systems using NAT information obtained through UPnP/PCP.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 14 Feb 2012 13:51:21 +0900

> will get gradually replaced by IPv6-supporting boxes as time goes on.

The problem is that IPv6 specification is still broken in
several ways to be not operational that existing boxes must
be replaced after the specification is fixed.

The more serious problem is that IPv6 people in IETF do
not admit IPv6 broken, which makes it impossible to fix
IPv6.

For an example, see my recent presentation at APOPS:

http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf

						Masataka Ohta

---

From: Roger Jørgensen <[email-masked]>
Date: Tue, 14 Feb 2012 09:24:16 +0100

> not admit IPv6 broken, which makes it impossible to fix

Make a draft, gather your "supporters" and take that discussion on
6man wg. I'm sure there are people open to consider any arguments on
what's wrong/or not.

Either way, we're way passed changing any of the important parts of
IPv6. That has to be IPv6 v2 WITH backward compability to IPv6 (as we
currently know it).

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 14 Feb 2012 18:10:51 +0900

> 6man wg. I'm sure there are people open to consider any arguments on

Now, I'm tired of speaking with those who decided that IPv6
must be perfect.

They have been warned about 10 years ago.

Nowadays, I'm telling operators how IPv6 is broken to be
not operational.

> IPv6. That has to be IPv6 v2 WITH backward compability to IPv6 (as we

A problem, maybe the worst operationally, of IPv6 is that IPv6
address is 16B, divine to remember, because of failed attempt
to have SLAAC.

As most operators are human, forget backward compatibility.

It is a lot easier for all the players to make IPv4 with NAT
end to end transparent.

					Masataka Ohta

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 14 Feb 2012 06:28:45 -0800

On 2/13/2012 7:09 PM, Brian E Carpenter wrote:
> into IPv6.

So, an initial requirement that simply said "we need a larger address space" 
became "we need a larger address space, a new routing architecture, and a slew 
of other new mechanisms".

For an exercise like creating IPv6, this is called second system syndrome.[1] 
If often accounts for massive delays.  15 years qualifies.

> application proxying vs native, I don't think so.

In theory, there is no difference between theory and practice...

By saying 'benchmarking' you appear to be referring to something like 
transformation time.  But notice that I gave a list that had nothing to do with 
cpu or i/o performance.

I fear that anyone who thinks that developing and operating a slightly enhanced 
router, such as I described, is the same as an application gateway probably does 
not understand the relative complexities or OA&M demands of either very well.

d/

[1][http://en.wikipedia.org/wiki/Second-system_effect
-- 

   Dave Crocker

---

From: Hector <[email-masked]>
Date: Tue, 14 Feb 2012 11:31:32 -0500

+1.  One point I would like to make regarding not being encourage to 
move to IPv6, was increased when the RIRs established the new IPv4 
request "prove your need" policies.  It immediately strengthen the 
notion that we must keep our existing IPv4 Class C network because if 
we let it go, we might not be able to get it back.  If this policy was 
in place, when we first migrated to the net in the 90s', I could 
easily see a problem of being denied or hassled enough to show why our 
then new business plan should be enough.

IOW, the RIR policies only strengthen existing companies to be very 
careful about migrating to IPv6, which in itself is inherently complex 
and still long time. IPv4 is still required for reachability during 
any migration period which seems to me will be a very very long time.

Of course, a HDTV industry lobby can force federal legislation to 
force the migration and new equipment to be IPv6 ready.  But TVs is a 
consumer market mostly. With IP, its commercial interest as well, and 
there will be resistance if there is a major cost involved to make the 
change - or at least some federal subsidy will be demanded if its 
going to be forced.

Ma Bell did it right when they changed from 7 digit local calls to 
requiring the 10 digits today for new local area codes.  And this was 
before customers were legally allowed to "own" their phone numbers for 
life, make it transferable. I'm sure the ideal forward thinker at Ma 
Bell would of said, "If we are changing it number to 10, why not get 
ready and make it 16 or 20?"  I think that would be been harder to do 
to make that change. 10 was good because it was already part of the 
people's mindset to make the non-local call.  Not the same analogy of 
course, its possible to add more digits to reach any end-phone.  Not 
possible with IPv4 unless a port is used which is the only possible 
extension to it.

Anyway, I agree with your points regarding the realities.  IPv6 is a 
costly endeavor, IPv4 with NATs is what people are using at all 
levels, consumers and business, simply because of cost and it allows 
people to continue to operate at all levels.

--
HLS

---

From: Greg Daley <[email-masked]>
Date: Tue, 14 Feb 2012 13:57:41 +1100

Hi Randy and Brian, 

I am sure the discussion of the discussion has been had before, but:
 
> > bigger addresses that is transparently backwards compatible. We've
> > known that since at least 1992.
> 
> i guess you forget the discussion of variable length.  i hope we don't have to
> rehash it here.
> 

I think that the compatibility issue is a key reason why adoption has been difficult.

Others are: 

No compelling IPv6 only features
-> From my reading several key features were directed at IPv6 only originally, like IPsec.  Successive works to provided all non-address IPv6 features in IPv4.
-> This in part is being addressed by helpful capabilities such as DHCPv6PD (although we could kill things entirely by back porting this to IPv4 ;-)

No local use benefit
-> Ostensibly deploying IPv6 only gets you (slightly) more work. 
-> compare this to transformative technologies such as Ethernet and IPv4, which had a better price point and enabled new local capabilities, which did not rely on neighbours adopting the same protocol.

Of course, these are short-sighted analysis.

Being able to uniquely address a peer device is a key benefit which we will see drive adoption once 103.X/8 is gone.

Another key benefit is local addressability which handles organizational merges/changes/private peering with ULAs (resolves the RFC-1918 collision problem).

For a few years I have been involved in an extremely pragmatic market where people want to see the money they will save by deploying a networking technology.  What would get my customers adopting would be a compelling TCO argument.

Sincerely,

Greg Daley 
Solutions Architect
Logicalis Australia Pty Ltd
[email-masked]
t +61 3 8532 4042
m +61 401 772 770