[Ila] Proposed charter

Tom Herbert <tom@quantonium.net> Wed, 17 January 2018 23:14 UTC

Return-Path: <tom@quantonium.net>
X-Original-To: ila@ietfa.amsl.com
Delivered-To: ila@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 65D7412EAD3 for <ila@ietfa.amsl.com>; Wed, 17 Jan 2018 15:14:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cO07EF5WmEpA for <ila@ietfa.amsl.com>; Wed, 17 Jan 2018 15:14:12 -0800 (PST)
Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B62D212EAD1 for <ila@ietf.org>; Wed, 17 Jan 2018 15:14:11 -0800 (PST)
Received: by mail-wr0-x234.google.com with SMTP id f11so10197492wre.4 for <ila@ietf.org>; Wed, 17 Jan 2018 15:14:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=hwYg2gtbh869iXmbyBtASrnZMB0vfCXET9hBtsI9j6w=; b=POd6CgWJXZSmPAku8yXXrA7xh/49vism/6O29FeOQ13hYO9vh9eY/nbdJet36lsgga MNGIx2/YKhEV9E4mu8RJDUZDJVAXSG8P4+Tz/ZHV5CQ/OEl5lSlT9Fl+f6gSuSF6VB+o 0NHUGCU+fAn+4OR2y1nFf80gTlh4W08cI3AtSRDHbvAVb0Fu0qcJWRo+760gphKVVuqs 72NXaIpdB2XVV0ZYL420Be4MSgDiyHxsd5JqSPrEATkunx8ZWB9HnbrrN4gbxooyr1ui loypG4CWXK1vD3v9WV558HlPgIchWOmZC/GsVzKfx7FBFDTF+J2CujbzAJVaxz7GGqPt gwvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=hwYg2gtbh869iXmbyBtASrnZMB0vfCXET9hBtsI9j6w=; b=fC0nuYDk5LoH9GviIAq83o6xEMhLEiaYVwtWYuH0Idfbh+5APGYJ3SUvWLQqbr7p8e Rq3/w7RPWXGDDjloRGkSShxNOw8yGWc86s0jcIOmxqYyIIgfpOEJa8vnDBuiANcbAC3l fdXybyKCh1KPeijLxCvxPSCkua0/iQnN/gm9hLH0jhLO1zuCH+zkvc2XIP+tsk1TY5eG BtEz3Dj7BTzenl2Mw1NXyQqh+ByIn0uuSjQAkaTKixJCNhTTLr+k9V9JmAQVGt65C1HN kYWlb9GtFhBgiZlK5DLnc+DXFMuqMN35FAsRn3p5uDQs38/WJj94iGSZIoXB7+HRJFa4 Bqdg==
X-Gm-Message-State: AKwxyteH83QzrWKTtr20AleTrupFDirgc7gNJ71yJT+8cmSgQLZnfEY/ xXnUa9svIEUrJZvysUGE3+6+M3r82IXW6+PXEEy8cOuG
X-Google-Smtp-Source: ACJfBoujUyYeMeulAkc2lZtlH+DdY+1yKkzeHTYBvQnSnUe2cl3+tX9aCsZHF8qzt47MOqy2rEIA+68lyfFeuQurNaI=
X-Received: by with SMTP id c5mr4188137wrg.105.1516230850037; Wed, 17 Jan 2018 15:14:10 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 17 Jan 2018 15:14:09 -0800 (PST)
From: Tom Herbert <tom@quantonium.net>
Date: Wed, 17 Jan 2018 15:14:09 -0800
Message-ID: <CAPDqMeqWDdqgrU4UrhCBo0W2kD4CODnPPNJHAC_8LrZXcaoJRw@mail.gmail.com>
To: ila@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/zteb1NSpqBO22zwyQGjK6K4dYos>
Subject: [Ila] Proposed charter
X-BeenThere: ila@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Identifier Locator Addressing <ila.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ila>, <mailto:ila-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ila/>
List-Post: <mailto:ila@ietf.org>
List-Help: <mailto:ila-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ila>, <mailto:ila-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jan 2018 23:14:13 -0000

Here is a first stab at a charter. Please comment!


Identifier-locator addressing (ILA) is a method of identifier/locator
split used with IPv6 that eschews encapsulation. It is a means to
implement network overlays based on translations between
application-visible, non-topological “identifier”  addresses, and
topological “locator” addresses. Locator addresses allow packets to be
forwarded to the network location where a logical or mobile node
currently resides or is attached. Before delivery to the ultimate
destination or application, addresses are reverse translated back to
the original application visible addresses. A database of identifier
to locator mappings is maintained to facilitate translation.  Nodes
can be mobile such that their identifier to locator mapping changes,
but identifier addresses are persistent. ILA is similar to ILNP,
however ILA is confined to the network layer, not limited to end node
deployment, and doesn’t require extension headers.

The goal of this group is to define and standardize the ILA datapath
and control plane. The ILA datapath defines the address structure and
mechanisms for translating between application visible identifier
addresses and locator addresses.The control plane includes protocols
to disseminate identifier to locator mappings. Similar to IP routing,
different control plane protocols might be defined for different

The use cases of ILA include mobility, datacenter virtualization, and
network virtualization; these will be elaborated on by the group.
There are several benefits of ILA compared to existing solutions. ILA
enables anchor-less mobility, benefits user privacy, and provides
advantages over traditional encapsulation methods in terms of
performance, efficiency, and compatibility with deployed networking

Nodes performing ILA translation maintain a table of identifier to
locator mappings. A node might might contain a full set of mappings
(ILA routers) or a working set cache of mappings (ILA forwarding nodes
and ILA hosts). Similar to IP routing protocols, different protocols
may be employed for these two cases. There are three basic methods for
populating the cache: push, pull, and redirects. The methods chosen
must be considered in light of security considerations and potential
for Denial of Service attacks.

This group will pay particular attention to privacy, secure, and
scalability characteristics of the solution. A goal of ILA is to
facilitate strong user privacy in addresses; this is acheived by
purging IP addresses of hierarchy that could be used to infer
geo-location, and also by allowing applications to use source
addresses for different flows to prevent unwanted correlations being
being made by a third party . The mapping system contains personally
identifiable information (PII) that can reveal user identities or
physical location of users, hence access to the mapping system must be
strictly controlled. Scalability of both the deployment architecture
and mapping system is important since the number of identifiers in a
network is expected to be in the billions.

This group will try to reuse relevant technologies from existing
mobility and encapsulation solutions. It will also leverage recent
work in scalable distributed databases and key-value stores. The work
produced by this group may be relevant to DMM, nvo3, LISP, int-area,
v6ops working groups in IETF, as well as other SDOs such as 3GPP.