Subject: Re: History of autoconfig RFCs and siblings, please?

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 06 Sep 2007 15:40:20 +0900

At Wed, 29 Aug 2007 15:00:55 -0400,
"TJ" <[email-masked]> wrote:

> IIRC - The 64 bit "host piece"/IID (or conversely, "only" a 64 bit routing
> prefix) is a requirement only of the 2000::/3 address space, yes?

Not really, according to RFC4291:

   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.
(section 2.5.1)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Sep 2007 14:27:21 +1200

Catching up ...

On 2007-08-30 14:08, [email-masked] wrote:
>> Brian D,
>>
>> You seem to be assuming that PI will be the dominant mode.
> 
> Not at all. I am assuming that prefixes in the DFZ won't be deaggregated
> to any significant degree. All PA are aggregated, in theory at least,
> under PI prefixes.

OK, so we see this roughly the same.

> I am in fact only assuming PI prefixes as numerous as ASNs.

Or maybe two or three times that many? But yes, of the order of
tens of thousands.

> And that more multihoming for true "end-users" will be enabled by
> the ability to have duplicative PA blocks big enough to cover end sites
> N times over.

Which was indeed the starting assumption for multi6 and shim6.

> 
> I am assuming that the *vast* majority of networks will have PA native,
> or ULA-* native and 1:1 NAT onto PA, or "unannounced" PI internally
> with 1:1 NAT facing multiple upstream PA blocks.

Here we differ; I hope we never see NAT between ULA and PA; such a site
should simply use its ULA prefix for internal services and its PA
prefix(es) for offering and accessing external services.

> 
>> This seems very unlikely, since the vast majority of users
>> (i.e. SOHO) have no interest in what their IP address is and
>> no motivation to pay extra for PI.
> 
> (I don't disagree on the latter, making this moot. And you mis-speak
> for me on what I assume.)

Clearly, for which I appologise.

> 
>> We have no possible
>> difficulty in supporting a few million PI prefixes in the
>> /48 or /56 world currently planned (apart from BGP4 blowing
>> up, of course, but that's being discussed elsewhere).
> 
> I disagree strongly.
> 
> Yes, I'm aware, and I'm participating in those discussions.

And I didn't mean to imply that those discussions are easy or
anywhere near finished; my assertion is that address assignment
in itself is not a problem. More below...

> 
> The size of the autoconf prefix is out of scope for *those* venues.
> 
> However, it *directly* impacts assignments in those areas.
> 
> Which is why I raised the question, here.
> 
> Whether autoconf uses /64 or /68 or /80, has direct implications on
> the minimum prefix assignable to an end-user should be, and what the
> typical minimum minimum PI block size should be.

Yes, but given that we can manufacture 35 trillion /48s if we need them,
and that the RIRs are applying very conservative policies which
even lead to assigning /56s to sites, I just don't get why there
is a supply problem. (Setting aside current allocation guidelines
for PI, which could clearly be changed if they had to be.)

> 
> A "few million" PI prefixes is not actually something we should plan for,

I should explain. My view is that there is no reasonable scenario
where we would need more than ten million multihomed sites in the world
(that would amount to one multihomed enterprise network or local
ISP per thousand people in about 2050). So *if* we come up with no
better multihoming solution than straight PI, as per RFC 4116, *then*
we'd need a way to route 10^7 prefixes. It's the worst case scenario,
not a plan. The reason I've been putting thought into multi6, shim6,
RAM, etc for several years is indeed to avoid the need for that scenario.

> even if it fits into the range of space between /3 and /32 (as in,
> 2000::/3, and /32 LIR PI assignments.)
> 
> Here's why:
> 
> On the biggest iron currently deployed in most networks, the size
> of the DFZ in IPv6 that can *reasonably* supported has an upper bound
> dictated by deployed TCAM size and per-prefix TCAM allocation needed.
> 
> These days, for example, on an IPv6-*only* Cisco 7600 with 3BXL, will
> only hold a theoretical maximum of 119,000 prefixes. Bigger iron may
> support double that, but again, only as IPv6-ONLY. When you add IPv4
> onto the same platform, the huge IPv4 DFZ  eats most of the capacity
> for IPv6 prefixes. Most providers will need to have dual-stack for
> a considerable period of time (3-5 years minimum, IMHO.)

10 to 20 years, IMHO.

> 
> And on that basis, how many end-user assignments fit into PI prefixes
> which are sized sufficiently to grow vertically inside reserved space,
> rather than multiply and bloat the DFZ, is very important.

Agreed.

> 
> Too big an end assignment, and it results in a squeeze play, where either
> too few PI blocks can be reserved to go around (fairly), or too many small
> PI blocks end up being used.
> 
> Adding 16 more bits to the range between PI block size and end-user
> assignment prefix length, and the squeeze effect is relaxed considerably.

What do you mean by end-user? I thought that PI was for assignment to
end-user sites in the majority of cases. Are you discussing consumer ISPs?
Why wouldn't they just get appropriate size PA prefixes?

In any case, if it does turn out that we need a lot more PI space than
the current PI guidlines assume, I'm sure the community will
change the guidelines. Architecturally, PI and PA aren't really
any different anyway.

> 
> Making really big assignments (say /20 to /42) to handle end-assignments
> of /80, gives a much longer life span to each PI block, and keeps the
> PI per ASN down to a nice low value of "1".

As Jinmei-san pointed out, we don't really have that option.

Regards
    Brian Carpenter
    University of Auckland
> 
> Brian Dickson
> 
>> Regards
>>     Brian Carpenter
>>
>> On 2007-08-30 03:17, [email-masked] wrote:
>>> Iljitsch wrote:
>>>> On 29-aug-2007, at 16:23, Thomas Narten wrote:
>>>>>> (I suppose it's a bit late in the game to go back to MAC-48 as II?)
>>>>> Yes. The difficulty is figuring out how to move to something different
>>>>> in a backwards-compatable way. I.e., we'd need a transition strategy.
>>>> But what would be the point of doing that now?
>>> The point, which I have avoided making until now, is that II has direct
>>> impact on the available range of assignments by RIRs to LIRs, for PI
>>> blocks,
>>> that also allow for very long timescale predictive assignments.
>>>
>>> Basically, the minimum prefix size * number of assignments * LIRs,
>>> when projected over a timeframe of decades, while preserving a global
>>> DFZ consisting of one PI block per LIR, has a problem fitting into the
>>> number of bits per RIR.
>>>
>>> Right now, RIRs are reserving only an additional 2 bits per LIR
>>> assignment,
>>> for "growth". Alternative allocation policies (bisection) don't
>>> guarantee
>>> the ability to assign arbitrarily large blocks indefinitely - while that
>>> is in fact the long-term requirement. Block sizes *should* increase over
>>> time, even as the frequency of their assignment decreases.
>>>
>>> What works best is, a best-fit approach, where any organization gets way
>>> more space than they need, sized according to their own best guess as to
>>> long-term growth *potential*.
>>>
>>> Then, reserve even more space for each, in a consistent manner.
>>>
>>> Take all these requests, and fill them in an optimized space-packing
>>> manner.
>>>
>>> At some point, growth requests get filled via "growing" the assignment
>>> for
>>> a given LIR into its reserved space.
>>>
>>> And, long-term periodic reviews of those growth patterns may result in
>>> bisecting *some* of those reserved blocks to make more space available
>>> for similar assignments.
>>>
>>> This can be shown to meet the requirements of individual LIRs to within
>>> a few orders of magnitude of their long-term projections (pretty good),
>>> and at the same time, optimize the packing efficiency, meaning the truly
>>> free space will not be fragmented except to the degree absolutely
>>> necessary
>>> for the existing assignments.
>>>
>>> This means that new assignments have the largest possible potential
>>> prefix
>>> size available, compared to other allocation methods. This can even be
>>> demonstrated or possibly even proven mathematically, by modeling the
>>> problem space.
>>>
>>>> The fact that we have so many local bits in the IPv6 address is our
>>>> insurance policy against address policy screwups because a single /64
>>>> is enough to run a network of arbitrary size if you forego stateless
>>>> autoconfig.
>>> The same would be true of /80, which is what MAC-48 would result in, for
>>> minimum prefix size for autoconf (and thus the standard end-user
>>> assignment
>>> size).
>>>
>>> Of the 16 bits reclaimed via this change, I would propose to the RIRs,
>>> that 4 bits be added to initial allocations, 4 bits to reservations
>>> above
>>> the initial allocations (for long-term growth), and the other 8 bits add
>>> to the total space available for the RIRs to allocate to LIRs - by
>>> adjusting
>>> the minimum and initial allocation sizes by 8 bits.
>>>
>>> The numbers (4 bits and 8 bits) are not accidental - they are one nibble
>>> in size, which matches up with the boundaries for reverse address
>>> lookups,
>>> via ip6.arpa - which uses nibbles.
>>>
>>> It seems to me, that while it would be an uphill battle, the main two
>>> issues
>>> are transition and compatibity, and inertia (e.g. deployed code and
>>> networks.)
>>>
>>> The overall benefits to address space assignment, IMHO, outweigh that
>>> cost,
>>> especially when considering the long-term health of the DFZ and the cost
>>> to member organizations when having to do expensive upgrades to their
>>> entire infrastructure to support bloat in the DFZ.
>>>
>>> Brian
>>>
>>>

---

From: Brian Dickson <[email-masked]>
Date: Mon, 17 Sep 2007 19:24:48 -0400

The following is meant to be used for demonstration purposes.
It is meant for any and all to make reference to in discussions where 
"16 bits" may come into play.

(I anticipate sending out something soon which does just that. ;-))

What's 16 Bits Between Friends?

In any discussion about protocols, where an object is sized as N bits, 
there will inevitably come a discussion about specific values for N.
There may be tendencies to make values of N divisible evenly by 4, 8, 
16, or even 32.
Similarly, this may occur for choices for constituent parts, where there 
is a trade-off between size of the object component, and the number of 
objects that might be seen.

So, what is the case against something having an "extra" 16 bits, 
meaning 16 bits more than is likely necessary even in the most extreme 
of high-ball predictions for need?

That's where a simple example can illustrate what an "extra" 16 bits 
really looks like.

Consider a physical object, something that is itself quite common: the 
rest-room key for a coffee shop.

The key itself has no intrinsic value, but the lack of a key can have 
dire consequences (at least to the prospective user of the rest-room.)

Accordingly, common practice is to attach the key to a suitably sized 
object, small enough to be carried, but large enough so that it does not 
fit in a pocket.
One common object is the hub-cap of an automobile's wheel (sans wheel 
and automobile, of course!). A hubcap is approximately 1 square foot, or 
0.1 m^2 in area.

