Re: [vwrap] VWRAP and IPv6

[Michael Dickson <[e-mail]>]

On Thu, 2010-05-20 at 09:50 +0000, Morgaine wrote:
> A /64 is the smallest routable IPv6 subnet, hence there is no extra
> routing overhead for the 2^(128-64) addresses in the basic block that
> every user will have allocated.
> 
> Needless to say, there won't be anything like 2^64 objects in your
> scenegraph, so if you use your IPv6 address space to address every
> scenegraph object that you have instantiated client-side, you will
> still have an extremely sparsely used /64 block.  You'll be keeping
> track of which addresses you have assigned dynamically of course. (An
> address space of this size is not linearly scannable in realistic
> time.)
> 
> In principle this is no different to using UUIDs --- your IPv6
> micro-servers will have unguessable IPv6 addresses within your /64
> block, and it'll be up to you to tell other participants in the
> protocol (for example server-side objects) with which of your IPv6
> micro-servers they are to communicate.  This is why an ADT that is
> supportive of IPv6 operation needs to be able to carry such data
> efficiently --- the UUID is no longer the only 128-bit datum of
> interest.

No, it *is* different as another poster has indicated because a hardware
or software layer needs to maintain the physical to address translation
and those tables are generally of finite size. In a virtualized
environment it gets worse size across multiple vm's you may need to
maintain more that one copy for each entry to get hardware speeds.

VWRAP is an application layer protocol and as such it should use logical
names for things as opposed to IP addresses and let the appropriate name
to address translation happen.

-1 to using IPv6 addresses as identifiers for this and other reasons
that have been raised. I think the consensus has been pretty solidly
against it so far.

Mike


> Of course your entire /64 block is routed as one, since there are no
> smaller routable subnets in IPv6, and therefore your objections about
> routing non-scalability do not apply.
> 
> 
> Morgaine.
> 
> 
> 
> 
> =====================================
> 
> On Wed, May 19, 2010 at 10:56 PM, Richard Barnes <[e-mail]>
> wrote:
>         The impact of IPv6 on VWs should be far less than you imagine,
>         I think. :)
>         
>         It has often been said that many, many things will be assigned
>         IPv6 addresses.  There will certainly be enough to go around,
>         but that doesn't make them good application-layer
>         identifiers.  If you want to use IP addresses with IP, they
>         have to route, and that means that they have to be either (1)
>         topologically assigned, or (2) overlay routed, e.g., with
>         mobile IP.  So if you want to use an IP address to address
>         something, you're going to have to either change that address
>         when the thing gets connected differently, or you'll need some
>         overlay routing scheme to route to a persistent address.  (And
>         if you're not going to use the address with IP, then why would
>         you use an IP address?)
>         
>         VWRAP, as an application layer protocol, has a choice about
>         what identifiers to use for things and how to use those
>         identifiers.  ISTM that using IP addresses (again, of either
>         type) remains a bad idea, compared with something that is
>         decoupled from the routing layer.
>         
>         As far as the DNS, I'm not sure what your point is:
>         (i) DNS caching has been around for decades
>         (ii) DNS names can already refer to multiple addresses
>         (iii) Depends on implementation.  Maybe there's some
>         application-layer way to resolve names.  E.g., SIP endpoints
>         don't need to have DNS records because the INVITE transaction
>         maps from SIP URIs to IP addresses.
>         (iv) From RFC 4291: "IPv6 addresses are 128-bit identifiers
>         for interfaces and sets of
>         interfaces"
>         (v) Seems like there's a use case lurking, hard to address
>         without details.  But you're probably still at the application
>         layer.  For instance, if you were telling your peer to send
>         you an HTTP request, you would send an HTTP URI, which can
>         already handle IPv6 addresses.
>         
>         --Richard
>         
>         
>         
>         
>         On May 19, 2010, at 9:35 AM, Morgaine wrote:
>         
>                 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
>                 
>                 _______________________________________________
>                 vwrap mailing list
>                 [e-mail]
>                 https://www.ietf.org/mailman/listinfo/vwrap
>         
>         _______________________________________________
>         vwrap mailing list
>         [e-mail]
>         https://www.ietf.org/mailman/listinfo/vwrap
>         
>