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

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

Hi Bob,

> -----Original Message-----
> From: Bob Hinden [mailto:[email-masked]]
> Sent: Thursday, October 15, 2020 12:24 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:10 PM, Templin (US), Fred L <[email-masked]> wrote:
> >
> > Bob,
> >
> >> -----Original Message-----
> >> From: Bob Hinden [mailto:[email-masked]]
> >> Sent: Thursday, October 15, 2020 11:43 AM
> >> 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 11:40 AM, Templin (US), Fred L <[email-masked]> wrote:
> >>>
> >>>>>>>
> >>>>>>
> >>>>>> The use of site locals also sets limitations of addressing/routing in the underlay.
> >>>>>
> >>>>> This is rather about addressing/routing in the *overlay*.
> >>>>>
> >>>>>> 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.
> >>>>>
> >>>>> Per-packet - a simple bit-flip changes the address from SLA to LLA or vice-versa.
> >>>>
> >>>> Umm, that would break the transport protocol checksum.
> >>>
> >>> Good point, and that brings into focus the need for RFC2473 encapsulation.
> >>> If you want a packet with IPv6 link-local addresses (LLAs) to go more than
> >>> one hop, encapsulate it in an IPv6 header with the same LLAs and then
> >>> flip the bit to turn them into SLAs. Then, present the (encapsulated) packet
> >>> to the IPv6 overlay routing system.
> >>
> >> If you want the packets to go more than one hop, then don’t use link-local addresses.
> >
> > 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. 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.

Fred

> Bob

---

From: Bob Hinden <[email-masked]>
Date: Thu, 15 Oct 2020 13:28:36 -0700

Fred,

> On Oct 15, 2020, at 12:40 PM, Templin (US), Fred L <[email-masked]> wrote:
> 
>>>> 
>>> 
> benefits.

I read that, but was not convinced that the benefits were sufficient to justify what you are proposing.

> About changes to IPv6, all that has been asked so far is for the OMNI

The OMNI draft updated RFC1191, RFC3879, RFC4291, RFC4443, and RFC8201.

Bob