Re: [Int-area] ILA and int-area

Brian E Carpenter <> Wed, 17 May 2017 05:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5CF6A12E3AE for <>; Tue, 16 May 2017 22:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CqGMrCqCMo0Y for <>; Tue, 16 May 2017 22:33:07 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A92B9129B82 for <>; Tue, 16 May 2017 22:29:47 -0700 (PDT)
Received: by with SMTP id m17so1569117pfg.3 for <>; Tue, 16 May 2017 22:29:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=3KjlVVbzJmZYClF1b+T/qs4VNq7jB5kf98RTAGxSosA=; b=KSJiRHTcn/hbec+64bfUAxfBuYgPeUc0zJv7OTCZ4Xq0GIqwBSyyvxk4RW+OorUEly RxSLx5UTGf3b2xUvmIUFZ6lz2VgiMHoOopWhq1HYpPH2KWHXK5Cmq2Gf8K410EbK5sTQ OaqswddPNSk1MZcfrYwcWQyJcpyOhY220k8Df02fbMHRIqBTd10DFDuy51qAX+bRo10c 1/ZMI+Rd7Ki54Mh3mRnoqAuxvS65niDafOJQxADAUz8N1xHJo6w8xnNS+IVJUPtgDgp0 u8V55qyw9xjCoTqXmWFgu+ZQsOr7psYMiucXapZBr3vfABV1PhwDFsCSGIxkchUnPEah nB8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=3KjlVVbzJmZYClF1b+T/qs4VNq7jB5kf98RTAGxSosA=; b=d/bQvsaglIEvAgUoT38jWsGStXBCzib9hGAeAB+Yet57JbVJrM93deXBTTjEl0mUlQ Hg7NF5M3PBqV2wq9n5dr+fd1tDqDE5jI3O0FyJH/vK3BTPwSbQQBfEDhO9vbRqME7vO+ 4KZuGCo5SJQT5KpxOywgnXRPxPKn0l6bOdjSeP9X32JdKvJZDcIWeUSZLNZAP1ZYLNbN 9zy07lyUUWU2vruKDQ0YrZsf72YyyfhYANFkLBkHQ0DP+F8w9TH7b1XzZYOJm+pxHJQL m1nSGySHN00NDTpmnkTz/81BSyLmWTd++SLDP2kHbTSGxvrwTkT3KdX2qIbokHeQIoOG WvVw==
X-Gm-Message-State: AODbwcB3cLmzv31QEq0C2A9xTtXk8gIva329JHLAnxJVGcYkNtPJrw36 ROk4ZPs+RI3ICA==
X-Received: by with SMTP id w23mr2087622plk.73.1494998987267; Tue, 16 May 2017 22:29:47 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id 3sm1355406pfp.11.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 22:29:46 -0700 (PDT)
To: Tom Herbert <>, "" <>
References: <>
Cc: Petr Lapukhov <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Wed, 17 May 2017 17:29:48 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Int-area] ILA and int-area
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 May 2017 05:33:09 -0000

On 14/05/2017 05:42, Tom Herbert wrote:
> Hello,
> At the Chicago WG meeting I made a request that ILA be taken up as a
> WG item in int-area. The WG chairs and AD requested that we raise a
> discussion on the list about what else is needed to be done for ILA
> (Identifier Locator Addressing draft-herbert-nvo3-ila-04). The
> question was also raised if int-area is the right WG for ILA or if it
> should have a BOF.

I think it's fine for int-area to take this up, as long as 6man
is alerted.

A few somewhat random comments:

Is there any particular reason you chose a /64 routing prefix,
rather than say /72 or /80? I don't see any dependency on SLAAC,
so there's no reason to care about /64, right? I assume you would
use DHCPv6 or some other method of assigning addresses to VMs.

If you used /72 or /80 you'd have flexibility with a ULA prefix to
insert a subnet field.

> The format of an ILA address with a global unicast locator is:
>    |<--------------- Locator --------------->|
>    |3 bits| N bits        | M bits  | 61-N-M | 64 bits              |
>    +------+-------------+---------+---------------------------------+
>    | 001  | Global prefix | Subnet  | Host   |      Identifier      |
>    +------+---------------+---------+--------+----------------------+

Why is this restricted to 2000::/3?

> The format of an ILA address with a unique local IPv6 unicast locator
> is:
>    |<--------------- Locator --------->|
>    | 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
>    +--------+-+------------+-----------+----------------------------+
>    | FC00   |L| Global ID  | Host      |        Identifier          |
>    +--------+-+------------+-----------+----------------------------+

The first byte is confusing; presumably you're trying to express
fd00::/8 so why not put 11111101 ?

I agree that the flow label would be tricky to use for this sort of
purpose, but I have a couple of comments anyway:

>   o The flow label is only twenty bits, this is too small to be a
>     discriminator in forwarding a virtual packet to a specific
>     destination. Conceptually, the flow label might be used in a
>     type of label switching to solve that.

Perhaps, but 6man fairly comprehensively rejected that type of usage.
In practice it's excluded by section 4 of RFC6437.

      o The flow label is not considered immutable in transit,
        intermediate devices may change it.

That's not phrased quite right. RFC6437 section 2 says:

"  Once set to a non-zero value, the Flow Label is expected to be
   delivered unchanged to the destination node(s).  A forwarding node
   MUST either leave a non-zero flow label value unchanged or change it
   only for compelling operational security reasons as described in
   Section 6.1.

   There is no way to verify whether a flow label has been modified en

You could in fact have an operational guarantee that within an
administrative domain, no middleboxes will change the flow label.
So something like this is more accurate:

     o  The flow label is not protected against changes in transit.

>    o Intermediate devices must not insert extension headers
>      [RFC2460bis].

I think you could say:

      o Current specifications do not allow intermediate devices to
        insert extension headers [RFC2460bis].