On 17 Nov 2008, at 19:52, Robin Whittle wrote:
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,
Robin,
They might not be equal-length and definitely would not be splitting
the IPv4 address into 2 fields (not enough bits). Such an equal-length
split happens to be the engineering for ILNP for IPv6, but the
engineering
of ILNP for IPv4 will necessarily be different (as I have noted before).
ILNP is really an architecture; it is best thought of architecturally
within the IRTF RG, rather than dwelling on the engineering bits.
with differing semantics. This would not be compatible with IPv4
as a protocol or with IPv4 address assignments.
Again, you are criticising something other than what
ILNP for IPv4 would be. Both of those claims are incorrect.
I gather you haven't had the time yet to read the research
literature on ILNP, since you continue to criticise something
other than ILNP (presumably based on assumptions arising
from not reading the research literature).
Perhaps you mean tunneling IPv4 in some way over the ILNP system. If
so, ...
No. Incorrect assumption on your part.
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
Wrong. I have never proposed using 2 16-bit fields for ILNPv4,
and that is certainly NOT how I would engineer ILNPv4.
One would want to have a set of Locator bits and a set of
Identifier bits, but since the engineering of IPv4 is
different from IPv6, likewise the engineering of ILNPv4
would necessarily be different from the engineering of
ILNPv6.
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.
IPv4 protocol enhancements have occurred regularly over the
past 20+ years and have been implemented in IPv4 stacks. IPv6
similarly keeps adopting enhancements and getting them implemented
in IPv6 stacks.
ILNP can be used with either or both of those protocols;
it is not limited to IPv6.
Separately, since the IPv6 deployment is smaller at present,
the IPv6 routing issues are in fact easier for *any* proposal
to resolve. Host stack changes are easier to get deployed
in a smaller deployment base, which means that any host stack
change will be easier to deploy in IPv6 than in IPv4.
This is never going to happen.
I have long gathered that is your opinion.
Different people on this list seem to have different
opinions on this and other topics. In fact, consensus
seems hard to identify on many topics within the Routing RG.
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).
Others of us think that a range of concepts can provide those
capabilities. The ILNP concept is sufficiently plausible that
a number of peer-reviewed papers on how it could do those things
have been published over the past several years. There are other
approaches (i.e. other than "PI addressing") that have been proposed
within the Routing RG that also seem plausible to me.
This will never happen.
More opinion unsupported by technical facts.
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.
The issue of originating nodes figuring out Path MTU is the
same regardless of which IP options the originating node
does or does not have in a particular packet.
There are standard, and widely deployed, mechanisms to
deal with that issue. It is not a huge problem in the
deployed IPv4 or deployed IPv6 Internet today, given that
we have a deployed Internet that generally works.
[Mark H's paper on 'How the Internet only just works'
seems relevant to mention here.]
ILNP doesn't change reality for the worse in this regard.
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.
Incorrect.
Nor does the traffic of these applications
help with the routing scaling problem.
Incorrect.
Applications with no API changes can use ILNP and can
gain benefits from using ILNP. Those benefits clearly
would increase over time as ILNP incrementally deployed.
The primary benefit to applications of using a newer API
is simply cleaner and simpler application software than
at present. That benefit would accrue even if using such
a more abstracted API over the deployed IPv4 Internet of 1990,
and is utterly independent of any of the proposals here.
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.
Incorrect.
...as best I understand it, unable to continue sessions in the even
of an
interruption which multihoming is supposed to cope with.
Please go read the research papers rather than guess,
and particularly rather than criticising something
other than ILNP and then mislabelling it as ILNP criticism.
OSI is clearly irrelevant to any discussion of practical solutions to
the routing scaling problem.
"Those who cannot learn from history are doomed to repeat it."
- George Santayana
I find that a knowledge of what worked and what didn't in ISO OSI
networking can be quite informative and helpful; other folks'
views might well vary.
I agree that in the context of solving the routing scaling problem
that all proposals involving host stack changes have somewhat similar
deployability.
Thank you. That is some progress at least.
Their deployability is so low that in terms of solving the routing
scaling problem, all these host-stack changing proposals are of
practical value.
I understand that is your opinion, although you seem to particularly
and curiously single out ILNP for attack, rather than making the
more general *and much more brief* comment that you don't believe that
any host stack changes are not possible.
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.
s/most folks/some vocal folks/
Opinions within the RG seem to vary widely on that topic.
This has been obvious to most people all along.
s/most people/some vocal people/
Opinions within the RG seem to vary widely on that also.
So why are we discussing SHIM6 or ILNP as if they could be helpful in
the real world?
Because they can be. For the record, I think HIP is also interesting,
although I personally am not as keen on using cryptography all/most
of the time as much as some HIP folks seem to be.
If you want to discuss ILNP as an interesting clean-slate idea, that
if fine. I am only interested in potentially practical solutions.
Please feel free to ignore ILNP if it improves your happiness or
lets you spend your time on matters you consider more important.
ILNP can't be practical for IPv4 and it can't solve the IPv6 problem
unless ...
Above you acknowledged that you don't really fully understand ILNP,
yet here you make such a bold confident assertion based on your
acknowledged lack of understanding. Curious.
OK - but are there any people who think that ILNP is a practical
solution for solving the routing scaling problem?
There are certainly some, and clearly some other than me, given both
the feedback from various folks and mentions of ILNP by other folks
both here and in other contexts.
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.
...or they have better things to do with their time than to try
to persuade you that any ideas other than your own might be
worth considering seriously in the context of the Routing RG.
I'm certainly not trying to change your mind -- on anything.
I am trying to make clear to others that your "analysis" is largely
based on incorrect assumptions and incomplete understanding of the
ILNP architectural concept.
Yours,
Ran
[EMAIL PROTECTED]
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
