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

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 9 Oct 2020 17:45:51 +0000

Hi, the OMNI spec defines an IPv6 link-local address format that embeds another
IP address/prefix inside the least significant bits:

https://datatracker.ietf.org/doc/draft-templin-6man-omni-interface/

The idea behind embedding IP information inside an IPv6 address was first published
 in RFC1884 (December 1995) where the "IPv4-compatible" and "IPv4-mapped" IPv6
addresses were defined. (This was the first edition of the IPv6 addressing architecture,
with the latest edition now as RFC4291.) Later, RFC4214 and RFC5214 put a more formal
structuring around embedded IP addresses and RFC5969 even went further to move
the embedded information up into the upper 64 bits of the IPv6 address.

The genesis of the OMNI concept of embedding additional IP information in the IPv6
address was introduced in the "AERO(bis)" draft following the publication of RFC6706.
This format was later cited in RFC7421. Now in the present OMNI draft, we have an
IPv6 link-local address format where embedded IP information begins immediately
after the fe80::/10 prefix thereby utilizing up to 112 available bits for encoding useful
information.

It has come to my attention that some are skeptical about embedded IP information
inside an IPv6 address. But, the OMNI draft shows clear benefits for making use of
these otherwise-wasted bits and follows on from decades-old examples that are
still in use today. Would love to hear everyone's thoughts on this.

Thanks - Fred

---

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

I forgot to mention RFC4380 which also embeds a *lot* of additional IP information
within the IPv6 address. There may be others I am also forgetting.

Fred

> -----Original Message-----
> From: atn [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
> Sent: Friday, October 09, 2020 10:46 AM
> To: 6man <[email-masked]>; [email-masked]
> Subject: [atn] Embedding IP information in an IPv6 address (OMNI)
> 
> --
> atn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/atn

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 9 Oct 2020 15:52:56 -0400

RFC 8064 updates all recommendations on content of the 64 bit Interface 
portion of IPv6.

Lots of old bad practices in old RFCs.

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: Fred Baker <[email-masked]>
Date: Fri, 9 Oct 2020 14:27:41 -0700

The concept of embedding information in the 54 “must be zero” bits of the link local address is enticing, but may not prove interoperable, given the “must be zero” definition of a link local address.

Sent using a machine that autocorrects in interesting ways...

> On Oct 9, 2020, at 12:53 PM, Robert Moskowitz <[email-masked]> wrote:
> 
>  RFC 8064 updates all recommendations on content of the 64 bit Interface portion of IPv6.
> 
> Robert Moskowitz
> C:      248-219-2059
> F:      248-968-2824
> E:      [email-masked]
> 
> There's no limit to what can be accomplished if it doesn't matter who gets the credit
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

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

Fred,

> The concept of embedding information in the 54 “must be zero” bits of the link local address is enticing, but may not prove 
> interoperable, given the “must be zero” definition of a link local address.

Also good input, but given that these link-local addresses are defined and intended
for the exclusive use of a specific IPv6-over-(foo) interface type, only interfaces that
understand the address format will process the addresses and they will understand
the usage of the 54 bits.

Thanks - Fred

---

From: Mark Smith <[email-masked]>
Date: Sat, 10 Oct 2020 10:30:06 +1100

On Sat, 10 Oct 2020, 08:35 Templin (US), Fred L, <[email-masked]>
wrote:

> Fred,
>
> > The concept of embedding information in the 54 “must be zero” bits of
> the link local address is enticing, but may not prove

Link specific versions of link-local addresses don't and won't comply with
RFC4291 and all of its ancestors, because there is nothing that says the
format of the link local address can be defined by link specific documents.
These zero bits have always been zeros.

Why the effort to shoehorn new functionality into existing and long defined
IPv6 address spaces?

Follow the ULA verses site-local example - if new functionality is
considered different enough to justify updating existing, decades old and
very widely deployed address formats, then I'd think the threshold of
asking for new IPv6 address space for this functionality is passed. We have
about 7/8ths of the IPv6 address space not defined for any purpose (it'd be
a different story for new functionality in IPv4 addressing).

With new address space there is no need to both update and be constrained
within old address space definitions, and there is much less if any
compatibility considerations and concerns with existing deployments.

You could call your new address space OMNI Link-Local Addresses.

Regards,
Mark.

---

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

Hi Mark,

We want to use link-locals (fe80::/10) – else we would have to do a wholesale update
of key RFCs such as RFC4861. Plus, RFC4291 says:

   Routers must not forward any packets with Link-Local source or
   destination addresses to other links.

and since the OMNI link is the only one on which the addresses would appear on
the “wire” it should be possible to make a good use out of the otherwise-wasted
54 buts. All it takes is an “updates RFC4291” , for which we see many prior examples.

Fred

From: Mark Smith [mailto:[email-masked]]
Sent: Friday, October 09, 2020 4:30 PM
To: Templin (US), Fred L <[email-masked]>
Cc: Fred Baker <[email-masked]>; Robert Moskowitz <[email-masked]>; 6man <[email-masked]>; [email-masked]
Subject: Re: [EXTERNAL] Re: [atn] Embedding IP information in an IPv6 address (OMNI)

On Sat, 10 Oct 2020, 08:35 Templin (US), Fred L, <[email-masked]<mailto:[email-masked]>> wrote:
Fred,

Link specific versions of link-local addresses don't and won't comply with RFC4291 and all of its ancestors, because there is nothing that says the format of the link local address can be defined by link specific documents. These zero bits have always been zeros.

Why the effort to shoehorn new functionality into existing and long defined IPv6 address spaces?

Follow the ULA verses site-local example - if new functionality is considered different enough to justify updating existing, decades old and very widely deployed address formats, then I'd think the threshold of asking for new IPv6 address space for this functionality is passed. We have about 7/8ths of the IPv6 address space not defined for any purpose (it'd be a different story for new functionality in IPv4 addressing).

