At 11:30 -0400 6/30/05, Daniel Senie wrote:

At 10:02 AM 6/30/2005, Fergie (Paul Ferguson) wrote:

...

Just in case anyone was wondering, U.S. gummint agencies will be screaming in migration agony for the next couple of years. ;-)

http://www.fcw.com/article89432-06-29-05-Web

GOSIP II anybody? Will it be different this time than it was with OSI? Everyone had to scramble in the late 1980s to get OSI stuff done, then the gov't never used it.

Having been in the US gov't (too) at the time of GOSIP, there were three reasons why I never used it much: 1) No budget was ever allocated to convert operations. (We had products, but we weren't forced, induced, encouraged to use it.) 2) The API for the GOSIP protocols was not standard - not only different from the API for TCP/IP, the API for GOSIP varied by platform. (POSIX had just begun.) 3) There was no tidbit of information available over the network that was on a server that spoke only GOSIP and not TCP/IP. (No compelling reason.) So, the questions are: will OMB fund the transfer of the US gov't sites? Will there ever be a US gov't web site only on IPv6? (I think the API issue has been solved.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.

On Jun 30, 2005, at 5:37 PM, Todd Underwood wrote:

where is the service that is available only on IPv6? i can't seem to find it.

You might ask yourself whether the Kame Turtle is dancing at http://www.kame.net/. This is a service that is *different* (returns a different web page) depending on whether you access it using IPv6 or IPv4. You might also look at IP mobility, and the routing being done for the US Army's WIN-T program. Link-local addresses and some of the improved flexibility of the IPv6 stack has figured in there. There are a number of IPv6-only or IPv6-dominant networks, mostly in Asia-Pac. NTT Communications runs one as a trial customer network, with a variety of services running over it. The various constituent networks of the CNGI are IPv6-only. There are others. Maybe you're saying that all of the applications you can think of run over IPv4 networks a well as IPv6, and if so you would be correct. As someone else said earlier in the thread, the reason to use IPv6 has to do with addresses, not the various issues brought up in the marketing hype. The reason the CNGI went all-IPv6 is pretty simple: on the North American continent, there are ~350M people, and Arin serves them with 75 /8s. In the Chinese *University*System*, there are ~320M people, and the Chinese figured they could be really thrifty and serve them using only 72 /8s. I know that this is absolutely surprising, but APNIC didn't give CERNET 72 /8s several years ago when they asked. I really can't imagine why. The fact that doing so would run the IPv4 address space instantly into the ground wouldn't be a factor would it? So CNGI went where they could predictably get the addresses they would need. Oh, by the way. Not everyone in China is in the Universities. They also have business there, or so they tell me... The point made in the article that Fergie forwarded was that Asia and Europe are moving to IPv6, whether you agree that they need to or not, and sooner or later we will have to run it in order to talk with them. They are business partners, and we *will* have to talk with them. We, the US, have made a few my-way-or-the-highway stands in the past, such as "who makes cell phones" and such. When the rest of the world went a different way, we wound up be net consumers of their products. Innovation transfered to them, and market share. The good senator is worried that head-in-the-sand attitudes like the one above will similarly relegate us to the back seat in a few years in the Internet. Call him "Chicken Little" if you like. But remember: even Chicken Little is occasionally right.

At 21:29 -0400 6/30/05, Todd Underwood wrote:

the rest of fred's comment stands with useful information but i'm still looking for the tipping point where people migrate, en-masse, away from the Internet to this new, incompatible network.

You can color me skeptical on IPv6 - basing this on attending way too many PPT presentations on the subject and only limited hands on experience. But while I think the tipping point doesn't exist today, I bet it will sooner or later. IPv6 is not all that "incompatible" with IPv4 really, it's a lot closer than CLNP and UDP. It's not that IPv6 is chasing what IPv4 already offers. A lot of the improvements to IPv4 are thanks to IPv6. The fact remains that IPv6's expanded address range will be what makes it trump IPv4 eventually. It's not GOSIP all over again. But the USG's OMB statement may not be the panacea to the fans of IPv6. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.

Date: Thu, 30 Jun 2005 21:29:04 -0400 From: Todd Underwood <todd@renesys.com> Sender: owner-nanog@merit.edu

On Thu, Jun 30, 2005 at 06:16:37PM -0700, Fred Baker wrote:

...

On Jun 30, 2005, at 5:37 PM, Todd Underwood wrote:

...

where is the service that is available only on IPv6? i can't seem to find it.

You might ask yourself whether the Kame Turtle is dancing at http://www.kame.net/. This is a service that is *different* (returns a different web page) depending on whether you access it using IPv6 or IPv4.

heh. i guess i'll have to live without the dancing turtle, and so will all the other Internet users. i wonder what other useful content is not available on the real Internet and only available via ipv6. i keep asking this question and keep getting non-answers like this.

the rest of fred's comment stands with useful information but i'm still looking for the tipping point where people migrate, en-masse, away from the Internet to this new, incompatible network.

You will also have to live without access to the worlds highest resolution electron microscope located at the Research Center for Ultra High Voltage Electron Microscopy (UHVEM) in Osaka, Japan. It is a significant bit of research hardware used by people all over the world and it is only accessible by IPv6. Once again, this is largely of significance to the R&E networking community and of far less interest to commercial Internet operators. This sort of thing is the reason that Abilene (Internet2) and ESnet are both IPv6 capable and have been for a long time. This is probably not a significant issue for most of you, but, as time passes, more and more content will start to be V6 only, especially if located in Asia and not having a business case to support access to the US. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634

Jay R. Ashworth wrote:

Well, with all due respect, of *course* there isn't any 'killer site' that is v6 only yet: the only motivation to do so at the moment, given the proportion of v4 to v6 end-users, is *specifically* to drive v4 to v6 conversion at the end-user level.

We need either one efficient v6 p2p application or sites providing free p0rn only over ipv6 connections. The same would work for multicast. Pete

At 12:14 PM +0200 2005-07-01, Andre Oppermann wrote:

Huh, Europe is moving to IPv6? I must have been asleep at all industry meeting in the past few month and years...

From what I've seen at the RIPE meetings, Europe is definitely moving towards IPv6. Maybe not as fast as some parts in Asia, but it's definitely moving that way. Moreover, it's moving towards IPv6 much faster than the US.

All the other stuff and the different address scopes are not only impractical but confuse the average consumer and MCSE admin to no end (and those are the people that have to deal with it all the time).

IPv6 has its problems, yes. There are implementation issues that confuse programmers at Sun working on Solaris, and confuse network application programmers with a hell of a lot of experience under their belt. If you can't talk directly to Jinmei himself, you're likely to be well and truly screwed. But just because IPv6 has problems doesn't mean that it doesn't solve the fundamental address space problem in IPv4, and doesn't mean that it is anything less than the best available alternative. -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.

What fundamental address space problem? I'd say we run out of AS numbers about a year before we run out of IPv4 addresses, whenever that is.

Fortunately we have solutions for both. 32 bit ASNs and 128 bit addresses. Pressure your vendors and peers to implement both. Death of internet not predicted. No film at 11. Rob

On 4-jul-2005, at 12:25, Andre Oppermann wrote:

I don't care what you see at RIPE meetings. You have to look at how many servers/services are reachable via IPv6. Nothing else. Sure, many European ISPs have got their IPv6 prefix and some even announce it via BGP, but actually using it for anything more useful than "hey, I can ping6 you!" is far off.

Well, a reasonable number of people are doing more than that. Of course I realize that the numbers that I'm about to list here can be interpreted in any number of ways, however, the trend is very clear: IPv6 is on the rise. Once in a while when I have nothing to do I load up the Amsterdam Internet Exchange membership list and visit all the web sites from the members, while keeping an eye on tcpdump. This tells me how many of those member's web sites are reachable over IPv6. The latest numbers I have are for march 2005. At that time, 9 or 213 members had IPv6-enabled web sites. About a year earlier this was 4 or 5 (one had AAAA but was unreachable), no information on the then current number of members.

...

IPv6 has its problems, yes. There are implementation issues that confuse programmers at Sun working on Solaris, and confuse network application programmers with a hell of a lot of experience under their belt. If you can't talk directly to Jinmei himself, you're likely to be well and truly screwed.

Ain't this *the* problem??? If not even Joe OperatingSystemEngineer can understand it, what is John Doe at home supposed to do?

The trouble is that different OSes have different ideas about how you should deal with IPv4+IPv6 coexistance on the socket API level. This is a big headache for the unfortunate souls who have to deal with it, but it's of no consequence at all to users. (If you write for one OS or one IP version or use a higher level API you won't have problems, though.)

You know, there is one thing Steve Jobs / Apple is getting right. That is getting out of the way and make *functionality* available to the average user.

I agree completely. All hail The Steve for giving us IPv6 on by default since MacOS 10.2! As of 10.4 the Safari browser handles IPv6 the way it should too, like iTunes and Apple's Mail have for ages (although there is a nasty bug in the 10.4 Mail that required me to go back to talking to my mail server over IPv4).

...

But just because IPv6 has problems doesn't mean that it doesn't solve the fundamental address space problem in IPv4, and doesn't mean that it is anything less than the best available alternative.

What fundamental address space problem?

6 billion people with more under way with 3.7 billion usable addresses (how many do YOU use?) looks like a fundamental, long term problem to me.

I'd say we run out of AS numbers about a year before we run out of IPv4 addresses, whenever that is.

