Subject: [Int-area] 240/4

From: Eliot Lear <[email-masked]>
Date: Wed, 05 Dec 2007 16:27:27 -0800

Thanks for your comments about 240/4 at the int-area.

After the int-area meeting I had a chance to sit down with Dave Thaler.

Dave's basic concern is that if we say now that we don't want to decide
a use for 240/4 6to4 and other code cannot actually be modified because
it behaves differently based on whether address space is public or private.

Another concern Dave raised was the difference between "controlled" and
"uncontrolled" environments.  In an uncontrolled environment one can
never be sure as to whether or not all devices have been modified to
allow for the new range.

Finally, a platform has a choice.  It can do one of the following:

    * Nothing
    * Make the space a compile time option
    * Make the space a configuration option
    * Just turn it on

Dave is of the opinion that doing the latter (or having default enabled
for the middle two) is akin to inviting the sorts of security concerns
that have been raised about v6 deployment.

Dave can correct me if I've gotten this wrong.

I am less concerned about security considerations in this particular
case, since devices could send packets with 240/4 sources or
destinations NOW.  Also, if we are to make this address space usable at
all, ever, we need to get beyond these concerns.

Also, MANY devices and stacks do not use mechanisms like 6to4 that
distinguish between RFC 1918 space and public space.  I believe those
devices should make their changes today.

Alain Durand raised concerns that devoting resources to making 240/4
available, while others at the same time said they needed the space now
for private purposes in a controlled environment.  I would like to
re-iterate what I said in the meeting, speaking for myself: there is no
Plan B.  We need to go to IPv6.  The only question for me is how do we
transition in an orderly and responsible fashion?

For the time being I would like to continue the discussions on how to
proceed and would invite interested parties to help.

Eliot

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 Dec 2007 18:10:13 -0800

> that have been raised about v6 deployment.

Can anyone point me to the RFC that states that IP stacks are supposed  
to be unable to use this space? This is quickly deteriorating into  
silliness if we need positive proof that this space is useful and  
secure before vendors are willing to remove obstacles against its use  
that, in my opinion, were never supposed to be there in the first place.

Having said that, it looks like telling people to remove the blocks  
and then think about a use for this space is probably not going to be  
a workable way forward. For the purposes of 6to4 and possibly others,  
it's important to know whether this will be private or public space.  
We know it probably can't be "real" public space because there will  
always be boxes that will filter it, but there's still a difference  
between public-with-practical-limitations and private-by-design. In  
reality, it's probably going to be space for some very specific  
purpose that doesn't easily fit into our public/private dichotomy.

> destinations NOW.

Right. Or any other source or destination, for that matter. How would  
receiving a 240/4 packet be worse than any other packet?

> transition in an orderly and responsible fashion?

In my opinion, the 240/4 and IPv6 issues are mostly orthogonal. They  
only come together in as far as that keeping 7% of the IPv4 address  
space "reserved" and then running out is very bad PR. The 240/4 block  
won't be useful for regular applications and even if it were,  
increasing the pool of free IPv4 addresses by 25% won't make the IPv4  
depletion issue go away, it just postpones the inevitable. A little.

---

From: Bob Hinden <[email-masked]>
Date: Sat, 8 Dec 2007 12:25:40 -0800

Eliot,

> I would like to

If there is no "Plan B", then would be putting all of our resources  
behind "Plan A".  To quote Scott McNeally, "all the wood behind one  
arrow".

If support for 240/4 requires IPv4 code changes then we shouldn't do it.

The only scenario that makes sense to me to use 240/4 as non-reserved  
address space is if it's use can help move us to IPv6 (e.g., Plan A).

Bob

---

From: Eliot Lear <[email-masked]>
Date: Mon, 10 Dec 2007 12:31:18 +0100

> behind "Plan A".  To quote Scott McNeally, "all the wood behind one

I view this proposal as assisting Plan A.  There are organizations that
exist who if they began their "transition" today wouldn't finish well
into 2015, and there are many structural reasons for this, not the least
of which has to do with compliance standards, complex software systems,
etc.
> If support for 240/4 requires IPv4 code changes then we shouldn't do it.

We are talking in most cases about a very small amount of code REMOVAL. 
As Alain rightly pointed out, you still need to system test, but this is
several orders of magnitude below the effort needed to implement IPv6.