The key is not bolted directly on, but instead typically attached by a 
short cord or chain, usually about 4 inches (0.1m).

So, what happens if we enlarge either the hubcap, or the chain, by 16 
bits? It becomes 65536 times the size.

The hubcap grows to the size of the deck of an aircraft carrier.
The chain or cord, becomes 6.5km long.

I would argue, then, that 16 bits too much, is *way* too much, in pretty 
much any situation. The example makes this, one would hope, self-evident.

(The presumption must be maintained, however, that the underlying object 
is appropriately sized to begin with, otherwise the analogy fails.)

Brian

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 18 Sep 2007 08:35:30 +0900 (JST)

> "16 bits" may come into play.

	ip address allocation has nothing to with the physical object sizes.
	for instance, you can have 2 separate ip addresses to core2duo CPU core
	if you want to.

itojun

---

From: Fred Baker <[email-masked]>
Date: Mon, 17 Sep 2007 17:21:47 -0700

I'm not quite sure what point you're making.

If it's the size of the network part or the host part of an IPv6  
address, as I recall the logic, the original stated requirement was  
that an ipng address should be able to represent 10^12 networks (42  
bits) and 10^15 hosts (52 bits). Considering the H ratio and the way  
the network and host part of an IPv4 address was/is used, one could  
have imagined an address that set aside 43 or more bits for the host  
part and 11 or more bits for the host part. That was the basis for  
SIP's 64 bit address.

Somewhere along the way, it was decided that a 128 bit address was  
more appropriate - if 32 bits isn't enough for all uses for all time,  
who says 64 is? Long story there that I wasn't a party to. But OK, it  
became 128 bits, and someone started talking about maybe using the  
MAC address in the host part. Someone noted that not all MAC  
addresses were 48 bits; for example, an E.164 address (a telephone  
number by any other name) when represented as BCD digits might easily  
be 16 digits, and some 802 series addresses are 64 bits. So it was  
suggested that 64 bits be set aside for the host part.

That left the network part. There have been numerous discussions  
about that, which I would summarize as the operators feeling a need  
for flexibility, the IETF making some recommendations, and changing  
those recommendations over time.

If your point is that 64 bits exceeds 48 bits, yes, but 48 bits  
doesn't meet the felt need. If it's not, then where are you going  
with the question?

On Sep 17, 2007, at 4:24 PM, Brian Dickson wrote:

> It is meant for any and all to make reference to in discussions  
> where "16 bits" may come into play.
>
> In any discussion about protocols, where an object is sized as N  
> bits, there will inevitably come a discussion about specific values  
> for N.
> There may be tendencies to make values of N divisible evenly by 4,  
> 8, 16, or even 32.
> Similarly, this may occur for choices for constituent parts, where  
> there is a trade-off between size of the object component, and the  
> number of objects that might be seen.
>
> meaning 16 bits more than is likely necessary even in the most  
> extreme of high-ball predictions for need?
>
> That's where a simple example can illustrate what an "extra" 16  
> bits really looks like.
>
> Consider a physical object, something that is itself quite common:  
> the rest-room key for a coffee shop.
>
> The key itself has no intrinsic value, but the lack of a key can  
> have dire consequences (at least to the prospective user of the  
> rest-room.)
>
> Accordingly, common practice is to attach the key to a suitably  
> sized object, small enough to be carried, but large enough so that  
> it does not fit in a pocket.
> One common object is the hub-cap of an automobile's wheel (sans  
> wheel and automobile, of course!). A hubcap is approximately 1  
> square foot, or 0.1 m^2 in area.
>
> The key is not bolted directly on, but instead typically attached  
> by a short cord or chain, usually about 4 inches (0.1m).
>
> So, what happens if we enlarge either the hubcap, or the chain, by  
> 16 bits? It becomes 65536 times the size.
>
> I would argue, then, that 16 bits too much, is *way* too much, in  
> pretty much any situation. The example makes this, one would hope,  
> self-evident.
>
> (The presumption must be maintained, however, that the underlying  
> object is appropriately sized to begin with, otherwise the analogy  
> fails.)
>
> Brian
>

---

From: Christian Huitema <[email-masked]>
Date: Mon, 17 Sep 2007 22:16:04 -0700

> who says 64 is? Long story there that I wasn't a party to.

That was actually decided during the review of the SIPP proposal, and was pretty much a condition for selecting SIPP (and 128 bits) as IPv6.

> But OK, it
> MAC address in the host part.

Part of same review. SIPP was competing for selection with TUBA, a proposal based on CLNP. CLNP (i.e. the OSI datagram layer) used variable length addresses, but the most prominent form featured 20 bytes addresses whose last 48 bits where derived from the 48 bit Ethernet address of the host. That allowed for auto-configuration, much like IPX. Auto-configuration based on MAC address was pretty much part of the initial deal, the rationale for moving from 64 to 128 bit. "Someone" was really many people, but if I had to pick a name I would say Scott Bradner.

> Someone noted that not all MAC

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

-- Christian Huitema

---

From: [email-masked]
Date: Tue, 18 Sep 2007 03:00:05 -0400 (EDT)

> doesn't meet the felt need. If it's not, then where are you going

Yes, that was where I was going, by way of the selection of EUI-64 as II.

In its current incarnation (which seems to be unchanging), EUI-64 is
essentially MAC-48 with an extra 16 bits in the middle, which are fixed
in value to "FFFE" (base 16).

Here are a few related observations:
- The mfg part (OUI) of MAC-48 is 24 bits, with approximately 16M values
- Each mfg can assign 24 bits of unique IDs per OUI
- The IEEE assigns further mfg numbers to the same mfg if it runs low or out
- Currently, there are 10667 OUIs

The fact that even today, we're at << 0.1% of number assignment on MACs,
suggests that 48 bits is probably enough for quite some time.

This doesn't mean that MAC addresses > 48 bits won't come along some day.

What I'm suggesting is, that we can build in enough flexibility to handle
that day, if/when it comes, without causing serious negative impact
by forcing a "one size fits all" solution that, today, wastes 16 bits of
address.

