Subject: Re: Implementation specific Interface-ID

From: Vijayrajan ranganathan <[email-masked]>
Date: Thu, 2 Jul 2009 12:40:20 +0530

Hi Thomas,
I have an interface that is shared by multiple virtual hosts on the box, each of
which requires autoconf addresses. The one standard address can't be shared
as, in my implementation, the IP address is the one that uniquely identifies
the virtual host for an incoming connection.

These addresses can failover to other interfaces or other nodes on the
same link.
Also, the cost of generating a duplicate address on the link is very
high, in terms
of client outage. Since these addresses are automatic, everything is expected to
work seamlessly as there may be no administrative involvement (as against
manually configured addresses).

I did consider using vlans but this requires huge changes in existing network
topology and switch-side re-configurations.

Is there a standard solution for this kind of problem?

Thanks & Regards
Vijay

On Wed, Jul 1, 2009 at 1:08 AM, Thomas Narten<[email-masked]> wrote:
> BTW, why do you want or need to do this? Why do you not not want to
> generate a standard Interface Identifier like everyone else?
>
> Thomas
>
>> Hi Everyone,
>
>> I have an ethernet interface for which I am defining the Interface-ID
>> in a different manner.
>
>> For an ethernet interface with MAC "34-56-78-9A-BC-DE", I am defining
>> the Interface-ID to be "34-56-78-xy-zw-9A-BC-DE" instead of
>> "36-56-78-FF-FE-9A-BC-DE"
>
>> where x,y,z,w are my implementation-defined octets.
>
>> Note:
>> 1. I am fine with a locally-unique Interface-ID
>> 2. The solicited-node multicast address i'll generate for a given
>> unicast/anycast address based on this Interface-ID is the same as
>> that for RFC 2464 based Interface-ID.
>
>
>> Assuming I make this change in an IPv6 stack which conforms to RFCs
>
>> 2464 - Transmission of IPv6 Packets over Ethernet Networks
>> 3513 - Internet Protocol Version 6 (IPv6) Addressing Architecture
>> 4861 - Neighbor Discovery for IP version 6 (IPv6)
>> 4862 - IPv6 Stateless Address Autoconfiguration
>> 3810 - Multicast Listener Discovery Version 2 (MLDv2) for IPv6
>
>> After this change, will I still conform to these RFCs??
>
>
>> Thanks & Regards
>> Vijay
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>

---

From: Aleksi Suhonen <[email-masked]>
Date: Thu, 02 Jul 2009 14:15:22 +0300

> Is there a standard solution for this kind of problem?

One often used solution is that either the host OS or another virtual OS 
functions as a router between all the virtual OSes and the outside world.

Another solution is that some virtualization platforms (at least vmware 
and xen afaik) offer unique generated MAC addresses to each virtual OS, 
so the standard EUI-64 method will yield unique IIDs.

-- 
	Aleksi Suhonen, Research Assistant
	Department of Communications Engineering
	Tampere University of Technology

---

From: David Malone <[email-masked]>
Date: Fri, 3 Jul 2009 07:28:31 +0100

> Is there a standard solution for this kind of problem?

On some OSes it is possible to control the host part of the
autoconfigured address by manually configuring a link local address
before the interface is brought up. The host part of this address
is then used for the rest of the autoconfiguration process. I've
done this on older versions of FreeBSD.

	David.

---

From: Tim Chown <[email-masked]>
Date: Wed, 8 Jul 2009 13:53:44 +0100

> done this on older versions of FreeBSD.

Solaris has a pretty nice feature for tokenised v6 autoconf - if you
have say a DNS server and want it on <prefix>::53 you can simply put

token ::53/64 up

in /etc/hostname6.<interface>.

This was quite handy when we looked at renumbering.

-- 
Tim

---

From: Vijayrajan ranganathan <[email-masked]>
Date: Thu, 16 Jul 2009 00:06:29 +0530

Hi David,
    Yes, indeed the implementation I am working on (it is FreeBSD based)
    is generating autoconf addresses in the same manner. It picks up the
    host-id part from the configured Link-local address.

Thanks & Regards
Vijay

---

From: Vijayrajan ranganathan <[email-masked]>
Date: Thu, 16 Jul 2009 00:04:01 +0530

Hi Aleksi,
    These are indeed good ideas.
    The 1st solution is not feasible in my case as I am stuck with an
existing implementation.
    But regarding the 2nd solution, I am wondering how vmware and xen
are able to offer a unique MAC address to each virtual OS.
    I mean, what address space do these come from?
    What happens if they need to host a large number of virtual OSes,
do they pre-allocate these, any ideas?

Thanks & Regards
Vijay

On Thu, Jul 2, 2009 at 4:45 PM, Aleksi Suhonen<[email-masked]> wrote:
> Another solution is that some virtualization platforms (at least vmware and
> xen afaik) offer unique generated MAC addresses to each virtual OS, so the
> standard EUI-64 method will yield unique IIDs.
>
> --

---

From: Vijayrajan ranganathan <[email-masked]>
Date: Thu, 16 Jul 2009 00:11:35 +0530

Hi Tim,
    This is a wonderful idea!!
    Do you by any chance know whether Sun has a patent on this?
    Is it possible for me to adopt a variation of this idea in my
implementation?

    Thanks to everyone for sharing your thoughts, much appreciated !!

Thanks & Regards,
Vijay

---

From: Aleksi Suhonen <[email-masked]>
Date: Tue, 28 Jul 2009 10:26:22 +0300

Hi,

Sorry for slow response, I had somehow missed your message.

>     I mean, what address space do these come from?

Both Xen and VMware have reserved OUI address space:

00-16-3E   (hex)                Xensource, Inc.

00-05-69   (hex)                VMware, Inc.
00-0C-29   (hex)                VMware, Inc.
00-1C-14   (hex)                VMware, Inc
00-50-56   (hex)                VMware, Inc.

I don't remember which ones they use for what purposes.

> do they pre-allocate these, any ideas?

The OUI prefixes are 24 bits long, so you can accomodate 16 million 
virtual hosts per OUI. You can also configure some other mac prefix, if 
you run out or you don't want to use a certain prefix...

--
	Aleksi Suhonen