Eliot

---

From: Dave Thaler <[email-masked]>
Date: Mon, 10 Dec 2007 08:31:36 -0800

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]]
> Sent: Wednesday, December 05, 2007 6:10 PM
> To: Eliot Lear
> Cc: Internet Area
> Subject: Re: [Int-area] 240/4
>
> to be unable to use this space?

There's no RFC that defines how to use it.  That is, it's neither unicast nor multicast nor broadcast.

> This is quickly deteriorating into

For example, if your firewall software were somehow incapable of having filter rules for the 240/4 space where it could for other addresses, that would be a clear security hole.  Any time you have a business-critical operational tool (whether IDS, firewall, traffic engineering, or whatever else) that would refuse to accept configuration for such an address, receiving 240/4 would clearly be worse than for any other packet.

-Dave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 10 Dec 2007 21:25:11 +0100

> behind "Plan A".

I'd say that "Plan A" would be the continued operation of the  
internet. I think most of us agree that this involves a move to IPv6  
at some point, but I'm afraid the lack of a "Plan B" doesn't  
automatically spell out the nature of "Plan A".

> If support for 240/4 requires IPv4 code changes then we shouldn't do  

(Most of) the vendors set a very bad precedent by making this address  
space unusable because they couldn't find a documented intended use.  
It's important to reverse this as much as possible by saying that was  
the wrong thing to do lest we end up with IPv6 code that won't accept  
anything outside 2000::/3.

Maybe at some point someone will find a use for 240/4, but I wouldn't  
count on that.

> The only scenario that makes sense to me to use 240/4 as non- 
> reserved address space is if it's use can help move us to IPv6  
> (e.g., Plan A).

By that logic, shouldn't we stop all IPv4-related work?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 10 Dec 2007 21:29:53 +0100

> unicast nor multicast nor broadcast.

We know what broadcast and multicast are, and class E space (with the  
exception of 255.255.255.255/32) isn't that. So it must be unicast  
space.

>> How would

> For example, if your firewall software were somehow incapable of  
> having filter rules for the 240/4 space where it could for other  
> addresses, that would be a clear security hole.  Any time you have a  
> business-critical operational tool (whether IDS, firewall, traffic  
> engineering, or whatever else) that would refuse to accept  
> configuration for such an address, receiving 240/4 would clearly be  
> worse than for any other packet.

How could anyone build a security device that is incapable of  
filtering out packets that use 1/16th of the address space?

And obviously if a host is updated to work with 240/4 it would also be  
updated to apply normal filters to this space if this wasn't possible  
before.

---

From: Dave Thaler <[email-masked]>
Date: Mon, 10 Dec 2007 12:40:12 -0800

[...]
> filtering out packets that use 1/16th of the address space?
[...]

