Subject: [rrg] Fwd: I-D Action:draft-irtf-rrg-recommendation-09.txt

From: Tony Li <[email-masked]>
Date: Fri, 30 Jul 2010 01:05:49 -0700

Hi all,

After much delay, I've finally finished my editorial pass over the recommendation.  Please see the link below.

Please note that this pass was purely editorial.  I've tried to retain the same intent as the original text, but have tried to clean up the language and in some cases wordsmith things just a bit.  

I would ask that we start a two week (hopefully) final review cycle.  Could all contributors please review the text proper one last time, as well as my changes?  Other reviewers are also welcome at this point.

Diffs can be found here:

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-irtf-rrg-recommendation-09.txt

and here:

http://tools.ietf.org/rfcdiff?url2=draft-irtf-rrg-recommendation-09.txt

Comments to me or the list, as you see fit, please.

Thanks,
Tony

Begin forwarded message:

> From: [email-masked]
> Date: July 30, 2010 12:45:02 AM PDT
> To: [email-masked]
> Subject: I-D Action:draft-irtf-rrg-recommendation-09.txt 
> Reply-To: [email-masked]
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Recommendation for a Routing Architecture
> 	Author(s)       : T. Li
> 	Filename        : draft-irtf-rrg-recommendation-09.txt
> 	Pages           : 72
> 	Date            : 2010-07-30
> 
> It is commonly recognized that the Internet routing and addressing
> architecture is facing challenges in scalability, multihoming, and
> inter-domain traffic engineering.  This document surveys many of the
> proposals that were brought forward for discussion in this activity,
> as well as some of the subsequent analysis.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-irtf-rrg-recommendation-09.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Toni Stoev <[email-masked]>
Date: Sat, 31 Jul 2010 13:27:28 +0300

Hi,

Can somebody elaborate on this:

{
3.1.2.  Gains

   RANGI achieves almost all of the goals set forth by RRG as follows:

   1.  Routing Scalability: Scalability is achieved by decoupling
       identifiers from locators.
}

Toni

---

From: Robin Whittle <[email-masked]>
Date: Sun, 01 Aug 2010 13:21:02 +1000

Short version:   Draft 09 of the Report contains omissions and
                 misleading statements concerning Core-Edge
                 Elimination architectures in general and ILNP
                 in particular.

Hi Tony,

In the ILNP summary is the text:

  ILNP can be implemented such that existing applications (e.g.
  applications using the BSD Sockets API) do NOT need any changes or
  modifications to use ILNP.

I spent a day and a half trying to figure out how ILNPv6 could
support existing IPv6 applications - and I decided tentatively that
it couldn't be done.  Ran hasn't responded to my messages on this,
but you did - and you couldn't come up with a way of making it work
either:

   ILNP: stack behavior to work with IPv6 apps?
   http://www.ietf.org/mail-archive/web/rrg/current/msg07108.html

and 4 more messages in that thread.

The Critique assumes that ILNP can work with IPv6 applications -
although it notes that IP-address referrals won't work without
"additional mechanisms".  In practice, this means that some or many
IPv6 applications can't work with ILNP.

However, my attempt to see how ILNP would support IPv6 application
ran into trouble even without considering IP address referrals.  A
major difficulty was that when the app asks the stack to look up an
IP address, what does the stack give the app?  All attempts to figure
this out, by you and me, lead to outcomes which were clearly not
going to support IPv6 applications.

So I think the ILNP Summary as it stands contains a significant false
claim which is not tackled in the Critique.

Also, regarding ILNP, your Recommendation includes:

   It separates location from identity in a clear,
   straightforward way that is consistent with the
   remainder of the Internet architecture and makes
   both first-class citizens.