(There is a second down-side to how such things as autoconf work when only
64-bit host addressing is supported. That is, that only (128 - N) bit
network prefixes are supported. Which, due to the fixed 64 bit II size,
means only /64 networks are supported.

And yes, I'm going to "go there". Yes, it is potentially a can of worms,
but there's good reason to revisit the issue - the /64 minimum prefix size
has direct impact on number assignment policy issues, which don't need to
exist (or rather, which get seriously trivialized when /64 -> /80 or more.)

Here is another observation, from deep inspection of the OUI assignments.
None of the current OUIs contain FFFF or FFFE.

This happy coincindence means that, changing how autoconf works, and
changing the II used for autoconf, can be done while guaranteeing backward
and forward compatibility.

Consider two possible schemes for building an II - EUI-64, and MAC-48 with
an extra 16 bits of padding to the left. Looking only at the first 40 bits,
ie 24 bits of OUI plus 16 bits of padding, the two patterns are:

xxxxaaaaaa
bbbbbbFFFE

As long as no OUI includes FFFE, the two numbering schemes won't collide,
regardless of the last 24 bits, and regardless of values for 'xxxx'.

So, where does *that* take us? To a very interesting place, for sure...

If we relax the rules for autoconf, to say that only for a given Router
Advertisement of prefix X/N, that length(II) + N <= 128. We can pad any
II value on the left, to fill up the host portion, and not worry about
address conflicts.

For example:
- If we have xxxx:xxxx:xxxx:xxxx:xxxx/80 and we use the
  interface MAC-48 for the II, we get a unique address, with no padding.
- If we have yyyy:yyyy:yyyy:yyyy:yy/72, and we pad the MAC-48 of the
  interface with zeros, the address is still unique for all MAC-48 values
- And for backward compatibility, on Z/64, if we have both EUI-64 and padded
  MAC-48 addresses, there won't be any conflicting IPv6 addresses.

The last example suggests very convenient backward compatiblity paths, and
migration strategies. New style II's can be deployed on existing /64's, and
any networks where all hosts are either statically configured or all new
style, can have a new prefix length assigned with much greater flexibility.

Even if, at some later date, MAC-64 becomes the "new LAN MAC standard",
interoperability suggests that all hosts on such a network would need a
MAC-64. This in turn means, all hosts on such a network would need II's
with 64 bits. But conversely, *only* such networks need 64 bits of II.

If, rather than say all II's *MUST* be 64 bits, we generalize the standards
to allow for II's that vary in size depending on the underlying network,
we get the benefit of supporting existing widely deployed 48-bit MAC without
chewing up huge gobs of potential address space, for no obvious benefit,
and a definite, if not overly obvious, cost.

To be clear:
I am proposing that autoconf be modified to support II padding; that II
construction be permitted to be based on either EUI-64 or MAC-48; and that
the II choice of EUI-64 vs MAC-48 be under the host's administrator's
direct control.

RA stuff is otherwise the same - if an RA is not compatible due to prefix
size vs II size, autoconf will fail. However, the new flexibility means
that old and new II's can be mixed on /64's. Additionally, RA's for any
other prefix length between 0-63 and 65-80, would be supported by the new
II, with or without padding. The general rule would even support mixed mode
operation for multiple II sizes on the same network, presuming they were
at all compatible at layer 2, and presuming the largest II would fit.

The end result of all this, is to produce a modified RFC or set of RFCs,
which supports a minimum autoconf-compatible prefix size of /80, rather than
/64.

And this last is so that RIR address assignment policies have more breathing
room, to allow for lots and lots of assignments, hierarchical assignments
on nibble boundaries (important to ip6.arpa delegations), and room for long
term growth, all while minimizing (to "1") the number of PI or PA blocks
assigned per ASN in the default-free zone of the public IPv6 Internet.

It's a mouthful, and a huge PITA for getting these changes to the RFCs done,
*and* code written by vendors, *and* upgrades deployed.

If I didn't think it was extremely important work, essential for the long
term viability and the short term uptake of IPv6, I wouldn't be advocating
this path.

I do believe it is that important, however, and encourage anyone who thinks
I'm off my rocker, to read this a few times, think it over, and wait a day
or two before replying.

Installed base is important, and this addresses the issue. However, the
un-installed base vastly dwarfs the installed base, so I think we should
not get overly attached to EUI-64 as the be-all and end-all of autoconf.

We should look instead to, how easy MAC-48 autoconf would be to understand,
implement, and troubleshoot, and what *that* does to uptake of IPv6,
particularly in the vendor space for SOHO "routers", firewalls, NAT devices,
VPN devices, and the like. Currently, there are *zero* available IPv6 boxes
in the <$200 price range. This is *not* good.

The historical reasons for coming to a design choice are interesting, but
ultimately, not important, when the driving forces for use cases lead to
different choices, and alternatives can meet both the original design
goals *and* the newer requirements.

Brian

P.S. If 99.999% of networks on which IPv6 will be deployed, are Ethernet,
does it not make enormous sense to serve those with /80 prefixes, and let
the rest eat up a few (or a few dozen) /64's or whatever is needed.

P.P.S. Remember the original 16 bits argument? (99.999% / 65536) + 0.001%
is only 0.0025% - so the net savings are 99.9975% on *network*
allocations. This is about networks, not hosts. Network-bits + host-bits =
constant.

P.P.P.S Sorry about the long post. The ideas above are a package, and
don't fit in fewer bits. :-)

---

From: [email-masked]
Date: Tue, 18 Sep 2007 03:24:22 -0400 (EDT)

> 	for instance, you can have 2 separate ip addresses to core2duo CPU core

Of course, host addresses which are allocated are always /128 in size,
even if they are entries in a larger network.

I am discussing *network* allocation policies. Specifically, what the
impact is, if you use 16 more bits than necessary, for the host portion,
and thus have 16 fewer bits in the network portion.

This becomes important when we consider non-trivial hierarchies of
allocations, such as RIR->LIR->ISP, where internally further allocations
are made for internal aggregation purposes.

This is because, lest we forget, that aggregation is tied to allocation.
We cannot aggregate that which was not allocated suitably.

And, if we further presume nibble boundaries for allocation units and
aggregation points, as well as reservation of growth on nibble boundaries,
we run the risk of getting squeezed on the total nibbles available.

The basic math is: /64 vs /32 is 32 bits, which is only 8 nibbles.
If we reserve an extra nibble for growth, that means only 4 levels of
allocation between RIR and end user - which may not be enough.

Finding that we have 16 more bits, i.e. 4 more nibbles, gives that much
more flexibility and freedom to assign and use network space.

There may still be cases where it's not enough, but the frequency with which
those situation occur is likely to be a few orders of magnitude less.

It is the regularity with which the RIRs need to add more blocks to the
LIR assignments, that has direct impact on the Default-Free Zone (DFZ),
and the goal here is to avoid directly or indirectly triggering problems
in the DFZ by having too many prefixes - something that *is* seen in IPv4.

If we can prevent problems without causing other serious problems, should
we not make that effort?

Brian

---

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

> This doesn't mean that MAC addresses > 48 bits won't come along some day.

They're here already:

tiger# dmesg | egrep '(fwohci|fwip)'
fwohci0: OHCI version 1.0 (ROM=1)
fwohci0: No. of Isochronous channels is 4.
fwohci0: EUI64 00:11:06:00:00:00:6a:21
fwohci0: Phy 1394a available S400, 3 ports.
fwohci0: Link S400, max_rec 2048 bytes.
ieee1394if0 at fwohci0: IEEE1394 bus
fwohci0: Initiate bus reset
fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode
ieee1394if0 at fwohci0: IEEE1394 bus
fwip0 at ieee1394if0: IP over IEEE1394
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

> by forcing a "one size fits all" solution that, today, wastes 16 bits of

Ahem... by wasting those 16 bits, it allows for at most 64 bit of
network path in non-local environments, which allows for some useful
addressing tricks - e.g. embedded relay point addresses in multicast
addresses.

Regards,
	-is

---

From: John Day <[email-masked]>
Date: Tue, 18 Sep 2007 08:08:33 -0400

At 17:21 -0700 2007/09/17, Fred Baker wrote:
>more appropriate - if 32 bits isn't enough for all uses for all 
>time, who says 64 is? Long story there that I wasn't a party to. But 
>OK, it became 128 bits, and someone started talking about maybe 
>using the MAC address in the host part. Someone noted that not all 
>MAC addresses were 48 bits; for example, an E.164 address (a 
>telephone number by any other name) when represented as BCD digits 
>might easily be 16 digits, and some 802 series addresses are 64 
>bits. So it was suggested that 64 bits be set aside for the host 
>part.

And this is where they went seriously wrong as did CLNP.

By the early 80s, we had figured out that the obvious approach of 
using the lower layer address in the higher layer protocol is 
seriously flawed.  That approach is equivalent to creating a 
*pathname* as in Operating Systems.  (It works in OSs, because there 
*is* only one way to get any where, but doesn't work in networks, 
except for SNA, because, well, they are networks.)

The address is suppose to be route independent, specifying "where" 
without constraining "how to get there."  This does the opposite and 
merely compounds the error made with the original IMP addressing that 
we are still living with.  This is why we are having and will 
continue to have so much trouble with multihoming, mobility, scaling 
and a host of other problems.

IPv6 crawled into this hole a long time ago.  It is a little late to 
be trying to crawl out.  Time to move on.

Take care,
John

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 18 Sep 2007 22:00:17 +0900 (JST)

> and thus have 16 fewer bits in the network portion.

	each cellphone can serve a subnet around a persons' body.  then think
	about super-crowded trains in tokyo.

itojun

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 18 Sep 2007 15:15:59 +0200

> in value to "FFFE" (base 16).

If adding 16 extra bits makes sure that discussions about address  
conservation don't need to happen, it's bits well spent.

But apparently it didn't work, because now we have discussions about  
too many bits...

I suggest that there are only two reasonable approaches:

1. keep things the way they are now
2. move to variable length addresses

I'm assuming that we'll be doing 1. for quite some time and move to  
2. afterwards. But any efforts to redistribute bits within the 128  
that we have today or to change to a different fixed length just use  
up time, effort and money for no benefit whatsoever.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 18 Sep 2007 15:15:59 +0200

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Sep 2007 08:13:06 +1200

On 2007-09-18 19:24, [email-masked] wrote:
...
> are made for internal aggregation purposes.

Having that many layers of allocation hierarchy is an artificial
choice, and the aggregation argument only applies *within* a
single ISP's allocation. If we had flat allocation from IANA
to ISPs, your argument would go away. So assuming we keep the
artificial choice of allocation via RIRs and LIRs, that simply has
to work in a way that emulates flat allocation.

> We cannot aggregate that which was not allocated suitably.

LIRs and RIRs are not aggregators. It is of no importance whether
the ISPs who get their allocations from the same registry happen
to aggregate with each other or not. In fact, it's wrong to aim
for that, because it wastes address space.

     Brian C

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Sep 2007 08:13:06 +1200

Brian C

---

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

> to work in a way that emulates flat allocation.
Okay, bad choice of terminology (not mine, theirs, really).

To make it clearer, let's use a reasonable example:

RIR -> Big (Tier-1/2) ISP -> small ISP -> big enterprise -> enterprise 
site -> enterprise LAN

The first allocation is a direct allocation, and all subsequent ones are 
PA sub-assignments.

No matter who does the assignment of the PA "master" block, everything 
underneath is hierarchical.

And rather than just considering the initial allocation for each, 
consider the growth *of each entity*.

If you don't reserve enough room, at some point, new allocations need to 
happen. And if that happens
at the top, it's a new DFZ slot that gets eaten.

How often that happens, is a function of growth, and of the range 
between PA block sizes and autoconf size.

And, it has nothing at all to do with where the ISP gets its space. It 
has only to do with the size an ISP gets,
the number of  ISPs of each given size of block, and whether they need 
subsequent allocations.

And all of that is fundamentally driven by the size of the minimum 
end-user allocation.

Which is why I am advocating a small change, affecting only host 
autoconf functionality, to support ranges of
II construction that vary from /80 to /64 (or even larger). The 
flexibility would support arbitrary LAN numbering
and LAN technology, be it MAC-64, MAC-60, or MAC-68, or whatever.

Other than the changes to the autoconf RFC, and coding, I don't see an 
obvious downside to what I suggest.

Brian D

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Sep 2007 11:47:37 +1200

> RIR -> Big (Tier-1/2) ISP -> small ISP -> big enterprise -> enterprise 

If I was running a small ISP, there is no way I would
accept being forcibly aggregated under one specific Big ISP.
I'd go to my nearest registry.

If I was running a big enterprise, I'd also go straight to a
registry for my prefix. I'd also expect to flat route internally,
at least for a few hundred major sites. Aggregation isn't an
issue at that scale.

Basically I don't think we need that many layers of hierarchy to keep
the IGP and EGP routing tables to a practical size. (That's why
we abolished the TLA/NLA split in the address architecture.)

    Brian C

---

From: Brian Dickson <[email-masked]>
Date: Tue, 18 Sep 2007 20:17:37 -0400

Brian E Carpenter wrote:
>> RIR -> Big (Tier-1/2) ISP -> small ISP -> big enterprise -> 
>> enterprise site -> enterprise LAN
>>
>
You may be mistaking the "where one gets some address space from", with 
"this is the only address space you get" issue.

Multi-homed ISPs can reasonably be implemented with existing tools in 
IPv6, although not necessarily as fully automated as one might like.
Having multiple prefixes and having hosts with multiple addresses is 
expected to be the norm.

A small ISP should be happy being given PA space from multiple upstream 
ISPs. The "multiple" means no lock-in and no need for hot-cut renumbering.

A medium-sized ISP would likely have a small PI block for servers, and 
multiple upstream PA blocks, where every client gets one IPv6 from each 
upstream PA simultaneously.
> I'd go to my nearest registry.
You would - but not *everyone* will. That's my point.

And, in many parts of the world, *you don't have that option*.

If you have two choices of Big ISP and neither will speak BGP to you, 
you take what you can get.
> registry for my prefix.
Again, not everyone will. (And scalability of the DFZ necessarily relies 
on that).

And also again, not all locations provide that kind of choice.
> I'd also expect to flat route internally,
I think you miss the point of aggregation and allocation.

Aggregation isn't only done for the routing table size issues.

Routing performance similarly benefits or suffers by order-of-magnitude 
scaling. Want to carry 20,000 /128's in your OSPF cloud in area 0? Good 
luck on convergence times.

Organizational boundaries, cost centers, capacity planning, are all 
centralized functions, that typically require corresponding control over 
networking.

Whether the subdivision of enterprise space is done in a nice, 
structured, hierarchical tree-like fashion, or in a mob-rule, 
anarchy-like random fashion, the underlying need for multiple levels of 
allocation is a reasonable expectation, for a big percentage of big 
enterprises.
> we abolished the TLA/NLA split in the address architecture.)
If every router on the Internet were being configured by "Brian C", I'd 
agree with this viewpoint.