You missed the point.  If some software won't accept class E addresses in its configuration, it's a problem.  (For example a security device that just drops all 240/4 without being configurable to allow port-based filters or SPI or whatever, is just as bad since you can't use 240/4 for anything useful.)

The point is that 240/4 is simply not likely to be safe for general-purpose environments, only for controlled environments.

-Dave

---

From: Bob Hinden <[email-masked]>
Date: Mon, 10 Dec 2007 14:48:10 -0800

Iljitsch,

> (Most of) the vendors set a very bad precedent by making this  
> address space unusable because they couldn't find a documented  
> intended use. It's important to reverse this as much as possible by  
> saying that was the wrong thing to do lest we end up with IPv6 code  
> that won't accept anything outside 2000::/3.

I think the IPv6 specs are very clear on the unicast and non-unicast  
parts of the address space and include specific instructions to this  
effect.  So I think the scenario you cite is unlikely.

Unfortunately, even with CIDR this wasn't made clear with IPv4.  The  
Class E (aka 240/4) space wasn't ever defined.  The biggest issue I  
see with 240/4 we don't know for sure what works and what doesn't.   
It's hard to make a decision without that data.

> Maybe at some point someone will find a use for 240/4, but I  
> wouldn't count on that.
>

Yes.

Bob

---

From: Tony Li <[email-masked]>
Date: Mon, 10 Dec 2007 15:54:25 -0800

>> By that logic, shouldn't we stop all IPv4-related work?

Sorry, but for the rest of us who are trying to keep the airplane in  
the air, that's simply not a viable game plan.

Maintenance and features will need to continue, as fast as we can  
continue to pump them out.  [In some cases, it can clearly be argued  
that we're going faster than our capabilities.  So stipulated.  ;-)]

Tony

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 10 Dec 2007 16:36:07 -0800

Tony, 

> From: Tony Li [mailto:[email-masked]] 
> Sent: Monday, December 10, 2007 3:54 PM
> To: [email-masked]
> Cc: Internet Area

I want to keep the airplane in the air too, but my
preference is to move as soon as possible to IPv6
endpoint identifiers.

Fred
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Tue, 11 Dec 2007 02:46:46 +0100

Dave,
> You missed the point.  If some software won't accept class E addresses in its configuration, it's a problem.
>   

It's a problem, but it's not a security problem.   I think you are
referring to some of the security problems that folks have run into with
early IPv6 implementations and deployments.  Here the situation is quite
different.  We have a defined behavior (drop).  It's conceivable that
someone left 240/4 off the bogon list in one place and not another, but
again, in this case in particular the problem is sure to have made
itself known already, because hackers would have made use of the space,
if nobody else.

Eliot

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 11 Dec 2007 16:47:03 +0100

>> By that logic, shouldn't we stop all IPv4-related work?

That was a good question to ask indeed ;-)

A different topic than this thread , but a good one to ask, so I changed 
the subject line.

I understand the need to fix IPv4 when there is a need to fix a bug or 
an existing feature in a deployed protocol, but I don't understand why 
the IETF is not cutting new proposed work items that intend to provide 
new features to IPv4.

This uses important IETF CPU cycles and energy that we cannot afford to 
pay as a community. One cannot fight two wars at once, and the one we 
need to win right now is "IPv6 deployment".

Thierry

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 11 Dec 2007 07:51:49 -0800

Thierry, 

> From: Thierry Ernst [mailto:[email-masked]] 
> Sent: Tuesday, December 11, 2007 7:47 AM
> To: [email-masked]
> Cc: Internet Area
> Subject: [Int-area] Why the IETF is still working on 
> providing new featuresto IPv4 ?
> 
> Bob Hinden wrote:
> > Iljitsch,

> need to win right now is "IPv6 deployment".

I think that depends on what you mean by "IPv6 deployment".
IMHO, IPv6 deployment as endpoint identifiers is a MUST but
disruption of the IPv4 Internet is a SHOULD NOT.

Fred

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 11 Dec 2007 17:03:44 +0100

> disruption of the IPv4 Internet is a SHOULD NOT.

Agreed that IPv4 must not be disrupted.

What I meant to say is really all the work items for providing new 
features to IPv4. Example in the IPv4 mobility area.

Thierry

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 11 Dec 2007 08:12:16 -0800

> Agreed that IPv4 must not be disrupted.

OK.

> features to IPv4. Example in the IPv4 mobility area.

Clearly, I disagree. IMHO, IPv6 as endpoint identifiers
and IPv4 in-the-network is the right fit for growing
the Internet; see for example the RRG work.

Fred

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Dec 2007 08:42:35 -0800

> the Internet; see for example the RRG work.

See it indeed.

See the open questions list. See what open questions aren't there.

See which open questions are classic distributed-systems show-stoppers.
See which missing open questions are too.

Then decide whether "right fit" is a conclusion.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 11 Dec 2007 08:49:14 -0800

Joe, 

> From: Joe Touch [mailto:[email-masked]] 
> Sent: Tuesday, December 11, 2007 8:43 AM
> To: Templin, Fred L
> Cc: Thierry Ernst; Internet Area
> Subject: Re: [Int-area] Why the IETF is still working on 
> providing newfeaturesto IPv4 ?
> 
> 
> 
> Templin, Fred L wrote:

You are good at twisting words, but see the "IMHO" and see
the "for example" portions of my message before diverting
the discussion as a platform for tangential commentary. 

Fred

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Dec 2007 08:55:48 -0800

> the discussion as a platform for tangential commentary. 

Fred,

It was you who diverted the discussion with your own tangential
commentary; mine simply adds an additional, albeit different, viewpoint.

I agree that we don't need to discuss it here; if that's the case, it
need not have been brought up in this context or forum.

I encourage others to check out the work and participate in further
commentary on the rrg mailing list, not here, FWIW.

Joe

---

From: Bob Hinden <[email-masked]>
Date: Tue, 11 Dec 2007 10:21:05 -0800

Tony,

> Sorry, but for the rest of us who are trying to keep the airplane  
> in the air, that's simply not a viable game plan.
>
> continue to pump them out.

Maintenance and bug fixing should, of course, continue.  A lot a what  
the IETF is doing is new features and at some point that needs to  
stop.  All the product transitions I have been involved in require at  
some point stopping working on the old one.  It usually painful at  
the time, but is necessary.

>  [In some cases, it can clearly be argued that we're going faster  
> than our capabilities.  So stipulated.  ;-)]

