On 12/1/2016 8:20 AM, Templin, Fred L wrote: > ,,, >>> It is the same as the way the Redirect function works on physical links, >>> except >>> that the Redirect applies to an entire network prefix and not just a >>> singleton >>> address. This has already been published in RFC6706, and what we are now >>> specifying is essentially RFC6706(bis). >> OK, then the bis doc might fall within INTAREA (though I would think it >> could be very hazardous to allow a redirect to apply to an entire >> prefix! - isn't that an attack vector?) > It is secure, because there is a trust anchor (the AERO Server) that is > trusted by > both AERO Clients (the source and target) and the Clients will only accept the > Redirection if it comes through the Server. The difference is that the source > Client has to solicit a Redirect by first sending what is called a > "Predirect". The > Predirect lets the target Client know that source is authorized to source > packets > from its claimed prefix, and the target Client returns a Redirect. When the > source > Client gets the predirect, it knows that the target Client is prepared to > accept its > packets via the direct path not including the Server. This basic behavior is > already > discussed in RFC6706, but we are seeking to (bis) that work now.
But is this safe outside of the AERO environment? > > >>> .... >>> The AERO interface is an NBMA interface where the ingress sees all potential >>> egresses as potential "neighbors". >> Isn't that true for all multipoint links? >> >>> An AERO interface that is configured over >>> multiple underlying interfaces would appear to have multiple link-layer >>> addresses. Each link-layer address can have a different set of TOS-based >>> priorities so that the AERO interface can specify to its neighbors as to >>> which link-layer address to use for which class of traffic. >> That just means you have a tunnel model that allows one instance to >> represent multiple tunnels (or tunnel interfaces). That's fine, but >> seems local to the definition of the tunnel. > No, it is one tunnel interface with potentially multiple link-layer addresses. ... OK. We already have models for that - ethernet interfaces have multiple addresses too. >>> >From an IPv6 neighbor discovery standpoint, this is realized by allowing >>> >IPv6 ND >>> messages to include multiple S/TLLAOs - one for each underlying interface. >>> Each >>> S/TLLAO has a set of TOS-based priorities allowing neighbors to select the >>> best >>> underlying interface for the given packet TOS. This is described in Section >>> 3.5 >>> of the document. I can demonstrate how this works in actual running code >>> over a webex if you would like. >> I understand the principle, but you're describing a feature of the >> tunnel mechanism that seems based largely on applying existing IP >> capability inside the tunnel. > What I am describing is an augmentation of IPv6 neighbor discovery where ND > messages can carry multiple S/TLLAOs and the neighbor cache entries can have > multiple link-layer addresses. RFC4861 is silent on whether this is > permissible. > AERO makes it explicit. But my question is whether this requires something specific to AERO to work or has generic utility even in the base Internet. > >>>>>> I'm not claiming this wouldn't be useful. I'm saying that we need to >>>>>> know what problem it solves to know where to home it. >>>>> I have identified two very important use cases relating to aviation. >>>> You've defined a customer, IMO - which is great, but short of taking >>>> this to an aerospace forum, it doesn't really help me understand where >>>> in the IETF it should be discussed. >>> It is being proposed to the International Civil Aviation Organization (ICAO) >>> where standards are being established for the future civil aviation data >>> communications architecture. >> Sure, so it sounds like a standard there and a de-facto one within the >> IETF (e.g., individual informational). > ICAO is not a community of network and computing equipment engineers > and researchers in the same way as the IETF is. There is no one in ICAO > who can serve as an RFC Editor for a standard that would be based on > AERO or any other network technology. There is no one in ICAO who > can build reference implementations and/or establish rough consensus > among the network and computing equipment community. ICAO looks > to the IETF for Internetworking standards. > >> I haven't seen a case yet as to why INTAREA should adopt it per se... > Everything we have talked about above relates to a specific link layer model > for tunnels (NBMA) and is manifested as an "IP-over-(foo)" document much > in the same spirit as for IP-over-Ethernet, IP-over-FDDI, IP-over-ATM, etc. > That seems like an Intarea consideration to me. I looked at a few of those, and they were mostly homed in tech-specific WGs, not in INTAREA. Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
