RE: OMNI Interface - formal issues

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

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/

> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Templin (US), Fred L
> Sent: Tuesday, June 02, 2020 9:33 AM
> To: Jaron, Zdenek <[e-mail]>; 6man WG <[e-mail]>
> Subject: RE: OMNI Interface - formal issues
> 
> 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
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------