However, there are many, many organizations running networks, all 
interconnecting. Not all are run by rocket scientists. Many are 
outsourced to the local ISP.

Some of those relationships will fall within hierarchies of more than 
two deep, in a PA assignment and re-assignment sense.

Having enough flexibility (or "stretch") in the PA->minimum allocation 
sizes, is important to have those organizations be the tail that wags 
the dog.

The ability to "capture" as much growth as possible, within reserved or 
allocated blocks (PI or PA), without requiring new DFZ slots on a 
recurring basis, is the key goal.

Think of this "capture" as the equivalent of water-tight doors on a 
large ship. It doesn't matter if *your* section has no water, and is 
sealed nice and tight. If other sections start to overflow, the ship 
will start to sink.

And, you *are* on the same ship as everyone else.

We can ignore the (potential) issue, or address it as early as we can. I 
chose the latter.

Brian D

---

From: Brian Dickson <[email-masked]>
Date: Tue, 18 Sep 2007 20:39:23 -0400

Brian Dickson wrote:
> You may be mistaking the "where one gets some address space from", 
> with "this is the only address space you get" issue.
>
> A small ISP should be happy being given PA space from multiple 
> upstream ISPs. The "multiple" means no lock-in and no need for hot-cut 
> renumbering.
>
> multiple upstream PA blocks, where every client gets one IPv6 from 
> each upstream PA simultaneously.
> Again, not everyone will. (And scalability of the DFZ necessarily 
> relies on that).
>
> Routing performance similarly benefits or suffers by 
> order-of-magnitude scaling. Want to carry 20,000 /128's in your OSPF 
> cloud in area 0? Good luck on convergence times.
>
> centralized functions, that typically require corresponding control 
> over networking.
>
> anarchy-like random fashion, the underlying need for multiple levels 
> of allocation is a reasonable expectation, for a big percentage of big 
> enterprises.
>>
> If every router on the Internet were being configured by "Brian C", 
> I'd agree with this viewpoint.
>
Er, this should read, "... *not* be the tail that wags the dog.".
Sorry.

Brian
>
> The ability to "capture" as much growth as possible, within reserved 
> or allocated blocks (PI or PA), without requiring new DFZ slots on a 
> We can ignore the (potential) issue, or address it as early as we can. 
> I chose the latter.
>
> Brian D
>

---

From: Brian Dickson <[email-masked]>
Date: Tue, 18 Sep 2007 20:52:20 -0400

Iljitsch van Beijnum wrote:
> I'm assuming that we'll be doing 1. for quite some time and move to 2. 
> afterwards. 
The later we do 2, the less benefit there is.

The problem is, that we don't *have* those 16 bits to reclaim, ever, 
since we give them away with *every* allocation from space that is 
assigned to us.

Once you do even one assignment, the odds of you being able to reclaim 
all that later are slim to none, and this happens at all levels.

If you wait until it's urgent, it is already too late.

The earlier the move is made, the more benefit and less pain there is.

It doesn't even require existing assignments be changed at all - which 
is the compelling part of the argument. It's a forward looking move.

No baby, no bathwater. No throwing anything out. No renumbering, only 
smarter assignments once the deployed base can start using it.

Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 19 Sep 2007 15:33:11 +0200

On 19-sep-2007, at 2:52, Brian Dickson wrote:

> The problem is, that we don't *have* those 16 bits to reclaim,  
> ever, since we give them away with *every* allocation from space  
> that is assigned to us.

Your assumption is that the best place to keep those bits is at the  
ISP/LIR, RIR or IANA. I disagree. It's a good thing that end-users  
get these bits that can possibly later be freed up by appropriate  
protocol action.

> It doesn't even require existing assignments be changed at all -  
> which is the compelling part of the argument. It's a forward  
> looking move.

> No baby, no bathwater. No throwing anything out. No renumbering,  
> only smarter assignments once the deployed base can start using it.

I haven't read all your messages on the subject yet, but how do you  
handle the universal/local bit that's in the 16 bits that you want to  
reclaim?

---

From: Brian Dickson <[email-masked]>
Date: Wed, 19 Sep 2007 09:56:58 -0400

> handle the universal/local bit that's in the 16 bits that you want to 
The U/L bit is currently being munged on the high bit of the EUI-64, 
which is the high bit of the OUI part of the MAC-48 address.

The 16 bits I want to reclaim, are in the *middle* of the EUI-64, not at 
the top end. I want to reclaim the "FFFE" fixed value bits.

EUI-64 format is:
<oui-24>FFFE<24bitsSerial>

MAC-48 format is:
<oui-24><24bitsSerial>

As for U/L bit:

Currently, U/L munges EUI-64:
<[01]ui-24>FFFE<24bitsSerial>

What I'm proposing for II is:
<optional padding><oui-24><24bitsSerial>

which then gets munged by:
<[01]ptional padding><oui-24><24bitsSerial> (or 
<[01]ui-24><24bitsSerial> if no padding exists).

So, in the /80 case, the top bit of OUI gets set to 0 or 1 regardless of 
what it was before, *exactly* like it does in the /64 for EUI-64 use.
(The fact that OUI-24 happens to not need the top bit to disambiguate 
between OUIs, is as far as I can tell, a happy coincidence rather than 
part of the IEEE spec.)

Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 19 Sep 2007 16:12:38 +0200

On 19-sep-2007, at 15:56, Brian Dickson wrote:

