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

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 19 Oct 2020 13:29:34 +0000

HI Bob,

> -----Original Message-----
> From: Bob Hinden [mailto:[email-masked]]
> Sent: Saturday, October 17, 2020 4:02 PM
> To: Templin (US), Fred L <[email-masked]>
> Cc: Bob Hinden <[email-masked]>; Manfredi (US), Albert E <[email-masked]>; IPv6 List <[email-masked]>; Ole
> Trøan <[email-masked]>; [email-masked]
> Subject: Re: [atn] [EXTERNAL] Embedding IP information in an IPv6 address (OMNI)
> 
> Fred,
> 
> > On Oct 17, 2020, at 10:00 AM, Templin (US), Fred L <[email-masked]> wrote:
> >
> > Hi Bob,
> >
> >> -----Original Message-----
> >> From: Bob Hinden [mailto:[email-masked]]
> >> Sent: Saturday, October 17, 2020 9:47 AM
> >> To: Templin (US), Fred L <[email-masked]>
> >> Cc: Bob Hinden <[email-masked]>; Manfredi (US), Albert E <[email-masked]>; IPv6 List <[email-masked]>;
> Ole
> >> Trøan <[email-masked]>; [email-masked]
> >> Subject: Re: [atn] [EXTERNAL] Embedding IP information in an IPv6 address (OMNI)
> >>
> >> Fred,
> >>
> >>> On Oct 17, 2020, at 9:01 AM, Templin (US), Fred L <[email-masked]> wrote:
> >>>
> >>> 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).
> >>
> >> I think we are saying you are asking for too much.
> >
> > The ask is to bring SLAs off mothballs and back into service - it would be a good use
> > of an otherwise wasted space.
> 
> 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.

OMNI Is a good reason to re-instate SLAs. OMNI will also want to use ULAs, but for
other and non-overlapping purposes.

> >>> 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*.
> >>
> >> Where is the problem statement for this?
> >
> > 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.

True that the OMNI draft does not yet reference ipwave (will fix in the next version).
But, draft-ietf-ipwave-vehicular-networking heavily cites OMNI.

> >> 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.
> >
> > 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.
> 
> 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.

Let me know what I can do to make it more clear.

Thanks - Fred

> Bob
> 
> 
> >
> > Thanks - Fred
> >
> >> Bob
> >>
> >>
> >>>
> >>> Thanks - Fred
> >>>
> >>>> -----Original Message-----
> >>>> 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,
> >>>>
> >>>>> On Oct 16, 2020, at 2:47 PM, Manfredi (US), Albert E <[email-masked]> wrote:
> >>>>>
> >>>>> 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.
> >>>>
> >>>> 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: Mon, 19 Oct 2020 16:40:53 +0000

Bob,

> other and non-overlapping purposes.

Before this discussion goes too much further, I want to point out that the term "SLA"
has never been used in association with "Site Local Address" prior to the use in OMNI
and these current list discussions; the term was introduced by me, but I would not like
for it to retroactively refer to "site" because it never has before in the past. So, I would
like to propose that we break that connection starting now.

What OMNI needs is an address range that is unique within the scope of a layer-2
spanning tree manifested by a service that joins together the segments of a
(segmented) link. So, I propose we rename fec0::/10 for its use in OMNI as one
of the following:

"Spanning-tree Local Addresses (SLA)"
"Service Local Addresses (SLA)"
"Segment Local Addresses (SLA)"

The term "site" is not relevant to OMNI and would no longer be used in that
context (once we submit a document update, that is). Would that address
the concern?

Thanks - Fred

---

From: Bob Hinden <[email-masked]>
Date: Mon, 19 Oct 2020 10:00:56 -0700

Fred,

I think most people read SLA as Site-Local Address, especially since you are proposing to use the prefix defined in RFC3513:

   Site-local unicast   1111111011           FEC0::/10       2.5.6

In my view any proposal to reuse this prefix, will need to deal with the issues raised in RFC 3879, the document that deprecated this prefix.   This would need its own document that would obsolete RFC 3879.  It would also need to investigate if deployed hosts and routers block these prefixes.

Bob

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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 19 Oct 2020 17:27:09 +0000

Bob, we could call it "Domain-Local Addresses (DLA)" and include the following
definition in the OMNI spec:

OMNI Domain - a set of affiliated OMNI links that collectively provide services
                                 under a common Mobility Service Prefix (MSP).

About whether routers will route fec0::/10 prefixes, I know I can make quagga
route fc80::/10 and I assume that it will also route fec0::/10 but I will test that
out and let you know. My assumption is that if quagga will route it, then
commercial routers will too?

Thanks - Fred

