[Planetlab-devel] IPv6 support for MyPLC

[maoke]

Marc E. Fiuczynski wrote:
> Hello Maoke,
>
>   
>> Marc has mentioned a method to substitute FF:FE in the eui-64 format
>> with the sliver id. i think this is a good idea. on the other hand, if
>> we can get a special company id (first 24 bits in MAC address) for
>> vserver like xen or vmware, why don't we do this? ;-)
>>     
>
> What is involved in applying for this company id?
>
> How does VMware/Xen generate unique MAC addresses per VM in a LAN with
> potentially 100s of physical machines with each of which having, say, 100
> VMs?  Do they simply rely on a good random algorithm to select the lower 24
> bits of the MAC and then rely on ICMPv6 "duplicate address detection" (DaD)
> to make sure no one else is using that address?   What happens when an
> administrator rewires a physical machine (unplugging it for say 10 seconds)
> and on a different physical machine a VM comes online selecting a virtual
> MAC# that already is being used by a VM on the unplugged physical machine?
> In such a scenario, the ICMPv6 DAD code will claim that the newly select
> address is ok, but then all hell will break loose when the admin plugs the
> unplugged machine back in.  While this might appear like one of those "one
> in a million" events, my guess is that it wouldn't be so rare.  Ideally, I'd
> like to just avoid this altogether somehow by using a scheme that can
> operate 100% using autoconf rather than having to rely on some sort of
> centralized or coordinated DHCPv6 service.
>
> Marc
>
>
>   
hi marc,

1. for the company id, please refer to 
http://standards.ieee.org/regauth/oui/index.shtml and we can now find 
out what xen and vmware have get from ieee. i guess we can do the same 
thing for planetlab (not sure which name for the company_id application 
is better, planetlab or vserver).

2. i don't know how it is inside the vmware or xen. on the other hand, i 
googled something about this, :P, e.g.

    http://www.techarchsolutions.com/vmware_faq.asp#19
    http://wiki.xensource.com/xenwiki/XenNetworking
   
it is well known that for vmware, if mac address is automatically 
assigned, then it may change every time a virtual machine is reboot. 
therefore it is believed that a random address generator is applied. it 
is said in the faq that the way of mac address assignment doesn't 
guarantee no conflict. for xen, it is suggested to manually configure 
mac addresses with carefully select some bits in the mac addresses. 
maybe guys in xen community, if there are some in this mail list, can 
provide more information.

personally, i suggest that we can find a good way to avoid the potential 
conflict. both vmware and xen allow manually configuration for the mac 
addresses of the virtual machines. vserver can be so designed too. the 
"manual action" could be done by a script within the root context, as 
long as we set a pretty algorithm in it. e.g. we can encoding node_id 
and slice_id into the lower 24 bits of the mac address, by applying a 
global hash function. this algorithm is applied permanently, regardless 
of the physical position of the host node. a simple research must be 
done for the algorithm. after that, each sliver can get their unique 
eui-64 address without conflict.

you might argue that 24-bit is not a large-enough space. if so, we can 
apply for more company ids from IEEE. ^_^

on the other hand, how many logical interfaces is allowed in a sliver? 
single one might restrict people from doing routing/forwarding 
experiments. but if many, wow... the 24-bit space will be really a 
problem, unless we only require relatively local uniqueness.

- maoke