Did you have any editorial comments? All I'm finding are (continued) disputes about content.
Tony On Jul 31, 2010, at 8:21 PM, Robin Whittle wrote: > 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 > > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
