[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Re: ILNP Critique
[First, I'd like to apologise to all for the delayed response.
Work requires me to travel a great deal just now. Often I am
offline during those trips, as in the recent past. It can take
me a bit to catch up on my list backlog when I return.]
Earlier, Robin Whittle wrote:
% I listened to Steve Blake's presentation and had enough of a look at
% your I-D:
%
% http://tools.ietf.org/html/draft-rja-ilnp-intro-01
%
% to determine that your proposal involves radical changes to
% IPv6.
As has been discussed in the past on the Routing RG list,
the ILNP architecture can also support IPv4.
This is also on Slide 15 [All slide references are to the
presentation made in Dublin in July 2008.]
The word "radical" is opinion and seems overblown.
Pmplementation of ILNP could be done in a manner quite similar to
how one might implement SHIM6, for example. New DNS resource
records appear regularly. Adding an IPv6 Destination Option is
straight forward and consistent with the rest of IPv6.
% These include changes in the API between applications
% and the host stack.
[draft-rja-ilnp-intro-01, section 7, page 10]
Existing applications can use existing networking APIs with ILNP.
No application needs to be updated or changed.
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.
A new API is offered -- in addition to existing APIs. This new
more abstract API has also been discussed on this list several
times. It would be modeled on the existing Java networking API,
using the comhination of "domain name" and "service name" in lieu
of the sockaddr. Applications using this new API should work
equally well over IPv4, IPv6, HIP, ILNP, SIX/ONE, LISP, or pretty
much any other proposal here. The new API works regardless of
proposal mainly because it is properly abstracted, not requiring
applications to know anything about how the networking services
are implemented. My main regret is that the IPv6 community
did not specify this a decade ago.
(Such a new API might even work over an OSI stack, if any still
exist, although I haven't considered the OSI question in any
detail.)
% So I understand that your proposal involves revising the
% IPv6 protocol, host stacks, host APIs and applications.
ILNP involves adding a new IP option to carry a Nonce. One could
have ILNP without the Nonce option, instead always using IPsec,
although that's not the design choice I've made so far.
Some might prefer that approach, which is one that HIP takes.
I thought it better to have a non-cryptographic authentication
mechanism for deployments where cryptographic authentication
is not deemed necessary. I'm told off-list that some HIP
folks are contemplating a non-cryptographic authentication
mechanism as an alternative for HIP.
ILNP does not require host APIs or applications to change.
[draft-rja-ilnp-intro-01, section 7, page 10.]
Supporting the new API is an idea largely independent of ILNP,
just as the new API itself is independent of ILNP.
HIP and several other proposals here also require host stacks to
change to one degree or another. One would have thought that all
of the "host stack change" proposals would have somewhat similar
deployability, although your notes to the RG list have not
indicated you believe this.
% You propose to solve the routing scaling problem not just be
% having everyone change their ISP services, their routing systems,
% addresses and host stacks and their applications to use IPv6
% instead of IPv4, but to have them further change their host
% stacks and applications to something different from IPv6!
[Slide 15]
The ILNP architecture can work over IPv4 as well,
if folks desire that. The engineering varies a bit,
but the architecture remains the same.
Experience so far has been that it is simpler to explain the
architecture in the context of IPv6. Once folks understand that,
most folks seem to understand how it could also be mapped to IPv4
without further explanation.
[Slides 37 and 38]
So ILNP does NOT require:
- ISP service changes
[Slide 11, Slide 15]
- routing system changes of any kind
[Slide 11, Slide 15]
- address plan changes, since an IP routing
prefix has identical bits to a Locator
[draft-rja-ilnp-intro, page 4; Slides 16-18]
- application changes
[draft-rja-ilnp-intro, Section 7, Page 10]
ILNP does:
- make ISP service changes easier to deploy, if desired
[Slide 31; draft-rja-ilnp-intro, Page 7]
- enable existing routing protocols and forwarding
engines to be re-used without changes
[draft-rja-intro-01, Section 7; Slide 15]
- enables the existing IDR table to initially shrink
in size and subsequently grow proportionally to
the number of ISPs rather than proportionally to
the number of multi-homed sites (which is roughly
the present scaling behaviour).
[Slide 21, Slide 31]
- enable mobile hosts and also mobile networks
to become native capabilities of the Internet,
rather than optional add-ons that are not
widely supported in implementations
[draft-rja-ilnp-intro, Section 7, Page 10;
Slides 25 through 29]
- enable incremental deployment and full backwards
compatibility (with either IPv6 or IPv4 respectively
for ILNPv6 or ILNPv4).
[draft-rja-ilnp-intro, Section 7, page 10;
Slides 37 and 38]
- bring incremental benefits to sites that deploy
it (including many of the above items).
[Many slides; draft-rja-ilnp-intro-01, Section 8]
% Domain name becomes the central identifier for IP and
% network layers.
This was discussed on slide 39.
This already is true in the deployed Internet.
As some might recall, I spent much of the late 1990s working
for a multi-continent (including AU) residential broadband
network service provider in (access) network engineering.
It was quite clear to us, particularly to our support call center
downstairs from me, by 1997 that users were entirely unable to
distinguish "DNS server unavailable" from "Network down". Other
network service providers have made the same observation at least
at APRICOT, NANOG, and RIPE since 1997. All reports from NSP
folks indicate that issue has become worse, not better, in the
intervening decade.
% Mobile node must change its DNS as it moves!
The DNS mechanisms proposed for use with ILNP
mobility are already:
- standardised by the IETF
- implemented in BIND
- implemented in MS Windows
- in use by many Windows deployments
- known to be interoperable between BIND
and MS-Windows implementations
[Source: "DNS & BIND" by Cricket Liu & Paul Albitz, 5th Edition]
[Source: http://www.ietf.org/rfc/rfc-index.txt]
% DNS is like the home agent! or DNS points to the
% rendezvous server.
[Slides 25 through 29 described the mobility approach.]
There is no "rendezvous server" in ILNP. In fact, there
are no mobility servers of any sort. This helps make
mobility much simpler.
Instead, like any normal application already does, when a new
session is opened, the DNS resolver library (or equivalent) makes
a DNS lookup to find the location of the specified domain-name,
gets an answer, and sends packets to that location.
The mobility aspects of ILNP have been discussed in a fair bit of
detail in several published research papers, notably at MobiArch
and MobiWAC.
[Two of these papers are cited on page 2 of
draft-rja-ilnp-intro-01 with a full bibliographic
entry on page 14 of the same draft.]
At least those 2 papers would have been trivial
to find using one's favourite search engine, likely
the several others would also have turned up.
(ASIDE:
As this is explicitly a "Research Group", not an IETF
"Working Group", the normal expectation is that IRTF participants
have done a literature search and are trying to keep up with the
published research literature in the area.)
% I recall a lot of discussion about the problem of ensuring 64 bit
% identifiers are unique in the world. Your proposal (page 4) does
% not ensure an identifier is unique, except in the scope of a 64 bit
% identifier.
[draft-rja-ilnp-intro-01, pages 4 and 5]
I have consistently said for ~15 years now that identifiers
are not required to be globally unique, but that instead the
functional requirement is to have "probably unique" IDs.
HIP is taking roughly the same position. HIP identifiers can
collide (e.g. due to a hash collision). As with ILNP IDs,
such a collision is unlikely.
If one wants a globally-unique ID, this is straight forward to
obtain from any system with an IEEE Ethernet or Firewire
interface. In this case the scope bit of the EUI-64 is set to
"global". [draft-rja-ilnp-intro-01, pages 4 and 5]
If one wants anonymous IDs, with the increased probability of
collision manual selection implies, that can be done by setting
the scope bit to "local" and generating 62 bits in whichever way
one chooses.
Similarly, one can have an ID that is derived from the hash of a
public-key, as HIP does, by setting the scope bit of the EUI-64
to "local". Again, since there are 2 reserved bits in an EUI-64,
one has 62 user-selected or hash-output bits left.
(In fact, I think ILNP can be engineered to provide all of the
capabilities of HIP as a deployment option. Both HIP and ILNP
were born in the IRTF Namespace RG. Both were significantly
influenced by the earlier GSE work by O'Dell. So the
similarities between ILNP and HIP are not at all surprising.
There are also some obvious design differences. :-)
% Your introduction claims that "Map and Encapsulate" is a
% separate class of solution from "Identifier/Locator Split"
% Split - but this strikes me as wrong, since for instance
% LISP is both.
Not at all.
On the RG list, most notably in conversations with jnc, I have
stated very precise definitions for terms, in the interest of
clarity. Some others have slightly or greatly differing
definitions.
LISP is a very interesting proposal, but what LISP calls an EID
is really a "scoped address" because the EID is used for
multi-hop forwarding within the end-sites. So LISP is a "map and
encapsulate" solution, but LISP lacks a (pure) identifier so it
is not also an "Identifier/ Locator Split" solution (at least
when working with my definitions).
NOTE WELL that I don't think Identifier/Locator Split approaches
are the only ones that could work in this situation, so I don't
consider this to necessarily be a problem for LISP. I have
wished the LISP folks would change the term "EID" to something
more precisely accurate. (One imagines the LISP folks are
working with a different definition of "identifier" than I am. :-)
- . . . crisp and clear semantics for the Identifier and for
- the Locator, removing the semantically-muddled concept of the
- IP address . . .
% yet removes arguably the most important thing in the Internet,
% the concept of being able to uniquely identify a host, or a
% host's interface. (Yes I know NAT clobbers this . . .)
I do not think there is a strong case to support the claim
that the "[address] is the most important thing in the
Internet".
As you note, that ship sailed years ago. NAT means that there
is often no globally unique name for a node's interface in the
currently deployed Internet. However, the deployed Internet
still works fine for the overwhelming majority of people.
Therefore this must not have been "the most important thing in
the Internet" nor even very important, else NAT would never have
self-deployed globally so widely and so quickly.
% Page 6: you need to change the pseudoheader checksum algorithm -
% so you need to change host stacks at both ends of any
% communication involving ILNP.
Host stacks do have some implementation changes with ILNP
as compared with today.
The pseudo-header checksum code fragment is not necessarily what
changes, however. There are a range of engineering choices in
this area. One ought not overspecify things lest one prevent
implementers from making appropriate implementation-specific
optimisations.
Please let me note at least two implementation options
to begin.
1) bzero() the Locator before the pseudo-header checksum
is calculated. The Locator can be added in ip_output()
for outging ILNP packets.
2) Have both existing and new pseudo-header checksums
implemented. Add a flag to the mbuf chain (or pbuf
equivalent) to indicate whether ILNP-mode is in use
for this packet or the backwards-compatible Classic IP
mode is in use for this packet. Put an if statement
around the two pseudo-header checksum algorithm
calculations that branches based on the value of that flag.
So one can quite easily support existing IPv4/IPv6 and
ILNPv4/ILNPv6 concurrently within a host stack.
The mere existence of support for both IPv4 and IPv6 at once in
existing deployed systems shows this is possible, as their
pseudo-header checksums cover differently sized objects (just as
ILNP uses the same algorithm, but covers slightly differently
sized objects).
% I think this means that you can't support multihoming or
% whatever benefits for communications with non-upgraded hosts.
(I am unable to really understand/parse/lex the quoted sentence
above. Terribly sorry.)
Communications with existing nodes works the same as it does
today. Communications with existing nodes is no worse than at
present, which is the functional requirement here.
% So there are almost no benefits for early adoptors -
There are significant benefits for early adopters.
This was addressed earlier.
% Pages 6 and 7: ILNP does not appear to support site
% multihoming.
[Slide 31; draft-rja-ilnp-intro-01, Section 3]
Site multihoming works fine. It is frankly the same
architecturally as supporting a mobile network.
One can imagine several ways to do this.
A) Dynamically update the set of valid Locators
for a site as the site's set of upstreams changes.
IP Router Advertisement's with prefix advertisements,
IPv6 ND, and DHCP can all help with this and
are readily available today.
B) Have the site border routers update the Locator
values according to local policy before sending
packets up to an ISP and again downstream when
receiving packets from an ISP. See Slide 33.
As this uses prefixes, this would require a table inside
the router equal to the number of upstream prefixes,
and would scale quite well as a consequence. NATs
and forwarding ASICs separately have shown that
locator rewriting could be performed at wire-speed,
even for very high-speed (10G to 100G) links. If
multiple site border routers exist, the set of
valid prefixes can be coordinated among them,
much as distributed firewalls do already.
(This seems to have some similarities with Six/One's
approach to site multi-homing, if I understand that
correctly.) [NB: This approach would want one to update
the router, but this is not the only approach one
could deploy, so router changes are not required
for ILNP.]
C) I'm sure that other ways exist. Some of the ideas
of Teco Boot in the MANET world seem quite
interesting and likely could yield another approach.
Site Multi-homing has been discussed on some past research
papers. It is also part of our latest MILCOM paper, to be
presented next month in San Diego.
% But site multihoming is the only way of doing it robustly and
% efficiently. End-user networks need a single point of control
% in order that their potentially thousands of nodes keep working
% without a glitch.
That "control point" at present is the site border router.
The site border router remains the "control point" for
multi-homing in the ILNP architecture. There is no loss of
end-site ability to deploy various routing policy choices.
% SHIM6 supports site multihoming - but no-one wants to multihome
% this way.
It is not clear that "no one wants to multi-home this way".
SHIM6 implementations are not widely available yet. No
reasonable polls have been run either within the RG or in the
broader user population on that question.
% Page 7: There is an ICMP message to tell correspondents that
% the current node is moving to another locator. This needs
% to be secured, so you use a nonce in the ICMP message.
One can use a Nonce or can use IPsec. I expect most sites will
view IPsec as overkill (cryptography is sometimes necessary, but
nearly always painful; it is too easy for an adversary to force
one to perform expensive calculations anytime cryptography is in
use).
% There is a reference to an I-D draft-rja-ilnp-icmp-00,
% but no such I-D exists.
Mea culpa. I did not get that submitted before the Dublin I-D
cutoff.
[Slide 28]
Conceptually the ICMP Locator Update is pretty simple. One has
an ICMP message with the currently-valid set of Locators. This
message must be authenticated of course. The recipients use it
to update their internal Locator::ID cache after the packet has
been authenticated.
% How do you plan to ensure the ICMP packet gets to its
% destination? You would need a secured acknowledgement packet -
% so it seems a bit odd using ICMP for something like this.
[Slide 27]
There is no magic with ICMP. It could be UDP or some new
protocol over IP and remain the same architecture. I'm
open-minded about these engineering details; I'm more
interested in getting the architecture correct.
This is described in greater detail in the MobiArch papers and
also in the MobiWAC paper. The design assumes that the Internet
remains unreliable and that packets might occasionally get
dropped somewhere in transit.
% The node needs to have the nonce sent by the correspondent,
% and the above-mentioned I-D proposes sending a 32 bit or
% 96 bit nonce within an IPv6 destination option header.
% So you are adding an 8 or 16 byte destination option header
% to every initial packet which uses ILNP. If the destination
% host is not upgraded, it should send back an ICMP Parameter
% Problem message.
Yes.
% So it seems that every ILNP host is required to at first send an
% ILNP format packet to whichever host it is sending a packet to -
% at least if it got the IP address as a referral, rather than from
% DNS.
First, let us understand the liklihood of your assumption that an
IP address referral happened. The vast majority of referrals in
the deployed Internet are web referrals that provide a URL that
contains an FQDN. Referrals using a raw IP address exist, but
are much much less common in the deployed Internet today.
There are at least three possible approaches that the node could
take to an IP address referral:
1) If desired, the node can do a reverse DNS lookup on the
referral, and then learn whether the target supports ILNP from
the presence/absence of I/L records in the DNS.
2) Alternately, the node can try to open a TCP/UDP/SCTP session
using ILNP mode. If that fails, the node can fall back to
Classic IP mode.
3) Lastly, the node can just assume that the referral is on
a non-upgraded node and only try Classic IP mode, which
will work 100% of the time.
% (Is it OK to have a destination option header in an ICMP packet,
% such as a ping packet?)
Yes. This is allowed today.
% Then if the destination is not upgraded, wait for its single ICMP
% packet (which could easily be dropped) before sending the packet
% again in normal IPv6 mode. This seems to imply significant delay
% to the establishment of communications with all non-upgraded hosts
% uncles the application gets the address via DNS, or already knows
% for some reason the destination host is or is not an ILNP host.
See earlier text for correction on some of the assumptions in the
quoted text immediately above.
Further, humans won't be able to tell, because the incremental
delay of one additional round-trip is so small, particularly for
reliable transport protocols such as TCP or SCTP. Most
applications (mail, web, file transfer, even most video
streaming) are TCP-based at present. In a number of cases today,
initial TCP packets might not be delivered due to congestion,
which would have the same human behaviour as the round trip that
didn't work trying ILNP. Yet, people are not widely unhappy with
the current time performance for connection opening.
So the incremental delay is not generally a problem. It would be
an issue for an inter-planetary mission or lunar mission, but I
believe there is a separate Delay-Tolerant Networking RG that is
developing a separate protocol suite for those applications.
% On page 7 you mention site multihoming, but I have no clear idea
% what this would involve. How does the site administrator tell all
% the hosts in their network that they are on a different
% locator?
For IPv6, an obvious way to do this is via existing IPv6
ND mechanisms. For IPv4, Router Advertisements can help.
Or see the 3 specific alternatives outlined above, some
of which don't require hosts be aware of any multi-homing
changes.
% draft-rja-ilnp-dns-00
% Page 3 para 2 you refer to both two and four new DNS
% resource records.
A typo, terribly sorry.
[Slides 22 & 23 describe 3 new DNS resource records.]
% There is no reference in this I-D to any optimisation or to
% multihoming.
The I-Ds are intended to be read as a set. Multihoming is
discussed in other I-Ds in draft-rja-ilnp-intro, Section 3
and in Slide 31.
Separately, this is described in more detail in our MobiArch
paper and also in the MobiWAC paper -- both of which are
cited with full bibliographic entry in draft-rja-ilnp-intro
page 14.
(Time constraints forced me to submit all the drafts hastily.
This haste sadly shows in all of the drafts.)
% You propose new DNS records for Locator and Identifier. So DNS
% servers need to be upgraded, and likewise DNS code in host stacks.
Both do need to be upgraded eventually to support additional DNS
RR types.
DNS RR types have been incrementally upgraded throughout the
years that the DNS has existed, with very widespread success.
Both DNS resolver libraries and DNS servers can be upgraded
incrementally.
Periodic security concerns about DNS or DNS software seem to be
forcing DNS software upgrades regardless. The current scare
seems likely to cause a mass migration of older BIND deployments
to BIND v9, for example.
% On page 10 you state that the existing BSD Sockets API can still be
% used to support IP address referrals, but I don't understand this
% at all, if the most significant 64 bits of the IP address could be
% changed when a multihoming service interruption forces the adoption
% of a new locator.
One only uses a referral to initially open a connection.
% I guess scalability would be achieved by allowing only ISPs to
% advertise prefixes in the DFZ. Each ISP might have dozens to
% millions of end-user networks connected via the one prefix.
% End-user networks then do not have any fixed addresses, other
% than the collection of 64 bit identifier addresses of all their
% nodes.
That would be one approach. One can imagine other approaches
as well.
% Your draft provides no guidance on how hosts are supposed to
% choose their 64 bit identifiers. In the absence of anything to
% the contrary, the set of identifiers in end-user network X may be
% a random set from the 64 bit space. Likewise, the identifiers of
% end-user network Y could be a random set from the same space.
Wrong.
[draft-rja-ilnp-intro, Section 1, Pages 4 and 5,
especially 1st paragraph of page 5; Also slide 18]
The Node-ID can be most easily formed from any MAC address on the
box, as with IPv6 Interface-IDs at present. A node may have more
than one Node-ID at a time. Other methods exist for creating
Node-IDs (e.g. anonymous Node-IDs or HIP-compatible Node-IDs).
% It only works with IPv6,
Wrong. [Slides 14 & 15]
ILNP can work with either IPv4 or IPv6, as has been stated on the
RG list several times, and is explicitly stated in the
presentation. ILNP is an architecture, not an engineering
standards proposal. The ILNP architecture can be mapped to
either or both versions of IP.
% then only by radically changing host stacks and applications
Host stacks do change with ILNP.
Applications do not require any changes.
[draft-rja-ilnp-intro-01, pages 9-11, Sections 7 and 8]
"radically" is your opinion.
% as currently specified, it removes the concept of a globally
% unique identifier.
NAT removed that concept by the middle 1990s.
So that's long dead, by your own admission (above).
% It has no links from the RRG wiki and has no
% summary and analysis document.
Quite correct.
My arm was twisted, by folks who appear to have read some of the
research papers, to put together a presentation for the Dublin RG
meeting. Under this RG's process rules, some I-Ds on the
presentation topic needed to exist. So I quickly created some
I-Ds to resolve that process issue. Thanks again to Steve
Blake for presenting this for me at Dublin.
ILNP is a research project, not an IETF standards project. ILNP
predates this RG's current focus by some years. It also predates
the IAB Workshop that drove the re-charter of this RG by some
years. I have not been inclined to play the "advocacy" game that
some have chosen to play. (I'm terribly sorry if that upsets
someone, but I don't regret the choice of how to spend my time.)
I would like to see some of the *architectural ideas* behind ILNP
get adopted in some future Internet. I'm not emotionally
entangled in whether ILNP as described in the I-Ds gets widely
deployed.
% I think the routing scaling problem is not so bad that it must
% be solved by changing hosts,
(Each person is entitled to their opinion. :-)
% especially host applications.
Applications do not need to change for ILNP.
[draft-rja-ilnp-intro-01, pages 9-11, Sections 7 and 8]
% Admittedly, there are few IPv6 hosts, so host changes for IPv6
% are not as unthinkable as for IPv4.
This makes any networking change easier for IPv6 than for IPv4,
not just host changes.
% I shouldn't have to do a literature search or muck around
% trying to find cited I-Ds which don't exist.
In the IRTF, as different from the IETF, one is expected to be
familiar with the historical research literature in the area,
and also to try to track current research publications. This
has been true since the creation of the IRTF decades back.
Originally, all IRTF groups had closed membership. It is
an improvement that some RGs have open membership, but it
does not remove the ethical obligation to track the research
literature for a RG that one is participating in.
I do apologise for the missing ICMP I-D and for the typos in
the existing I-Ds. They were written in too much haste,
trying to get them submitted before I went offline prior
to the Dublin I-D cutoff.
[At least two of the research papers were cited on page 2
of draft-rja-ilnp-intro-01 with full bibliographic entry
on page 14. That should have made them easy to find
using a search engine.]
% Please correct them in detail, a blanket statement like this
% doesn't help me or anyone else. Please also correct any
% mistakes I made in this message.
Done. In most cases I've pointed back to where my answer
came from in the existing RG online documentation.
My apologies for the delayed response, which delay
was driven by overseas travel during which I was offline.
% How many people do in fact understand ILNP?
Based on conversations at past IRTF meetings and on other
conversations with various folks, I think many people understood
the ILNP architecture prior to this note appearing. People who
have been following the research literature in this area have had
an easier time, since research papers on ILNP go back several
years now.
Yours,
Ran Atkinson
rja@extremenetworks.com
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg