RE: [EXTERNAL] Re: [atn] Embedding IP information in an IPv6 address (OMNI)

["Templin (US), Fred L" <[e-mail]>]

Bob,

> -----Original Message-----
> From: atn [mailto:[e-mail]] On Behalf Of Bob Hinden
> Sent: Tuesday, October 20, 2020 10:05 AM
> To: Michael Richardson <[e-mail]>
> Cc: IPv6 List <[e-mail]>; Bob Hinden <[e-mail]>; [e-mail]
> Subject: [EXTERNAL] Re: [atn] Embedding IP information in an IPv6 address (OMNI)
> 
> Michael,
> 
> > On Oct 19, 2020, at 10:37 AM, Michael Richardson <[e-mail]> wrote:
> >
> > Signed PGP part
> >
> > Bob Hinden <[e-mail]> 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.
> 
> I agree.

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.

> > Bob, can you file away all the historical objections to SLA, and can we just
> > use another name.
> >
> 
> It’s all written down in RFC 3879.
> 
> 
> > 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.
> >
> 
> 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, 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

> Bob
>