With new address space there is no need to both update and be constrained within old address space definitions, and there is much less if any compatibility considerations and concerns with existing deployments.

Regards,
Mark.

Thanks - Fred
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

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

Responding to this point again:

Ø  Link specific versions of link-local addresses don't and won't comply with RFC4291 and all of its ancestors, because there is nothing that says the format of the link local address can be defined by link specific documents

IPv6-over-foo documents already do place their own link-specific interpretations on
link-local addresses. It happens in RFC2464, RFC2467, RFC2470, etc. Each of these specs
gives its own link-specific representation of link-local addresses including a prefix
length definition that does not appear in RFC4291. This is the way that link-locals are
defined within the context of *that specific interface type*, and the addresses are
not to be forwarded to other interface types. And, none of these documents say
“updates RFC4291”. What is being proposed in the OMNI spec is really no different
in spirit – it just makes a good use out of otherwise-wasted bits which by the way is
very important on low-end data links such as those that occur in aviation applications.

Fred

From: atn [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
Sent: Saturday, October 10, 2020 9:12 AM
To: Mark Smith <[email-masked]>
Cc: Robert Moskowitz <[email-masked]>; 6man <[email-masked]>; [email-masked]; Fred Baker <[email-masked]>
Subject: Re: [atn] [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)

Hi Mark,

Fred

From: Mark Smith [mailto:[email-masked]]
Sent: Friday, October 09, 2020 4:30 PM
To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
Cc: Fred Baker <[email-masked]<mailto:[email-masked]>>; Robert Moskowitz <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [EXTERNAL] Re: [atn] Embedding IP information in an IPv6 address (OMNI)

Regards,
Mark.

Thanks - Fred

---

From: Mark Smith <[email-masked]>
Date: Wed, 14 Oct 2020 07:25:30 +1100

Hi Fred,

> 54 buts. All it takes is an “updates RFC4291” , for which we see many

I don't think it is as easy as just updating RFC4291. There are literally
billions of deployed implementations of IPv6 that expect these bits to be
zero, and have for the past 25 years since the link-local prefix format was
defined in RFC1884.

These zero bits aren't wasted, their value is to fill out the space between
the high order link-local fe80::/10 prefix and the lower 64 bit IID to
align them, so that the link-local address is 128 bits long. "Waste" only
occurs when no useful value is gained from something, and if course field
alignment is useful.

You possibly will run into an issue with BSD IPv6 implementations, which
from what I understand, store information in these zero bits' position when
they hold a link-local address in memory.

It would be easier to reclaim these bits if they were 'reserved', and if
there was a statement such as "set to zero upon transmission, ignored upon
receipt" however I've never seen such a clause for the link-local
subnet-prefix (I think that sort of clause might only exist for flag bits
in multicast addresses). Since RFC1884, these bits have always been
specified as being set to zero, with no possible caveats or exceptions
being suggested.

If you need to have another address space that isn't forwarded off link,
then that can be specified as a requirement for the new address space (and
you could do some receiver enforcement using the Hop Count == 255 trick
that ND uses). Packets leaking off of a link that shouldn't is always a
risk, and already occurs with link-locals (packets with DA=ULA/GUA, SA=LLA
are known to leak off-link).

Regards,
Mark.

>
> Fred
>
>
>
> *From:* Mark Smith [mailto:[email-masked]]
> *Sent:* Friday, October 09, 2020 4:30 PM
> *To:* Templin (US), Fred L <[email-masked]>
> *Cc:* Fred Baker <[email-masked]>; Robert Moskowitz <
> [email-masked]>; 6man <[email-masked]>; [email-masked]
> *Subject:* Re: [EXTERNAL] Re: [atn] Embedding IP information in an IPv6
> address (OMNI)
>
>
>
> On Sat, 10 Oct 2020, 08:35 Templin (US), Fred L, <
> [email-masked]> wrote:
>
> Fred,
>

---

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

Mark, see my follow-up message. There is no problem with an IPv6-over-foo spec
defining its link-local address format. Almost all of the existing IPv6-over-foo specs
define an interface-specific interpretation of link-locals with a prefix length (fe80::/64)
that does not appear in RFC4291, and none of them update RFC4291. All that is said
in RFC4291 is “fe80::/10”, which does not agree with the IPv6-over-foo specs. I hear
your point about the BSD hack of writing data into the 54 “unused” bits in memory,
but I am not sympathetic to that approach when what is being offered here is a
brand-new interface type that does not already exist in widely-deployed
implementations, so it is a chance for a fresh start for all implementations.

As it turns out, however, I am also seeking a re-purposing of the RFC4291 “site-local”
prefix fec0::/10 where the rightmost 118 bits of the address will be defined in exact
1x1 correspondence with what I am proposing for OMNI interface link-locals. You
might then say, “there you go – just use those, and leave link-locals alone”. I get
that, but the problem is that some documents (RFC4861 in particular) have exacting
requirements on link-local addresses to the point that we would have to do a major
“updates” to RFC4861 which I think would create an impasse far greater than the
one you seem to be implying for the proposed use of link-locals.

Personally, I do not see a problem. I have this link-local address format and
parsing in my OMNI interface implementation which I am hoping to make public
by the end of this year. There are no conflicts with existing code, and no overlaps
with other interface types. New documentation will clearly outline the use of
these link-locals within the context of the OMNI interface so there is no ambiguity.
So, greedy as I am, I yes do want to define both link-local and site-local addressing
according to the OMNI interface spec. The benefit IMHO far outweighs any of the
concerns I have heard.

Thanks - Fred

Sent: Tuesday, October 13, 2020 1:26 PM

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 Sun, 11 Oct 2020, 03:12 Templin (US), Fred L, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Mark,

I don't think it is as easy as just updating RFC4291. There are literally billions of deployed implementations of IPv6 that expect these bits to be zero, and have for the past 25 years since the link-local prefix format was defined in RFC1884.

These zero bits aren't wasted, their value is to fill out the space between the high order link-local fe80::/10 prefix and the lower 64 bit IID to align them, so that the link-local address is 128 bits long. "Waste" only occurs when no useful value is gained from something, and if course field alignment is useful.

You possibly will run into an issue with BSD IPv6 implementations, which from what I understand, store information in these zero bits' position when they hold a link-local address in memory.

It would be easier to reclaim these bits if they were 'reserved', and if there was a statement such as "set to zero upon transmission, ignored upon receipt" however I've never seen such a clause for the link-local subnet-prefix (I think that sort of clause might only exist for flag bits in multicast addresses). Since RFC1884, these bits have always been specified as being set to zero, with no possible caveats or exceptions being suggested.

If you need to have another address space that isn't forwarded off link, then that can be specified as a requirement for the new address space (and you could do some receiver enforcement using the Hop Count == 255 trick that ND uses). Packets leaking off of a link that shouldn't is always a risk, and already occurs with link-locals (packets with DA=ULA/GUA, SA=LLA are known to leak off-link).

Regards,
Mark.

Fred

From: Mark Smith [mailto:[email-masked]<mailto:[email-masked]>]

Regards,
Mark.

Thanks - Fred

---

From: 神明達哉 <[email-masked]>
Date: Tue, 13 Oct 2020 15:53:49 -0700

At Mon, 12 Oct 2020 13:15:09 +0000,
"Templin (US), Fred L" <[email-masked]> wrote:

> “updates RFC4291”.

These three RFC don't have to update the addressing architecture RFC
(which is, currently, RFC4291) in this regard in that all of them
specify the intermediate 54 bits are zeros and the interface
identifier length being 64 bits.  It's the same for other existing
link-specific RFCs I know of.

If a new link-specific specification wants to use a non-0 value in
that 54-bit field, it will have to formerly update RFC4291 so that all
relevant RFCs are still kept consistent.  That's the sense when we
revised SLAAC as described in Section 2 of RFC4862:

   interface identifier -  [...]  The
      exact length of an interface identifier and the way it is created
      is defined in a separate link-type specific document that covers
      issues related to the transmission of IP over a particular link
      type (e.g., [RFC2464]).  Note that the address architecture
      [RFC4291] also defines the length of the interface identifiers for
      some set of addresses, but the two sets of definitions must be
      consistent.

We had essentially the same type of discussion about 1.5 years ago,
where the char of the relevant WG declared we can't just publish a
link-type specific doc that would become inconsistent with RFC4291:
https://mailarchive.ietf.org/arch/msg/its/-OlXR-zYgsPcAioh58RObbigSp0/

I don't necessarily say such a change is never possible, but if
there's a lesson from that previous discussion, it would be that it's
not as easy/trivial as you might think.

--
JINMEI, Tatuya

---

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

Below:

> From: 神明達哉 [mailto:[email-masked]]
> Sent: Tuesday, October 13, 2020 3:54 PM
> Cc: Mark Smith <[email-masked]>; Robert Moskowitz <[email-masked]>; 6man <[email-masked]>; [email-masked]
> Subject: Re: [atn] Re: Embedding IP information in an IPv6 address (OMNI)
> 
> > Ø  Link specific versions of link-local addresses don't and won't comply with RFC4291 and all of its ancestors, because there is nothing
> that says the format of the link local address can be defined by link specific documents
> >

What in your opinion would be easier - a) update RFC4291 to allow coding of
the link-local address 54 zero bits, or b) update RFC4861 to allow routers to use
site-local addresses instead of link-local?

