Re: [vwrap] VWRAP and IPv6

[Richard Barnes <[e-mail]>]

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



On May 20, 2010, at 8:55 AM, Michael Dickson wrote:

> 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
>>
>>
>
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap