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
