I'm tired and I'm going to bed. Tony
On Jul 13, 2010, at 12:59 AM, Robin Whittle wrote: > Short version: Despite me writing two detailed examples > with questions, Tony has not provided any > explanation of how an ILNP stack could work > with IPv6 applications - to support ordinary > operation with such applications in non-ILNP > hosts while also providing all ILNP's benefits > when working with such applications in ILNP- > equipped hosts. > > Rather than me work on long examples with > detailed questions which Tony generally doesn't > answer, I suggest that he either agree with the > statement that ILNP can't work with ordinary > IPv6 applications - or that he show in detail > exactly how it would work. > > Tony also wrote: > >> a name oriented stack would be the best solution. > > So I asked him what he thinks of Christian > Vogt's Name Based Sockets architecture, which > does exactly this - but would require radical > rewriting of many applications and major changes > to many of the protocols they use. > > > Hi Tony, > > Thanks for your reply to one of my questions: > >>> When an application does a DNS lookup of an FQDN via the ILNP stack, >>> and the stack receives the results and finds ID and L64 records (I am >>> ignoring ILNPv4, LP records etc. for simplicity) does the stack >>> return the IP address to the application with the upper 64 bits zeroed? >> >> This is an implementation question, and there are various different >> alternatives. I can conceive of several different implementation >> strategies, all of which seem equally valid at this point. Assuming >> a BSD sockets based implementation: >> >> a) Pass back any valid v6 address. When the socket is opened, index >> into the locator cache and determine the locators and ID from >> the address. > > "Any valid IPv6 address" isn't clear. Do you mean any random > address, or do you mean one of the addresses formed by a Locator > and the Identifier? > > I don't see how this could work, or be compatible with the text > in the I-Ds which indicate that the upper 64 bits of addresses > should be zeroed. > > So this is not an explanation. > > >> b) Pass back a pointer/index/handle to the record in the locator >> cache. Play fun games to ensure that the locator cache entry >> is still valid. Lie to the application in telling it that it >> is a v6 address. Might mess up applications that feel the >> urge to print the v6 address. Breaks my heart not at all. ;-) > > This is obviously not a solution. Your disregard for ILNP > incompatibility with existing IPv6 applications is duly noted. > > >> c) Pass back a pointer/index/handle to a FQDN cache in the stack. >> Only do the DNS lookup when the socket is opened. > > This is like b) - returning an artificial number as a result of a > DNS. > > You would need to do this for all newly opened sockets - since > you don't know whether the socket will be for an ILNP host or > not. Lookups of FQDNs such as with getaddrinfo() can return > multiple IP addresses, with a linked list of addrinfo > structures. This c) approach obviously can't work, since you > don't even know how many pointers to return as if they are IP > addresses, since you haven't yet done the lookup. > > > None of what you write above is helpful to someone who wants to > understand how an ILNP stack would work, in its most basic > sense - supporting ordinary IPv6 applications in their > communications with IPv6 and or ILNP hosts which are also > running ordinary applications. > > >> That's two minutes of thought. > > It appears that this is the first time you have considered this > - I had assumed you and Ran had already gone through it so you > were sure ILNP could work with ordinary IPv6 hosts, as you both > claim it does. > > >> Other stacks are not BSD sockets based, such as Cisco's IOS. >> There all sorts of strange things could happen. ;-) > > Sure - I was trying to devise the most minimal, conducive, > example of ILNP stack operation to try to figure out how it > would work. > > >> And having a name oriented stack would be the best solution. > > OK - so you believe ILNP is not the best solution. > > What do you think of Christian Vogt's Name Based Sockets > architecture? That requires substantially rewritten > applications. > > >> I was trying to reply to the rest of this, but gave up. It was all >> implementation detail. > > It was my attempt to understand how ILNP would work - and the > more I looked at it, the more I doubted it could work. > > Your inability to provide any explanation of how it could work - > and your lack of care about compatibility with many IPv6 > applications - makes me even more inclined to think that no-one > has ever tried to figure out how to make ILNP work with IPv6 > sockets, and that in fact it can't. > > Rather than me doing lots of work on examples with questions > which you generally don't answer, please consider this: > > The ILNPv6/v4 stack can't support all, or anything like all, > existing IPv6/v4 applications - to allow them to operate > normally with non-ILNP hosts, while also enabling them to > work properly with such applications in ILNP-equipped hosts, > to achieve the benefits: multihoming, mobility and TE. > > If you agree, then that's fine. To me and pretty much > everyone else, that your understanding of ILNP is completely > at odds with what most people consider deployable. > > If you disagree, then please provide some examples, with details > comparable to my examples, of exactly how the ILNP stack would > support existing IPv6 applications. > > - Robin > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