We need a good answer for this - either a) or b). The benefit of what is being
proposed by OMNI is too great to simply say no to both.

Thanks - Fred

---

From: Bob Hinden <[email-masked]>
Date: Tue, 13 Oct 2020 22:37:44 -0700

I don’t support embedding extra information in IPv6 addresses.  RFC4291 is clear:

   2.5.  Unicast Addresses

     . . . . .

     Except for the knowledge of the subnet boundary discussed in the
     previous paragraphs, nodes should not make any assumptions about the
     structure of an IPv6 address.

As other have said Link Local Addresses are defined with 54-bits of zero in them:

   Link-Local addresses are for use on a single link.  Link-Local
   addresses have the following format:

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+

Bob

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

---

From: [email-masked]
Date: Wed, 14 Oct 2020 12:15:26 +0200

Fred,

> proposed by OMNI is too great to simply say no to both.

It's unclear to me what the benfits are.
Would you be able to summarize here, or point to the relevant paragraphs in the OMNI draft?

Best regards,
Ole

---

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

Ole - see below:

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, October 14, 2020 3:15 AM
> Cc: 神明達哉 <[email-masked]>; Robert Moskowitz <[email-masked]>; 6man WG <[email-masked]>; [email-masked]
> Subject: Re: Embedding IP information in an IPv6 address (OMNI)
> 
> Fred,
> 
> >