>> I haven't read all your messages on the subject yet, but how do  
>> you handle the universal/local bit that's in the 16 bits that you  
>> want to reclaim?

> The U/L bit is currently being munged on the high bit of the  
> EUI-64, which is the high bit of the OUI part of the MAC-48 address.

No, it's the 7th highest bit (bit 6 according to IETF bit numbering,  
which is different from what we learn in software engineering school)  
of the EUI-64. In ethernet MAC addresses, the first bit on the wire  
is the group bit and the second the u/l bit. However, the bits are  
sent most significant byte first, least significant bit first, so the  
bit order within each byte is the opposite of what you would expect.

> The 16 bits I want to reclaim, are in the *middle* of the EUI-64,  
> not at the top end. I want to reclaim the "FFFE" fixed value bits.

Well, ok. But the effect is the same: the u/l bit is no longer bit 70  
in the IPv6 address but bit 86.

> So, in the /80 case, the top bit of OUI gets set to 0 or 1  
> regardless of what it was before, *exactly* like it does in the /64  
> for EUI-64 use.

Yes, but now if I have a 128-bit IPv6 address I don't know where the  
u/l bit is. I guess this isn't an issue for 128-bit addresses but  
only when dealing with the lower 64 or 48 bits used to number a  
subnet, and then the subnet size will tell you what you need to know.

This still breaks the notion that once you do duplicate address  
detection for your MAC-derived link-local address you can assume that  
any other MAC-derived addresses are also unique.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 19 Sep 2007 11:10:33 -0400

> any other MAC-derived addresses are also unique.
How does it break this notion?

Consider:
RFC 2462 says if DAD fails for link-local, the interface should be disabled.
I claim that if it succeeds for link-local, under either scheme, it will 
succeed for all autoconf addresses on the same interface, under either 
scheme.
(BTW, a corrolary is: it will even succeed when both schemes are in use 
on /64 prefixes, since FFFE does not collide with any part of any 
assigned OUI.)

This is clear enough, by working backwards:
If DAD would fail for some other address built on this new format for 
II, <padding><oui24><24bitSerial>, then it would fail for 
<oui24><24bitSerial>, which means DAD would fail for link-local.
In order for this to happen, however, DAD on the new address must be 
attempted, which can only occur if link-local DAD had succeeded, or else 
the interface would have been disabled.
Link-local cannot both succeed and fail.

Ergo, DAD on link-local will guarantee DAD success on all other 
MAC-derived addresses under this scheme.

I.e. your assertion is incorrect, while mine is correct.

Brian

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 20 Sep 2007 00:29:10 +0900 (JST)

> > any other MAC-derived addresses are also unique.

	no.

itojun

[email-masked]>
To: [email-masked]
Date: Thu, 20 Sep 2007 00:29:10 +0900 (JST)
From: [email-masked] (Jun-ichiro itojun Hagino)
Cc: [email-masked], [email-masked]
Subject: Re: What's 16 bits between friends?

> > any other MAC-derived addresses are also unique.

	no.

itojun

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 20 Sep 2007 00:41:27 +0900 (JST)

> > > any other MAC-derived addresses are also unique.

	i was too vague.  dig up the archive and see the never-ending
	discussion.  do not repeat it, please, for the sake of reduced waste
	of electrons.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Sep 2007 10:07:04 +1200

We're arguing past each other.

I am never going to agree that we have a shortage of bits
in ::/64. If we waste those bits due to inserting an
unnecessary hierarchy in the prefix assignment process,
shame on us. If the current registry practices are having that
effect, then we need to work with the registries to change
their practices.

Choosing EUI-64 format was a strategic decision taken from
a very long term (many decades) viewpoint. I see no case
for changing that choice.

      Brian C

---

From: Bob Hinden <[email-masked]>
Date: Wed, 19 Sep 2007 15:35:34 -0700

> for changing that choice.

My personal view as well.

Bob

---

From: Christian Huitema <[email-masked]>
Date: Wed, 19 Sep 2007 15:51:25 -0700

> My personal view as well.

Doing something like SEND would require much more work if there were less than 64 bit in the host ID.

-- Christian Huitema

---

From: Brian Dickson <[email-masked]>
Date: Wed, 19 Sep 2007 18:58:35 -0400

> effect, then we need to work with the registries to change
It isn't the registries that are the problem, nor is it the problem of 
anyone in any particular hierarchy.

It is merely that hierarchies exist.

And it isn't necessarily a "today" problem, like we have in IPv4.

It's a "2-3 years from now" problem, which exists *only* during a window 
where the core Internet
infrastructure consists of lots of routers doing both IPv4 and IPv6, 
without lots of players
having to do massive core-wide infrastructure upgrades.

Here's the problem I forsee, in a nutshell:

If, or when, significant numbers of ASNs start having to get additional 
IPv6 allocations from their RIRs,
allocations which are typically PA (for reassignment to their 
customers), at a time when most ASNs have
migrated to dual-stack IPv6, the total number of IPv6 prefixes *in the 
DFZ* becomes a problem.

The underlying problem is that any recipient of a single direct IPv6 
allocation, has the ability to use it all up,
without being irresponsible in the allocations given out, in a time 
frame that hits this window.

And the worst thing about this is, if *any* recipient can do this, there 
is a strong likelihood that *many* will do this.

If an ISP gets a /32, and gives out /48's, which they can do without 
requiring supporting documentation,
and reserves space for each allocation (say a nibble), that leaves only 
12 bits of "range", or 4096 customers.

I dare say that there are a fair whack of ISPs with that many customers, 
who are most likely to get only
a /32.

Even *if* RIRs are reserving space for them adjacent to those original 
assignments, there is nothing that
would stop anyone from announcing two adjacent /32's instead of a /31.

Think of the addition of each single extra prefix from each ASN, as 
something akin to an allergen.
It doesn't take very many to cause an allergic reaction in the core. The 
goal is to be *extremely* conservative
about allocation schemes, so as to avoid for as long as possible, the 
need for *any* recipient of directly
allocated space (from their RIR) to get a second allocation.

What I'm attempting to do, is ensure this doesn't happen in the "window" 
timeframe, by having much more
space given out relative to the minimum allocations - something that can 
only happen if there are more bits.

(After some point in time, I would expect the dominant infrastructure to 
be IPv6, with islands of IPv4 hold-outs
whose needs might be adequately served by IPv4-to-IPv6 proxies.)

If we get another 16 bits, with /80 as the minimum, then end assignments 
of /64, from ISP blocks sized
at /40, for example, even when allowing for 8 bits above the /64 and 8 
bits above the /40, gives lots more
space for growth at each level, 16 times as many potential customers, 
and a much lower likelihood that anyone,
let alone lots of folks, will need to ask for more space inside of 10 years.
> for changing that choice.

I'm not arguing for changing *all* of IPv6 away from EUI-64.

I'm arguing *for* *allowing* choices of II format of EUI-64 *or* any 
other suitable unique II specific to the layer 2 medium.

For Ethernet, one such choice would be EUI-48 (which is what MAC-48 is 
supposed to now be called, per IEEE).
And, for those situations where RA prefix size + II size < 128, padding.
(Possibly special-cased so that when RA prefix size is /64, for 
compatibility reasons, it uses EUI-64 format for the II.)

Any place where advanced IPv6 features are necessary, whatever those may 
be, that *require* /64, can trivially be supported by use of /64 by 
network administrators.

Anywhere those aren't needed, I am advocating use of /80 instead, so as 
to preserve both address space, *and* ability to do autoconf. I *do* see 
autoconf as an important feature.

I fully realize that *there are* in use today, numerous technologies 
whose MAC is EUI-64. Those obviously *need* /64.

But, there is a vastly huge deployed IPv4 infrastructure that neither 
wants, nor needs, any IPv6 features beyond IP connectivity, where IPv6 
is treated as "IPv4 with more bits" (plus autoconf instead of dhcp).

*IF* I'm able to convince you that the situation warrants more bits, 
would you agree that what I propose is a reasonable compromise towards 
that end?