> Sent: Monday, October 19, 2020 10:01 AM
> Cc: Bob Hinden <[email-masked]>; Manfredi (US), Albert E <[email-masked]>; Ole Trøan
> <[email-masked]>; IPv6 List <[email-masked]>; [email-masked]
> Subject: [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)
> 
> Fred,
> 
> In my view any proposal to reuse this prefix, will need to deal with the issues raised in RFC 3879, the document that deprecated this
> prefix.   This would need its own document that would obsolete RFC 3879.  It would also need to investigate if deployed hosts and
> routers block these prefixes.
> 
> 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.
> >>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Oct 2020 13:37:24 -0400

Bob Hinden <[email-masked]> wrote:
    > I think most people read SLA as Site-Local Address, especially since
    > you are proposing to use the prefix defined in RFC3513:

Yes, I keep saying to Fred, that overloading SLA is a recipe for
misunderstanding.   I think Fred has fixated on those three letters though.

Bob, can you file away all the historical objections to SLA, and can we just
use another name.

Fred needs a /10 with some new name and new semantics.
     Reusing FEC0::/10 is ONE option, given that it's just sitting there rotting.
     Allocating another prefix that satisfies the needs of OMNI is another.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Philip Homburg <[email-masked]>
Date: Tue, 20 Oct 2020 12:54:54 +0200

> > other and non-overlapping purposes.

When I read the draft from the point of view of a general purpose overlay
network technology, then I find the architecture far from clear.

Maybe the draft would benefit from a separate architecture document. The draft
reads like at large collection of ideas that may work in aviation, but it is
unclear how they would apply to other domains.

For example, the draft introduces technical details, like SLAs, without
describing why they are needed and how they are used.

Then later they pop up seemly at random, for example in Section 12.1 (Router
Discovery in IP Multihop and IPv4-Only Access Networks):
"For IPv6-enabled ANETs, the MN then encapsulates the message in
"an IPv6 header with source address set to the SLA corresponding to
"the LLA source address and with destination set to site-scoped
"All-Routers multicast (ff05::2)[RFC4291]."

How does a mobile node that is doing router discovery know the link number
to put in the SLA? How does the mobile node knows its MNP?

Then later in the same section:
"for unicast-only
"IPv4-only ANETs, the MN instead sets the destination address to the
"unicast IPv4 adddress of an AR [RFC5214].

RFC 5214 is 6over4. Section 6 says: "IPv4 multicast MUST be available.". It
is not clear how this connects to the previous sentence. It also not clear
how the mobile node would know the IPv4 address of an AR.

If you know that the router is multiple hops away, why not use protocols that
are designed for this situation, https for example, to receive configuration
indead of trying to shoehorn a protocol that is designed to work on a single
link?

Somehow, Section 12.3 introduces a poor man's DHCPv6 relay. No explanation
is given why that is needed. 

Section 9.1.3 (Interface Attributes) is something that could benefit from
Ole's CBOR draft. Beyond that, it is completely unclear to me how this would
work in general. For example:

"Link encodes a 4-bit link metric.  The value '0' means the link
"is DOWN, and the remaining values mean the link is UP with
"metric ranging from '1' ("lowest") to '15' ("highest").

And now what?

There is Appendix A (Interface Attribute Heuristic Bitmap Encoding)

"Adaptation of the OMNI option Interface Attributes Heuristic Bitmap
"encoding to specific Internetworks such as the Aeronautical
"Telecommunications Network with Internet Protocol Services (ATN/IPS)
"may include link selection preferences based on other traffic
"classifiers (e.g., transport port numbers, etc.) in addition to the
"existing DSCP-based preferences.

The first time the word Heuristic appears in the draft is in Appendix A.
I have no clue what is going on there. 

Section 17 (OMNI Interfaces on the Open Internet) is quite relevant to any
kind of general purpose deployment. Note that connecting to the internet is
only described this late in the document. However, this section leaves me
without any kind of understanding of what is acually going on. There are
references to VPNs, and SEND. But I have no clue how this all connects.

The document reads as 'mobile nodes talk to access routers and then magic
happens'. I can see how in aviation you would have dedicated access routers
around the globe that run a routing protocol, etc. to make this work.
Outside such a confined environment I don't see how this would work.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 20 Oct 2020 10:04:58 -0700

Michael,

> On Oct 19, 2020, at 10:37 AM, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

I agree.

> Bob, can you file away all the historical objections to SLA, and can we just

It’s all written down in RFC 3879.

>     Allocating another prefix that satisfies the needs of OMNI is another.

Trying to reuse the site-local prefix is IMHO not going to have a good outcome, and I don’t think it is necessary.

If OMNI needs its own prefix, it can request that.   The length of that prefix will have to be justified.

