Re: [vwrap] VWRAP and IPv6

["Robert G. Jakabosky" <[e-mail]>]

On Wednesday 19, Morgaine wrote:
> Faced with that future, it's a mistake to think in IPv4 terms and consider
> IPv6 addresses as merely denoting a host which can be obtained from its
> FQDN.  That's IPv4 thinking, and represents only a very basic use case for
> IPv6.  In more extended use cases, IPv6 addresses will become much more
> like active local UUIDs than like today's host IP addresses.  They will be
> used for inner-application addressing, for example to make every object in
> an application an addressable micro-server.

It is an interesting idea (making all objects directly addressable), but you 
are not thinking about the costs of dynamically binding large number of IPv6 
addresses to the server's NIC.  Think about the case where you have 100 
servers with 10,000 - 100,000 objects each, those servers will need to send 
out a lot of ARP traffic.  Also each server would need to have a very large 
ARP cache, and the border routers would need to handle advertising the routes 
for all those IPv6 addresses.  This will not scale well.

The only way to get around the routing/ARP issue would be to assign a block to 
each server and allocate IP addresses from the servers block for object on 
that server.  But then you can't move the object between servers with out 
changing it's IP address, which it would have to send a notice to all who 
where communicating with it.

Also besides the network routing/ARP traffic overhead, there is also overhead 
in the OS layer.  Have you even tested what the resource overhead is in the 
OS with 10,000 - 100,000 IPv6 addresses bound to a NIC?  How many open socket 
connections do you think the server will need to handle? or would the objects 
communicate with connection-less unreliable UDP?

Maybe you should try out this idea with working code to show what the 
costs/overhead will be in management a large number of IPv6 addresses.
For testing you can get some free /48 or /64 blocks of IPv6 addresses from: 
http://tunnelbroker.net/

> VWRAP is being born into an IPv6 world, and it would be a mistake to
> hardwire IPv4 thinking into its design.  We continually refer to the need
> for extensibility and a desire to future-proof the protocol, but lip
> service is not enough.  Adding IPv6 addresses to the underlying ADT would
> provide a bare minimum level of thinking ahead to support VWRAP
> implementations that embrace large numbers of communicating objects.  (A
> generally extensible ADT would of course achieve the same thing, and more.)

Even when IPv4 runs out there will be a lot of people stuck on IPv4 networks 
old routers, old DSL modems, ISPs who are slow to add IPv6 support.

I don't see anyone on this list trying to hardwire IPv4 into the design of 
VWRAP.  As long as the VWRAP doesn't keep the SL UDP protocol as-is with it's 
fixed IPv4 address data type.

VWRAP should support both IPv4 & IPv6.  I see no good reason to lock VWRAP to 
IPv6 only.

-- 
Robert G. Jakabosky