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.
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.
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.)
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