The benefits include:

+ a means for configuring a unique IPv6 link-local address (i.e., the "OMNI LLA")
  that is known to be unique on the link without requiring SLAAC or MLD/DAD
+ a means for asserting and/or receiving IPv6 GUA prefixes without explicit
   prefix delegation messaging over the wire

So, for example, if a node has been pre-assigned an IPv6 GUA prefix 2001:db8:1:2::/64
then it can configure the OMNI LLA fe80:2001:db8:1:2:: (but note that this is not RFC4862
SLAAC; it is a simplified means of setting up an administratively-configured LLA that is
known to be unique on the link). The node can then assert its IPv6 GUA to the routing
system by sending an RS with fe80:2001:db8:1:2:: as the source address and with a
Prefix Length value 'N'.

In a second example, if a node has no pre-assigned IPv6 GUA then it can send an RS
message with IPv6 address unspecified. When it gets back an RA, it can determine its
(delegated) IPv6 GUA prefix by examining the destination address. For example, if
the RA message has destination address fe80:2001:db8:3:4:: and the message includes
a Prefix Length 'N' and lifetime value, it can adopt fe80:2001:db8:3:4:: as its own
OMNI LLA and adopt 2001:db8:1:2::/N as its own IPv6 GUA prefix.

There are also IPv4-compatible OMNI LLAs of the form fe80::ffff:[v4addr] and
"Service" OMNI LLAs of the form fe80::[32-bit ID]. All of these address forms
appear in Section 7 of the document, and their use is discussed throughout:

Thanks - Fred

> Ole=

---

From: Fernando Gont <[email-masked]>
Date: Wed, 14 Oct 2020 10:35:59 -0300

Hi, Fred,

On 13/10/20 17:58, Templin (US), Fred L wrote:
> defining its link-local address format. Almost all of the existing 
> IPv6-over-foo specs  define an interface-specific interpretation of link-locals with a prefix 
> length (fe80::/64) that does not appear in RFC4291, and none of them update RFC4291. All 
> that is said in RFC4291 is “fe80::/10”, which does not agree with the IPv6-over-foo 
> specs. I hear your point about the BSD hack of writing data into the 54 “unused” bits 
> in memory, but I am not sympathetic to that approach when what is being offered 
> here is a brand-new interface type that does not already exist in widely-deployed

Without having given a lot of thought about the context, it would seem 
to me that things like ND proxy might make addresses from one link 
visible in another.

Based on the (BSD) deployed code, if I had to do anything that would 
require using the zero bits in fe80::/64, I would probably consider 
using a different prefix altogether.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Wed, 14 Oct 2020 10:40:33 -0300

Hi, Fred,

On 9/10/20 14:45, Templin (US), Fred L wrote:
[...]
> still in use today. Would love to hear everyone's thoughts on this.

It would seem to me that such work would have to involve an update of 
RFC4291 if you want to play with the prefix bits, and of RFC7136 if you 
want to play with the IID bits.

Thanks,

---

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

Fernando,

We really do want to define the link-local address format for OMNI interfaces.
Too many things depend on every IPv6 interface configuring a unique link-local
address. The address format and the means by which it is assured unique is what
we want to specify for OMNI in an "IPv6-over-foo"-specifc document.

Thanks - Fred

> From: Fernando Gont [mailto:[email-masked]]
> Sent: Wednesday, October 14, 2020 6:41 AM
> To: Templin (US), Fred L <[email-masked]>; 6man <[email-masked]>; [email-masked]
> Subject: [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)
>

---

From: [email-masked]
Date: Wed, 14 Oct 2020 19:45:15 +0200

Thanks Fred for the explanation.

>  that is known to be unique on the link without requiring SLAAC or MLD/DAD

Benefit is in the eye of the beholder.
Manual configuration is a common cause of duplicate address. Why can't that happen here?
If you the setup here is that you have "some" information pre-configured. Why not also the link-local address?

>   prefix delegation messaging over the wire

Implied prefix delegation by the implementation knowing that it should find it's prefix at bit position <n:m> in the packet... doesn't seem like following the principle of least astonishment.
Likewise having the routing system glean information from RSs... is that really the level of adaptiveness you need from a routing system?

I'm not sure I get the motivation between these choices?
As opposed to using existing IPv6 mechanisms for the same.

Best regards,
Ole

---

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

Ole - see below for follow-up:

> Sent: Wednesday, October 14, 2020 10:45 AM

