Re: [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)

Philip Homburg <> Wed, 21 October 2020 12:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C7D93A0AD6; Wed, 21 Oct 2020 05:25:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GzZ6FYVSZhhS; Wed, 21 Oct 2020 05:25:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD1DE3A0AD4; Wed, 21 Oct 2020 05:25:19 -0700 (PDT)
Received: from (localhost [::ffff:]) by with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kVDB2-0000FAC; Wed, 21 Oct 2020 14:25:12 +0200
Message-Id: <>
Cc: "Templin (US), Fred L" <>, "" <>
Subject: Re: [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)
From: Philip Homburg <>
References: <> <> <> <>
In-reply-to: Your message of "Tue, 20 Oct 2020 20:07:12 +0000 ." <>
Date: Wed, 21 Oct 2020 14:25:07 +0200
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Oct 2020 12:25:22 -0000

> So, we split the doc into
> two parts, with everything relating to the interface moved into
> the OMNI draft and everything pertaining to mobility left in the
> AERO draft.  This allowed the OMNI draft to take on the form of an
> "IPv6-over-foo" spec independently of the AERO draft. In this way,
> the interface specification can be made to work with other mobility
> solution alternatives than just AERO, as ICAO still has other
> candidate mobility solutions under consideration.

It seems to me there are two ways to read this draft:
1) as a part of AERO. In that case we should focus on how to minimize the
   changes we are making. For example, it doesn't seem to make a lot of sense
   to allocate a /10 just for communication within aviation. 
2) As a far more general overlay network technology. But in that case, there
   should be an archtitecture for the general case. And the draft should
   actually focus on the general case, and have aviation specific parts in
   other drafts. 

Currently, it seems that the draft wants to do 2) but is actually doing 1)