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

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 15 Oct 2020 20:58:41 +0000

Bob,

> -----Original Message-----
> From: Bob Hinden [mailto:[email-masked]]
> Sent: Thursday, October 15, 2020 1:29 PM
> To: Templin (US), Fred L <[email-masked]>
> Cc: Bob Hinden <[email-masked]>; Ole Trøan <[email-masked]>; IPv6 List <[email-masked]>; [email-masked]
> Subject: Re: Embedding IP information in an IPv6 address (OMNI)
> 
> Fred,
> 
> > On Oct 15, 2020, at 12:40 PM, Templin (US), Fred L <[email-masked]> wrote:
> >
> >>>>
> >>>
> >>> That circles us right back to the subject of how RFC4861 is intrinsically tied to
> >>> the use of link-local address and the fact that all IPv6 interfaces are required
> >>> to configure a unique link-local address. It would be a bear to try to change
> >>> that, so OMNI employs RFC2473 encapsulation instead of trying to override
> >>> the bedrock IPv6 standards. The use of RFC2473 encapsulation also brings
> >>> other important benefits.
> >>
> >> Right, that how ND works.   Seems to me that you are proposing many changes to IPv6 for some degree of optimization.   It’s
> unclear
> >> to me that the benefit outweighs the cost.
> >
> > Rather than repeating them again here, I would invite you to go back over the
> > message exchanges I had with Ole yesterday (10/14/2020) where I outlined the
> > benefits.
> 
> I read that, but was not convinced that the benefits were sufficient to justify what you are proposing.

I think that may be due to the fact that we have only examined a few fundamental
aspects of the architecture, and there is more to it than what has been discussed
so far - a *lot* more.  For instance, the reason for wanting both LLAs and SLAs is so
that we can use overlay "L2 bridging" to join disjoint Internetworks together as
though they were one big bridged campus LAN. For example, in civil aviation there
are many network service providers including ARINC, SITA, Inmarsat and others and
each runs their own networks as an independent entity. But, an aircraft connected
to ARINC may need to communicate with an air traffic controller in SITA. OMNI then
views each of the providers as a link *segment* and bridges the segments using
RFC2473 encapsulation with SLAs and BGP router peerings between the providers.
The IPv6 layer then sees this bridged arrangement as a single, connected IPv6 link
and the aircraft and ATC can communicate as peers on the link even though they
are located in different provider networks in the underlay. 

> > About changes to IPv6, all that has been asked so far is for the OMNI
> > interface to define its own link-local addresses - having that, none of the IPv6
> > standards like RFC4861, RFC8200 etc. are changed.
> 
> The OMNI draft updated RFC1191, RFC3879, RFC4291, RFC4443, and RFC8201.

When I said "all that has been asked for *so far*", I meant in terms of what has
been discussed on the list up to now. Up to now, the only aspects of OMNI we
have touched on are the LLAs and SLAs, and it is only RFC3879 and RFC4291 that
are in question. So, until we get around to discussing the OAL let's put the other
RFCs aside for now.

Thanks - Fred

> Bob

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 15 Oct 2020 21:24:58 +0000

> are located in different provider networks in the underlay.

It is important to understand that the RFC2473 encapsulation I am referring to is
a "mid-layer" encapsulation and not the outermost encapsulation. When joining
multiple providers as I have said above, the SLAs are not routable in the public
Internet; only public IP addresses are routable within that realm. The OMNI
approach fully understands this, and therefore the RFC2473 encapsulation I am
referring to occurs as a *mid-layer* encapsulation and not the outermost
encapsulation. The outer encapsulation would use public IP addresses and some
form of security like IPsec or Wiregurad. So what we would end up with is:

  1) an inner IPv6 packet with GUA or LLA addresses
  2) a mid-layer RFC2473 encapsulation IPv6 header with SLA addresses
  3) an outer encapsulation IP header with public addresses plus any security codes

Fred

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 15 Oct 2020 22:27:15 +0000

And even more:

> From: atn [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
> Sent: Thursday, October 15, 2020 2:25 PM
> To: Bob Hinden <[email-masked]>
> Cc: Ole Trøan <[email-masked]>; IPv6 List <[email-masked]>; [email-masked]
> Subject: Re: [atn] Embedding IP information in an IPv6 address (OMNI)
> 
> A bit more to this:
> 

There are several benefits for using RFC2473 encapsulation in this way. First, it allows
IPv6 Neighbor Discovery (IPv6 ND) messages to travel across multiple Internetworks.
Let's say that a Client is connected to the ARINC network, but its Server is in the SITA
network. The RS/RA/NS/NA messages that make up the IPv6 ND protocol can be
encapsulated in an RFC2473 header and shipped between the client and server
without decrementing the IPv6 Hop Limit nor sending a packet with link-local
addresses through a router.

That is on the control plane. In the data plane, RFC2473 is at the heart of the OMNI
Adaptation Layer (OAL) which is in Chapter 5 of the document and I really recommend
you read. The OAL performs an analogous function as for AAL5, and adapts message
sizes to the diverse MTUs of the underlying interfaces and/or the underlying network
minimum path MTU. It selects a "cell size" for segmentation and reassembly the same
as for AAL5 (albeit with a larger cell size than ATM) and uses IPv6 fragmentation and
reassembly on the RFC2473 mid-layer packet as its segmentation and reassembly
scheme. This enables lossless and adaptive packet sizing, with soft error feedback
to the original source when packets are becoming "uncomfortably large". It is the
long-sought solution for tunnel path MTU discovery, and it is a major improvement
over the current state of affairs.

Fred

---

From: Bob Hinden <[email-masked]>
Date: Thu, 15 Oct 2020 15:41:52 -0700

Fred,

> On Oct 15, 2020, at 1:58 PM, Templin (US), Fred L <[email-masked]> wrote:
> 
> Bob,
> 

I think this is a bad idea, that is trying to make a set of networks with a whole range of characteristics (i.e., speed, delay, drop rates, errors, cost, etc.) look like a single "big bridged campus LAN”.   Most people have stopped buildings “big bridged campus LANs” a long while ago, what your are proposing is much harder given the different characteristics of the networks you mention.

I think a better approach is to treat the networks separately and use transport protocols techniques to use them efficiently separately and concurrently.   Likely the transport protocols and applications above them will need to be aware of the underlying networks.

> are in question. So, until we get around to discussing the OAL let's put the other

I disagree, you are clearly proposing a lot of changes, discussing them separately doesn’t change that.

Bob

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 15 Oct 2020 23:08:26 +0000

Bob,

> Sent: Thursday, October 15, 2020 3:42 PM
> Subject: [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)
> 
> Fred,
> 
> I think this is a bad idea, that is trying to make a set of networks with a whole range of characteristics (i.e., speed, delay, drop rates,
> errors, cost, etc.) look like a single "big bridged campus LAN”.   Most people have stopped buildings “big bridged campus LANs” a long
> while ago, what your are proposing is much harder given the different characteristics of the networks you mention.

I think you may have gotten a polar opposite read from what the OMNI technology
is all about - OMNI is about diversity; not homogeneity. The OMNI "multilink" concept
in particular is about accommodating all manners of data links having diverse properties
and characteristics, while presenting the best possible performance profiles to mobile
nodes in the face of dynamically changing conditions. The "bridged campus LAN"
concept is not a physical thing; it is a virtual one that allows nodes to communicate as
single-hop neighbors at the IP layer while their underlying data link properties may be
varying dynamically. This discussion now starts to enter into the realm of what we have
been debating in the ICAO working groups for the past several years, and has motivated
the design based on expert input from the aviation community. And, what is good for
aviation also turns out to be good for the worldwide mobile Internet for any manners
of mobile nodes.

Fred

> I think a better approach is to treat the networks separately and use transport protocols techniques to use them efficiently separately
> and concurrently.   Likely the transport protocols and applications above them will need to be aware of the underlying networks.
> 
> >

---

From: Bob Hinden <[email-masked]>
Date: Thu, 15 Oct 2020 16:20:16 -0700

Fred,

> On Oct 15, 2020, at 4:08 PM, Templin (US), Fred L <[email-masked]> wrote:
> 
>>> 
>> 

I think I understand what you are trying to do.  I just don’t think this will work, some problems are best not solved at L3.   As I outlined below, I think the transport layer (and probably application layer) will also need to be involved.

Bob

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 15 Oct 2020 23:27:02 +0000

Bob,

> Sent: Thursday, October 15, 2020 4:20 PM
> Subject: Re: [EXTERNAL] Embedding IP information in an IPv6 address (OMNI)
> 
> Fred,
> 

To clarify what I meant when I said "L2 bridge", I was actually referring to plain IPv6 routers
that operate on the RFC2463 encapsulation header *at a layer below IP*. These routers run
plain old BGP and exchange SLA routes. But again, this happens at a layer below the IP
layer seen by the transports and applications.

> I think I understand what you are trying to do.  I just don’t think this will work, some problems are best not solved at L3.   As I outlined
> below, I think the transport layer (and probably application layer) will also need to be involved.

We are not solving this at L3; we are solving it at the adaptation layer below the IP
layer seen by the transports and applications. It is called the OMNI Adaptation Layer.
And, if you want to see it working I would be happy to demonstrate with real
running code.

Thanks - Fred