Short version: Ran's IDs claim that ILNP is a product of the RRG.
ILNPv4's dependence on IPv4 Options makes it vastly
harder to deploy than ILNPv6, as well as adding
overhead to all packets. If this could be done -
upgrading all IPv4 DFZ routers - then it would be
better to do something like Ivip's modified
header forwarding or a new protocol specifically
crafted for the same purpose.
There's no discussion of interoperability between
ILNPv6 and ILNPv4, although they can or do use the
same Identifiers.
Mobility with ILNP (or any other CEE architecture)
will always be expensive, due to the need for a node
to send Locator Update messages to all correspondent
nodes. How can the stack know which correspondent
nodes from the past are still active, particularly
with sparse UDP-based application protocols? The
stack might be forced to send updates to many nodes
from the past.
There's no Ack system for the Locator Update
messages - and I suggest there should be. However
this makes getting a new Locator still more
expensive - for both the mobile node and all its
correspondents.
I believe the ILNP approach to mobility is
unworkable - particularly for radio-linked nodes
which may frequently and arbitrarily gain new
Locators and lose their old ones. The delays
involved in sending out all the Locator Update
messages via a potentially slow and unreliable radio
link mean that this approach to mobility won't be
suitable for VoIP. This applies to all other CEE
mobility approaches and to LISP Mobile. AFAIK, the
only workable, VoIP-compatible, approach to global
mobility is TTR Mobility, which is for Ivip and
perhaps LISP or IRON.
Hi Ran,
Your IDs:
http://tools.ietf.org/html/draft-rja-ilnp-intro-05
http://tools.ietf.org/html/draft-rja-ilnp-dns-05
http://tools.ietf.org/html/draft-rja-ilnp-nonce-04
http://tools.ietf.org/html/draft-rja-ilnp-icmp-03
state in their Abstracts:
"This is a product of the IRTF Routing RG."
This is incorrect. The RRG has no consensus on anything, and has
rough consensus on only a few things, primarily concerning
terminology. The RRG has not chosen ILNP or developed it. The
co-chairs chose to recommend ILNP. You alone have developed ILNP.
ILNP is no more a "product of the RRG" than Ivip or any other
architecture which has been developed and discussed on the list in
the last 3 years.
Please remove this statement.
I suggest you add a note that while ILNPv4 is intended to be
"backwards compatible" with IPv4, it can only be deployed after all
routers, including any DFZ router between the two networks, have been
upgraded to handle the new IPv4 Option. This is a much higher hurdle
to adoption than faced by ILNPv6, which does not require any changes
to routers. Both ILNPv4/v6 require changes to host stacks - but I
understand not to applications or stack-app APIs.
The new IPv4 Option involves overhead on every packet, just like
encapsulation. However, it has an advantage over encapsulation by an
ITR in that the sending host sets the packet length, and the packet
is not made any longer in the network - so this should avoid Path MTU
Discovery problems which are caused by ITR encapsulation as used in
Ivip and LISP.
In the long term, Ivip would use modified header forwarding, rather
than encapsulation. To whatever extent it is possible to upgrade all
IPv4 DFZ routers for your ILNPv4 IPv4 Option, it would also be
possible to upgrade them to use Ivip's modified header forwarding
technique for IPv4:
http://tools.ietf.org/html/draft-whittle-ivip-etr-addr-forw-00
or to achieve the same result with a new protocol with a header the
same length as IPv4, but with 30, 31 or perhaps 32 bits of ETR
address built-in.
This would not involve the PMTUD problems of encapsulation or the the
overhead of encapsulation (or of your IPv4 Option). It would provide
scalable routing for IPv4, without any host changes - with the
addition of ITRs, ETRs etc.
The obvious two ways to carry the ILNP Identifier with ILNPv4
are either as an IPv4 Option or as an IPv6-style Extension
Header placed after the IPv4 header and before the upper-layer
protocol (e.g. OSPF, TCP, UDP, SCTP).
AFAIK there is no such thing as an "IPv6-style Extension Header
placed after the IPv4 header", so the only way is the IPv4 Option.
The first question a reader is likely to have about ILNPv6 and ILNPv4
is interoperability between the two systems - or whether there is
really one ILNP system spanning both the IPv4 and IPv6 Internets.
However I think your drafts do not discuss this at all. Is there one
Identifier namespace for the two systems, or a separate namespace for
each one?
On mobility:
So in ILNP, when a connectivity change affects the set of
valid Locators, the affected node(s) actively:
(1) use the ICMP Locator Update message to inform their
existing correspondents with the updated information
about their currently valid Locator(s). [ILNP-ICMP]
AND also
(2) update their DNS entries, most commonly by using
the Secure Dynamic DNS Update mechanism. [RFC 3007]
In the unlikely event of simultaneous motion which changes
both nodes' Locators within a very small time period, a
node can use the DNS to discover the new Locator value(s)
for the other node.
There are two serious difficulties with this approach to mobility, as
I mentioned in my recent message to Toni Stoev.
Firstly, every time a node gets a new Locator, it has to send out
Locator Update messages to every node it is currently communicating
with. This implies that the stack knows what sessions are active -
but how can the stack know this for sure with a UDP-based application
protocol? So the stack might have to send out these messages to lots
of nodes, including ones which don't matter any more, since the
application in fact won't be receiving packets from those nodes, but
the stack has no way of knowing this.
There's no Ack mechanism in the Locator Update message system:
http://tools.ietf.org/html/draft-rja-ilnp-icmp-02
so what happens if the message does not reach the other node, due to
packet loss or due to the other node having adopted a new Locator?
The other node would continue sending subsequent packets to the old
Locator address and the application would fail.
I think that in order to make this robust, the node which sends the
messages needs to get Acks, and resend the Locator Update messages
until there is an Ack. However, this makes the process more expensive.
I think ILNP's approach to mobility is unworkable.
The mobile node could get a new Locator at any time, and this could
happen very frequently with physically mobile devices with multiple
wireless networks. Also, even when it doesn't move, radio
propagation conditions and the way the radio network connects the
node to its various towers and base-stations can result in it being
connected via a new IP gateway, and so getting a new IP address
(Locator).
If every such change involves a flurry of outgoing Locator Update
messages, and worse-still a flurry of incoming Acks, then this is
never going to be practical for mobility.
Also, you have a loss of connectivity until the correspondent nodes
get the Locator Update message. I think this makes it unsuitable for
VoIP - so I think this approach to mobility is never going to be
acceptable.
The only approach I know of which would work for mobility, without
excessive mobile node effort and without significant delays affecting
application connectivity is TTR (Translating Tunnel Router) Mobility:
http://www.firstpr.com.au/ip/ivip/#mobile
This is only applicable to Core-Edge Separation architectures such as
Ivip, LISP and perhaps IRON - not to Core-Edge Elimination (Loc/ID
Separation) such as ILNP.
When the MN gets a new IP address it simply establishes a new two-way
(typically encrypted) tunnel to its current TTR, which is typically
nearby. This need take no more than a small fraction of a second.
It can do this for multiple new IP addresses, so it can have multiple
tunnels to the TTR if it has connections to multiple access networks.
I have only looked briefly at intro-05. I don't intend to help you
fine-tune ILNP because I believe this and any other Core-Edge
Elimination (Locator/ID Separation) architecture is undesirable
compared to what can be done with Core-Edge Elimination (LISP, Ivip
and IRON). For a summary of my position, not counting the many
updates to IRON since I wrote this in March:
http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html
That said, I guess ILNP is probably the best of the CEE architectures
since it doesn't involve alterations to applications.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