(You don't yet have to agree that the situation warrants more bits.)

Brian

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 20 Sep 2007 08:07:30 +0900 (JST)

> other suitable unique II specific to the layer 2 medium.

	making the host ("interface ID" in IPv6-speack) to be fixed length,
	with bigger bitwidth, makes IPv6 address independent from the hardware
	interface layer.

	today, i see the following horror story a lot:
	- use like /28 or something for an IPv4 subnet
	- there are 15th computer installed, no room for the new computer
	- renember and get /27
	- repeat it with (prefix length + 1)
	- repeat it with (prefix length + 2)
	- ...

	today the most expensive cost is the human labor cost.  one less IT
	guy = happier management level.

itojun

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 20 Sep 2007 00:33:36 +0100

Brian Dickson wrote:
[..]
> 12 bits of "range", or 4096 customers.

You do realize that a /48 is *65536* /64's and as such there will be
only very view sites worldwide which will ever need more?

You also realize that these sites are already very large and can easily
justify another /48, either adjacent or not from their upstream address
provider, may that be a LIR or RIR.

> who are most likely to get only

Please check http://www.sixxs.net/tools/grh/dfp/ it clearly shows that
there are today at 2x /19, 6x /20 and various other large blocks.

> would stop anyone from announcing two adjacent /32's instead of a /31.
[..]

That is not a problem that the IETF or the RIR's can fix.

IETF define protocols, the RIRs provide address space based on those
specifications and how their members want them to be allocated.
ISPs use it, and they use it in any way they want.
See again above URL, but then /tools/grh/lg/ for a nice looking glass
showing you that various ISPs are already de-aggregating but also that
quite a number of ISPs are using the 'strict filter' set already as per
http://www.space.net/~gert/RIPE/ipv6-filters.html and thus are cutting
out all more specific announcements. Note also that GRH nicely colors
those in the looking glass when looking for 'bogons', though it doesn't
tag them as completely evil, just something which should not be there.

If this de-aggregation is going to cause too much entries (there are
only ~900 today!) then ISPs who will have problems with their routers
will start applying prefix filtering, taking those sub-allocs out of the
loop.

The real solution to your perceived routing problem is being discussed
on [email-masked]. The big problem though remains always that one will need
to have the information in as-good-as realtime to know where you have to
route your packet, as such you will most likely need a more or less full
table to do that, or at least a table of 'I talked to them before' kind
of prefixes.

Changing the distribution of address space won't solve this problem at
all though. As instead of a /48 being inserted in BGP from one ASN, they
will just insert a /64. The real thing that can avoid that is ISPs
filtering and the ones wanting to insert them not being able to pay
enough to convince ISPs that they should accept theirs.

Greets,
 Jeroen

---

From: Brian Dickson <[email-masked]>
Date: Thu, 20 Sep 2007 13:13:49 -0400

> 	with bigger bitwidth, makes IPv6 address independent from the hardware
I think we agree in principal on the objective. Where we don't agree on, 
is the scope of the solution.

Currently, the II spec is fixed regardless of medium.

I argue that there his benefit to expanding the II spec on a per-medium 
(family) basis, on a permissibility basis.

Example:
Any II can be EUI-64.
Or, an II for anything that has L2 addressing with MAC-48 / EUI-48, can 
use MAC-48 / EUI-48 for its II.

The "flexibility" of which I speak, is not user-defined.
It is only extending the II format on a per MAC/media basis.
It happens to be more forward-thinking than even using  EUI-64 as a 
required II format.
E.g. If EUI-72 were to come out, it would automatically just work, ie.e 
be supported by the RFCs and protocols.

> 	guy = happier management level.
Autoconf would still guarantee uniqueness, and numbering would only 
change for a device if the NIC or medium-type were to change.

What this buys is, for Ethernet types, the ability to deploy networks 
with autoconf using /80, which in turn
affects the *ability* to globally allocate to end-user sites, smaller 
blocks than /48 or /56 (which are common
denominators today).

Today, autoconf *requires* /64, with no other choices.

And to make one other point clear:

The distinction of differing II between media type, does not impose any 
compatibility problem.

I'll go into detail here; ignore it if you don't care about the details, 
but please read if you want to
disagree with the assertion immediate above this, about no compatibility 
problem.

Generally, for hosts on a subnet to speak directly, they need to be able 
to speak at L2 - which means
they have to have compatible frame formats and L2 addresses.

Even if, hypothetically, bridging together two different media types 
were possible, if they had different
sizes of L2 addresses, there would be no way for the short guys to 
disambiguate the long guys. At best,
there would need to be some kind of proxy that would need to do L2 DAD 
(!!!). And for IPv6, even
with EUI-64, that would break autoconf, unless the bridge was L3 IPv6 
autoconf-aware. At which
point it is basically a NAT or router.

Notwithstanding even *that*, if two hosts with different MAC sizes were 
talking via autoconf on IPv6,
the only way they could talk is if the RA sent a prefix short enough for 
autoconf to work on the biggest
MAC. At which point, the smaller MAC would just pad its II, and 
everything would still work.

Which means, this works independent of the prefix size, and independent 
of the L2 formats, with no
address collisions between hosts using EUI-48 and EUI-64. (The IEEE has 
assigned OUIs in such
a way as to ensure this - no FFFE in OUI-24 or even OUI-36 exists.)

---

From: Brian Dickson <[email-masked]>
Date: Fri, 21 Sep 2007 13:14:43 -0400

> for changing that choice.
Let me make the case very simple:

IF an RA advertises a /80 prefix:
- EUI-64 autoconf WILL fail
- EUI-48 autoconf WILL succeed (the proposed extention to autoconf II 
construction)

This does not REQUIRE that all II be EUI-48, or even that ALL interfaces 
support EUI-48. Clearly neither of those makes any sense.

I am proposing ONLY that AUTOCONF be extended in cases where it 
otherwise would fail, to construct an alternate II based on whatever MAC 
happens to be on the interface.

NB:
This is actually very much analogous to what is done on Link-Local.
If you recall, Link-Local does *not* specify EUI-64 for II, nor does it 
specify even the *size* of the II. It is II-agnostic, other than number 
of bits maximum in an II not exceeding 55 bits (/9 prefix)
It merely says, to build a LL address, take "FE80::/9" and bit-wise OR 
it with the II.
(End NB comment)

I am suggesting similarly, take the RA prefix, and bit-wise OR it with 
whatever alternative for II (i.e. MAC address) is used, and do this ONLY 
for prefix other than /64.

Per the INT AD's message today, please indicate:
(a) if you feel this will cause harm
(b) if you only are reluctant to have the RFC changed
(c) if you actively oppose this on grounds other than (b)

If (c), please voice your *specific* concerns. Again, this is II used 
only for autoconf, and only when presented with an RA of something other 
than /64.

Brian Dickson

---

From: Christian Huitema <[email-masked]>
Date: Fri, 21 Sep 2007 10:39:41 -0700

This whole thread is based on an illusion.

The desire is to help small network operators subdivide the prefix announced by their ISP.

In principle, if the ISP follows the current guidelines, there is no issue: even the smallest network receives a /48, and deals with it.

In practice, some ISP are reluctant to follow these guidelines. They profess concern about address space exhaustion, but we cannot ignore the obvious marketing implications. If there is a two-tier allocation, say /48 for enterprises and /64 for residential, then ISP can use that in a two-tier tariff.

And here comes the illusion. If we observe that ISP only give a /64 to residential customers, then it is tempting to develop technology so that /64 can be subdivided in multiple subnets, so that each link gets some /(64+N) prefix. But has anyone stopped to ponder what will happen next?

If ISP observe that a /64 prefix can be subdivided, and that a single link can be addressed with /(64+N), what do you believe will happen? How long will it take before we observe a different 3-tier tariff, in which enterprises get /48, small businesses get /64, and residential users get /(64+N)? And what will we do then? Develop technology so that a /(64+N) prefix can be divided in /(64+N+P) subnet prefixes?

-- Christian Huitema

---

From: David Conrad <[email-masked]>
Date: Fri, 21 Sep 2007 10:49:09 -0700

Why is the IETF trying to micromanage ISP business models?

Is there a valid technical reason to allow for longer than /64 prefixes?

Regards,
-drc

On Sep 21, 2007, at 10:39 AM, Christian Huitema wrote:
> In principle, if the ISP follows the current guidelines, there is  
> no issue: even the smallest network receives a /48, and deals with it.
>
> In practice, some ISP are reluctant to follow these guidelines.  
> They profess concern about address space exhaustion, but we cannot  
> ignore the obvious marketing implications. If there is a two-tier  
> allocation, say /48 for enterprises and /64 for residential, then  
> ISP can use that in a two-tier tariff.
>
> And here comes the illusion. If we observe that ISP only give a /64  
> to residential customers, then it is tempting to develop technology  
> so that /64 can be subdivided in multiple subnets, so that each  
> link gets some /(64+N) prefix. But has anyone stopped to ponder  
> what will happen next?
>
> If ISP observe that a /64 prefix can be subdivided, and that a  
> single link can be addressed with /(64+N), what do you believe will  
> happen? How long will it take before we observe a different 3-tier  
> tariff, in which enterprises get /48, small businesses get /64, and  
> residential users get /(64+N)? And what will we do then? Develop  
> technology so that a /(64+N) prefix can be divided in /(64+N+P)  
> subnet prefixes?
>
> -- Christian Huitema
>
>
>

---

From: Brian Dickson <[email-masked]>
Date: Fri, 21 Sep 2007 13:57:14 -0400

> Is there a valid technical reason to allow for longer than /64 prefixes?
Almost the right question:
s/allow for/not allow for/

I.e. In the absence of a (valid technical) reason *not* to allow this, 
it should be permitted for discussion/proposal/modification of the RFC(s).

Any tie (where tie means opinion differs mildly, no strong opposition by 
the vast majority, and no technical obstacle), goes to permissive 
modifications.

Brian
>> In principle, if the ISP follows the current guidelines, there is no 
>> issue: even the smallest network receives a /48, and deals with it.
>>
>> In practice, some ISP are reluctant to follow these guidelines. They 
>> profess concern about address space exhaustion, but we cannot ignore 
>> the obvious marketing implications. If there is a two-tier 
>> allocation, say /48 for enterprises and /64 for residential, then ISP 
>> can use that in a two-tier tariff.
>>
>> so that /64 can be subdivided in multiple subnets, so that each link 
>> gets some /(64+N) prefix. But has anyone stopped to ponder what will 
>> happen next?
>>
>> If ISP observe that a /64 prefix can be subdivided, and that a single 
>> link can be addressed with /(64+N), what do you believe will happen? 
>> How long will it take before we observe a different 3-tier tariff, in 
>> which enterprises get /48, small businesses get /64, and residential 
>> users get /(64+N)? And what will we do then? Develop technology so 
>> that a /(64+N) prefix can be divided in /(64+N+P) subnet prefixes?
>>
>> -- Christian Huitema
>>
>>
>>

---

From: james woodyatt <[email-masked]>
Date: Fri, 21 Sep 2007 11:37:42 -0700

On Sep 21, 2007, at 10:57, Brian Dickson wrote:
> Almost the right question: s/allow for/not allow for/
>
> I.e. In the absence of a (valid technical) reason *not* to allow  
> this, it should be permitted for discussion/proposal/modification  
> of the RFC(s).

Here's why I don't care what documents allow for prefixes lengths  
over 64 bits: all that hardware and software already shipped to  
customers that won't and can't use them.  There's no point in  
shipping products that require every node on the network to support  
this new autoconf protocol to communicate if it has no backward  
compatibility.  I don't see how an advertised prefix over 64 bits  
allows for any backward compatibility.

> Any tie (where tie means opinion differs mildly, no strong  
> opposition by the vast majority, and no technical obstacle), goes  
> to permissive modifications.

I see no reason why any IETF participants should be writing standards  
track documents for a protocol when there is no significant  
constituency among the participants who would be expected to make  
gear to comply with it.

This sounds like a fine topic for experimental research.  Have fun  
storming the castle.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Brian Dickson <[email-masked]>
Date: Fri, 21 Sep 2007 18:19:24 -0400

james woodyatt wrote:
> Here's why I don't care what documents allow for prefixes lengths over 
> 64 bits: all that hardware and software already shipped to customers 
> that won't and can't use them. 
Won't? Without modifications, sure, I agree there.

Can't? I beg to differ.
To the best of my knowledge, which is rather extensive, no one is 
burning ASICs that do IPv6 with /64 hard-coded in silicon, as affects 
II's and routing/switching.
At worst, new versions of firmware/software would be needed - for 
*clients* of RAs, that is. Routers doing RA don't need any software 
changes at all.

I think you may be attacking a straw man. This change applies *only* to 
autoconf hosts, which are normally considered "client" nodes.

So, sure, software on client machines would need upgrading. I never said 
otherwise, and it's pretty much a foregone conclusion that any 
substantial modification to any RFC has the same consequence.

That is not, in and of itself, a justification for, well, anything.
> There's no point in shipping products that require every node on the 
> network to support this new autoconf protocol to communicate if it has 
> no backward compatibility.  I don't see how an advertised prefix over 
> 64 bits allows for any backward compatibility.
>
It *has* 100% backward compatibility.
Here's why:
It works with any prefix size, including /64.
And in /64-land it will work 100% with existing code clients. There is 
no duplicate address problem.
I even go so far as to suggest preferring EUI-64 for /64 in the proposed 
scheme, rather than the new format. However, the two formats (EUI-64 and 
EUI-48 padded with *anything at all*) don't collide, ever. Even for the 
same MAC address, as it happens.
>> Any tie (where tie means opinion differs mildly, no strong opposition 
>> by the vast majority, and no technical obstacle), goes to permissive 
>> modifications.
>
> constituency among the participants who would be expected to make gear 
> to comply with it.
>
You mean, such as Linux boxes?
Here's what the patch required would likely look like, for this (not yet 
tested):