The fix for this has been on the IETF drawing boards for half a decade but somehow seems to stay there.

Fred, On Jun 30, 2005, at 6:16 PM, Fred Baker wrote:

Maybe you're saying that all of the applications you can think of run over IPv4 networks a well as IPv6, and if so you would be correct. As someone else said earlier in the thread, the reason to use IPv6 has to do with addresses,

Oh, you mean the 16 bits of additional address space IPv6 provides? I find it ironic that this is the same amount of address space NAT (eww. I said a bad word) buys you.

not the various issues brought up in the marketing hype.

And yet, we constantly hear the spin of IPv6's "improved security", "simpler routing", etc., etc., when IPv6 fans talk to rooms not full of network geeks. Remember the marketing hype about OSI? Remember the marketing hype about ATM?

The fact that doing so would run the IPv4 address space instantly into the ground wouldn't be a factor would it?

No, actually, it wasn't. Really. I can very honestly say that this was NOT a consideration in how IPv4 address space was allocated to organizations in China, at least when I was at APNIC (if that was the request you were talking about). Rgds, -drc

We are already behind in innovation as most networks these days are run by accountants instead of people with an entrepaneur's sprit. We need good business practices so that the network will stay afloat financially I do not miss the 'dot.com' days. But what we have now is an overemphasis on cost-cutting and like it or not IPv6 implementation is seen as a 'frill' which will not reduce OPEX. I really fear we have lost the edge here in the west due to too much emphasis on the cost side of the equation ironically this has been driven by the current network where financial information is available instantly for decision making whereas in the past financial information about far-flung operation took up to a year to to arrive so if a division was profitable it was 'left alone' now with the instant availability we are seeing profitable divisions of companies shut down because the numerical analysis shows the capital could be used to generate a higher return elsewhere. Innovation is expensive and it does not return an immediate benefit and right now all the average corporation cares about is the next quarter's figures not whether the company will be profitable in 5 years. We are seeing many instances of companies eating their seed corn instead of investing in the future. IPv6 would have been adopted much sooner if the protocol had been written as an extension of IPv4 and in this case it could have slid in under the accounting departments radar since new equipment and applications would not be needed. Scott C. McGrath On Thu, 30 Jun 2005, Fred Baker wrote:

On Jun 30, 2005, at 5:37 PM, Todd Underwood wrote:

...

where is the service that is available only on IPv6? i can't seem to find it.

You might ask yourself whether the Kame Turtle is dancing at http://www.kame.net/. This is a service that is *different* (returns a different web page) depending on whether you access it using IPv6 or IPv4. You might also look at IP mobility, and the routing being done for the US Army's WIN-T program. Link-local addresses and some of the improved flexibility of the IPv6 stack has figured in there.

There are a number of IPv6-only or IPv6-dominant networks, mostly in Asia-Pac. NTT Communications runs one as a trial customer network, with a variety of services running over it. The various constituent networks of the CNGI are IPv6-only. There are others.

Maybe you're saying that all of the applications you can think of run over IPv4 networks a well as IPv6, and if so you would be correct. As someone else said earlier in the thread, the reason to use IPv6 has to do with addresses, not the various issues brought up in the marketing hype. The reason the CNGI went all-IPv6 is pretty simple: on the North American continent, there are ~350M people, and Arin serves them with 75 /8s. In the Chinese *University*System*, there are ~320M people, and the Chinese figured they could be really thrifty and serve them using only 72 /8s. I know that this is absolutely surprising, but APNIC didn't give CERNET 72 /8s several years ago when they asked. I really can't imagine why. The fact that doing so would run the IPv4 address space instantly into the ground wouldn't be a factor would it? So CNGI went where they could predictably get the addresses they would need.

Oh, by the way. Not everyone in China is in the Universities. They also have business there, or so they tell me...

The point made in the article that Fergie forwarded was that Asia and Europe are moving to IPv6, whether you agree that they need to or not, and sooner or later we will have to run it in order to talk with them. They are business partners, and we *will* have to talk with them. We, the US, have made a few my-way-or-the-highway stands in the past, such as "who makes cell phones" and such. When the rest of the world went a different way, we wound up be net consumers of their products. Innovation transfered to them, and market share.

The good senator is worried that head-in-the-sand attitudes like the one above will similarly relegate us to the back seat in a few years in the Internet.

Call him "Chicken Little" if you like. But remember: even Chicken Little is occasionally right.

You do make some good points as IPv6 does not address routing scalability or multi-homing which would indeed make a contribution to lower OPEX and be easier to 'sell' to the financial people. As I read the spec it makes multi-homing more difficult since you are expected to receive space only from your SP there will be no 'portable assignments' as we know them today. If my reading of the spec is incorrect someone please point me in the right direction. IPv6's hex based nature is really a joy to work with IPv6 definitely fails the human factors part of the equation. Scott C. McGrath On Wed, 6 Jul 2005, David Conrad wrote:

On Jul 6, 2005, at 7:57 AM, Scott McGrath wrote:

...

IPv6 would have been adopted much sooner if the protocol had been written as an extension of IPv4 and in this case it could have slid in under the accounting departments radar since new equipment and applications would not be needed.

IPv6 would have been adopted much sooner if it had solved a problem that caused significant numbers of end users or large scale ISPs real pain. If IPv6 had actually addressed one or more of routing scalability, multi-homing, or transparent renumbering all the hand wringing about how the Asians and Europeans are going to overtake the US would not occur. Instead, IPv6 dealt with a problem that, for the most part, does not immediately affect the US market but which (arguably) does affect the other regions. I guess you can, if you like, blame it on the accountants...

Rgds, -drc

IPv6 is an excellent example of _second system_ (do you remember book, written by Brooks many years ago?) Happu engineers put all their crazy ideas together into the second version of first 9succesfull) thing, and they wonder why it do not work properly. OS/360 is one example, IPv6 will be another. IPv6 address allocation schema is terrible (who decided to use SP dependent spaces?), security is terrible (who designed IPSec protocol?) and so so on. Unfortunately, it can fail only if something else will be created, which do not looks so. ----- Original Message ----- From: "Daniel Golding" <dgolding@burtongroup.com> To: "Scott McGrath" <mcgrath@fas.harvard.edu>; "David Conrad" <david.conrad@nominum.com> Cc: <nanog@merit.edu> Sent: Wednesday, July 06, 2005 8:58 AM Subject: Re: OMB: IPv6 by June 2008

There is an element of fear-mongering in this discussion - that's why many of us react poorly to the idea of IPv6. How so?

- We are running out of IPv4 space! - We are falling behind <#insert scary group to reinforce fear of Other>! - We are not on the technical cutting edge!

Fear is a convenient motivator when facts are lacking. I've read the above three reasons, all of which are provable incorrect or simple fear

mongering,

repeatedly. The assertions that we are falling behind the Chinese or Japanese are weak echoes of past fears.

The market is our friend. Attempts to claim that technology trumps the market end badly - anyone remember 2001? The market sees little value in v6 right now. The market likes NAT and multihoming, even if many of us don't.

Attempts to regulate IPv6 into use are as foolish as the use of fear-based marketing. The gain is simply not worth the investment required.

- Daniel Golding

On 7/6/05 11:41 AM, "Scott McGrath" <mcgrath@fas.harvard.edu> wrote:

...

You do make some good points as IPv6 does not address routing

scalability

...

or multi-homing which would indeed make a contribution to lower OPEX and be easier to 'sell' to the financial people.

As I read the spec it makes multi-homing more difficult since you are expected to receive space only from your SP there will be no 'portable assignments' as we know them today. If my reading of the spec is incorrect someone please point me in the right direction.

IPv6's hex based nature is really a joy to work with IPv6 definitely fails the human factors part of the equation.

Scott C. McGrath

On Wed, 6 Jul 2005, David Conrad wrote:

...

On Jul 6, 2005, at 7:57 AM, Scott McGrath wrote:

...

IPv6 would have been adopted much sooner if the protocol had been written as an extension of IPv4 and in this case it could have slid in under the accounting departments radar since new equipment and applications would not be needed.

IPv6 would have been adopted much sooner if it had solved a problem that caused significant numbers of end users or large scale ISPs real pain. If IPv6 had actually addressed one or more of routing scalability, multi-homing, or transparent renumbering all the hand wringing about how the Asians and Europeans are going to overtake the US would not occur. Instead, IPv6 dealt with a problem that, for the most part, does not immediately affect the US market but which (arguably) does affect the other regions. I guess you can, if you like, blame it on the accountants...

Rgds, -drc

-- Daniel Golding Network and Telecommunications Strategies Burton Group