This is not true with ILNP mobility, since when the host roams to
another /64, there is no way of ensuring that some other host hasn't
already taken the IP address there with this hosts ID bits in the
lower 64 bits.   This has been extensively discussed in the threads:

   ILNPv6 Mobility problem
   ILNP Identifier and Locator semantics are muddled and !crisp
   ILNP Identifiers are not "first class citizens"
   ILNPv6 Mobility problem (attempt at summary)
   ILNPv6 Mobility - ILNP can't work with SEND (AFAIK)

ILNP mobility is subject to an "Identifier squatting" DoS attack,
which is easy to launch (look up the victim's FQDN and get its ID) by
the attacking host behaving in a manner which is indistinguishable to
the network from proper behaviour of any IPv6 or ILNP host.

Also, the Report doesn't distinguish between ILNPv6 and ILNPv4.
ILNPv4 makes all packets longer, and can only be introduced at all
once most or all DFZ and other routers have been upgraded.

For instance, in the Summary:

    Locators name subnetworks, rather than interfaces, so they
    are equivalent to an IP routing prefix.

is only true of ILNPv6.

Reading the Report as it stands, one might think:

  ILNP is for IPv4 and IPv6.

  ILNP doesn't require any changes to routers.

  ILNP mobility has no particular weaknesses specific to ILNP.

  ILNP supports existing applications.

But for ILNPv6:

  All applications must be rewritten.  (This places a huge
  additional burden on those who try to test ILNP - they
  will need to get a bunch of open-source apps and significantly
  rewrite them - and this may break the application's on-the-wire
  protocols.)

  Mobility is not robust against a simple DoS attack, or against
  a chance situation where the ID in the new /64 is already taken.

In addition, for ILNPv4:

  Most or all DFZ and other routers need to be upgraded before
  any ILNP hosts can communicate over the IPv4 Internet.

The Critique fails to capture two other objections to ILNP and other
CEE architectures:

  1 - They typically involve extra packets being sent and received
      by hosts (such as for DNS lookups) and so extra delays in the
      establishment of communications.

      For instance, A looks up B and sends B a packet.  If B's
      application needs to ensure its reply can only go to A, then
      B needs to find A's FQDN (AFAIK, by relying on reverse DNS
      lookup of A's IP address returning the FQDN) and then do a
      lookup of that FQDN to get A's Locator.  B cannot trust the
      Locator which came with A's initial packet since that
      packet could contain a locator not of the real A, but of a
      network where the attacker's machine has A's ID.

      Some applications don't actually need to do this, so if the
      applications are rewritten for ILNP, this will be less of a
      problem.  However, if ILNP is to support IPv6 applications,
      the stack in B needs to do these lookups before it can send
      B's application's reply packet - since IPv4/6 applications
      are written on the assumption that the routing system will
      never deliver a packet to a host with an Identity different
      from that of the packet's destination address.

      These DNS lookups take time.  They may involve intermediate
      lookups too.

      These delays to establishing communications, and the extra
      packets are particularly onerous for devices on 3G etc,
      wireless links which involve delays, costs, lost packets and
      bandwidth restrictions which are worse than what most of us
      are used to at home via a DSL service.

  2 - Substantial benefits to scalable routing and to anyone who
      adopts ILNP (or any other CEE architecture) only arise once
      all, or virtually all, hosts adopt it.  This is covered in:

        http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

      and so involves much greater hurdles to widespread adoption,
      while also requiring almost ubiquitous adoption before there
      can be substantial benefits.  Until all hosts (and so I think
      all apps) are upgraded, a significant proportion of
      communications will still rely on the old IPv4 or IPv6 system
      - so multihoming and mobility won't work for all
      communications.  Until then, networks will still want and need
      PI space to support the old style of communications.

With these omissions, and the false statements about ILNP, the 09
draft fails to inform readers of the major problems with CEE
architectures in general, and with some problems which are specific
to ILNP.

  - Robin

---

From: Tony Li <[email-masked]>
Date: Sat, 31 Jul 2010 22:51:38 -0700

Did you have any editorial comments?

All I'm finding are (continued) disputes about content.

Tony