There are two possibilities - one that the client already has a pre-assigned IPv6 GUA
prefix and another that the client does not. For civil aviation, aircraft will be given a
pre-assigned 24-bit Identification number that is essentially the equivalent of an
automobile's Vehicle Identification Number (VIN). It is hard-coded into the aircraft,
and it stays with the aircraft throughout its lifetime. The addressing scheme for
aircraft creates an IPv6 GUA prefix that embeds the 24-bit ID in the prefix so that
the prefix is uniquely assigned per-aircraft. For example, the ID 0x010203 would be
embedded within an aviation service prefix such as "2001:db8::/32" to produce the
aircraft-unique prefix 2001:db8:0102:0300::/56 (note that this is just an example,
and will not be the actual aviation service prefix nor format that will occur in
operational practice). In this way, each aircraft receives a unique IPv6 GUA prefix,
and can form a unique OMNI LLA as fe80:2001:db8:0102:0300::.

In the second case, a client that does not have a pre-assigned IPv6 GUA nor
OMNI LLA needs to get one from the network. It issues an RS message with
"unspecified" source address (i.e., "::") and with a "DUID" option that contains
a unique ID for the client. A router on the OMNI link receives the RS and
(acting as a DHCPv6 "proxy") uses the DUID to solicit a prefix delegation from the
DHCPv6 server. The server returns an IPv6 GUA such as 2001:db8:5:6::/64, and
the "proxy" constructs an OMNI LLA as fe80:2001:db8:5:6::. The "proxy" then
returns an RA message to the client with destination set to fe80:2001:db8:5:6::
and with a Prefix Length indication. The client then discovers that its OMNI LLA
is fe80:2001:db8:5:6:: and that its IPv6 GUA prefix is 2001:db8:5:6::/64. This
information is guaranteed to be unique on the link since it came from an
authoritative and well-managed DHCPv6 server.

So, we get both prefix delegation and unique IPv6 link-local address
assignment that is managed for uniqueness.

> Implied prefix delegation by the implementation knowing that it should find it's prefix at bit position <n:m> in the packet... doesn't
> seem like following the principle of least astonishment.

See above for the explanation. In terms of messaging, it would go like this:

Client  --- (RS) ---> Router ("Proxy")
Proxy --- (DHCPv6-PD Solicit) ---> DHCPv6 server
Proxy <--- (DHCPv6-PD Reply) --- DHCPv6 server
... Proxy adds route to the routing system...
Client <--- (RA) --- Router ("Proxy")

So, it becomes a way for the Client to initiate DHCPv6-PD but driven by the IPv6 ND
router discovery process. It allows for smaller messages on the Client<->Router link,
and can use security features available for IPv6 ND such as SEND, which would be an
improvement over the scant authentication features provided by DHCPv6.

It fits what we would like to do for civil aviation. I think it fits well for many other
use cases also.

Fred

---

From: 神明達哉 <[email-masked]>
Date: Wed, 14 Oct 2020 11:39:10 -0700

At Tue, 13 Oct 2020 23:16:14 +0000,

> proposed by OMNI is too great to simply say no to both.

Both a and b seem to me to be equally fundamental and therefore
equally challenging.  If the benefit is really so great (which I don't
know), though, you should be able to persuade the WG to make the
update - all I can say at this moment is "good luck:-)".

--
JINMEI, Tatuya

---

From: Philip Homburg <[email-masked]>
Date: Thu, 15 Oct 2020 11:51:44 +0200

>we want to specify for OMNI in an "IPv6-over-foo"-specifc document.

A few thoughts:
1) I think a general system for an IPv6-over-IPv6 overlay network is useful.
   I don't know enough about OMNI to know if OMNI is the right answer, but
   some of the concepts in OMNI seem quite useful to me.
2) There is too much code that knows about the link local prefix, that 
   adding a another one is probably not going to fly. 
3) Traditionally (i.e. since the inception of IPv6) IIDs are 64 bits. So it
   makes sense for OMNI to conform to that. Embedding the MNP in the IID 
   means that the MNP can be at most 64 bits long. I don't see any big problem
   with that.
4) However, the main thing standing in the way of using all 118 bits allowed by
   the fe80::/10 prefix seems to be the *BSD hack of putting an interface 
   number in the zero bits of a link local address. I think that the BSD
   communities should remove this hack, and we should not effectively let
   them squat those bits.
5) I don't see any argument why the MNP should be longer than 64 bits. So
   point 3 seems the best way to go forward.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 15 Oct 2020 12:48:40 +0200

[...]
>     communities should remove this hack, and we should not effectively let

I think 4) is the best way forward.

To pursue that path, maybe a draft is necessary that states 'BSD hack is 
harmful to LL addresses'.  Then an implementation might accompany it.

>     point 3 seems the best way to go forward.

