[Planetlab-devel] IPv6 support for MyPLC

Bound, Jim Jim.Bound at hp.com
Thu Nov 9 12:06:57 EST 2006


Hi Marc,

Let me be very clear.  The reason PLL would not be able to use IPv6 is
because not one mail on this list has made it clear to me how exactly
you configure IPv4 today or how you want to assign IPv6 addresses to
vservers.  I believe stateless autoconfig will work the problem is that
any IP architecture view assumes some entity absorbs the IP address
except in the case of a VLAN switch.  I had indirectly suggested a
software VLAN switch to multiple vservers on a single node for IPv6 with
use of prefix bits and same EUI.  No computer science or networking
engineering model, architecture, or paradigm can be done well in the
face of variant glued system integration components overlaying the base
IP network architecture reference model.  This is not a problem of IPv6
but rather a question of how to network configuration per the PLL
infrastructure.  IPv6 has done its job the tools exist.

Thanks
/jim 

> -----Original Message-----
> From: Marc E. Fiuczynski [mailto:mef at CS.Princeton.EDU] 
> Sent: Thursday, November 09, 2006 10:01 AM
> To: Bound, Jim; devel at lists.planet-lab.org
> Subject: RE: [Planetlab-devel] IPv6 support for MyPLC
> 
> Hi Jim + *,
> 
> Thanks for the feedback.  The problem with static IPv6 
> assignment is that it involves some sort of 
> central/coordinated management.  It is not clear that we can 
> request 300+ sites to set this up on our behalf, especially 
> as we insist to be on the outside of firewalls etc.  Before 
> resorting to such a solution (which I personally consider a 
> cop out and IPv6 not delivering on its promise), I wanted to 
> explore what one could do with the EUI.
> Continuing the search for a reasonable zero-admin autoconf 
> solution, my sense is that we could do the following:
> 
> 1) acquire a 24bit IEEE company id + assign some random 24 
> bit value and rely on DaD to ensure uniqueness
> 
> or
> 
> 2) overload the special 15bit value for EUI/MAC-48 
> encapsulation into EUI-64 and hope it wont conflict with IPv6 
> over firewire
> 
> or
> 
> 3) leverage the fact that all PL nodes will be dual stacked 
> and that each physical link will have a proper IPv4 address 
> that is either statically assigned or obtained by an existing 
> DHCP server to generate a unique EUI that identifies the VM.  
> One idea is to leverage something that essentially looks like 
> a IPv4-mapped-IPv6 address, except that it is permitted to 
> have a proper IPv6 prefix.  E.g., suppose the host is 
> assigned 128.112.139.71, then its corresponding link local 
> address could be fe80::ffff:128.112.139.71, right?!  We can 
> now use the unused upper 16bits to uniquely identify each 
> sliver.  E.g., sliver #500 would be fe80::500:ffff:128.112.139.71.
> 
> Thoughts?
> 
> Marc
> 
> 



More information about the Devel mailing list