Subject: INLP, Loc-ID Separation & Loc-ID Overloaded IP addresses

From: Robin Whittle <[email-masked]>
Date: Thu, 03 Nov 2011 15:42:49 +1100

Short version:  Ran objects to some things I wrote about his ILNP
                protocol - which was chosen in preference to the LISP
                protocol, IRON, Ivip and many others by the IRTF
                Routing Research Group co-chairs as their recommended
                scalable routing protocol for further IETF development
                (RFC-6115).

                However, he does not mention what statements he
                disagrees with.  He simply refers readers to a bunch of
                papers and some Internet Drafts at his site.

                Below is a list of things I wrote about ILNP and why I
                wrote them.

Hi Ran,

In the thread "Re: The death John McCarthy - LISP, HIP & GSE" you wrote:

> Gentle Folks,
>
> Robin Whittle either hasn't read the ILNP documents
> and published papers or he hasn't understood them.
> His characterisation of ILNP on this list is
> not correct in a wide range of dimensions.  Folks
> who want to learn more about ILNP might consider
> starting at this web site:
> 	<http://ilnp.cs.st-andrews.ac.uk>
>
> I'm not a LISP or HIP expert or spokesperson,
> but I also doubt that his characterisations
> of LISP or HIP are correct.
>
> Yours,
>
> Ran

This is all very broad-brush, as if you are too busy to help IETF list
people understand exactly which statements about ILNP you dispute.
Likewise you don't help the readers by directing them to any particular
documents at your site.  I recall that many of your messages to the IRTF
Routing Research Group list were of a similar form.

In recent IETF list messages I have characterised ILNP as:

  0 - A member of the Locator-Identifier Separation class of
      scalable routing protocols.

and the following I wrote about all Loc-ID Separation protocols:

  1 - They are IPv6-only.

  2 - They require rewritten stacks and applications.

  3 - They require hosts to send and receive more packets and do
      more work (than the current arrangements) in order to respond to
      a communication, when (as is often the case) it is important that
      the reply packet must go to no other host than the one which has
      the Identity specified as the source in the initiating packet.

  4 - They can't support mobility with MNs behind NAT or handle Loc
      changes fast enough for VoIP.

If there is something else I wrote which you object to, please write
about it to the list.  Likewise regarding any specific disagreements you
have with what I wrote about the LISP protocol and HIP.

Point 3 above is a critique of ILNP, HIP and GSE - or any other protocol
which I regard as being of the "Locator-Identifier Separation" class
(this does not include the LISP protocol).  I argue that such protocols
impose extra burdens of work, delays and extra packets going in and out
of a host which responds to an incoming communication initiation in a
way which requires its response not to be delivered to any host which
does not have the Identity specified in the sender field of the
initiating packet.  That's a rather long sentence, but it means that the
simple process we have with today's "Loc-ID overloaded IP address"
arrangement - of responding to the initiating packet's source IP address
- is something which sometimes, probably frequently, can't be done with
Loc-ID Separation.

  If a host ABC receives a communication request with the IP address
  XYZ in the source field (which in today's "overloaded" arrangement
  acts as both a host/endpoint Identifier and routing Locator) then
  ABC can send a reply packet straight back to the XYZ IP address
  without doing any lookups, knowing that the routing system will
  either deliver it to the host which has this IP address (or to one of
  multiple hosts, in the case of anycast) - or the packet will be
  dropped.

  So ABC can craft its reply with whatever information it wants host
  XYZ to have, but would not want any other host to have - and send it
  to IP address XYZ.

  This is still true if, as is possible, the source address of the
  initiating packet is spoofed.

  So in the current "overloaded" arrangement, a host can respond
  immediately and without any lookups.

  With Loc-ID Separation, to achieve the same assurance, ABC would need
  to do a mapping lookup of the Identifier which came in the initiating
  packet, and send the reply to one of the resulting Locators (assuming
  the Identifier was for a multi-homed host, meaning there would be at
  least two Locators).  This requires sending at least one packet to
  the global mapping system, which after some delay (due to its global
  geographic size, and due to the need for real-time non-cached
  responses forcing it to get a response from the one or one of a few
  authoritative query servers) would return a single packet of mapping
  information to ABC, with the Locators and some other stuff regarding
  which one to choose in preference to the others.  (Maybe the mapping
  would be too long for the and would need to go in two packets - or
  maybe it would be sent as a long packet in IPv6, which was too long
  for some part of the path near ABC, and so it would be dropped
  with a packet-to-big response, causing the query server to send the
  same information again in shorter packets - assuming the query server
  cached its response for this purpose.)

  Assuming the map reply packet arrives, then ABC can proceed to send a
  reply to XYZ, knowing it will get to XYZ or be dropped (and therefore
  will not to to any host other than XYZ), by sending the packet to one
  of the specified Locators.  If the mapping query or response packet
  gets lost, ABC will need to wait two or so seconds to send a second
  query.

  This is bad enough for a host in a data centre.  It is much worse for
  a host ABC hanging off a possibly low data-rate, expensive,
  high-latency high packet loss mobile radio link such as 3G or
  whatever.

