Subject: RE: OMNI Interface - formal issues

From: "Jaron, Zdenek" <[email-masked]>
Date: Tue, 2 Jun 2020 15:39:52 +0000

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.

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

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

Best regards
Zdenek Jaron

---

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

Zdenek, see below for responses:

> -----Original Message-----
> From: Jaron, Zdenek [mailto:[email-masked]]
> Sent: Tuesday, June 02, 2020 8:40 AM
> To: Templin (US), Fred L <[email-masked]>; 6man WG <[email-masked]>
> Subject: RE: OMNI Interface - formal issues
> 
> Dear Fred

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

> 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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 3 Jun 2020 00:00:02 +0000

Zdenek, I went ahead and updated the document per our discussion, however I backed
down from recommending an update to RFC4861. RFC4861 requirements can be met
without any updates by applying ULA encapsulation to IPv6 ND messages that need to
travel multiple hops. If we instead applied ULA translation without encapsulation, we
would have to make major updates to RFC4861 - so I left that as a future exercise.

Please have a look and let me know your thoughts; a quick scan of the diffs should
show the changes:

Thanks - Fred

---
A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Transmission of IPv6 Packets over Overlay Multilink Network (OMNI) Interfaces
        Authors         : Fred L. Templin
                          Tony Whyman
	Filename        : draft-templin-6man-omni-interface-24.txt
	Pages           : 47
	Date            : 2020-06-02

Abstract:
   Mobile nodes (e.g., aircraft of various configurations, terrestrial
   vehicles, seagoing vessels, enterprise wireless devices, etc.)
   communicate with networked correspondents over multiple access
   network data links and configure mobile routers to connect end user
   networks.  A multilink interface specification is therefore needed
   for coordination with the network-based mobility service.  This
   document specifies the transmission of IPv6 packets over Overlay
   Multilink Network (OMNI) Interfaces.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-templin-6man-omni-interface/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-templin-6man-omni-interface-24
https://datatracker.ietf.org/doc/html/draft-templin-6man-omni-interface-24

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-templin-6man-omni-interface-24

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

> From: ipv6 [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
> Sent: Tuesday, June 02, 2020 9:33 AM
> To: Jaron, Zdenek <[email-masked]>; 6man WG <[email-masked]>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------