RE: OMNI Interface - formal issues

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

Zdenek, see below for responses:

> -----Original Message-----
> From: Jaron, Zdenek [mailto:[e-mail]]
> Sent: Tuesday, June 02, 2020 8:40 AM
> To: Templin (US), Fred L <[e-mail]>; 6man WG <[e-mail]>
> Subject: RE: OMNI Interface - formal issues
> 
> Dear Fred
> Thank you for your reply.
> 
> > The OMNI spec is an "IPv6-over-foo" document which specifies the
> > operation of IPv6 over specific link layers. That includes the formation and
> > use of IPv6 link-local addresses. So, since only nodes that implement the
> > OMNI spec will ever see these link-local addresses it should be OK to define
> > the link local addresses as being relative to fe80::/10 as permitted by RFC4291
> > while overriding the default zero settings of the 54 intermediate bits. So,
> > since this is wholly contained within the OMNI spec I don't think we need to
> > formally update RFC4291.
>
> I still believe that any "IPv6-over-foo" must conform to the IPv6 Addressing
> Architecture [RFC4291]. This document says that all addresses from FE80::/10
> are interpreted as link-local (see Section 2.4.), but only addresses from
> range FE80::/64 may be actually used (see Section 2.5.6.: the 54 zeros are
> not "default", they are mandatory). In my understanding, this makes the rest
> of FE80::/10 reserved for future updates of [RFC4291]. Although I agree
> that chances to collision seem to be low, I think that using the whole
> FE80::/10 is otherwise equivalent to using any other currently
> unassigned/reserved IP address range.

The reason for the specification is that it is important that the LLAs align exactly
with the ULAs we are asking for (below) starting with the most significant bits
so that the ULAs can be used in longest-prefix-match decisions in routing
protocols. If it means that we need to update RFC4291 then so be it; we can
add that to our list of RFCs to update.
 
> > Good point, Zdenek - I honestly never dug deeply into RFC4193 and thought
> > that all of fc::/7 was our own playground for free expression. However, I
> > notice that RFC4193 says that bit 7 is "Set to 1 if the prefix is locally assigned
> > and Set to 0 may be defined in the future". The behavior you are describing
> > above is therefore with respect to "fd::/8", so what if we were to change the
> > OMNI spec to define "fc::/8" as permitted by RFC4193? That way, we would
> > be free to define the setting of fc80::/10 in the way we currently do in the
> > OMNI spec. However, I think you are correct we would still need to say
> > "updates RFC4193. What do you think?
>
> FC00::/8 is currently reserved and cannot be used at all without update
> to [RFC4193]. The "locally assigned" range FD00::/8 is limited to have
> bits 8-47 randomly generated (see [RFC4193], Section 3.2.), so currently it
> could only be used as a source of (any number of) unrelated /48 prefixes.

Right, which is why we will have to update RFC4193 to make use of fc00::/8.
Thanks for pointing this out.

> Personally, I would reconsider the need to introduce "OMNI ULAs". They seem
> to be used only for segment routing (which could probably use some
> deployment-specific addresses) and fragmentation (which, if I understand
> it correctly, could use link-local addresses).

Aside from the use in segment routing, the OMNI ULAs will match in 1x1
correspondence with OMNI LLAs. So, for example, if the OMNI LLA is
fe80:2001:db8:1:2:: then the corresponding OMNI ULA is fc80:2001:db8:1:2.
What this means is that, on the access network, we can use OMNI ULAs
as the source and destination addresses of IPv6 ND messages to get them
to travel multiple hops before reaching an access router. For example, if
we had airplane A serving as a multihop relay for airplane B, which in turn
serves as a multihop relay for airplane C, etc. then the outermost airplane
can send its IPv6 ND messages with ULA addresses instead of LLA ones,
and the messages would travel over multiple (MANET) hops before
reaching the ultimate airplane that has a connection to the ground
access router.

This is really just MANET 101 - nothing special or fancy - it's just that we
would be bending the rules ever so slightly in making the (unencapsulated)
IPv6 ND messages travel multiple MANET hops before reaching the router.
But, since we have stateless translation between our ULAs and LLAs it
is trivial for the router to regard the message as if it came from the local
link. So yes, we will also look to update RFC4861. Does this make us bad
people? In my opinion, no; we are simply being ambitious and with good
intentions.

Thanks - Fred

> Best regards
> Zdenek Jaron