That may have been happing for a long time....   :-)

Bob

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 11 Dec 2007 14:06:01 -0500

On Dec 11, 2007, at 10:47 AM, Thierry Ernst wrote:
> I understand the need to fix IPv4 when there is a need to fix a bug  
> or an existing feature in a deployed protocol, but I don't  
> understand why the IETF is not cutting new proposed work items that  
> intend to provide new features to IPv4.
>
> This uses important IETF CPU cycles and energy that we cannot  
> afford to pay as a community. One cannot fight two wars at once,  
> and the one we need to win right now is "IPv6 deployment".

I respectfully disagree...

IMO, our one "war" should be the continued growth and operational  
stability of the Internet.  The deployment of IPv4, IPv6 or other  
protocols may be means to that end, but they aren't ends in themselves.

We have concentrated a lot of effort on supporting IPv6 deployment  
and should continue to do so, because we believe it is necessary to  
sustain the growth of the Internet through the next decade.

However, there is no reason to believe that current IPv4-only sites  
will magically transform into IPv6-only sites any time in the near  
future, especially given the fact that it still isn't practical for  
an IPv6-only node (or a dual stack node with no IPv4 addresses  
configured) to connect to the Internet and access many common  
Internet sites and services.  So, we _also_ need to do the work  
necessary to keep IPv4 stable and fully operational.

Please note that I'm not commenting on the 240/4 proposal, per se.  I  
don't see any significant value in declaring 240/4 to be _yet  
another_ private IPv4 address space.   Without a more complete  
understanding of how widely deployed stacks and popular products will  
treat addresses in the 240/4 range, I don't know whether it would be  
a good idea to attempt to use these addresses as global IPv4 unicast  
addresses either.  Perhaps a survey of existing implementations is in  
order?

Margaret

---

From: Tony Li <[email-masked]>
Date: Tue, 11 Dec 2007 12:00:20 -0800

On Dec 11, 2007, at 10:21 AM, Bob Hinden wrote:

> Maintenance and bug fixing should, of course, continue.  A lot a  
> what the IETF is doing is new features and at some point that needs  
> to stop.  All the product transitions I have been involved in  
> require at some point stopping working on the old one.  It usually  
> painful at the time, but is necessary.

Feature development is not under the control of the IETF.  It is  
driven by end users and network operators who have money to spend.

As always, the IETF is not in a position to dictate the future of the  
Internet.  It can build consensus, to be sure, but when the IETF  
decides to part with that consensus, it becomes irrelevant.  Further,  
the consensus is weighted by revenue, not by sheer numbers.  Today,  
revenue is highly slanted towards IPv4 and shows no signs of  
shifting.  If the IETF chooses to not participate in that process, it  
can easily be shifted to the ITU.

Regards,
Tony

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 11 Dec 2007 15:20:07 -0500

I think the answer, to a significant degree, depends upon exactly what
you mean by "IPv4 related work."
For example, the ForCES work may or may not be useful.  It certainly
needs to work with and over IPv6.  But if we did not make sure it worked
with and over IPv4, then no one would use it, as a router that doesn't
handle IPv4 is not acceptable.

Similarly, if SIP were to refuse to carry IPv4 addresses in its headers,
that would be severely counter-productive.

Even the RRG work is taking the view that any proposed new architecture
has to provide value to and connectivity with folks who have IPv4, if it
is going to be adopted.

