Re: [vwrap] VWRAP and IPv6

[Dzonatas Sol <[e-mail]>]

There has been discussion about IPv6 with LLP, and that's probably only 
where any extra type is needed. In any other format or scheme there is 
no need for an extra type since a string value can cover the colon-dot 
notation of IPv6.

A UUID used in the IPv6 address is not really a UUID even if it can be 
used the same way. The exception being that unique generated IDs would 
need to check to make sure they don't collide with predefined addresses. 
The real benefit for this method is better left behind a custom network 
that isn't directly bridged to the Internet. There would need to be a 
gateway to convert UUID-IPv6 values to valid Internet addresses. The 
special network most likely would use the multi-cast broadcast features 
of IPv6. Without much detailed digression, newer technology for 
multi-core CPUs have broadcast arrays that would make the IPv6 
multi-cast probably not needed anymore for such solutions.

Morgaine wrote:
> Despite exceedingly low takeup of IPv6 so far, it's coming, and in the 
> context of IETF WG rates of progress, it is really imminent.� Of 
> special relevance to us is that IPv4 addresses are projected to run 
> out within roughly the same time frame as VWRAP materializes.
>
> There is little point in creating a new VW protocol today purely in 
> the context of IPv4 without thinking about tomorrow's IPv6 
> environment.� By the time that VWRAP is fully defined, we should 
> expect a substantial and rapidly increasing proportion of VWRAP 
> implementations to occur in IPv6-accessible worlds.� This is a 
> situation for which we need to plan now, otherwise the protocol will 
> be obsolete before it's even ready.
>
> To get the ball rolling, here are a few IPv6-related issues that we 
> could usefully address in the group:
>
>     * The 128-bit IP address of IPv6 is likely to become a common
>       payload, so it should be supported natively.� LLSD already
>       supports one 128-bit data type of course, the UUID.� IPv6
>       addresses should not be transported in UUID fields however,
>       since their statistical properties and semantics are totally
>       different.� In any case, the two spaces are disjoint so
>       confusing them would be a mistake.� The IPv6 address seems a
>       good candidate for its own defined type, in the absence of wide
>       integers.
>
>     * The extremely large address space of IPv6 has often been
>       portrayed as allowing everything around us to have its own IP
>       address.� In the context of virtual worlds, this idea can
>       actually be put to good use, with each virtual object bearing
>       its own IPv6 address.� One candidate application for this has
>       already been described in earlier discussions --- for example,
>       implementing virtual object simulation in two parts, one
>       client-side and one world-side, the two parts communicating
>       directly.� IPv6 addressing of objects makes this relatively easy
>       to achieve efficiently, so its implementation in IPv6-based
>       worlds is almost inevitable before long.� VWRAP should be ready
>       for this.
>
>     * The event queue in current implementations provides an indirect
>       and highly inefficient way of achieving world-to-client
>       communications.� IPv6 offers opportunities for direct
>       communication that can make the event queue approach obsolete,
>       so it's worth examining IPv6-oriented alternatives.
>
>     * We recently discussed feature and protocol negotiation within
>       VWRAP.� IPv6 provides much opportunity for new features and
>       protocol pathways to be negotiated between endpoints, so it
>       gives us a very real and imminent set of use cases for negotiation.
>
>
> It would also be a feather in VWRAP's cap to be considered an 
> "IPv6-capable application protocol" in a stronger sense than just to 
> be carried by IPv6 networks.� IPv6 does after all bring new abilities 
> to the table, such as the huge addressing, and it would be a mistake 
> to ignore them.
>
>
> Morgaine.
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>