We have relatively PI address space in IPv4, which works fine, even with current routers. No any problem to hold the whole world-wide routing with a future ones. Is it a pproblem keeping 500,000 routess in core routers? Of course, it is not (it was in 1996, but it is not in 2005 and it will not be in 2008 - even if you will have 1,000,000 routes). IPv6 schema was build to resolve problem which do not exists anymore (with fast CPU and cheap memory and ASIC's). I mean - when people switched from IPv4 to IPv6, they changed too much and too hard, trying to implement all their ideas. Result is terrible. IPSec - compare SSH and IPSec. Compare IPSec and PPTP. No, IPSec is extremely bad thing. ----- Original Message ----- From: "David Conrad" <david.conrad@nominum.com> To: "Alexei Roudnev" <alex@relcom.net> Cc: "Daniel Golding" <dgolding@burtongroup.com>; "Scott McGrath" <mcgrath@fas.harvard.edu>; <nanog@merit.edu> Sent: Thursday, July 07, 2005 12:01 AM Subject: Re: OMB: IPv6 by June 2008

On Jul 6, 2005, at 10:16 PM, Alexei Roudnev wrote:

...

IPv6 address allocation schema is terrible (who decided to use SP dependent spaces?),

Well, to date, provider based addressing works (although there were times when it was a close thing). Your alternative?

...

security is terrible (who designed IPSec protocol?) and so so on.

I wouldn't say terrible. Annoying, perhaps, but security is often like that. Your alternative?

...

Unfortunately, it can fail only if something else will be created, which do not looks so.

The "something else" already exists, although many are unhappy about it. It has evolved a bit -- it's now called NUTSS (http:// nutss.gforge.cis.cornell.edu/)... :-)

Rgds, -drc

On Jul 7, 2005, at 1:37 PM, Joe Abley wrote:

My various networked devices each get two addresses in this way. When they talk to some remote device that has a shim6 element in its protocol stack, I get all the benefits that I would expect to achieve by multi-homing: if one provider goes down, I use the other one without having to debug anything, or yank any cables, or answer any difficult pop-up questions. Sessions that are established before one provider dies continue to work afterwards. New sessions start up just fine. When the provider comes back on-line, everything continues to work. I probably don't even notice that the provider had a problem.

I've only briefly read stuff about shim6... I've seen mention of load sharing and redundancy, but what about load unbalancing and redundancy? An end-site with BGP today has lots of control over their outbound traffic patterns in particular... maybe I missed something, but I don't get how you can maintain this level of control with shim6. (inbound traffic unbalancing is also an issue... but I did read something about dynamically exchanging locators which I could see being used to unbalance inbound traffic, perhaps with more control than today's BGP setup)

Randy Bush wrote:

...

Is it a pproblem keeping 500,000 routess in core routers? Of course, it is not (it was in 1996, but it is not in 2005

really? we have not seen this so how do you know? and it will be fine with churn and pushing 300k forwarding entries into the fibs on a well-known vendor's line cards?

Soon the fib can be replaced by just an array with an index for every IPv4 address. With <255 interfaces, 4G is sufficient .-) Pete

What is CPU power of today's core routers? What's memory? Compare with junk-yard server - 2 x 1.4Ggz CPU, 4 GB RAM, total price about $1.5K.

Routers have 3 - 10 times reserve _today_ . Then, you can always sacrify reaction time a little. Reserves are tremendous in this area.

...

...

Is it a pproblem keeping 500,000 routess in core routers? Of course, it is not (it was in 1996, but it is not in 2005

really? we have not seen this so how do you know? and it will be fine with churn and pushing 300k forwarding entries into the fibs on a well-known vendor's line cards?

clue: some large isps have routers falling over today due to ram limitations on line cards. and it will cost a LOT of money for them to do upgrades which will last not long enough. as this is an ops list, can we try to stay somewhere in the neighborhood of operational realities? randy

On 7-jul-2005, at 7:16, Alexei Roudnev wrote:

IPv6 address allocation schema is terrible (who decided to use SP dependent spaces?)

Address allocation is unsustainable but that's not IPv6's fault: it's done the same way (or even worse) in IPv4. But somehow the industry as a whole seems incapable of recognizing that having each and every ISP with 200 customers (not even that in AfriNIC/LACNIC regions), no matter how regional/local, occupy a place at the top of the global addressing hierarchy is a flawed idea.

security is terrible (who designed IPSec protocol?) and so so on.

Security is terrible by virtue of its nature, which explains why most people prefer to be insecure most of the time. IPsec isn't bad, although I hate the overhead (although that's childs play compared to the epidemic of quoting previous messages verbatim that is now spreading among people who should know better) and the fact that it operates on addresses makes it hard to use as a replacement for SSL. (If you think IPsec is bad, try to implement an application on top of SSL.)

On 7 Jul 2005, at 08:27, Andre Oppermann wrote:

Err... So you want to protect the incumbent ISP's? Even those once started off with 200 customers. Who is going to decide if some (today) small ISP is worthy of receiving its own PA space or not?

Pretty much any ISP is capable of obtaining their own PA space under current RIR policies, regardless of size. The prohibition on PA space is to end sites, not ISPs. See, for example: http://www.arin.net/policy/index.html#six511 The myth that only large, established ISPs are able to obtain PA IPv6 address space really needs to disappear. Joe

On 2005-07-07, at 10:23, Andre Oppermann wrote:

It was about a spot in the global routing table. No matter if one gets PA or PI they get a routing table entry in the DFZ. There is no way around it other than to make the routing protocols more scaleable.

With the hole-punching/CIDR abuse multihoming that is widely used in IPv4, a slot in the DFZ gets burned each time an end site adds a provider, regardless of whether they are using PA or PI addresses. This slot represents state information for the multi-homed site which answers the question "how else can this set of addresses be reached?" The shim6 approach shifts this state from the DFZ to the endpoints which are exchanging unicast traffic. The endpoints exchange a set of possible locators through a protocol element within the IP layer and handle locator migration transparently to the transport layer above. Hence the question "how else can this particular remote address be reached" is answered using information on the host, not information in the network. With shim6 an end site can multi-home using one PA prefix per provider, without taking up additional slots in the DFZ. Hosts within the site are given multiple addresses (locators), and the layer-3 shim handles any change of locator needed for traffic exchanged between any two hosts. If one (or both) of the hosts exchanging traffic don't support shim6, then the traffic is exchanged without transport-layer stability across re-homing events (and, potentially, without any optimisation as to the choice of endpoint addresses for the session). So, the shim6 future of multihoming looks like this: 1. ISPs multi-home exactly as people are used to doing today, using PI prefixes, and taking up a slot in the DFZ per transit provider. Everybody is familiar with this already. There is no change for ISPs in this picture. 2. Multi-homed end sites obtain one PA prefix per upstream ISP, and hosts within those end-sites are assigned multiple addresses (in some automated, secure and controllable fashion). There are no additional slots burned in the DFZ by end site multi-homing. Hosts obtain transport-layer reliability across re-homing events using shim6, rather than relying on the network to take care of it. Joe

Andre, On Thu, Jul 07, 2005 at 06:04:22PM +0200, Andre Oppermann wrote:

Joe Abley wrote:

...

On 2005-07-07, at 10:23, Andre Oppermann wrote:

...

It was about a spot in the global routing table. No matter if one gets PA or PI they get a routing table entry in the DFZ. There is no way around it other than to make the routing protocols more scaleable.

With the hole-punching/CIDR abuse multihoming that is widely used in IPv4, a slot in the DFZ gets burned each time an end site adds a provider, regardless of whether they are using PA or PI addresses. This slot represents state information for the multi-homed site which answers the question "how else can this set of addresses be reached?"

The shim6 approach shifts this state from the DFZ to the endpoints which are exchanging unicast traffic. The endpoints exchange a set of possible locators through a protocol element within the IP layer and handle locator migration transparently to the transport layer above. Hence the question "how else can this particular remote address be reached" is answered using information on the host, not information in the network.

With shim6 an end site can multi-home using one PA prefix per provider, without taking up additional slots in the DFZ. Hosts within the site are given multiple addresses (locators), and the layer-3 shim handles any change of locator needed for traffic exchanged between any two hosts.

If one (or both) of the hosts exchanging traffic don't support shim6, then the traffic is exchanged without transport-layer stability across re-homing events (and, potentially, without any optimisation as to the choice of endpoint addresses for the session).

So, the shim6 future of multihoming looks like this:

1. ISPs multi-home exactly as people are used to doing today, using PI prefixes, and taking up a slot in the DFZ per transit provider. Everybody is familiar with this already. There is no change for ISPs in this picture.

2. Multi-homed end sites obtain one PA prefix per upstream ISP, and hosts within those end-sites are assigned multiple addresses (in some automated, secure and controllable fashion). There are no additional slots burned in the DFZ by end site multi-homing. Hosts obtain transport-layer reliability across re-homing events using shim6, rather than relying on the network to take care of it.

Ok, you don't think this thing will ever fly, do you?

I'm interested in what aspect(s) of shim6 you think might cause it to fail? Is it the technology itself (as much as is specified anyway), it's complexity, the underlying multihoming model, ...? Dave

Who need this complexity? What's wrong with old good _routing rotocol_ approach? Memory? (do not joke, today 4 Gb RAM is not a problem, when it is for slow routing system). CPU (the same)? What else? If it looked as a problem 10 years ago, it can not be relevant to today's realities. ----- Original Message ----- From: "Joe Abley" <jabley@isc.org> To: "Andre Oppermann" <nanog-list@nrg4u.com> Cc: "NANOG list" <nanog@merit.edu>; "Alexei Roudnev" <alex@relcom.net>; "Iljitsch van Beijnum" <iljitsch@muada.com> Sent: Thursday, July 07, 2005 8:11 AM Subject: Re: OMB: IPv6 by June 2008

On 2005-07-07, at 10:23, Andre Oppermann wrote:

...

It was about a spot in the global routing table. No matter if one gets PA or PI they get a routing table entry in the DFZ. There is no way around it other than to make the routing protocols more scaleable.