Even the plenaries last week noticed that a plan based on co-existence
makes a lot more sense than an assumption of transition.  IPv4 is going
to be used for a LONG time.  And it will be the bulk of the usage for
quite a while.  Pretending otherwise is just not effective.

Yours,
Joel M. Halpern

Thierry Ernst wrote:
> Bob Hinden wrote:
>> Iljitsch,
>>>> The only scenario that makes sense to me to use 240/4 as
>>>> non-reserved address space is if it's use can help move us to IPv6
>>>> (e.g., Plan A).
>>>
> ------------------------------------------------------------------------
>

---

From: David Meyer <[email-masked]>
Date: Tue, 11 Dec 2007 12:40:00 -0800

On Tue, Dec 11, 2007 at 12:00:20PM -0800, Tony Li wrote:
>> Maintenance and bug fixing should, of course, continue.  A lot a what the 
>> IETF is doing is new features and at some point that needs to stop.  All 
>> the product transitions I have been involved in require at some point 
>> stopping working on the old one.  It usually painful at the time, but is 
>> necessary.
>
>
> Feature development is not under the control of the IETF.  It is driven by 
> end users and network operators who have money to spend.
>
> Internet.  It can build consensus, to be sure, but when the IETF decides to 
> part with that consensus, it becomes irrelevant.  Further, the consensus is 
> weighted by revenue, not by sheer numbers.  Today, revenue is highly 
> slanted towards IPv4 and shows no signs of shifting.  If the IETF chooses 
> to not participate in that process, it can easily be shifted to the ITU.

	Nicely said.

	Dave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 Dec 2007 00:20:46 +0100

> handle IPv4 is not acceptable.

Right, "first do no harm".

But under a "no new IPv4 work" doctrine, certainly all NAT traversal  
work would be out?

> has to provide value to and connectivity with folks who have IPv4,  

"Has"? If we stumble upon the perfect solution that works with IPv6  
but not with IPv4 I don't think that solution will be ignored. But on  
the other hand, I don't think everyone will call it a day and go home  
at that point, either.

> quite a while.  Pretending otherwise is just not effective.

If that happens because people can keep running IPv4 without trouble  
for years to come, I have no problem with that. But I wouldn't want to  
accept this prediction as a design constraint.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 12 Dec 2007 05:48:29 +0100

Iljitsch,

> the other hand, I don't think everyone will call it a day and go home

I think the key issue the RRG has to look at is incremental
deployability.  Right now that means supporting IPv4.  Some years from
now it might well not.

Eliot

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 12 Dec 2007 16:46:17 +0100

Thierry Ernst wrote:
>>> non-reserved
>>> A different topic than this thread , but a good one to ask, so I 
>>> changed the subject line.
>>>

I think you meant MIP4 WG.

I wanted to say that while I'm happy to see more and more IPv6 addresses 
allocated and - right this evening - my home being invaded by 2^64 
addresses by my provider, I also think many if not all new paradigm 
applications aren't IPv6 but IPv4: facebook, itunes, gps, skype, fon, 
second life, you name it.

In this respect I think IPv4 Internet is becoming more and more pervasive.

I have yet to see a new widespread application (run on small numerous 
devices, embedded in the physical nature - "sand") that runs IPv6 and 
not IPv4.

That said, I'm happy to work on both IPv4 and IPv6 extensions, at IETF.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 Dec 2007 17:17:30 +0100

On 12 dec 2007, at 16:46, Alexandru Petrescu wrote:

> I wanted to say that while I'm happy to see more and more IPv6  
> addresses allocated and - right this evening - my home being invaded  
> by 2^64 addresses by my provider, I also think many if not all new  
> paradigm applications aren't IPv6 but IPv4: facebook, itunes, gps,  
> skype, fon, second life, you name it.

Small datapoint: iTunes supports IPv6 on both Mac and Windows and has  
for a number of years. I don't believe any Apple hosted stuff, such as  
the iTunes Store, is available over IPv6, though.

Iljitsch

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Dec 2007 08:24:31 -0800

Here's a good overall datapoint:
http://utility.nokia.net/~lars/meter/ipv6.html

Lars and I talked originally about a 'doomsday clock'-like metric, that
shows IPv6 uptake via tracking Fortune-500 and similar commercial sites.
This is the current result... not very encouraging, IMO.

