On Tue, Sep 18, 2007 at 03:00:05AM -0400, [EMAIL PROTECTED] wrote:
> 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.
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
> 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.
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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
