Subject: (no subject)

From: Ignatios Souvatzis <[email-masked]>
Date: Tue, 18 Sep 2007 14:04:11 +0200

Bcc: 
Subject: Re: What's 16 bits between friends?
Reply-To: 
In-Reply-To: <[email-masked]>

On Mon, Sep 17, 2007 at 10:16:04PM -0700, Christian Huitema wrote:

> That was, and still is, the official IEEE line. IEEE 802 is very
> concerned that 48 bit is not quite enough.

Let me add that IEEE1394 is using 64 bit addresses - and yes, it's in
occasional use here:

tiger# ifconfig fwip0
fwip0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        address: 00:11:06:00:00:00:6a:21
	inet6 fe80::211:600:0:6a21%fwip0 prefixlen 64 scopeid 0x1

Regards,
	-is

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian Dickson <[email-masked]>
Date: Tue, 18 Sep 2007 09:44:22 -0400

> Let me add that IEEE1394 is using 64 bit addresses - and yes, it's in
This comment actually make clear why one size isn't necessarily appropriate:
"Occasional use".

Compare that to deployed networks with hosts world-wide for MAC-48 (i.e. 
802.*) of >> 10^8 devices.
IPv4 networks in the DFZ numbering >>200,000 even with CIDR aggregation.

There is a need to deploy IPv6 into the global Internet to handle the 
IPv4 space exhaustion.

The routing infrastructure of the combined IPv4+IPv6 needs to survive 
the addition of IPv6, and handle
the dual routing via dual-stack, for a minimum of 3-10 years. This means 
not only supporting all of the
existing devices, but handling the continuation of exponential growth, 
ideally with a minimum of additional
routing slots eaten up on the devices in the DFZ.

The question I raise is:
Do we feel so strongly about universally supporting oddball cases, that 
we will not accommodate operator
need when it is presented?

 From what I have seen so far as responses, the counter arguments are:
- there are these wonky things that maybe a few dozen research sites are 
playing with that use 64-bits for MAC
- changing the spec would require, like, actual work. Let's just leave 
it alone

IMHO, those arguments don't hold water.

And, in fact, I'm talking about *relaxing* some of the requirements, in 
a permissive sense, where existing
implementations would not be out-of-spec. So, anyone who is lazy, can 
continue to use old code.

What I'm talking about, is adjusting the specs, so that those who see a 
need for new code, can do the
work, and have it continue to be considered valid as far as the RFCs are 
concerned.

As for prefixes, the RA stuff never actually was constrained to be only 
64 bits of network.
It was only that, for autoconf to work, the announced prefix had to mesh 
with the II exactly.

Relaxing *that* has no impact on the RA's, or old code. Nothing prevents 
an RA using /64, which
will continue to support EUI-64 with autoconf (old code).

What it *does* do, is allow for new code with flexible II of MAC-48 + 
padding, to work with arbitrary
prefixes announced by RA when doing autoconf.

Which, in turn, supports real-world use of autoconf on /80's, permitting 
global assignment
policy which will support real-world growth over the next decade or two, 
while protecting
the DFZ from prefix explosion caused by allocation "squeeze" effects.
> 	inet6 fe80::211:600:0:6a21%fwip0 prefixlen 64 scopeid 0x1
I note that all of the examples sent have link-local addresses only.

And, since each such network will include only similar devices, all with 
MAC-64, the addressing
used for those networks has no impact on the addressing for networks 
running Ethernet framing
and MAC-48.

Brian

---

From: Ignatios Souvatzis <[email-masked]>
Date: Tue, 18 Sep 2007 16:24:55 +0200

> routing slots eaten up on the devices in the DFZ.

But this is an argument to add not only more than 16 bits to the
Ethernet MAC to build the LAN, but more than 16 bit to the LAN size to
build the site address space, to make the globally-visible address
space even smaller - isn't it? Note that we have one site address
(assuming /48 sites only) per the maximum number of deployable Ethernet
devices, and 65536 LANs per the amount of deployable Ethernet devices 
- that really should be enough for 3-10 years.