Joe

---

From: "Pars Mutaf" <[email-masked]>
Date: Wed, 12 Dec 2007 18:25:08 +0100

With all due respect, I'm questioning this result ;-)
The client/server paradigm which, at least to me, does not really
require IPv6.

In my opinion the real dooms day metric is "how far we are from
the IP addressable cell phone", which is probably not measurable :-/

Millions of cell phones will receive incoming calls to their fixed IP
address. This is only possible with IPv6. But if the IETF has not
yet decided that IP-layer mobility is THE mobility solution, then
there is a problem.

Regards,
pars

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Dec 2007 09:35:50 -0800

> The client/server paradigm which, at least to me, does not really

The charts are intended to show the uptake of IPv6 commercially. Web
servers seem a reasonable way to measure that, at least initially.

> the IP addressable cell phone", which is probably not measurable :-/

Nor would an ATM addressable cellphone be, unless they talk to something
else using IPv6. Using IPv6 internally is irrelevant.

I would be surprised if IPv6 made it into cellphones and major companies
failed to upgrade their web servers to be surf-able from those phones.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 12 Dec 2007 09:42:23 -0800

Joe, 

If you are skeptical of IPv6 and you are also skeptical
of new architectures like the ones being discussed in
RRG, what would you have us do?

Fred

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Dec 2007 10:00:53 -0800

I couple of years ago, I did a study of what services a cell phone service 
provider could deploy on IPv6 that couldn't be deployed on IPv4. I was 
trying to get a good business case for persuading Docomo to do an early 
deployment of IPv6. The answer, to my suprise, was: nothing.

I also don't buy the argument: "When the RIRs stop giving out IPv4 addresses 
in 2 years, then everybody will *finally* start to deploy IPv6". What will 
happen is that someone will set up a Web site where globally routable IPv4 
addresses are auctioned. The price of a globally routable IPv4 address will 
go from zero to market driven. In other words, a market will develop in 
globally routable IPv4 addresses. If and when the incremental cost of 
deploying an IPv6 address exceeds the market price of a globally routable 
IPv4 address by a sufficient amount (maybe 5x, maybe 10x, whatever amount 
matches the disutility to the service provider of having to deploy IPv6), 
then IPv6 may get deployed.

For IPv6 to be widely deployed based on market forces, the economic 
advantage to the service provider must be sufficiently attractive to 
overcome the large sunk cost of the current IPv4 network. IPv6 deployment is 
a good example of how large sunk costs in infrastructure essentially 
throttle the deployment of a new technology, so that it becomes cheaper to 
continue developing the old technology. Another example (actually far more 
important to the future of the planet in general) is petroleum powered 
transport which is one reason why hybrid drivetrains are having and will 
continue to have more success than hydrogen.

Nonmarket forces, such as government mandates, are a different matter. They 
could possibly force deployment (and similarly and more importantly for 
nonpetrolum powered transport).

                jak

----- Original Message ----- 
From: "Joe Touch" <[email-masked]>
To: "Pars Mutaf" <[email-masked]>
Cc: "Templin, Fred L" <[email-masked]>; "Internet Area" 
<[email-masked]>
Sent: Wednesday, December 12, 2007 9:35 AM
Subject: Re: [Int-area] Why the IETF is still working on providing 
newfeaturesto IPv4 ?

Joe

>>> the iTunes Store, is available over IPv6, though.

--------------------------------------------------------------------------------

---

From: "Pars Mutaf" <[email-masked]>
Date: Wed, 12 Dec 2007 19:15:12 +0100

Thanks. What I mean is that IP-layer mobility is or has been a
MAJOR motivation for IPv6. But I don't see a CLEAR statement
that IETF mobility solution is IP-layer mobility. I see the same
mobility solutions replicated by SIP (including fast handover), for
example.

This means that either the IETF is doing "research" (!!!), or it is
standardizing faster than research, both of which are seriously
harmful to the community.  Really!

Given that IP mobility is a MAJOR motivation for IPv6
(to the point that you cannot achieve it without IPv6), one would
expect that IETF is supporting this solution and not another
one. This is not the my impression.

Compared to that, dividing the efforts into IPv4 and IPv6 is a
minor concern IMHO.

