Re: [PATCH] shared ipv6 cards

From: Frank Pavlic (
Date: Wed Mar 05 2003 - 15:21:08 EST

>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
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

To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to
More majordomo info at

This archive was generated by hypermail 2b29 : Fri Mar 07 2003 - 22:00:01 EST