Subject: Re: Embedding IP information in an IPv6 address (OMNI)

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 16 Oct 2020 16:03:19 +0000

Hi Philip,

> -----Original Message-----
> From: atn [mailto:[email-masked]] On Behalf Of Philip Homburg
> Sent: Friday, October 16, 2020 1:25 AM
> To: [email-masked]
> Cc: Templin (US), Fred L <[email-masked]>; [email-masked]
> Subject: Re: Embedding IP information in an IPv6 address (OMNI)
> 
> > There are many reasons why I like what we have already, but one
> > that I will point out is the ease of constructing a routable OMNI
> > site-local address (SLA) from a non-routable OMNI link-local address
> > (LLA). For an OMNI LLA such as fe80:2001:db8:1:2:: all that is
> > needed to turn it into an OMNI SLA is to set bit #9 to yield
> > fec0:2001:db8:1:2::. That is computationally very simple and allows
> > a single-bit translation between LLAs and SLAs (to get an LLA,
> > clear bit #9 and to get an SLA se bit #9). If instead the LLA had
> > the embedded prefix in bits 64 thru 127, the translation between
> > SLAs and LLAs would be much more expensive.
> 
> Site-local addresses are deprecated for a reason. Calling a new type of
> address 'site-local' is only creating confusion.

I don't want to call them "site-local" anymore; I want to rename them in
my draft as "segment-local".

> Of course, you can ask IANA to allocate a prefix for your particular purpose,
> and may be fec0:: but who knows. It seems bad to me to argue based on
> properties of a prefix you don't know you will get.

We can of course operate with any routable ::/10 prefix, and in fact the
draft called for ULAs until very recently until we were turned on to the
concept of re-purposing fec0::/10. It would be a good use of otherwise
wasted spaceo

> You call it 'site-local' and it seems that indeed you are recreating all of the
> problems of the original site-local. I.e, what if a single router is part
> of two OMNI sites, how the router distinguish between the two uses of the
> same prefix? Certainly if every mobile phone becomes an OMNI device it is quite
> likely that some router will serve multiple OMNI sites.

Bits 10-15 of the fec0::/10 prefix will be used to differentiate different
OMNI links. So, if we had multiple OMNI interfaces (e.g., omni0, omni1,
omni2, etc.) we would have multiple prefixes fec0::/16, fec1::/16, fec2::/16
up to feff::/16. That allows each node to connect to up to 64 OMNI links,
which is far more than we will need for aviation.
 
> ULA solved this problem. So it makes sense for OMNI to use ULA instead of a
> fixed prefix.

ULAs are what we started with - but what we want is a dedicated and
special-purpose mapping of a fixed ::/10 prefix, and my understanding
is that ULAs were intended to be general-purpose.

> Now back to your technical argument. Using a 64-bit IID for both link-local
> and the "site-local" makes changing from one prefix to another as cheap as
> you are proposing.
> 
> That said, any architecture where routers change addresses of packets on
> the fly is something I would avoid using.

No, it is not going to be about changing addresses on the fly; what it means
is that packets with IPv6 LLAs would be encapsulated in RFC2473 headers
with corresponding IPv6 ULAs - so, we are doing encapsulation; not translation.

> It is up to the originating transport protocol to select the source and
> destination address of a packet, and then all routers do is transport
> it to the destination. At the destination the packet arrives (mostly)
> unchanged.
> 
> If we wanted address translation, we could just stay with IPv4.

Not translation; encapsulation.

Fred

> --
> atn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/atn

---

From: Ted Hardie <[email-masked]>
Date: Fri, 16 Oct 2020 09:14:10 -0700

Hi Fred

On Fri, Oct 16, 2020 at 9:04 AM Templin (US), Fred L <
[email-masked]> wrote:

>   don't want to call them "site-local" anymore; I want to rename them in
> Given the very large amount of space, I think re-using fec0:: is not
really needed and probably not a good idea.  I think managing that would
require first moving it from "deprecated" to "unallocated" then waiting a
good long time for that to percolate through the industry's consciousness.
Only then would I think it safe to re-allocate.  It seems simpler to use
ULAs (or ask for a new allocation, if you really believe that is necessary).

Just my opinion, of course.

Ted

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 16 Oct 2020 16:31:21 +0000

Ted, thanks for your input. We actually started with ULAs but were turned on to SLAs
by the notion that we would be making good use of an otherwise-wasted space. The
other thing to consider is that whatever ::/10 prefix we use, it will be dedicated for
use with operating the OMNI Adaptation Layer (OAL). If we were to use ULAs for
that, then the ULAs could not be used for any other purposes within the OMNI
domain. If we instead use SLAs, then we can still use ULAs for end system addressing.

So, yes, I think we want to allow for all three of LLAs, SLAs and ULAs to coexist
within an OMNI domain and to be used for their respective purposes. GUAs will
also naturally fit in where needed.

Thanks - Fred

From: Ted Hardie [mailto:[email-masked]]
Sent: Friday, October 16, 2020 9:14 AM
To: Templin (US), Fred L <[email-masked]>
Cc: Philip Homburg <[email-masked]>; [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)

This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and know that the content is safe.

Hi Fred

On Fri, Oct 16, 2020 at 9:04 AM Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
  don't want to call them "site-local" anymore; I want to rename them in
my draft as "segment-local".

We can of course operate with any routable ::/10 prefix, and in fact the
draft called for ULAs until very recently until we were turned on to the
concept of re-purposing fec0::/10. It would be a good use of otherwise
wasted spaceo
Given the very large amount of space, I think re-using fec0:: is not really needed and probably not a good idea.  I think managing that would require first moving it from "deprecated" to "unallocated" then waiting a good long time for that to percolate through the industry's consciousness.  Only then would I think it safe to re-allocate.  It seems simpler to use ULAs (or ask for a new allocation, if you really believe that is necessary).

Ted

---

From: Ole Troan <[email-masked]>
Date: Fri, 16 Oct 2020 20:09:55 +0200

Fred,

I would challenge you to make OMNI entirely free from semantic addresses.
That would also help the working group understand what benefits semantic addresses bring to OMNI. 
And what the tradeoffs would be. 

Cheers,
Ole

> On 16 Oct 2020, at 18:31, Templin (US), Fred L <[email-masked]> wrote:
> 
> 
> On Fri, Oct 16, 2020 at 9:04 AM Templin (US), Fred L <[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Fri, 16 Oct 2020 21:47:04 +0000

From: ipv6 <[email-masked]> On Behalf Of Ole Troan

> I would challenge you to make OMNI entirely free from semantic addresses. That would also help the working group understand what benefits semantic addresses bring to OMNI. And what the tradeoffs would be.

I think it's a matter of speed and simplicity, no? You avoid that extra protocol, to assign addresses. Same idea as embedding the MAC into the IPv6 address. But it's true that the IETF likes to stay away from semantic addresses.

The path of least resistance, from all the back and forth, as of now, seems to be to either use ULAs, or to request a new /10 for this new purpose.

Bert

---

From: Bob Hinden <[email-masked]>
Date: Sat, 17 Oct 2020 08:52:04 -0700

Bert,

> On Oct 16, 2020, at 2:47 PM, Manfredi (US), Albert E <[email-masked]> wrote:
> 

I did some searching, found that there are currently about 500K aircraft of all types (general aviation, commercial, military, etc.).   Allocating a /10 seems excessive to me for this even with a lot of growth.

Using ULAs would be fine.   This might even be a good justification to use the other half of the ULA space as I suspect the ICAO could be an allocation authority.

Bob

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Sat, 17 Oct 2020 16:01:01 +0000

Bob, it looks like our notes crossed at approximately the same time, but I would say
the same thing to you that I just said to Bert - we will want all four of LLAs (for the
control plane), SLAs (for the OAL) and ULAs/GUAs (for end-system addressing).

About your scale calculations, there will be far more terrestrial vehicles, urban
air mobility vehicles, drones, pedestrians etc. than there are the number of
aircraft currently worldwide. But, scale is just one dimension of the problem
space and the more important dimension is *function*.

Thanks - Fred

> From: atn [mailto:[email-masked]] On Behalf Of Bob Hinden
> Sent: Saturday, October 17, 2020 8:52 AM
> To: Manfredi (US), Albert E <[email-masked]>
> Cc: IPv6 List <[email-masked]>; Ole Trøan <[email-masked]>; Bob Hinden <[email-masked]>; [email-masked]
> Subject: Re: [atn] [EXTERNAL] Embedding IP information in an IPv6 address (OMNI)
> 
> Bert,
> 
> >> I would challenge you to make OMNI entirely free from semantic addresses. That would also help the working group understand
> what benefits semantic addresses bring to OMNI. And what the tradeoffs would be.
> >
> > I think it's a matter of speed and simplicity, no? You avoid that extra protocol, to assign addresses. Same idea as embedding the MAC
> into the IPv6 address. But it's true that the IETF likes to stay away from semantic addresses.
> >
> I did some searching, found that there are currently about 500K aircraft of all types (general aviation, commercial, military, etc.).
> Allocating a /10 seems excessive to me for this even with a lot of growth.
>

---

From: Bob Hinden <[email-masked]>
Date: Sat, 17 Oct 2020 09:47:25 -0700

Fred,

> On Oct 17, 2020, at 9:01 AM, Templin (US), Fred L <[email-masked]> wrote:
> 

I think we are saying you are asking for too much.

> space and the more important dimension is *function*.

Where is the problem statement for this?  This is far beyond what was I understood was called for in the OMNI liaison letter (https://datatracker.ietf.org/liaison/1676/ ) that we thought the OMNI draft was focused on.  The liaison letter talks about aircraft, not vehicles, drones, pedestrians, etc.

I read what you are saying is a mobility solution for everything.

Bob

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Sat, 17 Oct 2020 17:00:43 +0000

Hi Bob,

> From: Bob Hinden [mailto:[email-masked]]
> Sent: Saturday, October 17, 2020 9:47 AM
> Cc: Bob Hinden <[email-masked]>; Manfredi (US), Albert E <[email-masked]>; IPv6 List <[email-masked]>; Ole
> Trøan <[email-masked]>; [email-masked]

The ask is to bring SLAs off mothballs and back into service - it would be a good use
of an otherwise wasted space. 

> Where is the problem statement for this?

https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/

> This is far beyond what was I understood was called for in the OMNI liaison letter
> (https://datatracker.ietf.org/liaison/1676/ ) that we thought the OMNI draft was focused on.  The liaison letter talks about aircraft, not
> vehicles, drones, pedestrians, etc.
> 

What we have been designing for the aircraft domain appears to be a good fit
for other mobility domains as well, with the above draft as evidence. I believe
we can satisfy the aircraft in the near term while still allowing for more
general-purpose mobility applicability.

Thanks - Fred

> >>> The path of least resistance, from all the back and forth, as of now, seems to be to either use ULAs, or to request a new /10 for
> this
> >> new purpose.
> >>
> >> Using ULAs would be fine.   This might even be a good justification to use the other half of the ULA space as I suspect the ICAO
> could
> >> be an allocation authority.
> >>
> >> Bob
> >>
> >>
> >

---

From: Vasilenko Eduard <[email-masked]>
Date: Sat, 17 Oct 2020 20:20:40 +0000

Hi Fred,
I could not imagine how many governments would agree to share 1 block for specific purpose.
Additionally, different governments would have 1000x different scalability needs.

I mean: it is not possible to just "request block for this purpose" upfront.
The architecture should be scalable to add blocks ad-hoc in the future.

Eduard
> From: ipv6 [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
> Sent: 17 октября 2020 г. 20:01
> To: Bob Hinden <[email-masked]>
> Cc: IPv6 List <[email-masked]>; [email-masked]
> Subject: RE: [atn] [EXTERNAL] Embedding IP information in an IPv6 address
> (OMNI)
> 
> Hi Bob,
> 
> > Cc: Bob Hinden <[email-masked]>; Manfredi (US), Albert E
> > <[email-masked]>; IPv6 List <[email-masked]>; Ole Trøan
> > <[email-masked]>; [email-masked]
> > > Bob, it looks like our notes crossed at approximately the same time,
> > > but I would say the same thing to you that I just said to Bert - we
> > > will want all four of LLAs (for the control plane), SLAs (for the OAL) and
> ULAs/GUAs (for end-system addressing).
> >
> The ask is to bring SLAs off mothballs and back into service - it would be a good
> use of an otherwise wasted space.
> 
> > > About your scale calculations, there will be far more terrestrial
> > > vehicles, urban air mobility vehicles, drones, pedestrians etc. than
> > > there are the number of aircraft currently worldwide. But, scale is
> > > just one dimension of the problem space and the more important dimension
> is *function*.
> >
> > This is far beyond what was I understood was called for in the OMNI
> > liaison letter (https://datatracker.ietf.org/liaison/1676/ ) that we
> > thought the OMNI draft was focused on.  The liaison letter talks about aircraft,
> not vehicles, drones, pedestrians, etc.
> >
> we can satisfy the aircraft in the near term while still allowing for more general-
> purpose mobility applicability.
> 
> Thanks - Fred
> 
> > Bob
> >
> >
> > >
> > > Thanks - Fred
> > >
> > >> Cc: IPv6 List <[email-masked]>; Ole Trøan <[email-masked]>;
> > >> Bob Hinden <[email-masked]>; [email-masked]
> > >>>> I would challenge you to make OMNI entirely free from semantic
> > >>>> addresses. That would also help the working group understand
> > >>> I think it's a matter of speed and simplicity, no? You avoid that
> > >>> extra protocol, to assign addresses. Same idea as embedding the
> > MAC
> > >>> The path of least resistance, from all the back and forth, as of
> > >>> now, seems to be to either use ULAs, or to request a new /10 for
> > this
> > >> new purpose.
> > >>
> > >> I did some searching, found that there are currently about 500K aircraft of
> all types (general aviation, commercial, military, etc.).
> > >> Using ULAs would be fine.   This might even be a good justification to use
> the other half of the ULA space as I suspect the ICAO
> > could

---

From: Bob Hinden <[email-masked]>
Date: Sat, 17 Oct 2020 16:02:17 -0700

Fred,

> On Oct 17, 2020, at 10:00 AM, Templin (US), Fred L <[email-masked]> wrote:
> 
> Hi Bob,
> 

There are very good reasons why SLA were deprecated, I don’t see a reason to change that.  ULAs are intended to replace the use of SLAs.

> https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/

That is interesting, but I don’t see any references to that in the omni draft, or any mention at all of ipwave.   Nor does the ipwave document reference your omni draft.

> general-purpose mobility applicability.

That is far from clear to me.   To me you have a solution, that changes a lot of things in IPv6, and you are claiming it solves all IP mobility problems.   Please excuse my skepticism, I can’t even tell if it solves the aircraft domain.

Bob