With the hole-punching/CIDR abuse multihoming that is widely used in IPv4, a slot in the DFZ gets burned each time an end site adds a provider, regardless of whether they are using PA or PI addresses. This slot represents state information for the multi-homed site which answers the question "how else can this set of addresses be reached?"

The shim6 approach shifts this state from the DFZ to the endpoints which are exchanging unicast traffic. The endpoints exchange a set of possible locators through a protocol element within the IP layer and handle locator migration transparently to the transport layer above. Hence the question "how else can this particular remote address be reached" is answered using information on the host, not information in the network.

With shim6 an end site can multi-home using one PA prefix per provider, without taking up additional slots in the DFZ. Hosts within the site are given multiple addresses (locators), and the layer-3 shim handles any change of locator needed for traffic exchanged between any two hosts.

If one (or both) of the hosts exchanging traffic don't support shim6, then the traffic is exchanged without transport-layer stability across re-homing events (and, potentially, without any optimisation as to the choice of endpoint addresses for the session).

So, the shim6 future of multihoming looks like this:

1. ISPs multi-home exactly as people are used to doing today, using PI prefixes, and taking up a slot in the DFZ per transit provider. Everybody is familiar with this already. There is no change for ISPs in this picture.

2. Multi-homed end sites obtain one PA prefix per upstream ISP, and hosts within those end-sites are assigned multiple addresses (in some automated, secure and controllable fashion). There are no additional slots burned in the DFZ by end site multi-homing. Hosts obtain transport-layer reliability across re-homing events using shim6, rather than relying on the network to take care of it.

Joe

You do not need to - any router have only `1 - 10% of all routing table active, and it is always possible to optimize these alghoritms. On the other hand - what's wrong with 4Gb on line card in big core router? It's cheap enough, even today. And we have not 1,000,000 routes yet. ----- Original Message ----- From: "Brad Knowles" <brad@stop.mail-abuse.org> To: "NANOG" <nanog@merit.edu> Sent: Friday, July 08, 2005 1:03 AM Subject: Re: OMB: IPv6 by June 2008

At 12:51 AM -0700 2005-07-08, Alexei Roudnev wrote:

...

Who need this complexity? What's wrong with old good _routing rotocol_ approach? Memory? (do not joke, today 4 Gb RAM is not a problem, when

it is

...

for slow routing system). CPU (the same)? What else?

Can you put 4GB on every linecard on every router you own? Can you put a Power5 or PowerPC 970MP processor on every linecard on every router you own? Does your vendor support you making any modifications/upgrades to any of their linecards, or do they require you to buy new ones with the go-faster features?

And how many tens of thousands of dollars do each of those go-faster linecards cost? And how many million-dollar fork-lift upgrades do you have to pay for in order to get the go-faster chassis in which to plug those go-faster cards into?

Do you have thousands of routers? Hundreds of thousands?

I'm asking serious questions here. I'm not a router guy, but I've heard a lot of comments on this list that give me pause, so I'd like to get real-world answers.

Speaking from my own perspective, it seems to me that we've got a scalability problem here when we're expecting most devices to have a pretty complete picture of the entire world. I think that's the real problem that has to be addressed.

In terms of the routing protocols and number of ASes, we know that it's possible to build machines which can handle those kinds of things at those kinds of numbers. The problem is that it's hard to do those kinds of things on a widespread basis (e.g., in every linecard in every router in the world), and most devices probably don't need that anyway.

I don't know what the real solution is. But it seems to me that we need to find something, and having people say "4GB of RAM? No problem" is not the way to get this solved.

-- Brad Knowles, <brad@stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."

-- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755

SAGE member since 1995. See <http://www.sage.org/> for more info.

On Fri, 8 Jul 2005, Brad Knowles wrote:

It's cheap enough, even today. And we have not 1,000,000 routes yet.

The please feel free to upgrade the entire Internet, and come back to us when you're done. You keep using the "entire internet" in your replies, when I was under the assumption that we were discussing the inter-provider DFZ. The only routers which could possibly be affected by the "prefix bloat problem" would be multi-homed and mostly inter-provider, which is a small fraction of "all routers on the internet". I'm not trying to accuse you of anything, but your arguments are beginning to sound like a disingenuous straw-man. matto --matt@snark.net------------------------------------------<darwin>< The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke

Brad Knowles wrote:

At 10:30 AM -0700 2005-07-08, Matt Ghali wrote:

...

You keep using the "entire internet" in your replies, when I was under the assumption that we were discussing the inter-provider DFZ.

The only routers which could possibly be affected by the "prefix bloat problem" would be multi-homed and mostly inter-provider, which is a small fraction of "all routers on the internet".

They're the biggest and most expensive routers on the Internet, and if the routing table were to be allowed to grow without bounds, they wouldn't be the only ones that would need to be replaced. Everyone else would very soon have the exact same problem. And there are enough of them that you'd probably spend more money upgrading them than upgrading all the other routers in the world.

The biggest routers are being upgraded anyway because of even higher link speeds and port desities. A Cisco "CRS-1 16-SLOT LINE-CARD CHASSIS ROUTE PROCESSOR" comes with 4 GB of route memory default size. Juniper's T320 and T640 come with 2 GB of main memory default size. That should take them to some higher number of routes. On the other hand a large DFZ routing table would simply dampen its growth by itself. If it gets to costly to multihome because of the hardware requirements only few would be able to so. Ergo we have a negative feedback system here keeping itself in check. Case solved and closed. -- Andre

Daniel Roesen wrote:

On Sat, Jul 09, 2005 at 12:08:08AM +0200, Andre Oppermann wrote:

...

On the other hand a large DFZ routing table would simply dampen its growth by itself. If it gets to costly to multihome because of the hardware requirements only few would be able to so. Ergo we have a negative feedback system here keeping itself in check. Case solved and closed.

Multihomed end sites usually get away with receiving only default route or some partial routes from their upstreams. So technically you can BGP multihome with Cisco 1600 or even smaller easily (dunno where BGP support is starting to become available).

Technically yes, practically no. At least not for the purposes people normally want to multihome. -- Andre

On 8 Jul 2005, at 19:26, Daniel Roesen wrote:

On Sat, Jul 09, 2005 at 12:52:35AM +0200, Andre Oppermann wrote:

...

...

Multihomed end sites usually get away with receiving only default route or some partial routes from their upstreams. So technically you can BGP multihome with Cisco 1600 or even smaller easily (dunno where BGP support is starting to become available).

Technically yes, practically no. At least not for the purposes people normally want to multihome.

I cannot confirm this observation from my experience supporting a number of customers with their multihoming setups that I've either designed myself or supported as part of "managed internet access" solutions.

Multi-homing is a tool used in the real network to protect against various failure modes. Some failure modes (e.g. last-mile link failure) can receive protection using a small router receiving multiple defaults. Other failure modes require a full table (e.g. link failure between the ISP and its upstream, or some other partial withdrawal of connectivity). The appropriate architecture depends on the needs of the site in question. One size does not fit all. Joe

At 12:08 AM +0200 2005-07-09, Andre Oppermann wrote:

The biggest routers are being upgraded anyway because of even higher link speeds and port desities.

I'm not surprised. After all, time does march on. But it doesn't help if the largest/fastest line cards available today are made obsolete overnight by people who have no concept of what it costs to route packets at OC-192 or OC-768 line speeds, and suggest that all the routers in the world could be replaced by a small handful of no-name el-cheapo PCs.

A Cisco "CRS-1 16-SLOT LINE-CARD CHASSIS ROUTE PROCESSOR" comes with 4 GB of route memory default size. Juniper's T320 and T640 come with 2 GB of main memory default size. That should take them to some higher number of routes.

Problem is, a Tier-1 provider is still going to have hundreds or thousands of routers that have to be upgraded, and there are a number of Tier-1s. Tier-2s aren't quite as bad off, but although they buy some transit from the Tier-1s, they still have a lot of private peering and they're not that far out of the DFZ themselves. And the Tier-2s have a lot less money to pay for the ultra-expensive forklift upgrades for the BFRs and GSRs and all that other mega-million dollar equipment. Meanwhile, a surprising number of people have to try and get by with linecards having only 128MB of RAM, at least according to RFC 3869.

On the other hand a large DFZ routing table would simply dampen its growth by itself. If it gets to costly to multihome because of the hardware requirements only few would be able to so. Ergo we have a negative feedback system here keeping itself in check. Case solved and closed.

And Volcanoes nicely solve the population problem for those who live too close to them. -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.

At 1:59 AM -0700 2005-07-08, Alexei Roudnev wrote:

You do not need to - any router have only `1 - 10% of all routing table active, and it is always possible to optimize these alghoritms.

If you've got proven solutions to all of the problems raised in RFC 3869, section 3.3, I'm sure we'd love to hear about them. Heck, if you've got even just one proven solution to one of those problems, we'd love to hear about them. But I think you're being more than a little disingenuous if you do not have proven solutions and simply roll out "Let's replace all the Internet core routers with dirt-cheap PCs" every time someone talks about an Internet routing scalability problem. Give me some evidence that you truly understand the problems of a Tier-1 provider, and that you've got real-world solutions, and I'd be perfectly happy to learn from whatever lessons you've got to teach. But even I am smart enough to figure out that the "let them eat cake" routine isn't particularly useful. -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.

