Re: [vwrap] VWRAP and IPv6

[Morgaine <[e-mail]>]

The impact of IPv6 on VWs is going to be far greater than you imagine, I
believe.  As things stand, VWRAP is being designed around the features and
limitations of IPv4 networking.  It will of course be able to ride on top of
IPv6 as a transport, but unable to benefit from its improved feature set,
unless we provide the means to do so.

The question "Why is there ever a need to carry an IP address in this
application-layer protocol, as opposed to, say, a DNS name or a URI?"
suggests an IPv4 mindset, because in IPv6 it has a variety of possible
answers:  (i) When the DNS lookup has already been done and does not need to
be done again, (ii) When a FQDN maps to multiple addresses, but you want to
refer to a specific one, (iii) When an IPv6 address does not have an
external address record, (iv) When the host is already known and the IP
address denotes something other than a physical NIC interface, or (v) When
listeners are allocated locally and dynamically for the current session
only, and their IP addresses need to be communicated to a peer --- this will
be an extremely common use case with IPv6.

In today's IPv4-based systems, it is normal for a user's machine to have a
single IP address, and for a client on that machine to talk to a server that
has a single customer-facing IP address too (although it may also have
others that are not public).  In IPv6-based systems, this simple scenario is
still possible but represents only a special case among a new and vastly
expanded set of IPv6 use cases.

The smallest allocatable block of IPv6 address space is a /64, so 2^(128-64)
IP addresses is the number that most normal IPv6 users will have, although
the much larger /48 blocks of 2^80 addresses are commonly assigned to users
as well.  With such IP riches client-side, it is certain that they will be
used for something, and the obvious suggestion is to give every VW object an
IPv6 address of its own.

Lest we forget, one of the most important properties of the REST paradigm is
addressability, but the benefits of high addressability go far beyond the
Web.  This is a property that will become ubiquitous throughout networked
computing with IPv6.  It's probably no exaggeration to say that *everything*
will be getting its own IP address. :-)

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.

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.)


Morgaine.







==============================================

On Mon, May 17, 2010 at 3:50 PM, David W Levine <[e-mail]> wrote:

>
>
> [e-mail] wrote on 05/17/2010 10:08:26 AM:
>
> > [image removed]
> >
> > Re: [vwrap] VWRAP and IPv6
> >
> > Richard Barnes
> >
> > to:
> >
> > Morgaine
> >
> > 05/17/2010 10:09 AM
> >
> > Sent by:
> >
> > [e-mail]
> >
> > Cc:
> >
> > vwrap
> >
> > In the spirit of good layering, it seems like we should be talking
> > about avoiding direct reliance on IP addresses instead of how we can
> > accommodate different addresses in the protocol.  Why is there ever a
> > need to carry an IP address in this application-layer protocol, as
> > opposed to, say, a DNS name or a URI?
> >
> > --Richard
> >
> +1
>
> We may from time to time have a IP address stuck in the form of a URI
> which has the dotted decimal form of an resource. The spec should make
> sure that form can be an IPV6 address, but that should be very straight
> forward.
>
> There may be some IPV6 features which eventually impact us at the protocol
> design level, but the entire VWRAP specification has been written in terms
> of
> URIs and Capabilities, not in terms of low level IP addresses. It would
> take an
> incredibly powerful argument to suggest that this should change. Likewise,
> while
> IPV6 changes addressing at the bottom of the stack, it doesn't appreciably
> change
> the cost of holding open sessions, of managing sockets and buffers inside
> of
> clients (especially lightweight devices) Further while we can all devoutly
> hope
> that IPV6 finally deploys broadly, making it a dependancy in the near term
> feels
> rather like a roadblock to possible adoption.
>
> - David
> ~ Zha
>
>
>
> >
> > On May 14, 2010, at 7:32 AM, 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
> >
> > _______________________________________________
> > vwrap mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/vwrap
>