Also, I would like to see if Fred can solve the “OMNI” problem using existing addresses, like Global Unicast and ULAs without anything new.   The networks that OMNI is proposing to use could easily get their own provider allocations.

Bob

---

From: Michael Richardson <[email-masked]>
Date: Tue, 20 Oct 2020 14:27:14 -0400

> network technology, then I find the architecture far from clear.

I also.
I can see that there is an architecture though.
The text just doesn't make it clear.

    > unclear how they would apply to other domains.

Yes, I think that's what happened.  Lots of ideas arrived, and were written
up, some of it implemented, but no other implementers were involved.

I think that this is one of the problems with documents spending so much time
as "individual" documents --- the accumulate cruft that is not structured
for group reading.

I think that the OMNI work is important, but it's far too involved for people
who are not doing it full time to contribute to.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

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

Bob,

> Sent: Tuesday, October 20, 2020 10:05 AM
> To: Michael Richardson <[email-masked]>
> Cc: IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>; [email-masked]
> Subject: [EXTERNAL] Re: [atn] Embedding IP information in an IPv6 address (OMNI)
> 
> Michael,
> 

I am fine with dropping "SLA"; it says that in the current OMNI draft, but we
can make it say something different in the next draft version.

> Also, I would like to see if Fred can solve the “OMNI” problem using existing addresses, like Global Unicast and ULAs without anything
> new.   The networks that OMNI is proposing to use could easily get their own provider allocations.

Bob, I honestly thought you would be warm to the idea, and that your initial
pushback was a way of encouraging a more thorough analysis of the proposal.
But, after several iterations now I am getting the sense that you truly don't
like it. Which surprises me, but I am open to discussing the alternatives.

In particular, the use case for the /10 prefix we need is for addressing in the
OMNI Adaptation Layer (OAL). The OAL inserts an RFC2473 IPv6 encapsulation
header which requires source and destination addresses - and the addresses
need to be routable within a bounded domain. The addresses will never leak
out onto the IPv6 Internet, so they need not be GUAs. We have already had
quite a bit of discussion on fec0::/10, so let's discuss ULAs as an alternative.

As it turns out, earlier versions of the OMNI draft called for using fc80::/10
(i.e., a /10 sub-prefix of fc00::/7). In fact, that is still what the code is using
because I have not had a chance to convert it over to SLAs yet. And, IPv6
routing services (e.g., quagga) route the fc80::/10 space just fine and without
allowing leakage out onto the IPv6 Internet. Which is sort of exactly what we
want. However, binding the fc80::/10 space for operating the OAL has the
disadvantage that the space can no longer be used for end system addressing,
and in some environments that might be seen as a limiting factor. But, on the
flip-side, there would still be ample portions of fc00::/7 left over to designate
as end system addresses in an all-ULA environment - or, GUAs could be used
for end system addressing instead.

So, with that analysis, the benefit of using fec0::/10 is that it makes a firm break
between what is LLA, what is OAL-dedicated and what is end-system ULA/GUA.
And, the OMNI draft could claim it as its "own" space. True that chopping up
fc00::/7 as described above can work too, but it somehow does not seem as
clean-cut as it would be if we had used fec0::/10. 

Fred

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 20 Oct 2020 20:07:12 +0000

Philip, sorry to top-post, but your comments by-and-large seem to be about not
having sufficient context and I think I can offer an explanation. Up to the beginning
of this year, what we now know as OMNI was previously wrapped up into a larger
integrated proposal called AERO:

https://datatracker.ietf.org/doc/draft-templin-intarea-6706bis/

The work had been progressing in the ICAO "Working Group-I Mobility Subgroup"
as an integrated package until a decision point was made by the group to separate
the air-ground interface specification from the mobility solution specification. 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. 

So, the part you referred to as "magic" is exactly those aspects that are covered
by the Mobility Service (MS) specification which is outside the scope of OMNI.
But, IMHO, the OMNI spec stands alone as an interface specification with the
understanding that details of the MS are out-of-scope.

Thanks - Fred

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Philip Homburg
> Sent: Tuesday, October 20, 2020 3:55 AM
> To: [email-masked]
> Cc: Templin (US), Fred L <[email-masked]>; [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Wed, 21 Oct 2020 14:25:07 +0200

> 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)

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 21 Oct 2020 13:36:23 +0000

Philip,

> Sent: Wednesday, October 21, 2020 5:25 AM
> To: [email-masked]
> Subject: Re: Embedding IP information in an IPv6 address (OMNI)
> 

Thanks for this useful perspective, but please note that AERO is no way specific
to just aviation. I expect AERO to apply for any mobile networking applications,
including cars, cellphones, drones, airplanes, ships, trains and anything else that
moves and has  an onboard network or uses IPv6 multi-addressing.

