Short version: ILNP is of no practical value to solving the routing
scaling problem since - assuming it could in fact
solve it under ideal conditions - and I am not sure
of that either. If so, it could only solve the
problem once the great majority of end-user networks
adopted it.
This would entail most end-user networks changing
all their host stacks and applications to be
compatible with the ILNP-modified version of IPv6.
They would also need to get IPv6 Internet
connections and stop using IPv4.
We can't force anyone to adopt anything. Our
solution needs to be attractive to the great
majority of end-user networks, from the smallest
to the largest. It needs to be attractive to them
in the near term - they won't adopt it unless it
provides immediate and substantial benefits.
Since end-user networks are only very indirectly
impacted by the routing scaling problem, the
benefits our scheme provides must be things which
are directly valuable, such as multihoming
and portability of address space when it was not
available to them by any other means, or perhaps
in a more cost-effective form than it is currently
available to them.
ILNP and any other proposal which involves host
stack changes, and worse-still application changes,
is a complete non-starter for the practical problem
of solving the routing scaling problem.
ILNP may be of theoretical interest, as a
clean-slate proposal. However, I am only interested
in discussing practical solutions.
Hi Ran,
On 5 October, you responded to my initial, tentative, critique of ILNP.
http://tools.ietf.org/html/draft-rja-ilnp-intro-01
based on what I recalled from listening to Steve Blake's presentation
in Dublin. I see now that the minutes of that meeting are here:
http://www.ietf.org/proceedings/08jul/RRG.html
and so are Steve's slides, which I had not seen before today:
http://www.ietf.org/proceedings/08jul/slides/RRG-4.pdf
My critique and your response:
http://psg.com/lists/rrg/2008/msg02464.html
http://psg.com/lists/rrg/2008/msg02604.html
> % I listened to Steve Blake's presentation and had enough of a look at
> % your I-D to determine that your proposal involves radical changes to
> % IPv6.
>
> As has been discussed in the past on the Routing RG list,
> the ILNP architecture can also support IPv4.
I don't see how it could, since it involves splitting the address
into two equal length segments, with differing semantics. This would
not be compatible with IPv4 as a protocol or with IPv4 address
assignments.
Your I-D mentions IPv4 only once, in passing and includes:
This documents the Concept of Operations for an experimental
extension to IPv6 which is known as the Identifier Locator
Network Protocol (ILNP).
The crux of this proposal is to split each 128-bit IPv6 address
into two separate fields, with crisp semantics for each.
Perhaps you mean tunneling IPv4 in some way over the ILNP system. If
so, this doesn't necessarily solve the routing scaling problem of the
IPv4 Internet.
> This is also on Slide 15 [All slide references are to the
> presentation made in Dublin in July 2008.]
The text is:
Same architecture can work for IPv4 (ILNPv4), but shortage of bits
makes the engineering ugly.
I think it would be more accurate to state that for IPv4 - where you
are proposing two 16 bit fields - your proposal could only make sense
in a theoretical discussion and could never be of practical use in
today's IPv4 Internet.
So ILNP is a modification to IPv6.
> The word "radical" is opinion and seems overblown.
I think "radical" is appropriate. You require changes to host
stacks, and I think to many applications - but not to routers.
You are proposing to have people adopt a drastically modified version
of IPv6 - a protocol which most folks have not adopted despite it
being available and promoted for a decade or so.
Yet to solve the routing scaling problem, we need most end-user
networks to adopt the new system. For ILNP to succeed in solving the
routing scaling problem, you would have to convince most end-user
networks to leave their IPv4 address space and to adopt IPv6 space
which is only meaningful to hosts with ILNP-modified stacks and
applications.
This is never going to happen. So I think your proposal is of
theoretical interest only. That doesn't mean it shouldn't be
discussed - but it should not be confused with an attempt to actually
solve the routing scaling problem with a proposal that large numbers
of end-user networks will actually want to adopt.
> Implementation of ILNP could be done in a manner quite similar to
> how one might implement SHIM6, for example. New DNS resource
> records appear regularly.
SHIM6 is only of advantage when both ends are using it. So in
general, for someone adopting SHIM6, the proportion of traffic which
benefits from SHIM6 scales directly with how many other people adopt
it. Initially, the proportion is close to zero.
For SHIM6, ILNP or whatever to provide benefits to end-user networks
sufficient to make a large number of such networks adopt it, the new
system needs to provide useful multihoming and "portability" (or at
least freedom from disruption and costs when selecting another ISP,
which I think can only be done with portable address space).
It is no good having multihoming etc. for 90% of your traffic, and
not for the other 10%.
This is why SHIM6, ILNP or anything similar will never in fact be
widely adopted. It only becomes useful enough to rely upon when
almost every other network in the world (ever other host in the case
of ILNP and SHIM6) has adopted it.
This will never happen.
> Adding an IPv6 Destination Option is straight forward and
> consistent with the rest of IPv6.
Sure, but it adds to the packet length, which is a source of overhead
in addition to IPv6's already bloated header.
At least this happens in the sending host - rather than a router -
with the application somehow knowing not to send a packet which would
cause the final packet to be longer than the MTU limit of the path.
> % These include changes in the API between applications
> % and the host stack.
>
> [draft-rja-ilnp-intro-01, section 7, page 10]
>
> Existing applications can use existing networking APIs with ILNP.
> No application needs to be updated or changed.
OK - but they don't gain any benefits of multihoming, freedom from
renumbering pain etc. Nor does the traffic of these applications
help with the routing scaling problem.
> For application protocols with referrals, one can use the
> concatenation of Locator and Identifier in place of the IP
> address -- again no protocol change and no application change.
OK, but any code which uses referrals is not going to work with
however you propose to do multihoming. That code would be using your
interface for plain "IPv6 as we know it" communications, unaffected
by whatever routing scaling benefits ILNP can provide and, as best I
understand it, unable to continue sessions in the even of an
interruption which multihoming is supposed to cope with.
> A new API is offered -- in addition to existing APIs. This new
> more abstract API has also been discussed on this list several
> times. It would be modeled on the existing Java networking API,
> using the comhination of "domain name" and "service name" in lieu
> of the sockaddr. Applications using this new API should work
> equally well over IPv4, IPv6, HIP, ILNP, SIX/ONE, LISP, or pretty
> much any other proposal here. The new API works regardless of
> proposal mainly because it is properly abstracted, not requiring
> applications to know anything about how the networking services
> are implemented. My main regret is that the IPv6 community
> did not specify this a decade ago.
I agree entirely - but I guess they were trying to make it easier to
get IPv4 applications running on IPv6.
> (Such a new API might even work over an OSI stack, if any still
> exist, although I haven't considered the OSI question in any
> detail.)
OSI is clearly irrelevant to any discussion of practical solutions to
the routing scaling problem.
> % So I understand that your proposal involves revising the
> % IPv6 protocol, host stacks, host APIs and applications.
>
> ILNP involves adding a new IP option to carry a Nonce. One could
> have ILNP without the Nonce option, instead always using IPsec,
> although that's not the design choice I've made so far.
>
> Some might prefer that approach, which is one that HIP takes.
> I thought it better to have a non-cryptographic authentication
> mechanism for deployments where cryptographic authentication
> is not deemed necessary. I'm told off-list that some HIP
> folks are contemplating a non-cryptographic authentication
> mechanism as an alternative for HIP.
>
> ILNP does not require host APIs or applications to change.
> [draft-rja-ilnp-intro-01, section 7, page 10.]
>
> Supporting the new API is an idea largely independent of ILNP,
> just as the new API itself is independent of ILNP.
But how does ILNP provide any benefits to routing scaling if it is a
set of changes to, or at least additions to, the IPv6 protocol, host
stacks and applications for all the traffic which happens between
applications without these ILNP enhancements?
If you could get everyone to rewrite their applications and host
stacks, all at once, of course ILNP could potentially provide a
robust solution to the routing scaling problem in the IPv6 Internet -
but it would be the ILNP-modified IPv6 Internet. The IPv6 Internet
would not exist and you would somehow have also figured out how to
get all IPv4 users to change their applications, stacks and Internet
connections overnight too.
> HIP and several other proposals here also require host stacks to
> change to one degree or another. One would have thought that all
> of the "host stack change" proposals would have somewhat similar
> deployability, although your notes to the RG list have not
> indicated you believe this.
I agree that in the context of solving the routing scaling problem
(it currently only exists in the IPv4 Internet, but will occur in the
IPv6 Internet if and when there is sufficient adoption) that all
proposals involving host stack changes have somewhat similar
deployability.
Their deployability is so low (due to the benefits scaling with the
proportion of other people who have deployed it, while end-users
really need 100% of their traffic to follow the new system in order
for it to be at all useful) that in terms of solving the routing
scaling problem, all these host-stack changing proposals are of
>>>>> ZERO <<<<<
practical value.
It has long been obvious to most folks on this list that there is no
way of getting enough people to change their stacks (or worse still
their stacks and applications) in sufficient numbers to solve the
routing scaling problem.
That is why all the potentially practical proposals - LISP, APT,
Ivip, TRRP and Six/One Router - are network-based solutions, which
involve no host changes whatsoever.
This has been obvious to most people all along.
So why are we discussing SHIM6 or ILNP as if they could be helpful in
the real world?
If you want to discuss ILNP as an interesting clean-slate idea, that
if fine. I am only interested in potentially practical solutions.
ILNP can't be practical for IPv4 and it can't solve the IPv6 problem
unless you have a way of getting everyone to adopt it, with new
applications etc. all at once.
I won't answer to the rest of your response, though people who want
to pursue ILNP as a theoretically practical proposal may find it
interesting. Except for this:
> % How many people do in fact understand ILNP?
>
> Based on conversations at past IRTF meetings and on other
> conversations with various folks, I think many people understood
> the ILNP architecture prior to this note appearing. People who
> have been following the research literature in this area have had
> an easier time, since research papers on ILNP go back several
> years now.
OK - but are there any people who think that ILNP is a practical
solution for solving the routing scaling problem?
If so, they they either have a response to my critique above, or they
have a completely different notion of what is practical from what I
(and I think many others) have.
- Robin
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