I think there are valid arguments for the MNPs (Mobil eNetwork Prefixes) 
to be longer than 64bits.  Some relate to the way cellular networks work.

Alex

---

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

Hi Philip,

> From: atn [mailto:[email-masked]] On Behalf Of Philip Homburg
> Sent: Thursday, October 15, 2020 2:52 AM
> To: [email-masked]
> Cc: Templin (US), Fred L <[email-masked]>; [email-masked]

Thanks for having a look at OMNI; let me know if there are any questions.

>    means that the MNP can be at most 64 bits long. I don't see any big problem

That is the way we had it in older draft versions, but have more recently
changed to using all of the bits 10 thru 128. The thing that inspired the
change was the realization that (not now, but in the not too distant
future) every air, ground, sea and space vehicle on the planet may
need to use OMNI - pedestrians, too. And, at some point, we may find
the /64 limit too restricting.

>    communities should remove this hack, and we should not effectively let

I agree.

>    point 3 seems the best way to go forward.

When the number of end systems needing MNPs goes up into the
countless billons scale, we may find ourselves hamstrung in the future
if we build in a hard /64 limit today.

Thanks - Fred

---

From: Philip Homburg <[email-masked]>
Date: Thu, 15 Oct 2020 18:43:40 +0200

>Thanks for having a look at OMNI; let me know if there are any questions.

I'll try to spend more time reading the draft.

>the /64 limit too restricting.

As long as we are talking about physical devices, I'm not sure how we
are going to run out of /64s.

Even if that would happen, there are probably lessons learned for an OMNIv2

In the past I would always relate handing out /64s to the number of 48-bit
MAC addresses, which a device typically has to communicate. We are not 
even close to running out of those. However, with randomized MACs, it may be
that future ethernet-like interfaces don't need a fixed MAC anymore.

Do you have a caculations when we would run out of /64 prefixes? Because that
would affect many other parts of IPv6 as well.

>> 4) However, the main thing standing in the way of using all 118 bits allo=
>wed by

Apart from the fact if there is consensus to make a change in this area,
I guess it will also take quite some time to first mark the bits as reserved,
urging implementations to make sure the support the full fe80::/10 and then
allowing protocols like OMNI to use those bits.

So it seems to me that it might be better to start with at most a /64 today
and plan for a new version of OMNI that supports longer prefixes. And maybe
just testing if the link local prefix is take from fe80::/64 is enough to 
distinguish between the two formats.

---

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

Philip - see below:

> Sent: Thursday, October 15, 2020 9:44 AM
> To: [email-masked]

OK, thanks.

> are going to run out of /64s.

This is a very important point - it is not just about physical devices but also about
the arbitrarily complex virtual networks they may have on-board. In the future,
even my cellphone could have a deeply-nested virtual IPv6 network-of-networks
requiring subnetting and multi-addressing - its turtles all the way down.

> Even if that would happen, there are probably lessons learned for an OMNIv2

I'd rather get it right the first time.

Thanks - Fred

---

From: [email-masked]
Date: Thu, 15 Oct 2020 19:18:07 +0200

> I'd rather get it right the first time.

If I were you I would take a look at what it would take to change the solution to use explicit signalling instead of implicit through semantic addressing.
Explicit signalling would not have any of these type of limitations either.

Cheers,
Ole

---

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

Hi Ole,

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.

Thanks - Fred

> Sent: Thursday, October 15, 2020 10:18 AM
> Cc: Philip Homburg <[email-masked]>; 6man WG <[email-masked]>; [email-masked]

---

From: [email-masked]
Date: Thu, 15 Oct 2020 19:39:38 +0200

Fred,

> embedded prefix in bits 64 thru 127, the translation between SLAs and LLAs would

The use of site locals also sets limitations of addressing/routing in the underlay.
With regards to performance. Is the conversion between SLA/LLA something you do per packet?
If not, I'm unsure I see why optimising that is beneficial.

Cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Fri, 16 Oct 2020 10:25:05 +0200

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

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.

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.

ULA solved this problem. So it makes sense for OMNI to use ULA instead of a
fixed prefix.

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.

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.

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 16 Oct 2020 09:40:20 -0500

Hi Fred,

I am curious whether OMNI is designed with LEO satellite links like
StarLink which is being deployed worldwide and
operational partially in North America in mind?

Behcet