[Ipv6] PlanetLab IPv6 development: going beyond the required kernel fixes

[maoke]

hi marc and all,

first of all, it's great to hear the news about ipv6 support progress! 
my comments are written below.

Marc E. Fiuczynski wrote:
> We are still plugging along on the required kernel fixes to support a unique
> IPv6 address per sliver (i.e., a vserver or virtual machine) on PlanetLab.
> While this seems to be making happy progress, there are at least two issues
> that we need to resolve for which it would be great to get feedback /
> thoughts:
>
> 1) What IPv6 address should be assigned to a sliver (static or autoconf'd)?
>
> and
>
> 2) How to get the IPv6 addresses assigned to slivers into DNS?
>
>
> For 1):
>
> a) If it is static V6 address, from which pool of static IPv6 addresses
> should it come from?  How is this pool managed (DHCPv6)?  If it is managed
> by DHCPv6, who is in charge of this server and what specific request should
> we make to this server to give each sliver an address?  Does anyone know how
> this is done on Xen or VMware? Is there an RFC for this somewhere?
>
>   
in my mind, the address assignment for sliver could be either static or 
dynamic (from DHCPv6), depending on the user of the sliver. for the 
static approach, the address can be manually specified by the user of 
the sliver and therefore our planetLab system should be aware of the 
case of the address conflict. the ipv6 stack itself can apply neighbor 
discovery mechanism (RFC 2461) to detect the address conflict on a same 
link but i'm not sure how does this works for the virtual machines.

for the DHCPv6 approach, the link-local address of each sliver must be 
different in order that the DHCPv6 server can distinguish which sliver 
is sending the request. and then it can work just like a regular DHCPv6 
server without knowing whether the request is sent from a virtual 
machine or the host machine itself. however, the link-local address is 
almost always automatically generated, therefore, we must have each 
(virtual) interface MAC address for a virtual machine.

i'm not sure but i guess this is the way that Xen or VMware takes to 
solve the problem - to assign an interface in the virtual machine with a 
virtual MAC address instead of that one for the real network interface 
card.

> b) If it is an autoconf'd V6 address, what procedure should be used to give
> each vserver a unique address?  One idea would be to overload the EID based
> on the EUI-48 ether mac# + some system specific unique identifier for the
> vserver (or virtual machine) to which this address belongs in a manner
> compatible with the way EUI-48 numbers are encapsulated into EUI-64.  For
> example, suppose your ether mac# was de:ad:aa:aa:00:01 and the identifier
> for your vserver was 123 (i.e, the vid), then the IPv6 EID would be
> ::dead:aa12:30aa:0001.  Again, I am wondering how this is handled on Xen or
> VMware?
>
>   
this is the same with the DHCPv6 case. because EUI-64 scheme is working 
based on the MAC address of an interface. it should be a feasible way to 
assign virtual MAC address to an interface in virtual machine. ;-)

> For 2), regardless of how we assign addresses to slice (or virtual
> machines), we will need a solution to look up a sliver's unique IPv6
> address.  There are two approaches that I can think of.
>
> a) We can support a dynamic DNS solution at the planet-lab.org DNS server
> such that requests for $slivername.$planetlabhost.nodes.planet-lab.org will
> resolve to the correct IPv6 address.  The drawback is that there is only one
> primary DNS server and if communication to this DynDNS server fails, then
> the slice's IPv6 address wont be registered/available.  The benefit of this
> approach is that it requires now coordination with the sites that host
> PlanetLab nodes.
>
> b) We can put a DynDNS server into the root context of each PlanetLab host
> such that it forward resolves the IPv6 addresses of the slivers it hosts.
> This addresses the scalability / reliability issues from the solution above
> where we only have one primary DNS server.  The drawback is that we need to
> ask (and convince) each site to configure their DNS servers to delegate
> name looks up to the appropriate PlanetLab nodes that they host.  Another
> drawback is that DNS doesn't lend itself well to slice churn on the order of
> minutes or hours (e.g., for the short term experiments that folks like
> EMULAB would like to run on a PL based system).
>
> Maybe a combo DNS solution of a&b, where the DynDNS server from a) acts
> either as a primary when sites do not agree to do b), or as a secondary to
> the DNS servers on the PlanetLab hosts themselves.
>
> Any thoughts on this?
>
> Marc
>
>   

for the dynDNS issue, i support the idea of combo a&b.

furthermore, a new question comes to me, why don't we assign one (or 
several) 64-bit interface id to a *user* rather than to a sliver? in 
such a scenario, the sliver's ipv6 address can be generated from the 
host's /64 prefix and the interface id of whom currently uses it, 
without need of DHCPv6 or automatic configuration. further, there is no 
need of dynamic name resolution. we can give a *static* name for each 
user of the PlanetLab.

the only issue is that we should consider the problem of address 
conflict. 2^64 is quite as same as the space for credit card number (16 
decimal + 3 validation codes), therefore if we apply a specific 
characteristic in the interface id, the conflict can be easily avoided. 
even we can use the approach like cryptographically generated address 
(CGA, RFC 3972), in order to protect the user identification.

further comments?

best,
maoke