Regards,
pars

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Dec 2007 09:51:56 -0800

> RRG, what would you have us do?

I'm not skeptical of IPv6; I just wanted to point out a resource that
indicates its uptake.

I am skeptical of the architectures in RRG, having developed similar
ones in the X-Bone overlay system, and realizing the show-stopper was
the broadcast nature of encapsulation entry discovery about 8 years ago.

I would suggest we try to move forward with less engineering and more
social engineering. In specific, we need to abandon the either-or
approach, and embrace a concurrent approach to moving forward, driven by
apps. Here's the specific way I would like to see:

	- modify apps to request both v6 and v4 addrs during DNS

	- modify apps to issue TCP SYNs in both v4 and v6
		servers receiving both v4 and v6 can drop the v4

		clients should wait 1 extra RTT to see if both
		are received, and connect via v6 if answering

I.e., push IPv6 out by pushing it into the web and other apps. I would
give up on the following issues:

	- worrying about doubling DNS requests by asking for both
		v4 and v6

	- worrying about doubling TCP SYN traffic

	- worrying about dual-stack

Overall, we need to stop over-smithing complex solutions to hide the
transition to IPv6 by over-optimizing transparent interoperation.

Joe

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 12 Dec 2007 22:15:42 +0100

Joe Touch wrote:
> 
> Pars Mutaf wrote:
>> With all due respect, I'm questioning this result ;-) The
>> client/server paradigm which, at least to me, does not really 
>> require IPv6.
> 
>> In my opinion the real dooms day metric is "how far we are from the
>> IP addressable cell phone", which is probably not measurable :-/
> 
> Nor would an ATM addressable cellphone be, unless they talk to
> something else using IPv6. Using IPv6 internally is irrelevant.
> 
> I would be surprised if IPv6 made it into cellphones and major
> companies failed to upgrade their web servers to be surf-able from
> those phones.

Things may not always go hand in hand.  IPv6 cellphones _have_ been
spotted: stack, jvm and browser included (not sure about flashplayer).

I'm wondering what precisely technical problem do the companies' web
servers encounter to not support IPv6 http.

Alex

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Dec 2007 13:41:57 -0800

Alexandru Petrescu wrote:
...
> servers encounter to not support IPv6 http.

There are a few, though we really ought to try to get a reasonably
complete list and this is just ad-hoc:

1. not wanting to break browsers that prefer IPv6 but don't backoff and
try IPv4
	i.e., not wanting to look black-holed in those cases

2. lack of network management in IPv4
	one of the paradoxes, at least as net admin folk tell me,
	is they need IPv4 to monitor and administrate an IPv6 net

3. a (fairly accurate) belief that it's not worth the cost

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 16 Dec 2007 13:29:45 +0100

> This is the current result... not very encouraging, IMO.

You leave out what the result is, but I assume it's only a handful, if  
that.

Which is neither surprising nor a problem. There are three issues with  
making a big website IPv6-enabled:

1. Many of those use complex load balancing mechanisms to provide one  
service from a number of physical servers. It seems the vendors of  
these products aren't very quick with their IPv6 uptake and even if  
that isn't a problem, it's non-trivial to replicate these mechanisms  
for IPv6.

2. A small number of systems that think they have IPv6 connectivity  
don't actually have IPv6 connectivity. The most prominent example of  
this is Windows Vista machines that automatically enable 6to4 when  
they have a public IPv4 address but some networks that do provide  
public IPv4 addresses filter IPv6-in-IPv4 packets.

3. Although this has been getting a lot better the past years, it  
still happens that IPv6 connectivity is slower or buggier than IPv4  
connectivity.

As long as all the eyeballs are IPv4-capable thhere is almost no  
incentive for the content people to invite the problems above, even if  
the service provider hosting the content does support IPv6. (For  
instance, check to see how many people peering at the Amsterdam  
Internet Exchange have an IPv6 address for their router, and then  
check how many have an IPv6-enabled website.)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 16 Dec 2007 13:57:16 +0100

On 12 dec 2007, at 19:00, James Kempf wrote:

> I also don't buy the argument: "When the RIRs stop giving out IPv4  
> addresses in 2 years, then everybody will *finally* start to deploy  
> IPv6". What will happen is that someone will set up a Web site where  
> globally routable IPv4 addresses are auctioned.

