Re: [vwrap] VWRAP and IPv6

[Richard Barnes <[e-mail]>]

I'm losing interest in this debate, and I think we've all said our  
piece, so I'll just close with a reference to the venerable RFC 1958,  
"Architectural Principles of the Internet":
"
    In general, user applications should use names rather than  
addresses.
"
(taken from a nice presentation that Dave Thaler gave on how  
pathological IP addresses can be:)
<http://www.ietf.org/proceedings/73/slides/plenaryw-1.pdf>

Feel free to use IPv6 addresses in the application layer if you want,  
but be aware that there be dragons.

--Richard


On May 20, 2010, at 10:46 AM, Morgaine wrote:

> Abstracting over addresses is fine, Richard, but after you've dealt  
> with the abstractions you typically end up with addresses, and  
> that's what protocols work with from then on.
>
> The textual abstractions are only there for human comfort, ease of  
> configuration, and great flexibility of indirection, but  
> abstractions are just means to an end.  After the address  
> abstractions are de-abstracted, protocols work with the much more  
> efficient binary representations.  That's practically universal.
>
> It's easy to give a practical example of such operation.  For  
> example, consider a design in which all VW objects have two parts,  
> an in-world object (IWO) and an in-client object (ICO), where the  
> ICO is replicated in each client.  Let both parts be active, ie.  
> both sides can be event generators.  It's easy for ICOs to address  
> update events to their IWO because there is only one IWO, and access  
> could be optimized to network level after the de-abstraction step  
> for efficiency.  But what about updates in the reverse direction,  
> which is 1:N?
>
> In the typical IPv4 environment, the usual approach would be a  
> heavily indirected one, with updates travelling through layer upon  
> layer of middleware before reaching their target ICO.  In an IPv6  
> environment in which each ICO can have its own IPv6 address, there  
> need be no middleware at all between the host kernel and the target  
> object.  The resulting increase in efficiency by orders of magnitude  
> can have major ramifications on the operation of your world and of  
> your clients.
>
> And the cost of this massive leap in efficiency?  Merely to inform  
> the IWO of the ICO's dynamic IPv6 network address, which borders on  
> the trivial.
>
> One of my main interests is VW scalability, both of worlds and of  
> clients, and such efficiency gains are truly important.  Scaling VW  
> complexity and rendering of crowds or of highly detailed  
> visualizations requires some lateral thinking and more powerful  
> networking paradigms than we have been used to until now.  IPv6  
> offers some interesting solutions in that direction, and they will  
> be used.
>
>
> Morgaine.
>
>
>
>
>
> ==================================
>
> On Thu, May 20, 2010 at 2:43 PM, Richard Barnes <[e-mail]>  
> wrote:
> As an aside, there's nothing that says that subscribers have to be  
> allocated a /64.  Some proposed addressing schemes that are more  
> conservative (in the Asia/Pacific region IIRC) actually assign much  
> longer prefixes (smaller address blocks) to customers.
>
> Fine-grained addressability is not the same as fine-grained  
> allocation of *IP* addresses. Think of it this way: HTTP has very  
> fine-grained addressability, with individual identifier/locators for  
> pages, images, scripts, etc.  It's able to accomplish this not by  
> assigning an IPv6 address to every object, but by using an  
> application-layer identifier/locator -- namely a URL.
>
> Not using IPv6 addresses in applications is not painting oneself  
> into an IPv4 corner, it's good protocol design following the  
> layering model of the Internet.  (If we're using IPv4 addresses for  
> identifiers, we shouldn't be doing that either!)  Abstracting over  
> IP addresses is about freeing the application from having to worry  
> about whether its IPv4 or IPv6 or IPv10 or X.25 or whatever else at  
> the network layer.
>
> --Richard
>
>
>
>
> On May 20, 2010, at 9:23 AM, Morgaine wrote:
>
> On Thu, May 20, 2010 at 10:59 AM, Han Sontse  
> <[e-mail]> wrote:
> I recognize that it is temping to take advantage of the huge address  
> space that IPv6 offers but my test engineer instincts tell me it is  
> unwise to do so.
>
>
> I too am an engineer, but solid engineering instincts do not tell us  
> to use only those facilities whose numbers or sizes can be tested  
> exhaustively.  If it were so, we would not have multi-terabyte disk  
> drives today.
>
> The /64 minimum routable subnet of IPv6 address space was not  
> designed as it was because people were expected to need 2^64 NIC  
> cards in their PCs.  This immense per-user address block was created  
> because IPv6 designers could see beyond IPv4's use of addresses for  
> host interface identification, and were visionary enough to realize  
> that all objects could benefit from network addressability.  This  
> also happens to be one of the key messages of REST.  Addressability  
> is extremely important, the finer the better, not only on the Web,  
> and not only with URIs.
>
> With IPv6 just around the corner, I foresee such addressability at  
> fine levels of granularity appearing in VWs relatively soon.  IPv4  
> worlds will have to emulate what IPv6 worlds achieve natively, and  
> that is the right way around.  When legacy design restricts  
> progress, the only thing it achieves is rapid obsolescence.
>
> I would prefer VWRAP not to be painting itself into an IPv4 corner  
> of obsolescence before it's even released, which is why I'm raising  
> this topic --- it's intended as a heads-up for the group.
>
> Since the rise of VWs and IPv6 take-up are going to occur  
> concurrently, I think the next few years are going to be very  
> interesting on the VW networking front.  My recommendation is to  
> observe carefully what happens, and not to make any rash decisions  
> based on legacy ideas that could cut off your future.
>
>
> Morgaine.
>
>
>
>
>
> ===================================
>
> On Thu, May 20, 2010 at 10:59 AM, Han Sontse  
> <[e-mail]> wrote:
> It's a bad idea to use IP addresses for anything other than  
> addressing a machine level interface.  Using them to interface  
> objects at or above the application level is asking for trouble.    
> UUIDs are UUIDs... IP addresses are IP addresses.   The two should  
> not be mixed.   I recognize that it is temping to take advantage of  
> the huge address space that IPv6 offers but my test engineer  
> instincts tell me it is unwise to do so.
>
> Han.
>
> On May 20, 2010, at 2:50 AM, 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.
>
> 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
>
> _______________________________________________
> 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