So my critique of Locator-Identifier Protocols is also of one of the
longest cherished wishes of quite a few IETF people, from the early 80s
to this day.  An early write-up of this wish is in RFC-1498, which was
originally written in 1982.

I wrote about this on the RRG list (2010-06-22):

  "Overloading" of Loc & ID functions is good for hosts and should be
  maintained
  http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html

in response to something you wrote in an earlier message:

  RA> If we ignore the lack of 40 years since the initial definition
    > of IP itself, I believe there is actually pretty broad consensus,
    > both within this RG, and also within the routing/addressing parts
    > of the IETF, that the current overloaded semantics are indeed
    > the root of multiple problems.

but you never responded.  Toni Stoev replied and in messages 07022, 25,
27, 29 and 30 we discussed his proposal - but I couldn't envisage a
fast, lightweight, secure way of doing it.

  RW> Toni hasn't yet described a secure method by which
    > one node can tell another it has a new Locator.
    >
    > I can't imagine how this proposal, or any other CEE
    > (Loc/ID Separation) architecture, such as ILNP,
    > could handle mobility with sufficiently short
    > delays and sufficiently light-weight protocols
    > to make it practical or attractive for VoIP.
    >
    > If a scalable routing proposal can't do mobility
    > with delays short enough to not disrupt conversations
    > with VoIP, then I think it is a non-starter.  So far
    > I think TTR Mobility is the only approach to mobility
    > which can do this - and it is only for CES
    > architectures such as LISP, Ivip and perhaps IRON.

Here are the reasons why I wrote these things about ILNP.

0 - Quoting from http://tools.ietf.org/html/draft-rja-ilnp-intro-11

      "The crux of this proposal is to have different names for the
       identity of a node and the location of its subnet, with crisp
       semantics for each.  This enhances the Internet Architecture
       by adding crisp and clear semantics for the Identifier and
       for the Locator, removing the semantically-muddled concept
       of the IP address, and updating end system protocols slightly,
       without requiring router changes."

    Throughout the document, the term "the Identifier/Locator split
    mode (of operation)" is used to refer to the use of ILNP.

    So I assume you agree with me that ILNP is a Locator-Identifier
    Separation (AKA "Split") protocol.

1 - ILNPv6 has a 64 bit Identifier - the lower order bits of the
    field currently known as the 128 bit IP address - so there's no
    need for a new packet format.  In ILNPv4 the 32 bit IP addresses
    become Locators and a new packet format is required to carry 64 bit
    Identifiers:

      "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)."

      "At least some currently available IPv4 forwarding silicon
       is able to parse past IPv4 options to examine the upper-
       layer protocol header at wire-speed on reasonably fast
       (e.g. 1 Gbps or better) network interfaces.  By contrast,
       no existing silicon is able to parse past a new Extension
       Header at all.  So, for engineering reasons, ILNPv4 uses
       a new IPv4 Option to carry the Identifier values."

    HIP and GSE are applicable to IPv6 only.  I argue that ILNPv4
    is so impractical as not to be considered realistic, because
    some, most or all routers in the DFZ handle packets with IPv4
    options via their "slow path" - with the CPU rather than the
    fast forwarding hardware.   I have no knowledge of this directly
    but it was discussed on the RRG and people who I assume do have
    direct knowledge of this agreed.  See RRG msg06001 and:

    End-to-end measurements on performance penalties of IPv4 options
    Fransson, P.; Jonsson, A.
    Global Telecommunications Conference, 2004. GLOBECOM apos;04. IEEE
    Volume 3, Issue , 29 Nov.-3 Dec. 2004 Page(s): 1441 - 1447 Vol.3
    10.1109/GLOCOM.2004.1378221

