Subject: [vwrap] VWRAP and IPv6

From: Morgaine <[email-masked]>
Date: Fri, 14 May 2010 12:32:32 +0100

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.

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 14 May 2010 08:57:13 -0700

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:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 17 May 2010 10:08:26 -0400

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

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  
> environment.  By the time that VWRAP is fully defined, we should  
> implementations to occur in IPv6-accessible worlds.  This is a  
> 	• 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  
> 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  
> 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

---

From: David W Levine <[email-masked]>
Date: Mon, 17 May 2010 10:50:49 -0400

[email-masked] 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:
> 
> [email-masked]
> 
> Cc:
> 
> vwrap
> 
+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

---

From: Morgaine <[email-masked]>
Date: Wed, 19 May 2010 14:35:57 +0100

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.

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

---

From: Richard Barnes <[email-masked]>
Date: Wed, 19 May 2010 17:56:41 -0400

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.
>
> 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.
>
>
>
>
>
>
>
> 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
> "IPv6-

---

From: "Robert G. Jakabosky" <[email-masked]>
Date: Wed, 19 May 2010 16:45:50 -0700

On Wednesday 19, Morgaine wrote:
> 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/

> 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

---

From: Morgaine <[email-masked]>
Date: Thu, 20 May 2010 10:50:53 +0100

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 <[email-masked]> wrote:

> The impact of IPv6 on VWs should be far less than you imagine, I think. :)
>
> 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?)
>
> 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.
>
> (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
>
>
>
>> 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

---

From: Han Sontse <[email-masked]>
Date: Thu, 20 May 2010 02:59:15 -0700

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

---

From: Michael Dickson <[email-masked]>
Date: Thu, 20 May 2010 07:55:08 -0500

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

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 May 2010 09:18:23 -0400

Just to try to clarify the pain that comes from trying to use IPv6  
addresses as pure identifiers (as separate from their routing/locator  
function), I can think of at least five groups who are trying to come  
up with approaches to making this work:
1. HIP <http://tools.ietf.org/wg/hip/>
2. HIPRG <http://irtf.org/charter?gtype=rg&group=hiprg>
3. MIP6 <http://tools.ietf.org/wg/mip6/>
4. LISP <http://tools.ietf.org/wg/lisp/>
5. MEXT < http://tools.ietf.org/wg/mext/>

--Richard

---

From: Morgaine <[email-masked]>
Date: Thu, 20 May 2010 14:23:33 +0100

On Thu, May 20, 2010 at 10:59 AM, Han Sontse <[email-masked]>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 <[email-masked]>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.
>
> 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.
>
>> 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
>>
>>
>>
>>> 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
>>> 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

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 May 2010 09:43:28 -0400

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  
> <[email-masked]> 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  
> <[email-masked]> 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.
>
>> routing overhead for the 2^(128-64) addresses in the basic block  
>> that every user will have allocated.
>>
>> track of which addresses you have assigned dynamically of course.  
>> (An address space of this size is not linearly scannable in  
>> realistic time.)
>>
>> 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.
>>
>>
>>
>>
>> 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?)
>>
>> 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.
>>
>> (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.
>> 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
>>
>>
>>
>> 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.
>>
>> 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  
>> 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.
>>
>> will have, although the much larger /48 blocks of 2^80 addresses  
>> are commonly assigned to users as well.  With such IP riches client- 
>> obvious suggestion is to give every VW object an IPv6 address of  
>> its own.
>>
>> obtained from its FQDN.  That's IPv4 thinking, and represents only  
>> a very basic use case for IPv6.  In more extended use cases, IPv6  
>> 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.
>>
>>
>>
>>
>>
>>
>>

---

From: Morgaine <[email-masked]>
Date: Thu, 20 May 2010 15:46:46 +0100

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 <[email-masked]> wrote:

> 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
> 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
>
>
>
>
>> 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.
>>
>>> routing overhead for the 2^(128-64) addresses in the basic block that every
>>> user will have allocated.
>>>
>>> way to resolve names.  E.g., SIP endpoints don't need to have DNS records

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 May 2010 11:19:44 -0400

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.
>
> 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.
>
>
>
>
>
> 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
>
>
>
>
> 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  
> smaller routable subnets in IPv6, and therefore your objections  
> 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?)
>

---

From: David W Levine <[email-masked]>
Date: Thu, 20 May 2010 11:42:53 -0400

+1 on all counts here.

The current service establishment pattens proposed in VWRAP is not only 
IPV4/IPV6 agnostic, it leverages the 
web and internet in an extremely traditional fashion. Named services are 
request via a capability name and 
seedcap, and a URI is returned, with possible content negotiation as to 
details.

 The whole point of returning a URI is to isolate VWRAP from transport. 
That URI could bind onto an HTTP(S) URL, onto
an XMPP  endpoint, onto a RTP stream, onto SIP... 

The most common profile for some time, is likely that most services will 
be on boring URLs with boring http/https endpoints, with names
which bind onto boring IPV4 addresses, but, it should be totally 
transparent to the higher level code whether the 
network stack is V4 or V6, or TCP/IP at all. If I had a valid URI which 
bound onto a SNA LU 6.2 endpoint,  and
matching transport stacks, it ought to work. 

- David
~ Zha 

[email-masked] wrote on 05/20/2010 11:19:44 AM:

> 05/20/2010 11:20 AM

---

From: Morgaine <[email-masked]>
Date: Thu, 20 May 2010 17:31:19 +0100

It wasn't intended as a debate, Richard, only as a heads-up of what's
coming.  We each have our own individual interests, and the intersection of
VWs and IPv6 may not be one of yours ---  that's perfectly fine of course.
:-)

But IPv6 is coming.  /64's for everyone are coming.  The desire to scale VWs
is coming.  The need to reduce or eliminate overheads where technology
allows is coming too, and IPv6's huge assigned user address blocks allow
exactly that.  Some virtual worlds will take advantage of this important
facility, and hence are likely to scale far better than those that don't.

I looked at Dave Thaler's slides, but there's very little there on this
topic.  The advice "user applications should use names rather than
addresses" is very good advice indeed, but Dave prefixed it very sensibly
with "In general" because it does not apply in all cases.  In particular, it
does not apply where there are no names, nor where IP addresses are
generated dynamically.

I gave a practical example of this in my previous post.  When an ICO is
generated dynamically in a client, there is no corresponding domain name
that can be looked up, so a dynamic name would have to be manufactured to
comply with a "must have names" dogma.  There might actually be a good
technical (and non-dogmatic) reason for indirection by name at that level.
If so then it would have to be examined, in the usual engineering way.

Notice however that dynamic name lookups don't make IP addresses disappear.
If we provide an IWO with a name abstraction to denote an ICO's IPv6
address, then the IWO would acquire the ICO's address by lookup.  The IWO
could then make the very efficient direct connection to its corresponding
IPv6 peer on the client.  The use of name lookups just affects IP address
acquisition, it doesn't change the IWO-ICO connection architecture.

Notice that this fits into our REST-like model very cleanly.  A REST
resource could be provided in the client, acting as a container which
indexes local ICOs by the name (URI) of their corresponding IWO.  An IWO
could then easily request any ICO metadata it needs, including the IPv6
address of its peer ICO, prior to establishing a direct connection to it.

Morgaine.

On Thu, May 20, 2010 at 4:19 PM, Richard Barnes <[email-masked]> wrote:

> 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,
>   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:)
> Feel free to use IPv6 addresses in the application layer if you want, but
> be aware that there be dragons.
>
> --Richard
>
>
>
>  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.
>>