Important IPv6 Policy Issue -- Your Input Requested

Mailman List Mirror (Read Only)
1

I would like to bring to the attention of Nanog an IPv6 policy issue
that I think is slipping under the radar right now.

The IETF IPv6 working group is considering two proposals right now
for IPv6 "private networks". Think RFC-1918 type space, but redefined
for the IPv6 world. Those two drafts can be found at:

http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-07.txt
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-00.txt

These drafts came up in the ARIN meeting, and I posted my analysis of
the problems with both at:

http://www.arin.net/mailing_lists/ppml/2849.html

I will post a very brief summary of my objections, for the first
(unique-local):

   - I believe the math is wrong on the rate of collisions, primarily
     because it assumes in a large organization there is a central
     coordination function to pick and distribute these addresses.
     However, since the whole point of "unique local" addresses is that
     there need be no coordination, I can easily see a case where a
     large conglomerate (Ford, GE, whatever) coming together with
     another will have both sides bringing hundreds, if not thoundsands
     of prefixes to the table as each division or other subgroup picks
     their own.

   - I think the likelyhood people will use the suggested hash methods
     to pick addresses is extremely low. People will either pick "human
     friendly" (1, 2, 3, 4, etc) or treat the space more like CIDR
     (where there is central delegation), both of which move the
     likelyhood of collision to near 1.

   In the end I think we need 1918 style space, and that it should
   simply be set aside as a large block and expected to never be
   useful in the context of other organizations, just like 1918
   space is today.