*** /usr/src/linux/net/ipv6/addrconf.c  2007-06-22 13:08:58.000000000 +0000
--- addrconf.c  2007-09-21 21:57:32.000000000 +0000
*** 1690,1695 ****
--- 1690,1705 ----
                        }
                        goto ok;
                }
+               elseif (pinfo->prefix_len > 3 && (pinfo->prefix_len + 
dev->addr_len <= 128)){   /* II needs to fit in available space */
+                       u8 my_ii[16];
+                       int i;
+                       memcpy(&addr, &pinfo->prefix, 16); /* prefix, 
plus zeros */
+                       
memcpy(my_ii+16-(dev->addr_len),dev->addr,dev->addr_len); /* use HW_ADDR 
from dev as II */
+                       /* Global/Local bit */
+                       my_ii[16-dev->addr_len] ^= 2; /* guaranteed to 
be INSIDE the HW_ADDR portion, and at proper location of EUI-64 */
+                       for(i=0;i<16;i++){ addr[i] |= my_ii[i];}
+                       goto ok;
+               }
                if (net_ratelimit())
                        printk(KERN_DEBUG "IPv6 addrconf: prefix with 
wrong length %d\n",
                               pinfo->prefix_len);

(This is a mod to a file in the most current Linux kernel sources - a 
file that hasn't changed since Hallowe'en, 2001!)

Similar patches should be equally trivial for OS X, FreeBSD, and other 
systems for which code is available.
(Vendors whose proprietary code is patched via SP's, I can't comment on 
per se, but I would hope it would be as easy as this for them.)

Most "devices" which either run a hacked-up, embedded version of FreeBSD 
or Linux, should not be difficult for vendors to fix.
Or in virtually all cases, consider putting IPv6 on with this fix.
I have yet to see a sub-enterprise level "router" with IPv6 available.

Brian Dickson
P.S. Inconceivable? You keep using that word. But I don't think it means 
what you think it means... (to paraphrase.)

---

From: <[email-masked]>
Date: Sun, 23 Sep 2007 09:54:11 +0100

> Why is the IETF trying to micromanage ISP business models?

"Second guess" is not the same as "micromanage". Given the recent
comments about end user participation it seems rather appropriate for
people to consider the impact of IETF decisions on end users. 

--Michael Dillon

---

From: Mark Smith <[email-masked]>
Date: Sun, 23 Sep 2007 19:59:35 +0930

> people to consider the impact of IETF decisions on end users. 

The fundamental end-users of the IETF technology is the world and it's
population. Network operators and administrators aren't the end-users
of networks, just like mechanics aren't the end-users of cars. Cars are
built to best suit the needs of the people who use them, not the people
who fix them.

So what's best for the IETF's end-users? Simplicity, because it's
cheaper to buy, to configure and to fix. Universal fixed length
interface IDs are simpler.

---

From: Jim Jackson <[email-masked]>
Date: Sun, 23 Sep 2007 15:42:01 +0100 (BST)

I've been lurking for a while, but this illustrates what I've seen in
quite a few posts on this list and on the ipv6ops list - some people just
know exactly what EVERYONE needs....

> interface IDs are simpler.

...and so the inference is that everyone MUST have this option.
chop logic boyo.

Jim

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 23 Sep 2007 17:27:14 +0200

> ...and so the inference is that everyone MUST have this option.

Right. If end-users need simplicity, then why do we have complexity?  
It certainly doesn't help the engineers.

Users need all kinds of stuff: one size never fits all. This means  
flexibility, which isn't something that automatically goes along well  
with simplicity.

---

From: Brian Dickson <[email-masked]>
Date: Sun, 23 Sep 2007 12:30:25 -0400

> interface IDs are simpler.

Actually, to follow your analogy, Interface Identifiers are an 
under-the-hood "thingie".
They are not a user-serviceable part.

Simplicity does *not* involve users configuring IIs. It goes without 
saying, then,
that autoconf (a use function) is the thing to look at.

If autoconf works, then *how* it works, and *what* it uses for II, is 
actually unimportant,
*to the user*. It has to *just work*.

(Network operators are generally more like dealers than mechanics, with 
their knowledge
and relationship with manufacturers. With all the good and bad that goes 
with that analogy.
But, that is unimportant to the central argument, which is why this is 
parenthesized.)

(BTW - I have yet to see a car built solely or even partially for the 
needs of the people.
Example of how cars are *not* made to user's needs:. "options" vs 
"options packages".)

The IETF seems to want to act like a design house, or so it seems for IPv6.
In some regards, it would better serve end-users, by acting like the 
NTSB or NHTSA or DMV or EPA,
or some combination thereof.

Brian

---

From: Mark Smith <[email-masked]>
Date: Mon, 24 Sep 2007 07:50:05 +0930

On Sun, 23 Sep 2007 15:42:01 +0100 (BST)

> know exactly what EVERYONE needs....

I know what my customers want - and I only operate a network because I
have customers who'll pay me to do it. If I don't know what my
customers want, I won't have them because I won't be giving them what
they want. The very large majority of my customers aren't engineers, so
they don't find technical complexity interesting. They just want it to
work, and they want it to work as cheaply as it can. 

Do a survey if you like. Ask people (not just engineers)
which option they prefer in any situation, the hard one or the easy
one. The majority will pick the easy one, and it's usually the simpler
one.

My customers might not understand what fixed length
interface ids are. However, what they will understand is that if a 10
minute job could be made 5, and I spend that saved 5 minutes on
something else for them that's also a need, they'll say, "we'll go with
the simpler and cheaper option for this problem."

> ...and so the inference is that everyone MUST have this option.

Yep, in particular when this thread is trying to change 10 years of
specified protocol and implementation. It's too late for that.

IMHO, the only way Brian would be able get this changed would be to use
IPv6 as the basis for IPngng, and start writing IPngng drafts.

---

From: Jim Jackson <[email-masked]>
Date: Mon, 24 Sep 2007 18:45:22 +0100 (BST)