So when I buy a block of four IPv4 addresses, what exactly can I do  
with those?

> The price of a globally routable IPv4 address will go from zero to  
> market driven. In other words, a market will develop in globally  
> routable IPv4 addresses. If and when the incremental cost of  
> deploying an IPv6 address exceeds the market price of a globally  
> routable IPv4 address by a sufficient amount (maybe 5x, maybe 10x,  
> whatever amount matches the disutility to the service provider of  
> having to deploy IPv6), then IPv6 may get deployed.

Please note that ARIN explicitly says that trading in IPv4 space isn't  
allowed. Although of course you can easily _rent_ address space, and  
the people providing you with that address space will throw in some  
connectivity to the internet with that for good measure.

The problem with the IPv6 transition isn't the cost side: starting  
from zero, it's probably cheaper already to deploy IPv6 than IPv4, and  
if that isn't the case today, it will be soon. The problematic part is  
the benefits side of the equation: with IPv4 you can talk to everyone  
connected to the internet, with IPv6 you can't talk to a statistically  
significant portion of the people connected to the internet.

Hopefully we can still address this omission by making available a  
better version of NAT-PT before the lack of new IPv4 addresses starts  
becoming a problem.

But even without that, what will happen after there is no longer  
enough free IPv4 space left for the RIRs to grant all requests that  
are in accordance with their policies, will be something like the  
following:

First of all, there is a large distribution of allocation sizes. Some  
large ISPs now get blocks of a million or more IPv4 addresses, while  
the minimum size is in the 256 - 1024 range. Even when there are no  
longer any blocks of a million, there will still be a lot of smaller  
blocks and so far, something in the order of 10 million addresses is  
returned to the RIRs each year. So the large ISPs will hit a wall, but  
the small content guys will probably be fine for at least another year  
or possibly many years.

Apparently it's hard to free up legacy IPv4 space, because this year  
we saw the return of a class A block for the first time in many years.  
So it's probably a mistake to assume that a little money will  
magically make all legacy IPv4 space available, although a lot of  
money might and a medium-sized amount of money will almost certainly  
be able to free up part of this space. The question is whether it will  
be possible to trade this address space. Remember that you can't use  
addresses without exposing that use.

So you're a large ISP and you find yourself unable to get the IPv4  
address space that you need to connect another million customers. You  
can probably scrape that address space together if you invest enough  
time and money--the first time. But what about a year later, and the  
year after that? I'd say that most ISPs in that situation will prefer  
to invest in technology that allows them to continue to do business  
without needing to obtain new IPv4 addresses by putting multiple  
customers behind a single IPv4 address.

The interesting part here is that there are three ways to do this:

1. IPv4 NAT
2. Dual stack IPv4 NAT + IPv6
3. IPv6 with some form of NAT-PT

Obviously, 2. is more expensive than 1., so unless there is something  
pushing ISPs to do 2., they'll be doing 1. unless 3. is more  
attractive than 1. However, 1. pretty much means the end of peer-to- 
peer applications unless consumers get access to NAT traversal  
technology that can work through four NAT devices (source CPE, source  
ISP, dest ISP, dest CPE). ISPs have a love-hate relationship with p2p:  
on the one hand, Skype means they can sell fewer voice minutes (if  
they're also in that business) and BitTorrent clogs their networks,  
but on the other hand, these services sell more and bigger  
connections. It will be interesting to see whether the love or hate  
part wins out.

> overcome the large sunk cost of the current IPv4 network. IPv6  
> deployment is a good example of how large sunk costs in  
> infrastructure essentially throttle the deployment of a new  
> technology, so that it becomes cheaper to continue developing the  
> old technology.

You mean like DSL and cable internet access rather than new fiber  
infrastructures?

> Nonmarket forces, such as government mandates, are a different  
> matter. They could possibly force deployment (and similarly and more  
> importantly for nonpetrolum powered transport).

If a technology isn't good enough to win the market without help from  
governments, do we really want it? There is no evidence that  
government technology selection is better than market technology  
selection.

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Dec 2007 10:07:42 -0800

> You leave out what the result is, but I assume it's only a handful, if

Basically zero, except in IETF-related sites, where it's under 2%.

Joe