[Also it is an argument to really make all LANs equal, and all
site-internal addressing equal, to minimize the reconfiguration needed
when you change the network technology ...]

But I might misunderstand your argument.

> need when it is presented?

[...]

> playing with that use 64-bits for MAC

Oh, there are not only IEEE1394 and Infiniband, and maybe a few others... 
There are also cryptographically generated addresses and "privacy"
addresses that use the lower /64 space.

	-is

---

From: <[email-masked]>
Date: Tue, 18 Sep 2007 15:47:27 +0100

> - there are these wonky things that maybe a few dozen 
> research sites are playing with that use 64-bits for MAC
> - changing the spec would require, like, actual work. Let's 
> just leave it alone
> 

If your goal is to enable IPv6 to be deployed in the global Internet,
then any changes which reserve FEWER bits for interface addresses would
be counterproductive. Since IPv6 does reserve a full 64 bits for
interface addresses, that means that there are only 64 bits that can be
used in network prefixes, i.e. routing table entries. This allows router
vendors the possibility to optimize their code or their route table
storage by only allowing 64 bits of data per entry if there are no known
prefixes longer than 64 bits. Your proposal to reduce the interface bits
makes it less possible to apply such an optimization which reduces the
ability of network operators to scale up the IPv6 Internet.

Of course, there is a similar negative factor here at a higher level. By
making fundamental changes to IPv6 at this late date, we would force
vendors to change their code, and network operators to update all their
routers. These things all take time, therefore your proposed changes
would delay the deployment of IPv6 on the global Internet.

> What I'm talking about, is adjusting the specs, so that those 
> who see a need for new code, can do the work, and have it 
> continue to be considered valid as far as the RFCs are concerned.

You and your friends can do any coding that you want but the only RFC
validity that it will have is Ready For Canucks.

> Which, in turn, supports real-world use of autoconf on /80's, 

I wasn't aware that there was such a huge demand for autoconf. Reading
the trade press leads me to think the opposite.

But if you disagree with me, write a draft and see if anyone else
supports you.

--Michael Dillon

---

From: Brian Dickson <[email-masked]>
Date: Tue, 18 Sep 2007 11:01:13 -0400

> the trade press leads me to think the opposite.
Did you not see my posting, on the results of the "straw poll"?

Between "all auto" and "mixed" (meaning static + autoconf hosts on one 
site, or even one subnet),
the total was >> 90%.

Granted, that was a relatively small sample set, but, well, the globally 
deployed
IPv6 universe is a small sample set, currently. (837 prefixes or 
thereabouts.)

BTW - reality trumps the trade press, as a general rule.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Tue, 18 Sep 2007 16:09:04 -0400

> ability of network operators to scale up the IPv6 Internet.
First of all, not all routes are /64.
There are of course aggregates, shorter prefixes.
But, there can be, and are, longer prefixes than /64. They just don't 
work with autoconf.

Many infrastructure routes on large IPv6 transit networks make use of 
the full range, all the way
down to /126's for point-to-point links. Those are often aggregated 
internally, by router, by site,
and by region, e.g. as /120's, /112's, and /104's. And loopbacks with 
/128's.

It isn't IPv6 that reserves 64 bits, it is only those subsets of IPv6 
functionality that use Interface Identifiers,
such as autoconf.

My goal is to keep the *number* of prefixes in the *DFZ* as small as 
possible. /64's or /80's, whichever
is used for LAN networks doing autoconf, should *never* appear in the 
DFZ. Only the top level PI blocks
or fully aggregated PA blocks, with no longer-prefixes, should appear in 
the DFZ.

So, the size of the autoconf prefix is actually irrelevant for what 
you're thinking of. The only places where
deaggregated prefixes should be seen, is where they are an ISPs 
infrastructure prefixes, or an ISP's
PA assignments, both of which need to be carried internally.
> would delay the deployment of IPv6 on the global Internet.
 Actually, if you paid attention to what I was saying - this ONLY 
affects HOSTS doing AUTOCONF.
IT DOES NOT REQUIRE ANY ROUTER CODE CHANGES.

