>It didn't get accepted because I wanted someone to go through
>the process of making sure the IPV6 standardization group had
>no problems with the things you guys are doing.
Ok that's a good point so I spent some time to read some of the IPv6 RFCs
and I think
the following extracts from RFC 2464 "IP Version 6 Addressing
Architecture" will resolve all doubt :
----->>>>>>
1. extract from section 2.5.1 Interface Identifiers:
"...
EUI-64 based Interface identifiers may have global
scope when a global token is available (e.g., IEEE 48bit MAC) or may
have local scope where a global token is not available (e.g., serial
links, tunnel end-points, etc.). It is required that the "u" bit
(universal/local bit in IEEE EUI-64 terminology) be inverted when
forming the interface identifier from the EUI-64. The "u" bit is set
to one (1) to indicate global scope, and it is set to zero (0) to
indicate local scope.
..."
and beneath in the same section:
"...
The motivation for inverting the "u" bit when forming the interface
identifier is to make it easy for system administrators to hand
configure local scope identifiers when hardware tokens are not
available. This is expected to be case for serial links, tunnel end-
points, etc. The alternative would have been for these to be of the
form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler ::1,
::2, etc.
The use of the universal/local bit in the IEEE EUI-64 identifier is
to allow development of future technology that can take advantage of
interface identifiers with global scope.
..."
2. extract from APPENDIX A Creating EUI-64 based Interface Identifiers:
"...
Links without Identifiers
There are a number of links that do not have any type of built-in
identifier. The most common of these are serial links and configured
tunnels. Interface identifiers must be chosen that are unique for
the link.
When no built-in identifier is available on a link the preferred
approach is to use a global interface identifier from another
interface or one which is assigned to the node itself. To use this
approach no other interface connecting the same node to the same link
may use the same identifier.
If there is no global interface identifier available for use on the
link the implementation needs to create a local scope interface
identifier. The only requirement is that it be unique on the link.
There are many possible approaches to select a link-unique interface
identifier. They include:
Manual Configuration
Generated Random Number
Node Serial Number (or other node-specific token)
The link-unique interface identifier should be generated in a manner
that it does not change after a reboot of a node or if interfaces are
added or deleted from the node.
..."
As the OSA card has only one unique MAC address but can be used by a lot
of Linux guests we
generate a unique identifier by using the dev_id in the net_device
structure.
Yet another argument is that there are a number of types of links that,
while multi-access, do not
have globally unique link identifiers like LocalTalk and Arcnet
devices so that they also have to generate
an interface identifier .
I attached the patch once again.
Mit freundlichen Grüssen / Best regards
Frank Pavlic
Linux for eServer Development
Schoenaicher Str. 220, 71032 Boeblingen
Phone: ext. +49-(0)7031/16-2463, int. *120-2463
mailto: pavlic@de.ibm.com
Attachment:
shared-ipv6.diff
Description: Binary data