It is interesting that people who are omniscient don't appear to
actually understand what is being proposed. Brian has had to repeat
several times that his proposal does NOT alter the standard
autoconfiguration operation.

While I'd not claim to know whether his proposal has sufficient merit to
be accepted, I have a gut feeling that a universal fixed 64 bit boundary
may cause future problems. I also think choice is good, as long as that
choice does not come at too higher "cost". But the proposal must be
understood before the costs can be weighed.

---

From: Brian Haberman <[email-masked]>
Date: Mon, 24 Sep 2007 14:13:57 -0400

All,
      This is a good note on which to end the speculative comments.  I 
would suggest that rather than commenting on the *possible* direction of 
Brian Dickson's proposal, that the WG wait for the actual draft 
describing the proposal.  That way, comments can be constructive and 
directed at a concrete specification.

Regards,
Brian
IPv6 WG co-chair

---

From: james woodyatt <[email-masked]>
Date: Mon, 24 Sep 2007 11:22:12 -0700

On Sep 21, 2007, at 15:19, Brian Dickson wrote:
>> customers that won't and can't use them.
>

I think you miss my point.  I don't care how easy it is to patch the  
source code.  What I can't do is force customers to upgrade all their  
network nodes at once with new firmware and operating system software  
before seeing any benefits of the new protocol.  And what are these  
benefits to the network user?  Cheaper numbers from a supply that's  
already astronomically large?

Go ahead and define a way to extend autoconf to support prefix  
lengths over 64 bits.  I'm just explaining why I likely-as-not won't  
care.  I don't see any real demand for it.  I'm also pretty sure that  
when there *is* a real demand for it, it will either be trivial to  
do, or it will be extremely tough to do because of something you're  
not foreseeing about the reasons why a standard /64 interface  
identifier was thought to be an important design feature in the first  
place, e.g. RFC 3041, SEND, et cetera.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 25 Sep 2007 18:13:41 +0900

Aside from the need for the "more flexible" interface identifiers
(which I personally don't see yet), I'd like to clarify one minor
point.

At Thu, 20 Sep 2007 13:13:49 -0400,

> Currently, the II spec is fixed regardless of medium.

Actually, the autoconfiguration spec (namely RFC2462, which was
revised as RFC4862 very recently) states that the length of interface
identifiers depend on specific link types - see the bullet for
"interface identifier" in the TERMINOLOGY section of RFC2462 and
RFC4862.  One confusing point is that the address architecture also
specifies the length of interface identifiers, which seems to be
independent from the underlying media (link) type.  We discussed this
in the rfc2462bis work, and clarified it in RFC4862:

      [...] The
      exact length of an interface identifier and the way it is created
      is defined in a separate link-type specific document that covers
      issues related to the transmission of IP over a particular link
      type (e.g., [RFC2464]).  Note that the address architecture
      [RFC4291] also defines the length of the interface identifiers for
      some set of addresses, but the two sets of definitions must be
      consistent.

The clarification was actually a compromise, and doesn't specifiy how
these definitions can be consistent.  But we could not find a better
way to explain the seeming discrepancy at that time; hence this text.

					JINMEI, Tatuya

---

From: David Conrad <[email-masked]>
Date: Wed, 26 Sep 2007 12:41:15 +0200

Hi,

On Sep 24, 2007, at 8:22 PM, james woodyatt wrote:
> I think you miss my point.  I don't care how easy it is to patch  
> the source code.  What I can't do is force customers to upgrade all  
> their network nodes at once with new firmware and operating system  
> software before seeing any benefits of the new protocol.

You mean like deploying IPv6?

> And what are these benefits to the network user?  Cheaper numbers  
> from a supply that's already astronomically large?

The RIRs, based on IETF guidelines of minimum prefix size and HD  
ratio, are allocating /21s, /20s, /19s, and shorter to individual  
ISPs.  How many of these prefixes are there in IPv6 as compared to IPv4?

Regards,
-drc

---

From: Brian Dickson <[email-masked]>
Date: Wed, 26 Sep 2007 09:45:49 -0400

> ISPs.  How many of these prefixes are there in IPv6 as compared to IPv4?
Assuming your question wasn't rhetorical...

The /N is numbered from the left.

IPv6 unicast space is 2000::/3, which is the same size as 
192.0.0.0-223.255.255.255 in IPv4, i.e. the old class "C" range.

In both places, /21 has the same meaning.

There is lots of space to assign such prefixes.

That *isn't* the problem.

The problem is, how efficiently the space is allocated, in terms of 
*number* of allocations, regardless of size, especially viewed over a 
window of time rather than a single snap-shot.

If growth by ISPs results in new allocations, the number of routing 
slots in the DFZ grows. DFZ slots are a critical resource.

DFZ slots are in extremely short supply, both because of the success of 
IPv4, and because of poor allocation policies throughout the life of 
IPv4. (Not all of those are the result of poor planning or 
implementation, but enough of them are.)

If it weren't the case that DFZ slots were *already* in short supply, 
there wouldn't be as much of a concern as is the current case.

And to answer OP's question:

The benefit to the network user is, a continued operation of the 
Internet, as you know it.

Running out of DFZ slots will cause severe hardship for everyone, and 
has the added risk of placing a financial squeeze on many ISPs at the 
Tier1/Tier2 level.

A further market shake-out would likely benefit only the survivors of 
the shake-out, and certainly not their customers, i.e. you and me.

Brian

---

From: David Conrad <[email-masked]>
Date: Wed, 26 Sep 2007 16:06:52 +0200

> Assuming your question wasn't rhetorical...

It was.  Sorry if that wasn't clear.

> There is lots of space to assign such prefixes.

There is the same number of prefixes.  The amount of space you get  
with one of those prefixes is, of course, mindbogglingly bigger.   
However, the way things work now, the mindboggling part goes almost  
entirely to LANs.  Sort of like the original IPv4 addressing model  
with a fixed 8 bits of network and 24 bits of host.  It would have  
been nice to have learned from past mistakes and minimize the number  
of fixed boundaries, but we didn't.

> slots in the DFZ grows.

IANA has allocated to each of the RIRs /12s specifically for the  
purpose of sparse allocations using the bisection method to allow  
allocations to grow.  The fact that some of the RIRs are still  
allocating sequentially may be a problem, however it is unlikely  
allocations by the RIRs are going to be a problem.  The problem will  
more likely be folks deaggregating their RIR allocations for traffic  
engineering purposes and/or customer multi-homing (since IPv6  
provided no new tools for controlling routing).

If this is your rationale for proposing modifying the way auto- 
configuration works, I suspect you're wasting your time.

Regards,
-drc

---

From: james woodyatt <[email-masked]>
Date: Wed, 26 Sep 2007 10:15:27 -0700

On Sep 26, 2007, at 03:41, David Conrad wrote:
>> the source code.  What I can't do is force customers to upgrade  
>> all their network nodes at once with new firmware and operating  
>> system software before seeing any benefits of the new protocol.
>

Actually, I don't have to force customers to upgrade all their  
network nodes to IPv6 at once.  There is an adequate incremental  
transition strategy in place.  Customers can choose to deploy IPv6 on  
only the nodes where they need to use it.  IPv4 still works fine.

Thinking about it some, I can imagine a transition strategy that  
wouldn't be too difficult.  It wouldn't come without any costs at  
all, however, c.f. me previous remarks about things that will be  
broken or deteriorated by shorter interface identifiers, and I'm not  
seeing much real benefit that might come from it.

> ISPs.  How many of these prefixes are there in IPv6 as compared to  

I fail to see how this is related to any proposed effort to shorten  
the length of interface identifiers.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 26 Sep 2007 14:04:55 -0400

james woodyatt wrote:
> e.g. RFC 3041, SEND, et cetera.
For example, RFC 3041 is *very* easy to fix.

Where it uses "upper 64 bits" and "lower 64 bits", change it to upper 
(length(ii)) bits, and lower (128 - length(ii)) bits.
If the II happens to be 48 bits, the upper 48 of the MD5 become the new 
temporary II, and the lower 80 become the stored value.
The "fixed" II 48 + stored 80 become the new 128 bits used as input to 
MD5 on the next cycle.

One observation related to 3041: having what is effectively VLSM, makes 
it orders of magnitude more difficult to first identify the location of
the network/host split, on mixed traffic sniffed at random locations on 
the internet.

Fixed /64 size makes finding the split point (network vs II) 
tautologically trivial - it's always after bit 64.

If sniffing/tracking is targeted, it becomes considerably easier to 
identify sources, e.g. if initial value of EUI-64 is known.
It becomes a deterministic sequence of II's. And once one II value is 
found, subsequent sniffing is equally trivial.

If, on the other hand, the *size* of the II is unknown, or even better 
changes over time, each step in the search sequence goes from
one step, to as many as (128 bits - 48 bits smallest II size - 3 bits of 
Unicast space = 77 bits) 77 choices to make for the next II values
that might be used.

(RFC 3041 should have included randomly rotating the bit-field before 
selecting N bits, to handle the determinism. But it doesn't, so for any 
II, the sequence is fixed.)

Which RFC is SEND, again?

Are there any RFCs you know of offhand that rely on 64-bit II? I'd 
really like to address them in my forthcoming I-D.

Thanks.