http://www.sm.luth.se/csee/csn/publications/end_to_end_measurements.pdf

    The abstract concludes:

      "From the analysis it can be concluded that there is a slight
       increase in delay and jitter and a severe increase in loss rate."

    If you have any evidence that most or all routers in the DFZ and
    in edge networks can handle IPv4 packets with novel options at
    full line rate, without excessive losses or delays, please present
    it.  If this was so, then it would greatly expand the possibilities
    of what can be done with the IPv4 Internet.

2 - GSE and HIP require existing IPv6 applications to be rewritten.

    Section 9.1 of draft-rja-ilnp-intro-11 claims (to my understanding)
    that a host with an ILNP stack will perform ILNP communications with
    today's IPv6 applications:

       The existing BSD Sockets API can continue to be used with
       ILNP underneath the API.  That API can be implemented in a
       manner that hides the underlying protocol changes from the
       applications.

    For a long while, I and I think other RRG folks - co-chair and
    ILNP supporter Tony Li included - accepted this notion that ILNP
    could work without the need to rewrite IPv6 applications.  I think
    this was regarded as a major feature of ILNP over any other Loc-ID
    Separation protocol.

    When I tried to figure out how this would work, I couldn't find
    a way.  You didn't respond to my requests for guidance.  Tony had
    a go at it, gave up (it was late) and never tried again:

      http://www.ietf.org/mail-archive/web/rrg/current/msg07113.html

    Before giving up, he wrote (msg07111):

      And having a name oriented stack would be the best solution.

    ILNP is not a name oriented stack protocol - and any such protocol
    would require rewritten applications.

3 - As mentioned above with the host ABC and XYZ discussion.

4 - Loc-ID Separation protocols (Core-Edge Elimination protocols)
    implement mobility by the Mobile Node (MN) getting a new IP address
    (Locator) and securely updating the global mapping system with
    this new Locator.  Either the MN or the global mapping system then
    needs to update the mapping stored by any hosts they are currently
    communicating with.

    To do this securely will take more time than is acceptable for VoIP.
    Since a MN may gain new Locators frequently - for instance just for
    a few seconds when coming into range of a WiFi system which is
    preferable to a 3G connection, the flurry of mapping updates to
    the potentially numerous correspondent hosts becomes unreasonably
    expensive.

    The LISP protocol's approach to mobility has the same problem,
    though it is not a Loc-ID Separation protocol.

    As far as I know, the only way of doing mobility without needing to
    instantly update the mapping of all the correspondent hosts is my
    TTR Mobility system, which can be applied to Ivip or LISP, and which
    I understand is used, in principle, for all communications (mobile
    and non-mobile networks) in Fred Templin's IRON.

       http://www.firstpr.com.au/ip/ivip/#mobile

          The correspondent hosts have mapping to a (typically close
          to the MN) ITR-like router I call a Translating Tunnel
          Router.  The MN establishes 2-way tunnels to one or more TTRs
          from each of its potentially multiple IP addresses, which can
          be behind any number of layers of NAT.  As these change, and
          as the best one to use changes, this is just a matter between
          the MN and the TTR which is currently receiving all the
          incoming packets from the correspondent hosts.

    Loc-ID Separation protocols can't work with the host behind NAT.
    That's fine when the protocol is used for the IPv6 Internet, but
    not for IPv4.

  - Robin

---

From: "t.petch" <[email-masked]>
Date: Fri, 4 Nov 2011 18:43:17 +0100

----- Original Message ----- 
From: "Robin Whittle" <[email-masked]>
To: "IETF Discussion Mailing List" <[email-masked]>
Cc: "Ran Atkinson" <[email-masked]>
Sent: Thursday, November 03, 2011 5:42 AM

> Routing Research Group list were of a similar form.

Robin

Leopards do not change their spots; they just lie in wait on
branches above your path waiting to leap down and 
devour you:-)

Tom Petch
Assiduous follower of all things RRG

<SNIP>
<SNIP>
<SNIP>