It *does* support the notion of those *using* routers changing the 
assignments they use on subnets
that are doing autoconf, from /64 to /80. Those don't even need to 
change for deployed subnets; this
primarily addresses long-term need for new deployments.

And, it isn't a one-size-fits-all alternative. There are side cases 
where special IPv6 stuff uses, and needs,
and expects to be given, a /64. That's fine. /64's and /80's can live 
together happily. The number of end user
assignments, be they /80 or /64, for autoconf subnets, remains the same. 
The only difference is, how much
space gets chewed up by a bazillion such assignments.

That's why I originally discussed the importance of understanding the 
value of an *extra* 16 bits.

You can fit 64k networks of size /80, in one /64, which means you can 
give loads of room for growth to
each customer, without impacting the overall capacity within, say, a 
/48, which is the smallest current
assignment.

A /48, broken down to /80, is 4.3 BILLION networks. Even giving 8 bits 
of growth room
to each end assignment, that is still 16 MILLION networks. That's a lot.

On the other hand, if you do the /64 thing, a /48 only has room for 64K 
networks, and no room
to grow any of them.

*THAT* is the squeeze play that can, and likely will, blow up the DFZ on 
IPv6 without changing the
current /64-only world of autoconf.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Tue, 18 Sep 2007 16:09:04 -0400

Brian

---

From: Mark Smith <[email-masked]>
Date: Wed, 19 Sep 2007 07:20:01 +0930

On Tue, 18 Sep 2007 16:09:04 -0400

> But, there can be, and are, longer prefixes than /64. They just don't 

Depending on the prefix length, >/64, they can also break other things
e.g. reserved subnet any cast addresses.

> and by region, e.g. as /120's, /112's, and /104's. And loopbacks with 

Excepting the loopback /128, all the other prefix lengths you mention
are really just a sign that people have applied their IPv4 address
conservation mentality to IPv6. The prefix lengths you mention doesn't
justify that it should be done, it just shows that functionaly it can
be done.

The loopback /128 is a special case exception because a loopback
doesn't ever have more than one node on the "link", nor will there be a
router, so fixed and reserved /128 value is a good solution. That being
said, there are examples where loopback interfaces might have more than
one logical node - ntpd's use of 127/8 is an example I can think of.

IPv4 addressing today is an example of a convenience verses
functionality trade off. It was (and is) convenient (i.e. *simple*) to
deal with fixed length addressing allocations - IPv4 was easier and
simpler to operate and understand back in the classful / fixed length
subnet days. If you look into the history of all networking protocols,
possibly excepting only CLNS, they've all had fixed boundaries between
their network and node portions. 

Unfortunately, for IPv4 and the Internet to be able continue to
function and grow, something had to be given up. When it comes to the
crunch, convenience will always trump continued functionality.
So we all accepted variable length IPv4 prefixes because we all still
wanted the Internet to continue to work. The problem is, in particular
for people who weren't around in the classful days or earlier, it seems
to have created a universal mentality that enough addressing to meeting
functional requirements is the only correct and acceptable answer.

With IPv6's much larger address space, we are now back in a position to
have *both* convenience and functionality. Lets not throw the baby
out with the bath water, by unnecessarily giving up addressing
convenience and simplicity, now we have a chance to get it back.

> IT DOES NOT REQUIRE ANY ROUTER CODE CHANGES.

There are far far more IPv6 capable end nodes out there already than
there are routers. All versions of Linux in the last 5 or so years, Mac
OS X, 3G(PP) phones, Windows Vista etc.

---

From: <[email-masked]>
Date: Wed, 19 Sep 2007 08:47:37 +0100

> The loopback /128 is a special case exception because a 
> loopback doesn't ever have more than one node on the "link", 
> nor will there be a router, so fixed and reserved /128 value 
> is a good solution. 

According to RFC 3627 /128 is not a good idea. It should be /126.

--Michael Dillon

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 19 Sep 2007 06:53:53 -0700

> According to RFC 3627 /128 is not a good idea. It should be /126.

RFC3627 doesn't say that. It says: "Using two /128
addresses is also one, though often cumbersome,
approach.", but it doesn't say that using /128 is
not a good idea.

Fred
[email-masked]