That said, I think we are actually not far off from achieving your 2) above. So,
I will turn back to your previous message and treat it as comments for the
document within that spirit. I will post a response shortly.

Fred

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 21 Oct 2020 14:38:35 +0000

Philip, see below for my responses to your specific comments:

Thanks - Fred

> unclear how they would apply to other domains.

The document came from an aviation committee, but the applicability is
far broader than just airplanes. Cars, cellphones, drones, airplanes, ships,
trains and anything else that moves and has  an onboard network or uses
IPv6 multi-addressing are also candidate users. Applicability to the ipwave
problem space has also been documented, e.g.

> describing why they are needed and how they are used.

Several people have objected to the use of that particular acronym, so
I will take action to remove it from the document and replace it with
something less objectionable. But the need is to have an address range
that can be used as the source and destination addresses of the RFC2473
IPv6 header inserted by the OAL. The addresses need to be routable
within a bounded domain, but they will never leak out onto the IPv6
Internet so they need not be GUAs. The clear candidates therefore
would be taking all of fec0::/10 or a sub-prefix portion of fc00::/7.
 
> "All-Routers multicast (ff05::2)[RFC4291]."

Yes, that stems from the requirement that the addresses need to be
routable within a bounded domain - in this case, IPv6 multi-hopping to
reach the boundary router of Mobile Ad-hoc Network for cases such
as vehicle-to-vehicle multihop access to infrastructure.

> to put in the SLA? How does the mobile node knows its MNP?

For commercial airplanes, there will be a 24-bit ID that is unique to the
aircraft and travels with the aircraft wherever it goes. Aircraft can then
statically determine their MNPs by concatenating the 24-bit ID with the
Mobility Service Prefix (MSP). For example, if the MSP is 2001:db8::/32
and the unique ID is 0x123456  the MNP is 2001:db8:1234:56::/56.

For other cases where there is no hard-coded unique ID, the Mobile
Node can use either the unspecified address or a temporary MNP for
the first contact to the AR and request the network to allocate an MNP
via DHCPv6.

> RFC 5214 is 6over4. Section 6 says: "IPv4 multicast MUST be available.". It

RFC5214 does not mandate multicast; I think you are referring to RFC2529?

> how the mobile node would know the IPv4 address of an AR.

The MN can have a list of IPv4 addresses discovered the same way as for
ISATAP deployment in enterprises. It may not know the IPv4 address of
the actual AR that it will contact, so this seems to suggest that an anycast
address could be useful.

> indead of trying to shoehorn a protocol that is designed to work on a single

No, this is not shoehorning - this is what ISATAP was designed for. We flew
ISATAP on drones back in Y2K.

> is given why that is needed.

It is not a DHCPv6 relay - it is a DHCPv6 *proxy*. The AR acts as a DHCPv6 client
on behalf of the MN the same way that a proxy would do. It is needed for cases
when the MN does not have a pre-assigned MNP, which may be the dominant
model for many use cases.

> "metric ranging from '1' ("lowest") to '15' ("highest").

I think what you may be missing is a couple of sentences explaining how the
Interface Attributes influence the Conceptual Sending Algorithm (section 11).
This is really the heart of what this mechanism is all about - it is about
multilink and Safety/Performance Based multilink selection. I think a few
connecting sentences - some in Section 11 and Section 9.1.3 might address
this concern.

> I have no clue what is going on there.

The terminology in Section 9 shifted to "Interface Attributes", but the change
did not carry forward into Appendix A as it should have. The Appendix A
language needs to be harmonized with the language used in Section 9.1.3.

> references to VPNs, and SEND. But I have no clue how this all connects.

I may be too close to the document to comprehend the understanding gap
you seem to be indicating. Can you say more about what you think is missing?

> Outside such a confined environment I don't see how this would work.

Yes, it is expected that the Access Routers (ARs) will engage in a Mobility
Service (MS) outside the scope of this document. The details of the MS are
intentionally omitted so as to be generic. What this document does is to
present an *interface* spec. From the perspective of the MN, all it cares
about are neighbors on the interface which would include ARs and potentially
also other MNs.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 21 Oct 2020 10:51:44 -0700

Philip,

> On Oct 21, 2020, at 5:25 AM, Philip Homburg <[email-masked]> wrote:
> 

I think this is a good summary.

I will add, if the goal is to meet the requirements in the liaison letter (https://datatracker.ietf.org/liaison/1676/) in the short term, then minimizing the changes would be helpful.

If the goal is “general overlay network”, then that is going to take a lot longer, might well need a BOF and its own working group.

Bob