It's chiken and egg problem. They do not have 4 Gb, because they do not need it_now_. techbnically it is not a problem even today. Small RAID systems have 1 Gb RAM easily. Line cards do not need so much memory - they can always cache routing tables. Just again - it is not _technical_ problem. IPv6 addressed problem which do note exists in reality. ----- Original Message ----- From: "Christopher L. Morrow" <christopher.morrow@mci.com> To: "Alexei Roudnev" <alex@relcom.net> Cc: "NANOG" <nanog@merit.edu>; "Brad Knowles" <brad@stop.mail-abuse.org> Sent: Friday, July 08, 2005 11:12 PM Subject: Re: OMB: IPv6 by June 2008

randy already asked for a kibosh on the lunacy here... I agree, it'd be nice, but...

On Fri, 8 Jul 2005, Alexei Roudnev wrote:

...

You do not need to - any router have only `1 - 10% of all routing table active, and it is always possible to optimize these alghoritms.

and routing vendor's haven't already done some optomizing you think?

...

On the other hand - what's wrong with 4Gb on line card in big core

router?

oh, please please name the router vendor that has 4gb of 'ram' (tcam/fpga/asic-'memory') on the 'linecard'. Oh, can't come up with one? One wonders why that is? If the solution were as simple as: "Joe, add 1.21jigawatts of memory to the linecard so we can support +1M routes" Don't you think the vendor would have done this to get people to stop bitching at them?

...

It's cheap enough, even today. And we have not 1,000,000 routes yet.

In YOUR network you don't... I'd venture to guess there are quite a few very large networks with +1M routes in them today.

remember though, I'm the chemical engineer... and I was trained to MAKE the crack cocaine...

On Sat, 09 Jul 2005 00:56:29 PDT, Alexei Roudnev said:

It's chiken and egg problem. They do not have 4 Gb, because they do not need it_now_. techbnically it is not a problem even today. Small RAID systems have 1 Gb RAM easily.

Line cards do not need so much memory - they can always cache routing tables.

Two words: "cache miss". And unlike a L1/L2 cache miss in a modern PC, where the CPU will *wait* for you to fill the cache line, the other end of that OC-192 is still in firehose mode....

On Sat, 09 Jul 2005 18:14:48 BST, "Stephen J. Wilcox" said:

forget the talk of juniper t320s in the core.. you are talking about the problem caused by multihoming and multihoming prefixes are not originated typically by such large and expensive routers but by small cheap systems at the edge.

Yes, but how well does that multihoming work if the Junipers in the core can't/ won't carry your announcement? Currently, multihoming only works because it's cost-shifting - the pain of carrying the announcement is felt by the carriers, not the originators.

On Fri, 8 Jul 2005, Alexei Roudnev wrote:

Who need this complexity? What's wrong with old good _routing rotocol_ approach? Memory? (do not joke, today 4 Gb RAM is not a problem, when it is for slow routing system). CPU (the same)? What else?

TCAMs are expensive and complex. Convergence time is also a problem. -- Mikael Abrahamsson email: swmike@swm.pp.se

Alexi, Ah, You mean the excellent 'The Mythical Man-Month' Fred Brooks wrote a second edition a few years back. I had not thought of IPv6 in terms of the second system effect but you are absolutely correct in your appraisal. Scott C. McGrath On Wed, 6 Jul 2005, Alexei Roudnev wrote:

IPv6 is an excellent example of _second system_ (do you remember book, written by Brooks many years ago?) Happu engineers put all their crazy ideas together into the second version of first 9succesfull) thing, and they wonder why it do not work properly. OS/360 is one example, IPv6 will be another.

IPv6 address allocation schema is terrible (who decided to use SP dependent spaces?), security is terrible (who designed IPSec protocol?) and so so on.

Unfortunately, it can fail only if something else will be created, which do not looks so. ----- Original Message ----- From: "Daniel Golding" <dgolding@burtongroup.com> To: "Scott McGrath" <mcgrath@fas.harvard.edu>; "David Conrad" <david.conrad@nominum.com> Cc: <nanog@merit.edu> Sent: Wednesday, July 06, 2005 8:58 AM Subject: Re: OMB: IPv6 by June 2008

...

There is an element of fear-mongering in this discussion - that's why many of us react poorly to the idea of IPv6. How so?

- We are running out of IPv4 space! - We are falling behind <#insert scary group to reinforce fear of Other>! - We are not on the technical cutting edge!

Fear is a convenient motivator when facts are lacking. I've read the above three reasons, all of which are provable incorrect or simple fear

mongering,

...

repeatedly. The assertions that we are falling behind the Chinese or Japanese are weak echoes of past fears.

The market is our friend. Attempts to claim that technology trumps the market end badly - anyone remember 2001? The market sees little value in v6 right now. The market likes NAT and multihoming, even if many of us don't.

Attempts to regulate IPv6 into use are as foolish as the use of fear-based marketing. The gain is simply not worth the investment required.

- Daniel Golding

On 7/6/05 11:41 AM, "Scott McGrath" <mcgrath@fas.harvard.edu> wrote:

...

You do make some good points as IPv6 does not address routing

scalability

...

or multi-homing which would indeed make a contribution to lower OPEX and be easier to 'sell' to the financial people.

As I read the spec it makes multi-homing more difficult since you are expected to receive space only from your SP there will be no 'portable assignments' as we know them today. If my reading of the spec is incorrect someone please point me in the right direction.

IPv6's hex based nature is really a joy to work with IPv6 definitely fails the human factors part of the equation.

Scott C. McGrath

On Wed, 6 Jul 2005, David Conrad wrote:

...

On Jul 6, 2005, at 7:57 AM, Scott McGrath wrote:

...

IPv6 would have been adopted much sooner if the protocol had been written as an extension of IPv4 and in this case it could have slid in under the accounting departments radar since new equipment and applications would not be needed.

IPv6 would have been adopted much sooner if it had solved a problem that caused significant numbers of end users or large scale ISPs real pain. If IPv6 had actually addressed one or more of routing scalability, multi-homing, or transparent renumbering all the hand wringing about how the Asians and Europeans are going to overtake the US would not occur. Instead, IPv6 dealt with a problem that, for the most part, does not immediately affect the US market but which (arguably) does affect the other regions. I guess you can, if you like, blame it on the accountants...

Rgds, -drc

-- Daniel Golding Network and Telecommunications Strategies Burton Group

On 7-jul-2005, at 0:18, Joe Abley wrote:

With great hindsight it would have been nice if the multi6/shim6 design exercise had come *during* the IPv6 design exercise, rather than afterwards: we might have ended up with a protocol/addressing model that accommodated both the address size problem and also the DFZ state bloat issue. Oh well.

Well, maybe I'm too optimistic here, but I believe that if a real solution to the DFZ problem presents itself, the IETF will bend over backwards and then some to shoehorn it into IP. But it certainly looks like a small DFZ table and portable address space are fundamentally incompatible.

On Jul 6, 2005, at 3:34 PM, Iljitsch van Beijnum wrote:

Well, maybe I'm too optimistic here, but I believe that if a real solution to the DFZ problem presents itself, the IETF will bend over backwards and then some to shoehorn it into IP.

I'd say yes. You are too optimistic. :-).

But it certainly looks like a small DFZ table and portable address space are fundamentally incompatible.

Well, yes. Of course. If you make the routing locator also be the endpoint identifier, then _of course_ you must deal with the topological significance of the endpoint identifier. It sort of follows. You can't have your cake and eat it too. Unfortunately, I do not believe a host-based solution like shim6 will ever be operationally deployable as it requires a rewrite of kernel stacks and such. I'm told people are already deploying IPv6 stacks that do not support the "mandatory" IPSEC goop and there is an expectation stack developers are going to tack on an optional bit of black magic that is used only in very rare circumstances? I have to admit some skepticism. Rgds, -drc

Small detail: On 6 Jul, 2005, at 16:30, David Conrad wrote:

If IPv6 had actually addressed one or more of routing scalability, multi-homing, or transparent renumbering

These are the same problem, looked at in different ways. The issue is: graph-sorting scalability demands abstraction; abstraction demands abstraction boundaries; abstraction boundaries must be reflected in node names (i.e., locators); nodes are physically portable, topologically portable, or both. To be fair, mass deployment of local wireless LANs for large numbers of people with portable equipment they carry with them from meeting to hotel room to coffee shop to airport lounge to home would not have been the obvious future for anyone in the ROAD process. However, this is today's reality, and the movement of "named things" is more likely to increase than not. "Stretchy LISes" has mostly hidden the physical portable aspect of named things. Bridging is ancient and well-understood. Logical portability happens too, for individual named things and varying-sized collections of them. The stretchy LIS approach works at a cost of header overhead and inefficient traffic flow. The widespread use of VPNs demonstrates this well. The alternative is to deal with disjunctions between the named thing and its topological location. Model A: you go from office to IETF meeting, the IP address you use to talk to the world stays the same, and comes from your office's address space. You use VPN technology to make this happen. Model B: you go from office to IETF meeting, and the IP address you use to talk to the world comes from the IETF meeting's address space. Now go to your hotel room. Model A: your socket-like things are still bound to the office address, and if you walked briskly enough, your sessions are likely still alive when you reconnect to your office with the VPN tech. Model B: oops, you have a new address. You can't use the old address. Your sessions are very likely toast. Good thing there are tools like screen(1) and restartable ftp! The difference between A and B is independent of the header formats, so long as the named thing normally overloads its identity and location. Model A allows for a disjunction between the identity and location, by bridging through the real topology to connect to a distant collection of addresses, abstracted via variable-length prefixes. Model B does not allow for a disjunction in the absence of a session protocol, in which case the session layer identifier is the named thing, and the current IP address is the locator. The session layer does not have to be particularly heavyweight, it does not have to be distinctly "above" the network and transport layers, it does not have to be the only session support available to the other protocols in use between communicating entities. Integrating renumbering-adaptability within the lower (N/T) has some attractions especially with regard to preserving the traditional datagram and octet-stream modes, reducing the peer-to-peer handshaking in the event of renumbering of one of the parties, and in leveraging the current DNS architecture. It would also eliminate the market need for NAT as a tool to assist in -- or avoid -- large-scale simultaneous renumbering as when a single-homed site switches ISPs.

Instead, IPv6 dealt with a problem that, for the most part, does not immediately affect the US market but which (arguably) does affect the other regions. I guess you can, if you like, blame it on the accountants...

People should blame it on the multiplexors. There is lots of scope for multiplexing address use: not everyone is awake and powered on simultaneously; not everyone really does need to accept inbound connections from *everywhere*, at least not all the time; not everyone needs to run a particular service on the same numbered port; some services are fine with uniqueness involving network-layer-addresss+protocol+port(+possible other things). NAT, like other forms of multiplexing the Internet has benefited from (e.g. TDM, WDM, time-sharing operating systems, ...), can allow for more efficient in one's use of limited resources -- in this case, aggregated address space -- in a way accountants seem able to cope with. Yes, TANSTAAFL. Sean.

On 6-jul-2005, at 17:56, Edward Lewis wrote:

The Internet serves society, society owes nothing to the Internet. Members of this list may prioritize communications technology, other members of society may prioritize different interests and concerns. That is why IPv6 must offer a benefit greater than it's cost.

You are approaching the problem at the wrong end by asking "what's in it for me to adopt IPv6 now". The real question is "is IPv6 inevitable in the long run". It's hard to be sure that the answer for that question is "yes", since all kinds of things can happen between now and, say, 2020. But it certainly looks like IPv4 addressing issues are becoming more and more painful over time. For instance, so far this year 98 million IPv4 addresses were assigned or allocated by RIRs. There are currently 1.1 - 1.2 billion usable addresses marked "reserved" (= "unused") by the IANA, so at this rate IANA be flat out in 2011. Now it's possible that the past 6 months were a fluke and it will take twice as long, or it's the start of a new trend and it's going to go even faster. In any event, in the year 2020 we're NOT going to run IPv4 as we know it today. It's possible that the packets that travel over the wires still look like regular IPv4/TCP/UDP packets and all the complexity is pushed out to the application or political/economic layers, but that's not a possibility that appeals to me. So by all means, be an IPv6 hold out as long as you like, but don't assume that just because adopting IPv6 doesn't make economic sense for you now, it isn't going to happen at some point in the next decade. No rush, though.

At 19:23 +0200 7/6/05, Iljitsch van Beijnum wrote: With the chicken little-ing again...

You are approaching the problem at the wrong end by asking "what's in it for me to adopt IPv6 now". The real question is "is IPv6 inevitable in the long run".

Pardon my skepticism, but I recall hearing about the coming of the world due to pollution in the 1970's and the end of the oil supply by the 1980's. (E.g., see http://www.ncpa.org/pub/bg/bg159/ for a discussion on the latter, albeit written before the most recent oil 'scare.') The point isn't whether IPv6 is good or not - it's that long-range predictions are often wrong. For every "memex" (http://www.iath.virginia.edu/elab/hfl0051.html) there's an oil crisis, Ada, GOSIP, economic default of New York City (Ford to City: Drop Dead! - NY Daily News, Oct 30, 1975)...

So by all means, be an IPv6 hold out as long as you like, but don't assume that just because adopting IPv6 doesn't make economic sense for you now, it isn't going to happen at some point in the next decade. No rush, though.

http://www.nanog.org/mtg-0405/augmentation.html Been there, done that, documented and shared results. (Yes, got the T-Shirt too. It was a NANOG, after all.) That wasn't even the first go-round I had with IPv6. My experiences were that IPv6 was painful - I ran into a lot of application bugs, OS's didn't deal with it well, and the ISP's were tough to deal with - as in, not many suppliers, not enough expertise to deliver on promises. Maybe things are better now (note the use of past tense in the previous paragraph), I don't deal with IPv6 at this time. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.

On Wed, Jul 06, 2005 at 09:46:53PM +0200, Iljitsch van Beijnum wrote:

We know how many IPv4 addresses there are. We know how many are unusable (although this number isn't 100% fixed). We know how many were given out. We know how many are given out now each year. What kind of magic do you expect will make this problem that's coming go away? Are there hidden pockets of yet undiscovered address space?

Undiscovered? No. But unless the situation has changed since I last looked (which is possible), there are some sizeable clumps that will never get used by the people who "own" them, which it has not been practicable to reclaim. The tighter the vise, the higher the fence it will be worthwhile to jump to reclaim that space... just like prospecting for oil. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer +-Internetworking------+----------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA http://bestpractices.wikicities.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me

On Jul 7, 2005, at 2:14 PM, Iljitsch van Beijnum wrote:

Right again. And like prospecting for oil, at some point you're burning it up faster than you can prospect it.

There are some 45 - 50 /8s assigned to single organizations. Let's assume for simplicity that those can all be reclaimed. That's 4 years at a /8 a month. So far so good. Then there are 40 - 45 /8s in class B space. That means 256 times as much effort to reclaim the address space, or reclaiming about 10 class Bs a day...

There is, of course, a slightly different model: As IPv4 address space becomes less freely available, there will be an increase in black and gray market transactions for that address space. Since these transactions involve actual money instead of the more difficult to account for human activity dealing with the RIRs or ISPs, there will be financial incentive both to reduce consumption as well as offer allocated but unused space via the black and gray markets. In this model, you get a natural, market-driven evolution towards a two tiered routing hierarchy (call it "the core" and "the edge") mediated by That Which Shall Not Be Named. As folks who "own" address space (yes, I know, address space isn't "owned". I suspect this convention might break down pretty quickly as address space becomes more scarce) figure out there's gold in dem dar unused tracts of address space, they'll make a quick buck selling it to somebody who desires it more (as demonstrated by their willingness to pay the "owner's" price) and moving their infrastructure behind a TWSNBN. Large blocks and provider aggregateable space will command a higher price, long prefix blobs spread out randomly a lower price due to the pain of trying to get it routed. Imagine (to pick an example purely at random) the President of MIT being presented with the choice of receiving a very large wad of cash in exchange for 18/8. How big would that wad have to be before she decided it'd be worth migrating 18/8 to 10/8 and living behind a TWSNBN? Of course, I'm sure this is all just a feverish nightmare caused by a bad habanero pepper... (why do I get a recurring image of Peter Lothberg wandering around the room collecting all the little balls he can?). Rgds, -drc P.S. No, I am not suggesting this is a good or even a likely outcome. Just pointing out that there can be other forces coming into play as scarcity becomes more noticeable.

Rubbish. Many of the organizations that hold legacy /8s are Universities. If a .edu can pick up even a few million dollars from selling off a class A, they will. After all, they could simply sell chunks. $1 per IP address is the going rate, as I understand - not so much for "grey market" transactions, but as a valuation used in merger/divestiture situations. If we simultaneously start making address space fungible (#nanog vocabulary word of the day!) and keep giving it away from the RIRs folks will have a choice. Choice is good. As some point, as address space becomes scarce, it will become more valuable. As it becomes more valuable, people will be willing to spend more money to get addresses. This is basic economics. We have an artificially scarce (but finite) resource - the market can fix our problems. At some point, the cost of buying enough address space for a given service provider or enterprise will become more than the cost of implementing IPv6. The market will then drive v6 implementation. Our system of allocating IP addresses is a cross between soviet-style central planning and FCC spectrum allocation. That doesn't need to occur. We can morph the RIRs into commodity exchanges and solve the following issues: - irritation with RIR procedures for getting address space - justification for address space ("cash is my justification") - worries about running out of address space as folks sell their hoarded space and the market loosens - motivation for shifting to v6 - there will be a real cost to using v4 addresses, but v6 addresses will be free. We can try to regulate the heck out of this, or let the market handle it. To quote Gorden Gecko, "greed is good" - at least for driving IPv6 adoption. - Dan On 7/8/05 5:27 AM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote:

On 8-jul-2005, at 9:42, David Conrad wrote:

...

...

There are some 45 - 50 /8s assigned to single organizations. Let's assume for simplicity that those can all be reclaimed. That's 4 years at a /8 a month. So far so good. Then there are 40 - 45 /8s in class B space. That means 256 times as much effort to reclaim the address space, or reclaiming about 10 class Bs a day...

...

There is, of course, a slightly different model:

...

As IPv4 address space becomes less freely available, there will be an increase in black and gray market transactions for that address space. Since these transactions involve actual money instead of the more difficult to account for human activity dealing with the RIRs or ISPs, there will be financial incentive both to reduce consumption as well as offer allocated but unused space via the black and gray markets.

I'm not saying you're wrong (although the RIRs may do their best to stop the sale of address space, with unknown success), but I'm not sure this will make a huge difference.

There are currently both holders of big chunks of address space, and holders of small chunks of address space, as well as organizations that burn up massive amounts of address space and those that use up very little. I can easily see how it makes sense for the users of relatively small amounts of address space to purchase or lease it from holders of (largely) unused /8s. At $1 per address, buying a /24 rather than jump through RIR hoops is probably a good deal for most people, while at $1 per address selling off your /8 is certainly worth the trouble.

However, I don't think the likes of Comcast (which received 3 /10s or 3/4 of a /8 this year, or more than $12 million worth at our speculated $1/addr) are going to want to spend this kind of money as long as there is ANY chance they can get addresses from the RIRs.

And then, think about it: how much money per address would you have to offer to someone with a spare /24 to part from those addresses? $1? $5? $10? I doubt the big ISPs that burn millions of addresses per year will be interested in that. Suddenly the transition to IPv6 (or recursive NAT...) is going to look very attractive.

So basically the tradeoffs between market forces and regular reclaming are similar: easy for /8s, hard for /16s and close to impossible for /24s.

And the real fun starts when people holding big blocks of address space start holding on to it because they expect to make more money that way in the future...

-- Daniel Golding Network and Telecommunications Strategies Burton Group

According to IANA, (http://www.iana.org/assignments/ipv4-address-space) MIT & MERIT are the two .edu /8 holders on the list. Stanford turned their /8 in a while ago. Many? On Fri, 8 Jul 2005, Daniel Golding wrote:

Rubbish. Many of the organizations that hold legacy /8s are Universities. If a .edu can pick up even a few million dollars from selling off a class A, they will. After all, they could simply sell chunks.

On Tue, Jul 12, 2005 at 08:41:04AM +0300, Hank Nussbacher wrote:

At 12:24 PM 11-07-05 -0400, Rich Emmings wrote:

...

According to IANA, (http://www.iana.org/assignments/ipv4-address-space) MIT & MERIT are the two .edu /8 holders on the list. Stanford turned their /8 in a while ago.

And I'm still holding my breathe to see when a commercial company returns their /8. -Hank

its already happened... over a dozen have been returned. --bill

...

Many?

On Fri, 8 Jul 2005, Daniel Golding wrote:

...

Rubbish. Many of the organizations that hold legacy /8s are Universities. If a .edu can pick up even a few million dollars from selling off a class A, they will. After all, they could simply sell chunks. +++++++++++++++++++++++++++++++++++++++++++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC.

At 11:52 PM 11-07-05 -0700, william(at)elan.net wrote:

On Tue, 12 Jul 2005 bmanning@vacation.karoshi.com wrote:

...

On Tue, Jul 12, 2005 at 08:41:04AM +0300, Hank Nussbacher wrote:

...

At 12:24 PM 11-07-05 -0400, Rich Emmings wrote:

...

According to IANA, (http://www.iana.org/assignments/ipv4-address-space) MIT & MERIT are the two .edu /8 holders on the list. Stanford turned their /8 in a while ago.

And I'm still holding my breathe to see when a commercial company returns their /8. -Hank

its already happened... over a dozen have been returned.

List that dozen blocks please or I'll not believe it. (I can only see 3 blocks that have been returned)

Why then single out Stanford's 36/8 with "Formerly Stanford University - Apr 93" and all other dozen commercial companies remain anonymously returned? -Hank

-- William Leibzon Elan Networks william@elan.net +++++++++++++++++++++++++++++++++++++++++++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC.

On Wed, Jul 06, 2005 at 09:46:53PM +0200, Iljitsch van Beijnum wrote:

It's getting better all the time, but there are still strange bugs in the applications, OSes and even the standards. IPv6 works very well for many things but not so well for others. Fortunately, there is still plenty of time to work out all the kinks before we need IPv6 to step up to the plate. In the mean time, we need SOME IPv6 so that the early adopters can find those kinks, and that part is right on track.

How are people making the case for IPv6 with popular applications like voice? With G.711 and 20ms voice samples, with IPv4 you get: 20 bytes IP + 8 bytes UDP + 12 bytes RTP + 160 bytes payload 20% overhead. Now with IPv6. Say we use shim6 or something like that to implement multihoming too. The shim6 header isn't decided yet, but I suppose it's got to contain at least a pair of addresses (32 bytes). 40 bytes IP + 32 bytes shim6 8 bytes UDP + 12 bytes RTP + 160 bytes payload 36.5% overhead Almost twice as much overhead is a much tougher pill to swallow. I would try to stay with IPv4 as long as I could. Even without adding shim6 into the picture you're taking a significant penalty. -Phil

With G.711 and 20ms voice samples, with IPv4 you get:

20 bytes IP + 8 bytes UDP + 12 bytes RTP + 160 bytes payload 20% overhead.

Now with IPv6. Say we use shim6 or something like that to implement multihoming too. The shim6 header isn't decided yet, but I suppose it's got to contain at least a pair of addresses (32 bytes).

40 bytes IP + 32 bytes shim6 8 bytes UDP + 12 bytes RTP + 160 bytes payload 36.5% overhead

hey! we charge by the byte. so ipv6 is looking better and better!

On Tue, Jul 12, 2005 at 09:35:37PM -0400, David Andersen wrote:

samples to squeeze into a low bandwidth channel. Enter IP header compression, which is shockingly effective at compressing IP headers of all sorts... if you've dedicated 128 bits for the address, and it's still just as static as it was in IPv4, it'll compress to just the same amount. This is an easy technical problem to solve.

IP header compression only works well over a link where you have few flows (fewer than the number of slots for compression) so my customers get to save some bandwidth on their access links and I get the privilege of wasting a lot in the core. But I certainly take Iljitsch's point: maybe I'm complaining about VoIP, not about IPv6. -Phil

Just spent the evening catching upon NANOG reading. IPv6, NAT, VoIP, address reclamation and routing scalability all in one thread - WOW. Truly a nice mix of top NANOG argument. Even one posting on sloppy IPv6 peering policy! So how many who write against IPv6 have tried it? For any who use IPv6, I am interested in NAT/PT, 6to4, faith and DSTM experiences. Drop me a line if your willing to share your data. A few years ago I set up my home network with OS X, XP, and FreeBSD on it to run dual stacked IPv6/IPv4 - Set up a tunnel - The autoconf works IMHO better than DHCP - I can watch the Kame swim on all systems. Yeah I know deploying IPv6 on a large scale is an annoying thought, but I think some of the resistance to IPv6 is more from "don't bother me, I'm busy" than any hard fast technological reason. I do buy the market arguments that it will be driven by customer demand, especially in the US. I also side with the view that IPv6 appears to be gaining traction. USG is the 600lb gorilla customer and network provider will take notice. I have tasted the IPv6 forum cool-aide, and don't think its all that bad. The stuff is starting to work. I am beginning to think that you soon will be able to swap 6 for 4 and user will not be the wiser. Perhaps the cool-aide is spiked? -- Joseph T. Klein PSTN: +1 414 961 1690 VoIP: +1 414 431 4231 Mobile: +1 414 628 3380

Iljitsch van Beijnum <iljitsch@muada.com> writes:

You are approaching the problem at the wrong end by asking "what's in it for me to adopt IPv6 now". The real question is "is IPv6 inevitable in the long run".

Death is inevitable "in the long run", but "end it all today" is probably not the proper answer. ---Rob

On Thu, 2005-07-07 at 10:39 -0400, Scott McGrath wrote:

1 - Get new (non-multihomed) address space from each of our upstreams

You mean from Abilene or get your own PA space? What is so odd about this, a number of other universities* already did this. Oh and for people in the ARIN region getting it is gratuit for the time being when you already have IPv4 space. * = see the list at http://www.sixxs.net/tools/grh/dfp/all/

2 - Replace network elements with IPv6 compatible network elements and S/W

On a per-link basis, start with tunnels where needed, go native later on or rather directly when possible. Most Cisco's can be upgraded to support IPv6, JunOS supports it too, though they now suddenly require some absurd fee especially for IPv6. For most layer2 setups getting IPv6 working is really a matter of upgrading the kernels or just enabling it.

3 - Convince all the researchers to dump all their instruments and buy new ones

Why? They can gradually upgrade when time and need arises. There is no flagday on which IPv4 disappears and IPv6 suddenly takes everything over. Also nobody is forcing you to, but it might be smart to do it while you have time and not when somebody demands it from you to do it yesterday ;)

4 - Retrain entire staff to support IPv6

You have to train people to drive a car, to program a new VCR etc. What is so odd about this?

No matter how hard I try I just am not going to be able to make any cogent argument which will allow the implementation of IPv6 since it appears to offer no benefits to the user community which in my case is extremely well informed on technologies which will benefit their research.

Maybe not at this time but it will later. Harvard is of course also one of the lucky fews having a /8 at their disposal for playing around.

The best I can hope for is IPv4 to IPv6 gateways.

Which exist, eg http://ipv6gate.sixxs.net ;) And you can also make them yourself easily of course. Greets, Jeroen

On Thu, 2005-07-07 at 18:02 +0200, Andre Oppermann wrote:

Jeroen Massar wrote:

...

On Thu, 2005-07-07 at 10:39 -0400, Scott McGrath wrote:

...

4 - Retrain entire staff to support IPv6

You have to train people to drive a car, to program a new VCR etc. What is so odd about this?

I had training to drive a car once in my life when I got my drivers license. I don't have to get a fresh training for every new car I end up driving throughout my life.

You will have to get an additional license for driving a truck or even when you are getting a caravan behind that car of yours though. Motorbikes also have different licenses and you get separate trainings for those. They all have wheels, look the same, operate somewhat the same, but are just a little bit different and need a bit different education. You also either read something, educated yourself or even got a training to operate IPv4 networks, now you will just need a refresh for IPv6. You can opt to not take it, but then don't complain you don't understand it. For that matter if you don't understand IPv6 you most likely don't IPv4 (fully) either.

If I need training to program my new VCR then the operating mode of that VCR is broken and I'm going to return it asap.

Then a lot of VCR's will be returned because if there is one thing many people don't seem to understand, even after reading the manual then it is a VCR.

It's that simple. Why are people buying iPod's like crazy? Because these thingies don't require training. People intuitively can use them because the GUI is designed well.

So you didn't read the manual of or train yourself to use your compiler| bgp|isis|rip|operatingsystem|.... and a lot of other things ? IP networks are not meant for the general public, they only care that the apps that use it work, they don't type on routers. Protocols don't have GUI's or do you have a point and click BGP? :) Greets, Jeroen

On the training issue. Everybody in our organization understands IPv4 at some basic level. The senior staff here myself included are conversant with IPv6 but you have the level 1 and 2 people who for the most part are not even aware IPv6 exists and there are a LOT more of them then there are of us and these are the people who are going to get their world rocked and who will need extensive training to be effective in a IPv6 world. Scott C. McGrath On Thu, 7 Jul 2005, Jeroen Massar wrote:

On Thu, 2005-07-07 at 18:02 +0200, Andre Oppermann wrote:

...

Jeroen Massar wrote:

...

On Thu, 2005-07-07 at 10:39 -0400, Scott McGrath wrote:

...

4 - Retrain entire staff to support IPv6

You have to train people to drive a car, to program a new VCR etc. What is so odd about this?

I had training to drive a car once in my life when I got my drivers license. I don't have to get a fresh training for every new car I end up driving throughout my life.

You will have to get an additional license for driving a truck or even when you are getting a caravan behind that car of yours though. Motorbikes also have different licenses and you get separate trainings for those. They all have wheels, look the same, operate somewhat the same, but are just a little bit different and need a bit different education.

You also either read something, educated yourself or even got a training to operate IPv4 networks, now you will just need a refresh for IPv6. You can opt to not take it, but then don't complain you don't understand it. For that matter if you don't understand IPv6 you most likely don't IPv4 (fully) either.

...

If I need training to program my new VCR then the operating mode of that VCR is broken and I'm going to return it asap.

Then a lot of VCR's will be returned because if there is one thing many people don't seem to understand, even after reading the manual then it is a VCR.

...

It's that simple. Why are people buying iPod's like crazy? Because these thingies don't require training. People intuitively can use them because the GUI is designed well.

So you didn't read the manual of or train yourself to use your compiler| bgp|isis|rip|operatingsystem|.... and a lot of other things ?

IP networks are not meant for the general public, they only care that the apps that use it work, they don't type on routers. Protocols don't have GUI's or do you have a point and click BGP? :)

Greets, Jeroen

Jeroen Massar wrote:

...

2 - Replace network elements with IPv6 compatible network elements and S/W

On a per-link basis, start with tunnels where needed, go native later on or rather directly when possible. Most Cisco's can be upgraded to support IPv6, JunOS supports it too, though they now suddenly require some absurd fee especially for IPv6. For most layer2 setups getting IPv6 working is really a matter of upgrading the kernels or just enabling it.

The problem are printers, thermometers, cameras, barcodescanners or in case of the person you are replying to: strange scientific instruments (I guess). Nils

A better question would be "What services does the competition offer via IPv6?" If the answer is "none" then how long will that situation last? What point along the adoption curve do you want to be?

that's simple, when it makes money, the kind that shows up on the p/l. when will that happen and why? randy

[reply to Andre below this one] On Thu, 2005-06-30 at 20:37 -0400, Todd Underwood wrote:

On Thu, Jun 30, 2005 at 01:21:33PM -0400, Edward Lewis wrote:

...

Having been in the US gov't (too) at the time of GOSIP, there were three reasons why I never used it much: [...] 3) There was no tidbit of information available over the network that was on a server that spoke only GOSIP and not TCP/IP. (No compelling reason.)

this is telling in this context.

where is the service that is available only on IPv6? i can't seem to find it.

http://ipv6gate.sixxs.net which allows you to see the silly dancing turtle, it is swimming actually, but you didn't know as you didn't see it :) Oh that thing allows one to see IPv4 sites when having IPv6 only and seeing IPv6 sites when having IPv4 only: http://www.kame.net.sixxs.org or http://www.kame.net.ipv6.sixxs.org for the Dancing Kame when on IPv4, getting the IPv6 site http://www.google.com.ipv4.sixxs.org for google, who don't do IPv6 yet. As for the questions "who uses IPv6", I can tell you that that gateway is making a certain politically-restricted group very happy to be able to see/read/use various internet sites they are not capable of using when using their normal IPv4 setup.

maybe that's because i use the Internet for my daily activities (as does everyone else, including people in asia) rather than some non-internet, incompatible, no-migration-plan-protocol-based network.

I am very happy to have been using IPv6 for over the last 5 years to be able to overcome, just as the above, silly policies which where laid upon me by goverments and monopolies. read: getting only 1 IP address while I have way more than 1 IP-addressable endpoint at my home.

manually configured tunnels forver! (until we stop caring or come up with a real reason to migrate to something else, by which plan maybe we can have a migration plan and a better protocol suite with multi-homing).

You mean automatically configured tunnels. Most people don't understand what tunneling is, they do know how to click a couple of times in a GUI. google(aiccu) ;) On Fri, 2005-07-01 at 12:14 +0200, Andre Oppermann wrote:

Fred Baker wrote:

...

The point made in the article that Fergie forwarded was that Asia and Europe are moving to IPv6, whether you agree that they need to or not, and sooner or later we will have to run it in order to talk with them.

Huh, Europe is moving to IPv6? I must have been asleep at all industry meeting in the past few month and years...

Ah, well that explains indeed why you are missing out on it. Read up at: http://www.sixxs.net/tools/grh/dfp/

The problem with IPv6 is that it is broken by design and doesn't solve a thing that needs to be solved. In addition various policies around IPv6 intermix layers that don't want to me mixed.

You still have not explained the "broken by design" stuff. Can you do it once? As for the policies, those will resolve themselves, at the moment it is steering into a "announce as few prefixes as possible, but you can announce upto a /48". Which sounds quite reasonable. The hardware can handle it anyway.

I'm going out on a limb here but IMO IPv6 would have been a big success if it would just have extended the IP header to 64bit addresses and rearranged the fields to be well aligned (modulo kicking header checksum and some other clarifications).

For various reasons, amongst that feature called autoconfiguration, 128bits are more appropriate. Actually IPv6 is 64-bits, at least on the routing level. That the endstretch checks the latter 64 bits where to put it on the l2 link is something you could just forget for simplicity sake.

Then directly integrate IPv4 into that namespace for a relativly clear and transparent transition path and be done with it.

You mean ::192.0.2.1 and ::ffff:192.0.2.1 ? Any idea how irritating those two are for programmers? One has a listening server and does a accept() and then a getpeername() to retrieve where the remote host is, you get an IPv6 address back, which you suddenly have to be parsing as a IPv4 one, because you wanted to do ACL matches. Now that is impractical, one can code around it but still. read http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html for the solution btw. The transition part is very clear, there are just many options because there are actually people who have different networks than what you might expect. The clear way: 0) we have IPv4 only boxes 1) add IPv6 stack to the boxes 2) turn on IPv6 on the network - using tunnels where l2 paths don't support it - using native where it does support it 3) upgrade the tools to support IPv6 4) co-exist IPv4 and IPv6 Nopes, I am not putting in a 'turn off IPv4', that is not going to happen in the coming couple of decenias.

All the other stuff and the different address scopes are not only impractical but confuse the average consumer and MCSE admin to no end (and those are the people that have to deal with it all the time).

Why are they impractical? The only address scopes you have is: - link local, compare it to your l2 mac address, it is mostly the same anyway - global unicast, which is the same as IPv4 unicast Then you also have multicast and ula's. What is so weird here? I've never found them impractical, did you ever tried to use them?

return (ENOKITCHENSINK);

If you don't have a kitchensink then you can always go to a restaurant ;) Fortunately the internet can live and work around missing components. And when you don't like it, write up a paper how you do think it would work and call it IPv8 or IPv16, but that was proposed quite some time ago by somebody who is fortunately gone silent. Greets, Jeroen PS: preparing food, and devouring it after and during it, is a lot fun, I suggest you try it one time, so go get your self a kitchensink :)

On Thu, 30 Jun 2005 14:02:33 GMT "Fergie (Paul Ferguson)" <fergdawg@netzero.net> wrote:

...

Just in case anyone was wondering, U.S. gummint agencies will be screaming in migration agony for the next couple of years. ;-)

http://www.fcw.com/article89432-06-29-05-Web

Well, when I was in the "gummint", we used to get these missives all the the time. (My personal favorite was the one that said that US Navy had to conduct all email over Outlook for security reasons.)

We waivered or ignored every one.

So I wouldn't count on this, either.

Regards Marshall Eubanks

Then there was, about 1989 or 1990, the one that all Military IT purchases had to be OSI Compliant TP0/CLNP Anybody? Regards. Ted Fischer

...

- ferg

-- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg@netzero.net or fergdawg@sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/