The second proposal (ula-central) is much more dangerous.

   - It is not good engineering to give something away for free with no
     method of recovery, even if that resource is plentiful.

   - The IETF should not be creating a new worldwide RIR.

   - The IETF should not be dictating fees (free).

     (more to the point, a worldwide RIR, with the language and other
     issues will be expensive, yet it has no method of income)

   - Since this is a free method of globally unique space it has a high
     likelyhood of being routed on portions of the public internet.
     Indeed, this problem was quickly dismissed by the authors
     (see http://www1.ietf.org/mail-archive/web/ipv6/current/msg03848.html),
     who completely missed the boat. It's not the rich who would demand
     their prefix be routed, but the poor. We already have situations
     where parts of Africa and Asia claim the fees for IP space are too
     high. If they had access to "free" "global" space they would jump
     on it, and later if the rest of the world wanted to contact that
     region they would almost certainly have to route it as well.

   - The "ownership should be private", yet the reason for a registry
     is to verify ownership and prevent hoarding. I'm not sure how those are
     combatable.

   - I think the IPv6 groups continue in their fantasy that people will
     manage multiple, complete overlay networks to fix numbering issues.

More to the point, it seems to me the working group is highly
enterprise focused, and seems to want to give enterprises what
they (think) they want with little concern for how it impacts the
global Internet.

Since this is a list of providers, I encourage you to read the
drafts, and submit your comments to the working group. The information
for the working group is at
http://www.ietf.org/html.charters/ipv6-charter.html, and includes
their mailing list archives and information on how to subscribe
and/or post.

Even if you disagree with me, much like voting the important thing is
that you voice your opinion.

2

Just out of interest, why do you think 1918-style space for v6 is needed?

Joe

3

In a message written on Mon, Nov 08, 2004 at 02:36:21PM -0500, Joe Abley wrote:

Just out of interest, why do you think 1918-style space for v6 is
needed?

I think people have found many good uses for IPv4 1918 space, and
that it is likely they would want to migrate those applications as
directly as possible to IPv6. Since supporting that sort of migration
does not require a huge amount of address space or burden on the
addressing processes, I see no reason not to have 1918 space in
IPv6.

However, both of these proposals go well beyond how 1918 space works
today, and both make promises of "global uniqueness" that are at
best inappropriate, at worst a road to disaster.

4

In a message written on Mon, Nov 08, 2004 at 02:36:21PM -0500, Joe Abley wrote:

Just out of interest, why do you think 1918-style space for v6 is
needed?

I think people have found many good uses for IPv4 1918 space, and
that it is likely they would want to migrate those applications as
directly as possible to IPv6.

I don't know of any applications that require RFC1918 addresses to be deployed. (Clearly, this is not to say there are none.)

I know of lots of networks that use RFC1918 addresses because of a (perceived, whatever) scarcity of IPv4 addresses, but presumably that argument doesn't necessarily follow for v6 networks, where ever customer site gets a /48.

There is some value in RFC1918 addresses being used in v4 in cases where an extensive internal infrastructure is expensive to renumber, and PI addresses are not available. It is not clear that RFC1918 addresses are the only solution to this problem, though.

Since supporting that sort of migration
does not require a huge amount of address space or burden on the
addressing processes, I see no reason not to have 1918 space in
IPv6.

This sounds like a direct path to IPv6 NAT.

However, both of these proposals go well beyond how 1918 space works
today, and both make promises of "global uniqueness" that are at
best inappropriate, at worst a road to disaster.

Agreed, the proposals (as you outlined; I haven't read them) sound like they are full of holes.

However, I worry about any natural assumption that RFC1918-like addresses are required for v6, simply because they are used in v4: it seems to me that the major reason to deploy v6 is to eliminate the very address scarcity that RFC1918 addresses are used to mitigate.

Perhaps the non-availability of RFC1918 addresses would provide a useful incentive for future v6 network architects to install globally-unique addresses on all hosts? Perhaps I am the only one that thinks that would be a good thing :wink:

Joe

5

Hello,

I must admint, I'm really not up on the more subtle aspects of v6 addressing
nor have I read the drafts you posted, but I've never understood why we needed
a new set of RFC1918-like IPv6 space. Wouldn't 0::10.0.0.0/104,
0::192.168.0.0/112, and 0::172.16.0.0/116 (or whatever the appropriate masks
would be) all function as v6 addresses with exactly the same properties at the
current RFC1918 space?

Eric :slight_smile:

6

In a message written on Mon, Nov 08, 2004 at 03:08:13PM -0500, Joe Abley wrote:

I don't know of any applications that require RFC1918 addresses to be
deployed. (Clearly, this is not to say there are none.)

By "applications" I did not mean "software programs" but rather
"methods of designing networks".

I know of lots of networks that use RFC1918 addresses because of a
(perceived, whatever) scarcity of IPv4 addresses, but presumably that
argument doesn't necessarily follow for v6 networks, where ever
customer site gets a /48.

A company may change providers often and want to use 1918 style space
to not have to renumber part of the network, or may choose IPv6 NAT
as superior to overlay networks. Indeed, I suspect overlay networks
are going to be hugely unpopular.

This sounds like a direct path to IPv6 NAT.

While I do not encourage IPv6 NAT, anyone who thinks IPv6 will put the
NAT Genie back in the bottle is smoking some serious crack. Lots of
people like NAT for lots of reasons, and I am 100% positive there will
be IPv6 NAT used by a lot of people.

One obvious use if these proposals pass is to use your non-routable
global unique prefix internally and NAT at the borders. Since a lot
of people think this is effective security, I think it will be a common
configuration.

Perhaps the non-availability of RFC1918 addresses would provide a
useful incentive for future v6 network architects to install
globally-unique addresses on all hosts? Perhaps I am the only one that
thinks that would be a good thing :wink:

Many people share your opinion, and I think it is a good one to
voice. That said at the end of the day most engineers are going
to treat IPv6 as "IPv4 with bigger addresses". I know most of the
IPv6 proponents just wrote me off as a loon by saying that, but I
do believe it's reality and you need look no further than the
existing test networks to see that it's the case. People who have
become used to CIDR, and NAT and such aren't going to forget those
idea's because someone told them "rigid boundaries are good" and
"you don't need private space anymore".

7

You're definitely not alone with this feeling :-). It's just that there are some conceivable scenarios, like intermittent connectivity (+local connectivity during the outage) which seems to call for either local addressing or global PI addressing, and the latter has not gained much momentum..

IPv6 site multihoming for bigger enterprises is also one area where (at the moment) something like ULAs have some questionable uses.

8

Well, you asked the original poster, but since you asked publicly, I'll answer with my reasons.

Reason #1: Lab use. People should NEVER, EVER pick random space from public space for doing experiments in the lab. Sooner or later something leaks, and people get really honked off. This happened a LOT with IPv4, prior to RFC 1597 and 1918. Let's not repeat the same mistake, and make sure people have a specific place to get address space from for experiments.

Reason #2: Disjoint networks: though we may think the only reason to use the IP protocol suites (v4 or v6) is to connect to other places in the world, there are networks which do not (or are at least not supposed to) intersect with the public Internet. Address allocation policies are based on what space you're going to advertise, and registries want money for the space. Networks that are not connected should be able to use the IP protocol suites too.

Reason #3: A separate set of blocks should be set aside for use ONLY in documentation. Otherwise people use whatever addresses are in the examples in their router manuals and leak packets. I was seeing RIP packets claiming to come from 128.185/16 the entire time in the 1990's I worked at Proteon. Of course implementing BCP38 would help with the misconfigured user networks that were spewing that stuff. Nonetheless, documentation examples are a legitimate case for which space should be set aside.

Reason #4: Initial configuration of equipment which lacks a console port. I know, you're going to suggest the use of autoconfiguration mechanisms or DHCP. That's sometimes hard, for example in the case of a broadband "router" (home gateway) box that's going to be the DHCP server, print servers, and other such equipment. Having some block for this (or just use some subnet of the RFC-1918-like space) is a reasonable use.

9

I must admint, I'm really not up on the more subtle aspects of v6
addressing nor have I read the drafts you posted, but I've never
understood why we needed a new set of RFC1918-like IPv6 space.

because there is not enough v6 address space?
because we like nats?
because we think we can't get space?

randy

10

> I must admint, I'm really not up on the more subtle aspects of v6
> addressing nor have I read the drafts you posted, but I've never
> understood why we needed a new set of RFC1918-like IPv6 space.

because there is not enough v6 address space?
because we like nats?

There's no PI (yet) for IPv6, so NAT becomes necessary again. People
don't like to give up the independence they have in IPv4 world.

because we think we can't get space?

For non-ISPs this is fact, given that there is no PI (yet). ISPs are
allowed to multihome and have their independent address space, other's
are told to be happy with vendor lock-in.

IPv6 won't fly like that. But that's no news, but still heads are
sticking deeply in the sandbox, unfortunately.

Regards,
Daniel

11

Reason #3: A separate set of blocks should be set aside for use ONLY in
documentation.

inet6num: 2001:0DB8::/32
netname: IPV6-DOC-AP
descr: IPv6 prefix for documentation purpose
[...]
remarks: This address range is to be used for documentation
remarks: purpose only. For more information please see
remarks:
http://www.apnic.net/info/faq/ipv6-documentation-prefix-faq.html

Reason #4: Initial configuration of equipment which lacks a console port. I
know, you're going to suggest the use of autoconfiguration mechanisms or
DHCP. That's sometimes hard, for example in the case of a broadband
"router" (home gateway) box that's going to be the DHCP server, print
servers, and other such equipment.

I don't see that this is "hard". The box will get a /48 from the ISP's
DHCPv6 server (or whatever is used for that) and re-use subnets for
that for inside routing. Like simply the first /64, and doing router
advertisements on the inside ethernet for this subnet to allow
autoconfig of the hosts of the home LAN.

Regards,
Daniel

12

Reason #1: Lab use. People should NEVER, EVER pick random space from public space for doing experiments in the lab. Sooner or later something leaks, and people get really honked off. This happened a LOT with IPv4, prior to RFC 1597 and 1918. Let's not repeat the same mistake, and make sure people have a specific place to get address space from for experiments.

Sure, though see #3 which can be stolen for lab usage as well.

Reason #2: Disjoint networks: though we may think the only reason to use the IP protocol suites (v4 or v6) is to connect to other places in the world, there are networks which do not (or are at least not supposed to) intersect with the public Internet. Address allocation policies are based on what space you're going to advertise, and registries want money for the space. Networks that are not connected should be able to use the IP protocol suites too.

For serious usage, I don't think the money involved is a major issues.

Reason #3: A separate set of blocks should be set aside for use ONLY in documentation. Otherwise people use whatever addresses are in the examples in their router manuals and leak packets. I was seeing RIP packets claiming to come from 128.185/16 the entire time in the 1990's I worked at Proteon. Of course implementing BCP38 would help with the misconfigured user networks that were spewing that stuff. Nonetheless, documentation examples are a legitimate case for which space should be set aside.

Already done, 2001:db8::/32 is set aside for documentation.

Reason #4: Initial configuration of equipment which lacks a console port. I know, you're going to suggest the use of autoconfiguration mechanisms or DHCP. That's sometimes hard, for example in the case of a broadband "router" (home gateway) box that's going to be the DHCP server, print servers, and other such equipment. Having some block for this (or just use some subnet of the RFC-1918-like space) is a reasonable use.

Setting up local v6 addressing for this reason seems like a bad idea because there is no NAT and no global connectivity, so the box will need some automated configuration protocol in any case.

13

I must admint, I'm really not up on the more subtle aspects of v6
addressing nor have I read the drafts you posted, but I've never
understood why we needed a new set of RFC1918-like IPv6 space.

because there is not enough v6 address space?
because we like nats?

There's no PI (yet) for IPv6, so NAT becomes necessary again. People
don't like to give up the independence they have in IPv4 world.

because we think we can't get space?

For non-ISPs this is fact, given that there is no PI (yet). ISPs are
allowed to multihome and have their independent address space, other's
are told to be happy with vendor lock-in.

IPv6 won't fly like that. But that's no news, but still heads are
sticking deeply in the sandbox, unfortunately.

let me see if i understand. you propose a technical cluster
<bleep> with which we are already horrifyingly familiar to fix
an administrative problem? have i got it right?

randy

14

No, you didn't. I didn't propose anything, and especially not NAT.
I just reflect realities out there.

Personally, I just wait for people to realize that they won't be
able to force people into provider lock-in, allow one PI prefix per
AS and THEN things can go off. With that, the global IPv6 table
would be around 18k routes btw. As IPv4 and ASN are virtually
unrestricted available today, I don't suspect any bigger growth
rates in IPv6 land for ASNs and prefixes than in the IPv4 land.
As such, I fail to see the problem with PI for IPv6 for a long long
time to come.

But that's just me silly. :slight_smile:

And yes, I read multi6 WG.

Regards,
Daniel

15

Well, thinking about the enterprise for a change might be a good idea,
as the Enterprise markets are the one paying most of the ISPs in the
end. And with the ISP-centric approach of the current address
policies there is absolutely no chance IPv6 will ever make it to the big
market.

As long as I can neither multihome nor NAT my network, I have no chance to
be independant of a provider. As the provider business itself is extremely
unstable that is something no enterprise can possibly want.

So there must be a way to be provider independent on my
network, otherwise I am pretty much doomed. I do hate NAT and I think it
is a major pain. Providers decided (they are the ones active
in the working groups on Address policies, remember?) that their customers
should not be able to be multihomed, because the equipment to handle this
is too expensive, so I at least want a globally unique private address,
so I do not have to double NAT, when I connect my network to
some customers or suppliers network.

I agree, that the proposed solutions are not perfect, but they at least
give enterprise network admins the chance to do the right thing.
With RfC1918 (shall we call it site local addressing, maybe?) I am
almost forced to use the same address space as
my customers and suppliers do. The two approaches mentioned only will give
collisions, when one side uses them inappropriately. I think
having the chance to do it right is better then not having it.

Nils

16

I will post a very brief summary of my objections, for the first
(unique-local):

   - I believe the math is wrong on the rate of collisions, primarily
     because it assumes in a large organization there is a central
     coordination function to pick and distribute these addresses.
     However, since the whole point of "unique local" addresses is that
     there need be no coordination, I can easily see a case where a
     large conglomerate (Ford, GE, whatever) coming together with
     another will have both sides bringing hundreds, if not thoundsands
     of prefixes to the table as each division or other subgroup picks
     their own.

Well, if they can manage to interconnect all those networks a tiny amount of coordination isn't too much to ask for. Also, with the proper hashing this shouldn't be much of a problem even without coordination. Yes, no coordination and bad hashing won't work, but guess what: don't do that.

   - I think the likelyhood people will use the suggested hash methods
     to pick addresses is extremely low. People will either pick "human
     friendly" (1, 2, 3, 4, etc) or treat the space more like CIDR
     (where there is central delegation), both of which move the
     likelyhood of collision to near 1.

   In the end I think we need 1918 style space, and that it should
   simply be set aside as a large block and expected to never be
   useful in the context of other organizations, just like 1918
   space is today.

Your argument is that people are going to be stupid so we should skip ahead and give them the result of their stupidity. Now obviously there will be people who do it the stupid way, but at least unique site locals allow the people who don't do it the stupid way certain benefits. I don't see how this can ever be a bad thing.

Also, you can still use the original IPv6 site local space, as I don't see it being reused for something else any time soon. But if you do, you'll probably discover that there is a reason why the IETF decided to deprecate those.

   - It is not good engineering to give something away for free with no
     method of recovery, even if that resource is plentiful.

So we should play telco and sell a service that is so cheap that the users are basically only paying for the billing? (= metered local calls)

   - Since this is a free method of globally unique space it has a high
     likelyhood of being routed on portions of the public internet.
     Indeed, this problem was quickly dismissed by the authors
     (see Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-07.txt),
     who completely missed the boat. It's not the rich who would demand
     their prefix be routed, but the poor.

That's nice. But it simply can't be done for any significant number of PI prefixes. That's why we're going through so much trouble to create a multihoming mechanism that doesn't kill the routing system.

Since this is a list of providers, I encourage you to read the
drafts, and submit your comments to the working group. The information
for the working group is at
IP Version 6 Working Group (ipv6), and includes
their mailing list archives and information on how to subscribe
and/or post.

Even if you disagree with me, much like voting the important thing is
that you voice your opinion.

I suggest that everyone who is willing to spend the time, also looks into the "site local" debates that have plagued the IETF in recent years.

17

In a message written on Mon, Nov 08, 2004 at 10:46:48PM +0100, Iljitsch van Beijnum wrote:

Well, if they can manage to interconnect all those networks a tiny
amount of coordination isn't too much to ask for. Also, with the proper
hashing this shouldn't be much of a problem even without coordination.
Yes, no coordination and bad hashing won't work, but guess what: don't
do that.

It is too much to ask for, because you assume it's one company day
one. What happens when AOL and Time Warner merge? There was no
chance of coordination before that. Or how about Cisco? They buy
what, 100-200 companies a year?

My problem is that even with good hashing it doesn't take long for
there to be a collision. And once there is a single collision the
whole system is suspect. It's the promise of "if you do this extra
work you'll never have to renumber" without delivering.

Your argument is that people are going to be stupid so we should skip
ahead and give them the result of their stupidity. Now obviously there
will be people who do it the stupid way, but at least unique site
locals allow the people who don't do it the stupid way certain
benefits. I don't see how this can ever be a bad thing.

No, my argument is that it only takes a few stupid people to make
this entire system not work at all. Since the draft seems to promise
it will work it is misleading people. Indeed, I have "proof" the IPv6
crowd realizes this won't work at all, and it's the other draft. If
this draft had a chance of working then there would be no need to create
a central registry to guarantee unique addresses. The very existence of
that draft shows some people realize this method will not work.

> - It is not good engineering to give something away for free with no
> method of recovery, even if that resource is plentiful.

So we should play telco and sell a service that is so cheap that the
users are basically only paying for the billing? (= metered local
calls)

No. My argument is not about money. In this system anyone can get
something for free anytime they want. "Lose" your address block?
Make it unusable for some purpose (eg, blacklisted)? Just want a
second (third, fourth, millionth) block, just go get it. Get a block,
then die? Well, no one else can ever use your personal block.

If you get a personal block, then die, no one else can ever reuse that
block. Every failed dot-com, that's address space we'll never be able
to use again. I realize there is a lot of space, but this proposal
really seems to ask the question "how fast can we waste space if we
try", which is very dangerous in my opinion.

That's nice. But it simply can't be done for any significant number of
PI prefixes. That's why we're going through so much trouble to create a
multihoming mechanism that doesn't kill the routing system.

Bah, hand-waving that makes no sense.

There are 33,000 allocated ASN's today. Give each one a PI prefix
(however they might get it). That's 33,000 routes. Given my routers
are fine with 140,000 now, and are being tested in labs to well
over 1 million and I fail to see the issue. Let's assume they all
have two PI prefixes for load balancing, ok, we're at 66,000, still
no problem.

More to the point, if most network admins have the choice of running a
full overlay network and updating software on every end host to be more
complex to make it understand the overlay networks or puting a few more
prefixes in the routing table and upgrading your router I bet they will
all pick the latter.

The problem is not routing PI blocks for all the existing ISP and even
companies. The problem is routing blocks for individuals. If ISP's
fall to pressure to route these prefixes between themselves (after all,
they are globally unique, so what's the harm?) and then you inject
individual's prefixes into the table you now have a melt down.

As with most system failures it takes multiple steps. However, I
think these steps are likely. ISP's in Asia have complained forever
that they don't get a fair share of the space. Well, here they can
take, take, take and use as much as they need. ISP's in Africa
have complained space costs too much (ARIN's fees, though low by
US standards are several years sallary in some countries), and want
a way around it. If those groups used this space even only internally
at first between each other (after all, the purpose is to allow
routing between organizations, just not to the global internet)
eventually there will be great pressure to add them to the global
table. It will be phrased as "UUNet won't accept prefixes from all
of Asia" or similar. Then we end up having to accept them with
none of the controls the RIR system puts in place for setting policy
or anything else. Prefixes will instead be randomly assigned
worldwide out of a single /7.

Distilled down the proposal makes no sense.

  1 You can have globally unique addresses.
  2 You can use them between organizations.
    a If your organization is an ISP, please don't allow them on the
      "Internet".

18

Reason #1: Lab use. People should NEVER, EVER pick random space from public space for doing experiments in the lab. Sooner or later something leaks, and people get really honked off. This happened a LOT with IPv4, prior to RFC 1597 and 1918. Let's not repeat the same mistake, and make sure people have a specific place to get address space from for experiments.

Sure, though see #3 which can be stolen for lab usage as well.

I'm not sure it's a great idea to tie these together, based on what I've seen in the past.

Reason #2: Disjoint networks: though we may think the only reason to use the IP protocol suites (v4 or v6) is to connect to other places in the world, there are networks which do not (or are at least not supposed to) intersect with the public Internet. Address allocation policies are based on what space you're going to advertise, and registries want money for the space. Networks that are not connected should be able to use the IP protocol suites too.

For serious usage, I don't think the money involved is a major issues.

Translation: only rich companies are entitled. Smaller businesses are not entitled to space, and not entitled to use IPv6. For offline use, I guess IPv4 will be the permanent solution.

Reason #3: A separate set of blocks should be set aside for use ONLY in documentation. Otherwise people use whatever addresses are in the examples in their router manuals and leak packets. I was seeing RIP packets claiming to come from 128.185/16 the entire time in the 1990's I worked at Proteon. Of course implementing BCP38 would help with the misconfigured user networks that were spewing that stuff. Nonetheless, documentation examples are a legitimate case for which space should be set aside.

Already done, 2001:db8::/32 is set aside for documentation.

Good.

Reason #4: Initial configuration of equipment which lacks a console port. I know, you're going to suggest the use of autoconfiguration mechanisms or DHCP. That's sometimes hard, for example in the case of a broadband "router" (home gateway) box that's going to be the DHCP server, print servers, and other such equipment. Having some block for this (or just use some subnet of the RFC-1918-like space) is a reasonable use.

Setting up local v6 addressing for this reason seems like a bad idea because there is no NAT and no global connectivity, so the box will need some automated configuration protocol in any case.

Autoconfiguration is probably not the answer to every piece of routing gear or every embedded system built. I guess designers will need to continue installing a serial port on every device to ensure there is some way to get into the device and configure it if autoconfiguration isn't able to conquer the world.

19

Leo Bicknell wrote:

I would like to bring to the attention of Nanog an IPv6 policy issue
that I think is slipping under the radar right now.

The IETF IPv6 working group is considering two proposals right now
for IPv6 "private networks". Think RFC-1918 type space, but redefined
for the IPv6 world. Those two drafts can be found at:

http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-07.txt
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-00.txt

These drafts came up in the ARIN meeting, and I posted my analysis of
the problems with both at:

http://www.arin.net/mailing_lists/ppml/2849.html

I dont understand much about ipv6. Yes I am now internationaly recognized for the ipv6 noob and loser that I am.

What I do know is that ostensibly we need it due to address shortage. Its also easy to see that a entire trainload of new technology has been hitched up to that wagon. No surprise that people are not pulling eachother down in their haste to jump on it

To all of us happily using ip4 does ipv6 offer anything valuable other than more space?

Do net admins who dread troubleshooting real networks with unrecognizable and unmemorizable addresses exist? Maintaining configuration where you will never spot a fat fingered address ever? And I mean even those who dont run "Real Networks (TM)"

All those people who curse vendors who make them put in 128 bit key software unlock codes, raise your hands. (I actualy memorized one or two of them after four years)

Is anybody keeping track of what percentage of ipv6 has already been spoken for in some way and what percentage of the categories spoken for are utilized in any way?

Yes I know. 128 bits address space is infinite! You couldnt run out if you tried! (~100 more /7 proposals like the one mentioned in parent and ipv6 is in trouble)

20

To all of us happily using ip4 does ipv6 offer anything valuable other
than more space?

Depends on who you are.

Do net admins who dread troubleshooting real networks with
unrecognizable and unmemorizable addresses exist?

Actually, I find IPv6 addresses much more memorizable as you can
give your addressing plan hierarchical structure and don't get
about arbitrary numbers like in v4 CIDR where you don't even see
where a subnet starts and ends.

Regards,
Daniel