Subject: Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 1 Dec 2016 16:20:46 +0000

Hi Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Wednesday, November 30, 2016 4:52 PM
> To: Templin, Fred L <[email-masked]>; Lucy yong <[email-masked]>; Brian E Carpenter
> <[email-masked]>; [email-masked]
> Subject: Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels
> 
> 
> 
> On 11/30/2016 3:17 PM, Templin, Fred L wrote:
> > Hi Joe,
> >
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[email-masked]]
> >> Sent: Wednesday, November 30, 2016 2:32 PM
> >> To: Templin, Fred L <[email-masked]>; Lucy yong <[email-masked]>; Brian E Carpenter
> >> <[email-masked]>; [email-masked]
> >> Subject: Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels
> >>
> >> Hi, Fred (et al.),
> >>
> >>
> >> On 11/30/2016 12:51 PM, Templin, Fred L wrote:
> >>> Hi Joe,
> >>> ...
> >>> I didn't mention route optimization. With AERO, route optimization is what happens
> >>> when the tunnel ingress switches from an egress that is on a suboptimal path to a
> >>> different egress that is on a better path.
> >> That's internal to the tunnel itself, related to the fact that your
> >> tunnel is multipoint and treats all egresses as valid.
> >>
> >> That's another feature, but again it's hard to see where that would be
> >> discussed. It's closest in spirit to egress determination in BGP or
> >> LISP, and has no clear relation (AFAICT) to INTAREA (expertise or
> >> purview). However...
> > 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.

> >>> Due to the link nature of the NBMA overlay,
> >>> that switching is accomplished through the use of IPv6 ND Redirect messages the
> >>> same as would occur on a physical link (and in the same spirit as published in RFC6706).
> >> I don't think I would call that routing either when it happens in a
> >> regular network or inside an NMBA tunnel.
> > It is the moral equivalent of the Redirect function on physical links.
> It's the exact same thing. I agree it's useful, just not that it's routing.

It is a Redirect, yes, except that the Redirect is preceded by a Predirect
and the exchange is brokered through a trust anchor.

> > ....
> > 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.
That way, if there were an IP address assigned to the tunnel interface the
inner packets could use the same inner IP address even if the encapsulated
packets used different encapsulation IP addresses (e.g., with some going
out over a WiFi interface and others going out over a cellular interface).
This also gives rise to the possibility of asymmetric paths in the forward
and reverse directions - e.g., send packets out over the cellular interface
and receive packets back over the WiFi interface.

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

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

Thanks - Fred
[email-masked]

> Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 1 Dec 2016 08:32:38 -0800

On 12/1/2016 8:20 AM, Templin, Fred L wrote:
> ,,,

But is this safe outside of the AERO environment?

...

OK. We already have models for that - ethernet interfaces have multiple
addresses too.
> multiple link-layer addresses. RFC4861 is silent on whether this is permissible.

But my question is whether this requires something specific to AERO to
work or has generic utility even in the base Internet.

> 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

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 1 Dec 2016 17:02:18 +0000

Hi Joe,

> Sent: Thursday, December 01, 2016 8:33 AM

There needs to be a trust basis for the Redirect target to know that it can
accepted packets from the source's claimed IP addresses. In AERO, the
trust basis is the AERO link critical infrastructure elements including
Servers and Relays. Other link types would need to evaluate what sort
of trust basis is necessary for that particular link.

> OK. We already have models for that - ethernet interfaces have multiple

IP-over-Ethernet and other IP-over-(foo) docs don't talk about that, as far as I know.

> work or has generic utility even in the base Internet.

I don't know about utility outside of AERO. All I know is that there is
significant utility within AERO.

> I looked at a few of those, and they were mostly homed in tech-specific

IPv6 ND (RFC4861) was developed in an intarea wg (6man). It says that
IP-over-(foo) documents need to be written to tell how to adapt IPv6
ND to specific link types. AERO is an IP-over-(foo) document in exactly
the spirit called for by RFC4861, and by that virtue it would seem to be
aligned with intarea unless there were some consensus to form an
AERO working group. But, I don't see a need to form a new wg just to
get one doc published that just as easily could come out of
intarea itself.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Thu, 1 Dec 2016 10:21:29 -0800

Hi, Fred,

To wrap up:

- Subnet Redirects appear to rely on AERO-specific mechanisms, so would
not be of more general relevance to a bis doc IMO

- multiple link addresses are already part of the Ethernet spec and
already handled by most IP over Ethernet implementations (and TOS
marking correlation is defined in 802.1p).  When you assign more than
one link address to a single physical interface, you're acting as if you
have multiple links. At that point, the forwarding table indicates not
only the next-hop IP but the outgoing link -- for multiple link
addresses these are treated as different virtual interfaces already.

- I agree that IPv6 ND was done in an INTAREA WG; the same might be true
for AERO, but the INTAREA WG should be a place where generic aspects of
all Internet layer issues should be addressed, not domain-specific
solutions (IMO).

AERO might be one doc, but it is 60+ pages with over 70 revisions. I don't think it would be useful to bog down INTAREA with something that large.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 1 Dec 2016 18:35:58 +0000

Hi Joe,

> Sent: Thursday, December 01, 2016 10:21 AM

RFC6706 already specifies how these Redirects work and is agnostic to the
link type. AERO(bis) tells how they work on AERO links through use of the
IPv6 ND protocol on a specific link type.

> marking correlation is defined in 802.1p). 

I'd like to see what you are talking about so I can compare it to what
AERO is doing.

> When you assign more than
> have multiple links.

No, you are acting as if there are multiple link-layer addresses on the
same link.

> At that point, the forwarding table indicates not

Going with what I just said above, the forwarding table indicates only
the next-hop IP. It is the neighbor cache entry for the next-hop IP
that includes the multiple link-layer addresses. But, it is all one link.

> AERO might be one doc, but it is 60+ pages with over 70 revisions. I don't think it would be useful to bog down INTAREA with

The document size and number of revisions are irrelevant. By making it
an intarea doc, it would revert back to a -00.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Thu, 1 Dec 2016 11:07:37 -0800

> IPv6 ND protocol on a specific link type.
My point is that the IPv6 ND extension would not be of generic use on
other IPv6 nets because of the lack of endpoint authentication.

> I'd like to see what you are talking about so I can compare it to what
See below...
> that includes the multiple link-layer addresses. But, it is all one link.
It acts exactly like one NMBA link on which your endpoint has multiple
virtual interfaces.

> an intarea doc, it would revert back to a -00.

That helps only the number of revisions issue; the point is that the
work associated with this doc involves substantial effort for review.
Anything that intensive IMO should involve the commitment of creating a
BOF and WG as evidence there is sufficient interest.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 1 Dec 2016 19:27:03 +0000

Hi Joe,

> Sent: Thursday, December 01, 2016 11:08 AM

RFC6706 discusses security considerations that apply to any link type that
redirection can be used on - and, not just NBMA tunnel links. This is over
and above what RFC4861 discusses in terms of Redirection security, so
RFC6706 indicates methods for improving security.

> It acts exactly like one NMBA link on which your endpoint has multiple

This is from RFC4861:

     Inbound load balancing - Nodes with replicated interfaces may want
           to load balance the reception of incoming packets across
           multiple network interfaces on the same link.  Such nodes
           have multiple link-layer addresses assigned to the same
           interface.  For example, a single network driver could
           represent multiple network interface cards as a single
           logical interface having multiple link-layer addresses.

AERO is not talking about inbound load balancing, but it is talking about
a single logical interface having multiple link-layer addresses in exactly
the same spirit as implied by this text. But, by allowing multiple S/TLLAOs
on IPv6 ND messages, AERO nodes can tell their neighbors about their
multiple link-layer address and how they prefer to have those link-layer
addresses used for inbound traffic.

> work associated with this doc involves substantial effort for review.

RFC6706 was 33pages long, but was reviewed and approved in a relatively
short time and without going through a working group formation. Is there
some kind of page count cutoff I am not aware of?

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Thu, 1 Dec 2016 11:47:20 -0800

> RFC6706 indicates methods for improving security.
Such an update would need to be stand-alone, as a rev of 4861. It's one
thing to redirect a single address, but redirecting an entire subnet is
potentially more problematic.

Yes, buried in 6706 are the issues that might be in such a rev, but we
can't expect IPv6 ND implementers to dive into a large spec that has no
clear relation to IPv6 and doesn't update 4861 to find it. If there is a
way for this approach to be generally useful, it really needs to be in a
4861bis update.

> the same spirit as implied by this text.
Which is what I said - one link with multiple interfaces. The example
given explains that this can be done through interface virtualization,
which I also noted.

Whether you use them for input or output reasons is up to the forwarding
plane; it shouldn't be buried inside the tunnel mechanism. That's a flaw
of many other tunnel approaches. Tunnels should stop at the interface.

>  But, by allowing multiple S/TLLAOs

In my terminology, they affect the forwarding table. Sure.

> some kind of page count cutoff I am not aware of?
It wasn't a WG doc either.

Yes, individua submissionl is another option.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 1 Dec 2016 20:52:11 +0000

Hi Joe,

> Sent: Thursday, December 01, 2016 11:47 AM

Can you say why you think redirecting an entire subnet is potentially more
problematic (noting that RFC6706 has been published since 2012 and so the
notion of subnet redirection is already well known)?

> way for this approach to be generally useful, it really needs to be in a

Not an RFC4861bis, no, but possibly in a document that updates RFC4861.
Is that what you meant?

> given explains that this can be done through interface virtualization,

No, it agrees with what I said: "a single network driver could represent
multiple network interface cards as a single logical interface having multiple
link-layer addresses". One interface; multiple link-layer addresses; one link.

> of many other tunnel approaches.

I disagree with any implications of a flaw. There is one forwarding table entry,
but the neighbor cache entry has multiple link-layer addresses. So, IP forwarding
does its normal thing at the IP layer, but inside the interface the packet is
forwarded to the correct link-layer address of the neighbor among multiple
candidates at the sub-IP layer. I can demonstrate this in running code today.

> Tunnels should stop at the interface.

But they don't. Look at the way OpenVPN works.

> In my terminology, they affect the forwarding table. Sure.

They do not affect the forwarding table at the IP layer. The IP layer sees only
a single next-hop while the sub-IP layer gets to see the multiple link-layer
addresses in the neighbor cache entry.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Mon, 5 Dec 2016 13:24:33 -0800

Hi, Fred,

> notion of subnet redirection is already well known)?
6706 is within the context of authenticated origin.

It's a problem in the more general case where that's not known - e.g.,
where host redirect is already used.

> Is that what you meant
I was thinking of a single doc focused on the subnet redirect. That
could be in a 4861bis or a single doc that updates 4861, but should not
be a small part of a much larger doc that does many other things
concurrently IMO.

> ?
The only difference is whether you can use vanilla IP forwarding (to
pick the outgoing virtual interface) or need some sort of additional
mechanism (that allows multiple IP forwarding entries to use the same
interface and next-hop IP, but needs additional fields to differentiate
the L2 source/dest). With virtual interfaces, you can use existing code.

> candidates at the sub-IP layer. I can demonstrate this in running code today.
I agree this works, but you need your new code to accomplish this for
the very reason you cite.

If you treat these as different interfaces, then existing forwarding
code would have sufficed.

> But they don't. Look at the way OpenVPN works.
Not the poster child of how networking works, IMO.

> They do not affect the forwarding table at the IP layer. 

They should. You're effectively using a different link source/dest.

> The IP layer sees only
That's the flaw, IMO - it's not needed of you use VIFs (we demonstrated
this in the X-Bone).

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 5 Dec 2016 22:29:04 +0000

Hi Joe,

> Sent: Monday, December 05, 2016 1:25 PM

Yes, that is correct. And, RFC6706 applies to all link types that support
Redirection (i.e., and not just tunnel NBMA links).

> where host redirect is already used.

I don't understand the point you are trying to make here, but it
might not even matter. 

> be a small part of a much larger doc that does many other things

RFC6706 specifies subnet redirect for any link type that can support
ordinary Redirect. RFC6706(bis) updates that spec.

> the L2 source/dest). With virtual interfaces, you can use existing code.

To be completely clear, with AERO the tunnel interface itself (i.e., the
AERO interface) is the virtual interface. Within the AERO interface there
are one or more underlying interfaces (physical or virtual), with each
interface having one or more addresses. The underlying interface
addresses are seen as link-layer addresses of the AERO interface.

The AERO interface is the node's point of connection to the AERO link,
where the AERO link is the entire underlying network. The AERO
interface therefore has multiple link-layer addresses but it connects
to a single link. This is consistent with the link model for ISATAP which
was published as RFC4214/RFC5214.

With this model, the inner IP layer uses vanilla IP forwarding to pick
the (singular) AERO interface as the outgoing interface. Once inside
the AERO interface, the inner IP destination address is mapped to
the correct corresponding AERO interface neighbor cache entry,
then encapsulation is applied, and then the encapsulated packet
is shipped out the correct underlying interface.

> the very reason you cite.

All tunnel drivers have code that operates at the sub-IP layer, i.e., and not
just OpenVPN. Look at the linux kernel sit.c, ipip.c, ip_gre.c, etc. drivers, and
look at any apps that use the TUN/TAP interface. This code is not flawed.

> code would have sufficed.

Existing IP forwarding code does suffice with a single interface. It is the
same as on any multipoint interface (e.g., Ethernet).

> Not the poster child of how networking works, IMO.

It is not just OpenVPN, which was used as only one widely-deployed
example.

> They should. You're effectively using a different link source/dest.

I'm not sure if this statement is born from a misunderstanding of the
 AERO interface/link model or some kind of preconceived notions you
may have from some other context. But, it is one (virtual) interface
connected to one (virtual) link the same way as Ethernet has one
(physical) interface connected to one (physical) link.

> That's the flaw, IMO - it's not needed of you use VIFs (we demonstrated

Not adhering to the X-Bone model does not necessarily constitute a flaw.
Otherwise, if X-Bone were the measuring stick pretty much all widely
deployed tunneling solutions would be considered flawed.

I would ask you to go through the AERO spec and tell me what you think
is broken. And, a dissimilarity with X-Bone does not necessarily mean
that something is broken.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Mon, 5 Dec 2016 14:46:37 -0800

> Redirection (i.e., and not just tunnel NBMA links).

It requires AERO tunneling, though - it doesn't apply to other sorts of
IPv6 links, tunneled or not.

> I don't understand the point you are trying to make here, but it
6706 proposes to use the redirect where source authentication is
available - notably within AERO. When that's not available (which is the
typical case for most IPv6 fabrics), subnet redirect becomes an
efficient attack vector.

> ordinary Redirect. RFC6706(bis) updates that spec.
See above; if it does so on links that don't use AERO tunnels (and thus
source authentication), then it's a big security hazard.

> is shipped out the correct underlying interface.
IP forwarding is supposed to pick outgoing interface and next-hop *IP*.
The neighbor cache is supposed to map next-hop IP to L2, but if it does
just that it has no way to differentiate packets (e.g., based on QOS).

The only solution using this (ISATAP) model is to have another instance
of IP QOS forwarding happen inside the interface too, so different QOS
can have different mappings.

That's why I think this model is incorrect. The simpler approach
considers each L2 encapsulation as a separate (virtual) interface to the
IP forwarding. In that case, the (one) IP forwarding can pick different
outgoing interfaces (with different or similar next-hop IPs), which
result in different encapsulations.

> look at any apps that use the TUN/TAP interface. This code is not flawed.

They should not have IP forwarding mechanisms in that code.

> same as on any multipoint interface (e.g., Ethernet).
Multipoint interfaces don't generally allow different encapsulations for
the same destination IP address.
(I claim that those that do aren't multipoint interfaces; they're hack
implementations of multiple interfaces as if they were one).

...
> (physical) interface connected to one (physical) link.
An ethernet interface has one "dest IP" -> "dest L2" map entry.
When you have multiple dest L2s for the same dest IP, you are doing IP
routing (IMO incorrectly) inside the link layer.

> Not adhering to the X-Bone model does not necessarily constitute a flaw.
Of course, but you should consider that the tunnel doc that has taken
years to converge is largely based on the X-Bone's model.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Dec 2016 18:19:29 +0000

Hi Joe,

> Sent: Monday, December 05, 2016 2:47 PM

No it doesn't require AERO tunneling - as is said many times over in RFC6706,
it can be applied to any link type which can use the ordinary Redirect function
and can provide sufficient trust basis. Ethernet is an example link type where
RFC6706 can be applied.

> typical case for most IPv6 fabrics), subnet redirect becomes an

RFC6706 expects a trusted intermediate router so that Redirects cannot
be spoofed. But again, that trust basis can be established on any link
type (e.g., Ethernet) and not just tunnels.

> source authentication), then it's a big security hazard.

Not true. On a campus Ethernet, if the source and destination can both
trust an intermediate router then there is a trust basis for the exchange
of Predirect/Redirect messages. The attack vector is spoofed Predirect
and Redirect messages, but the trusted intermediate router eliminates
the attack vector. Again, RFC6706 can be used on any link type.

> just that it has no way to differentiate packets (e.g., based on QOS).

In linux at least, there is a "Route to Interface" capability. For example,
"send all packets with destination covered by 2001:db8::/32 to interface
aero0". The interface then gets to decide what to do with them, and
exactly as you say the neighbor cache maps the next-hop IP to L2.

> can have different mappings.

QoS-base traffic engineering  is accommodated within the AERO interface.
Also mobility management, security, etc. It works, and I have the code to
prove it.

> result in different encapsulations.

AERO works, Joe. Just because it doesn't look like X-Bone does not
make it flawed.

> They should not have IP forwarding mechanisms in that code.

They can do anything they want inside the interface. Pick the packet up,
twirl it around, bounce it off the wall, etc. etc. As long as it eventually
gets encapsulated and shipped off to the correct L2.

> years to converge is largely based on the X-Bone's model.

Joe, I am sorry if the AERO model offends you - perhaps because it differs
from X-Bone. But, that does not make it wrong. Besides, aren't there any
number of other existing and emerging tunnel types (e.g., LISP) that don't
look exactly like X-Bone? 

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Tue, 6 Dec 2016 10:38:41 -0800

> and can provide sufficient trust basis. Ethernet is an example link type where
We're going in circles. AERO provides the authenticated origin. Most
other IPv6 environments do not. So this isn't a generic mechanism. It
applies only where authenticated origin info is available.

> type (e.g., Ethernet) and not just tunnels.
Agreed - CAN be  but typically is not.

> the attack vector. Again, RFC6706 can be used on any link type.
That supports trusted sources of such messages. On a campus ethernet,
that would require per-packet source authentication which is expensive.
...
> exactly as you say the neighbor cache maps the next-hop IP to L2.
Yes, on Linux there is code that implements a workaround to the fact
that you could - and IMO should - have used separate virtual interfaces.

> Also mobility management, security, etc. It works, and I have the code to

I'm not debating whether you CAN solve it this way, but whether you
SHOULD (and whether you even need to).

> AERO works, Joe. Just because it doesn't look like X-Bone does not
The X-Bone works too, and didn't need any of that specialized code
above. That's why I consider the AERO approach to be flawed - it
requires IP routing at a layer that is below IP. That cannot be
correctly integrated with all the other things happening at the main IP
forwarding layer in AERO - but can (and was) in the X-Bone.

> gets encapsulated and shipped off to the correct L2.
They CAN, but IMO they should not. Doing IP forwarding inside an
interface has the potential to interfere (or at least not be integrated
with) primary IP forwarding (that picked that interface).

...

> look exactly like X-Bone? 
There's a long list. One of the earliest was the fact that IPsec tunnel
mode buried IP forwarding inside as well - which is why we wrote
RFC3884. Another is the need for two layers of encapsulation to do
tunnels completely. That model is bourne out of a set of capabilities
that none of the current systems - AERO, LISP, etc. - support, all of
which the X-Bone supported nearly 20 years ago - without needing any of
the related "hacks" of replicating IP forwarding anywhere new.

I think AERO adds a few useful things - a better frag/reassembly
mechanism and security - to conventional IP-in-IP or even most other
IP-in-X-in-IP tunnels, but I do not consider it a complete network model.

But we can have the rest of that discussion off--list. We're fall afield
of the origin of this thread.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Dec 2016 19:04:09 +0000

Hi Joe,

> Sent: Tuesday, December 06, 2016 10:39 AM

On link types where the L2 source address cannot be spoofed, all it requires
is testing the L2 source address against a list of approved L2 source addresses.
This is needed even on links that support mechanisms like IEEE802.1x, since
otherwise there could be an insider attack. 

This same attack vector could be a matter of concern for even regular
host-based Redirection, by the way. The only reason AERO takes greater
pains to do message origin authentication is that the attack surface is
larger for redirection of an entire subnet than it is for redirection of
a singleton IP address.

> Agreed - CAN be  but typically is not.

The point is that the mechanism can be applied generically to any link type.

> that would require per-packet source authentication which is expensive.

The source authentication is simply checking the L2 source against a list
of known trusted L2 sources. That is not very expensive.

> SHOULD (and whether you even need to).

But, AERO DOES solve it this way.

> above.

Has X-Bone carried forward into modern implementations?

> That's why I consider the AERO approach to be flawed - it

I think you are concerned for no good reason, Joe. IP forwarding still
works exactly the way it always has while AERO does its thing at the
sub-IP layer.

> with) primary IP forwarding (that picked that interface).

IP forwarding picks the interface in exactly the way it is supposed to,
and the interface does the rest at the sub-IP layer. There is no potential
for interference.

> IP-in-X-in-IP tunnels, but I do not consider it a complete network model.

Again, Joe, I am sorry if you don't like it but there is nothing lacking or broken.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Tue, 6 Dec 2016 11:10:33 -0800

Fred,

First, we are violently agreeing that subnet redirect works only where
source addresses cannot be spoofed. The problem is that this is not the
typical case, so it's not a generic solution IMO.

On the general architecture point:

> Has X-Bone carried forward into modern implementations?
Its model for IPsec transport + IPIP tunnels is used in commercial routers.

It doesn't require new code anywhere, though - it has been compatible
with OS-X, FreeBSD, and Linux for nearly 20 years.

And its model is the basis of the tunnel draft.

We can continue to do things the hard way, needing new code and
mechanism, or the easy way that does not. I prefer the easy way.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Dec 2016 19:31:11 +0000

Hi Joe,

> Sent: Tuesday, December 06, 2016 11:11 AM

The same can be said about ordinary host-based Redirect (only works where
the source address cannot be spoofed). The only difference is the attack
surface is larger for subnet redirection which is why RFC6706 does the
due diligence of supporting data origin authentication.

Again, this is to defeat "insider" attacks. In environments where insider
attacks are not a matter of concern, then there is not even a need for
data origin authentication.

> Its model for IPsec transport + IPIP tunnels is used in commercial routers.

ISATAP is in commercial routers and widely deployed host implementations
too. Go to any Windows host , open a command window and type "ipconfig"
and you will see an ISATAP interface. (The code is also in linux.)

> mechanism, or the easy way that does not. I prefer the easy way.

AERO uses the NBMA tunnel virtual link model meaning that IPv6 ND works
the same as for an NBMA physical link. The model supports traffic engineering,
multi-homing, route optimization, fault tolerance, mobility management and
security. Do you have a solution for these that does not require new code?

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Tue, 6 Dec 2016 11:35:30 -0800

> due diligence of supporting data origin authentication.
Because the attack surface is larger is the reason it's an issue.

...
> security. Do you have a solution for these that does not require new code?

I already mentioned it - existing IP forwarding with virtual L2
interfaces. The existing IP forwarding supports TE, multihoming, route
optimization, etc - all without any new code.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Dec 2016 20:45:50 +0000

Hi Joe,

> Sent: Tuesday, December 06, 2016 11:36 AM

It's not an "issue" because a mitigation is provided. The mitigation is needed
only on links that may be subject to insider attacks - the same can be said
about standard host Redirects.

> optimization, etc - all without any new code.

I am talking about traffic engineering in terms of selecting one or more underlying
interfaces in the both the outbond and inbound directions. Take for example a
hypothetical cellphone that keeps both the 4G and WiFi links active at the same
time. TE should be able to steer some messages out the 4G interface and others
out the WiFi interface - say, texts over 4G and http over WiFi. In the inbound
direction,  I am talking about allowing the node to tell the network how to deliver
its inbound traffic. It is also possible to have asymmetry where outbound packets
going out over interface A and inbound packets coming in over interface B. And
then, I am also talking about the possibility of packet replication with duplicate
copies sent out one over the WiFi and the other over the 4G.

I am talking about multihoming in terms of having the singular tunnel virtual
interface configured over multiple underlying physical or virtual interfaces.
You can employ traffic engineering over the underlying interfaces as I
mentioned above, and you can change over from interface A to interface
B if interface A goes down.

I am talking about route optimization in terms of eliminating extraneous
doglegs from the path so that packets going from A->B->C can travel
directly from A->C instead.

And, I am talking about mobility and mobile networks in a way that is better than
Mobile IP. You didn't mention that in your list perhaps because you know that
mobility requires extra code. In AERO, a mobility event is what happens when
the IP address of an underlying interface changes. And, the AERO node simply
informs its neighbors of the L2 address change by sending IPv6 ND unsolicited
Neighbor Advertisements the same as for any link.

I am not talking about anything different than IPv6 ND and DHCPv6 messaging
over an ordinary IP link because those are the only mechanisms that are used.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Tue, 6 Dec 2016 12:58:38 -0800

> about standard host Redirects.

A standard host Redirect affects only one host. This affects the entire
subnet and needs better protection - which isn't always available.

> interfaces in the both the outbond and inbound directions. 
Sure - the problem is that you have two different TEs running:
  
- the main IP forwarding TE that picks the interface
- the intra-interface forwarding that picks the L2 encaps

That means the main TE is basically blind to the TE over the subnet.

If you do this with separate L2 VIFs, the main TE can pick the VIF itself.

Everything you want can be done by the main IP forwarding engine -
including ECMP.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Dec 2016 21:18:37 +0000

Hi Joe,

> Sent: Tuesday, December 06, 2016 12:59 PM

That is what I said - several times. And, that is why RFC6706 specifies
mitigations for links where insider attacks may be a concern. For other
links, it could be that no mitigations are necessary.

The due diligence of RFC6706 is a matter that I think should be appreciated
and not scorned.

> - the main IP forwarding TE that picks the interface

The main IP forwarding code will always pick the (singular) areo0 interface.

> - the intra-interface forwarding that picks the L2 encaps

Yes.

> That means the main TE is basically blind to the TE over the subnet.

So what?

> If you do this with separate L2 VIFs, the main TE can pick the VIF itself.

The interface does the right thing.

> Everything you want can be done by the main IP forwarding engine -

You didn't address the point about mobility, nor the other points I raised.
Are you aware of a mobility solution that requires no supporting code?

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Tue, 6 Dec 2016 13:28:27 -0800

Fred,

...
> The due diligence of RFC6706 is a matter that I think should be appreciated

I never scorned it; I just said that it's not complete.

If this is to be a generally useful mechanism, it needs to come out of
the AERO spec and be described as a direct extension to IPv6 ND
redirects, but that requires a much more detailed discussion of the
security requirements and how they can be achieved in existing IPv6
deployments.

> The main IP forwarding code will always pick the (singular) areo0 interface.
If there are multiple interfaces, why would it pick aero0? And what
would its QoS be? It can't have a single value, so the main IP
forwarding code can't decide between aero0 and other interfaces.

>> That means the main TE is basically blind to the TE over the subnet.
That means you potentially have two TEs fighting each other. I

> The interface does the right thing.
The interface can only do the right thing with the traffic it has
already been given by the main IP forwarder. It can't collaborate with
that forwarder.

> Are you aware of a mobility solution that requires no supporting code?
The other cases are either handled by existing IP forwarding or require
exactly the same amount of mechanism inside the IP forwarder that you
implement in the interface instead (e.g., for mobility and dogleg
redirection).

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 6 Dec 2016 13:37:24 -0800

Hi, Fred,

I'm encouraging you to pull this out of AERO and submit it as a separate
doc. I don't think it will gain acceptance as part of the larger spec;
most people won't see it as independently useful or won't find it at
all, IMO.

However, as part of a separate doc, you need to explain more carefully
the conditions under which it can be safe to use. I don't think assuming
source addresses are valid is a reasonable requirement; that requires
that every port on a LAN have that filtering. There needs to be some
other way to ensure that the message comes from a valid source, and
should rely on as few new protocols as possible.

FYI.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Dec 2016 21:46:47 +0000

Hi Joe,

> Sent: Tuesday, December 06, 2016 1:28 PM

RFC6706 has thoroughly discussed the threat model and provides effective
mitigations. It is therefore complete.

> forwarding code can't decide between aero0 and other interfaces.

The IP forwarding table has an entry such as:

  2001:db8::/32 -> aero0

Meaning that any IPv6 packet with a destination that matches 2001:db8::/32
*and for which no more-specific route exists* goes out interface aero0
unconditionally. The packet will have a TOS value, and it is that TOS that
guides the aero0 interface on how to portion traffic over the underlying
interfaces.

> That means you potentially have two TEs fighting each other. I

There is no fight if the IP layer has only one outbound interface alternative.

> already been given by the main IP forwarder. It can't collaborate with

No, the AERO interface doesn't need to collaborate with the IP layer. All
it does is looks at the packet's TOS value and uses that to select one or
more outbound underlying interfaces.

> implement in the interface instead (e.g., for mobility and dogleg

AERO mobility management and route optimization are better than existing
approaches. That is why the aviation and corporate mobile device communities
are looking at it.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Dec 2016 21:52:02 +0000

Hi Joe,

> Sent: Tuesday, December 06, 2016 1:37 PM
> To: Templin, Fred L <[email-masked]>
> Cc: [email-masked]
> Subject: regarding subnet redirects
> 
> Hi, Fred,
> 

Understand what you are saying, and I see the point. Can this be done
in such a way as to not block the AERO spec from going forward, however? 

> should rely on as few new protocols as possible.

There are certainly environments where source addresses cannot be
spoofed and so checking the source address is an option. Another
idea that is in AERO(bis) but not in RFC6706 is for the Predirect to
include a Nonce that the target has to echo back in the corresponding
Redirect. The source can then accept the Redirect only if it came from
a legitimate target.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Tue, 6 Dec 2016 13:59:02 -0800

> approaches. That is why the aviation and corporate mobile device communities
Perhaps, but by putting all the mechanisms in a single system you're
saying "buy it all or go away". If your solutions to each of these
issues is that great, why not demonstrate its utility in a more general
setting?

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 6 Dec 2016 13:59:06 -0800

> guides the aero0 interface on how to portion traffic over the underlying
The problem is that this makes it impossible for the IP forwarding table
to control which aero0 encaps is used, thus which QoS it gets.

I.e., the main IP forwarding can't take QoS into account. I understand
that Aero can do the right thing, but only with the packets it already
has. It can't say "oh, I don't have a QOS for that, let me give it back
to the main IP forwarding for another interface".

If you have only one link, sure - there's no problem. But if you have
more than one (which is much more typical, even for hosts), then you do.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 6 Dec 2016 14:02:13 -0800

Hi, Fred,

> in such a way as to not block the AERO spec from going forward, however? 
Why not?

Sure, they might be coupled in the pubs queue, but AFAICT the separate
items are more likely to go more quickly and can go first anyway.

This applies to all the parts of Aero - IMO, it's better to demonstrate
them as more generally useful. That goes for the frag/reassembly tunnel
shim layer, this redirect, mobilty, etc.

That doesn't mean you can't still try to move the integrated system
forward, but then the question is whether that is just a system that
uses the individual pieces or really has some other, overarching
components. (IMO, that's the difficulty with the doc where this
discussion started - AFAICT, that relies on components but doesn't
explain the overarching part).

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Dec 2016 22:43:50 +0000

Hi Joe,

I am looking at multilink nodes like manned aircraft and unmanned aerial vehicles that
may have many active aviation data links, e.g., SATCOM, LDACS, 4G, AeroMACS etc.
The links will be either available or unavailable at various phases of flight. But, AERO
lays down a single IP layer interface (the aero0 interface) so that the aviation data
links are seen as underlying interfaces each having one or more addresses. These
underlying addresses are then seen as the L2 addresses for the AERO interface.

Underlying interfaces may come up and go down dynamically during a flight, and their
addresses may change dynamically, e.g., if they hand over from cell tower A to cell
tower B. It is AERO's job to take care of any mobility related links and always keep
neighbors informed of the current L2 addresses and availability. But, it all still looks
like a single interface (aero0) to the IP layer.

Thanks - Fred

From: Joe Touch [mailto:[email-masked]]
Sent: Tuesday, December 06, 2016 1:59 PM
To: Templin, Fred L <[email-masked]>; Lucy yong <[email-masked]>; Brian E Carpenter <[email-masked]>; [email-masked]
Subject: Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels

  2001:db8::/32 -> aero0

interfaces.

The problem is that this makes it impossible for the IP forwarding table to control which aero0 encaps is used, thus which QoS it gets.

I.e., the main IP forwarding can't take QoS into account. I understand that Aero can do the right thing, but only with the packets it already has. It can't say "oh, I don't have a QOS for that, let me give it back to the main IP forwarding for another interface".

If you have only one link, sure - there's no problem. But if you have more than one (which is much more typical, even for hosts), then you do.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Dec 2016 22:46:50 +0000

Hi Joe,

> Sent: Tuesday, December 06, 2016 2:02 PM
> Subject: Re: regarding subnet redirects
> 
> Hi, Fred,
> 
> 

All valuable suggestions, thank you. Let me think more about it.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Tue, 6 Dec 2016 14:47:48 -0800

> underlying addresses are then seen as the L2 addresses for the AERO

You can accomplish the same thing using virtual interfaces using dynamic
routing. See the following:
J. Touch, T. Faber, “Dynamic Host Routing for Production Use of
Developmental Networks <http://www.isi.edu/touch/pubs/icnp97/>,” in
/Proc. ICNP ’97/, Atlanta, Oct. 1997, pp. 285-292.

> tower B. It is AERO’s job to take care of any mobility related links
> and always keep
>
You can do the same thing using IP forwarding without needing to bury
the forwarding decisions inside the link.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Dec 2016 23:39:12 +0000

Hi Joe,

The areas I described are very much wrapped around mobility, and for AERO
mobility is handled through dynamic neighbor cache updates over the AERO
interface. It is very important that these mobility events do not get propagated
into dynamic routing protocols like OSPF, which would clobber low data rate
data links like LDACS and many varieties of SATCOM. Dynamic neighbor cache
updates in the same manner as described in RFC4861 are the method employed
by AERO.

Thanks - Fred

From: Joe Touch [mailto:[email-masked]]
Sent: Tuesday, December 06, 2016 2:48 PM
To: Templin, Fred L <[email-masked]>; Lucy yong <[email-masked]>; Brian E Carpenter <[email-masked]>; [email-masked]
Subject: Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels

You can accomplish the same thing using virtual interfaces using dynamic routing. See the following:
J. Touch, T. Faber, "Dynamic Host Routing for Production Use of Developmental Networks<http://www.isi.edu/touch/pubs/icnp97/>," in Proc. ICNP '97, Atlanta, Oct. 1997, pp. 285-292.

You can do the same thing using IP forwarding without needing to bury the forwarding decisions inside the link.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 6 Dec 2016 15:42:30 -0800

> updates in the same manner as described in RFC4861 are the method employed

Those can be integrated easily into updates to the IP forwarding table.
That need not propagate to other nodes, and the update can be via any
routing protocol you want (Aero's or otherwise).

The primary benefit of integration into existing IP forwarding is that
you CAN propagate these if you want, and you CAN integrate the impact of
those updates into IP forwarding decisions. If you have only one link,
that doesn't matter - but it does otherwise.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 7 Dec 2016 16:57:26 +0000

Hi Joe,

AERO was designed to accommodate the orchestration of multiple data links with
dynamically changing properties (cost, performance, availability, mobility, etc.)
while allowing the mobile node to maintain a stable and unchanging IP address
or prefix. Mobile hosts assign a stable and unchanging IP address to the aero0
interface, while mobile routers leave the AERO interface unnumbered and
maintain a stable and unchanging IP prefix that can be used to number
downstream-attached networks and hosts. Again, sorry if you don't like it
but we are finding that this path meets our requirements while honoring
the "tunnels as links" architecture.

One thing to clarify again - AERO is not a routing protocol; it is simply an
adaptation of IPv6 ND on a specific link type, i.e., the AERO link. RFC4861
says that specific link types are to document the operation of IPv6 ND in
IP-over-(foo) documents. AERO is an IP-over-(foo) document.

Thanks - Fred

From: Joe Touch [mailto:[email-masked]]
Sent: Tuesday, December 06, 2016 3:43 PM
To: Templin, Fred L <[email-masked]>; Lucy yong <[email-masked]>; Brian E Carpenter <[email-masked]>; [email-masked]
Subject: Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels

Those can be integrated easily into updates to the IP forwarding table. That need not propagate to other nodes, and the update can be via any routing protocol you want (Aero's or otherwise).

The primary benefit of integration into existing IP forwarding is that you CAN propagate these if you want, and you CAN integrate the impact of those updates into IP forwarding decisions. If you have only one link, that doesn't matter - but it does otherwise.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Sat, 10 Dec 2016 00:25:14 +0000

Hi Joe,

I read your document and, for the applications I am concerned with, I still
think what I am doing is the better approach. One thing that you may not
have gathered is that the AERO interface does not maintain a replicated copy
of the entire IP forwarding table; it only keeps neighbor cache entries for its
currently active sets of neighbors. For AERO Clients, this would include the
default router(s) and any peers that it has recently received Redirects from.
For AERO Servers, the neighbor cache would include entries for the current
list of associated Clients. So, the AERO interface is not a full-blown IP router;
it is a neighbor discovery engine for its active set of neighbors.

So, unlike a dynamic routing protocol the AERO interface uses IPv6 Neighbor
Unreachability Detection (NUD) instead of routing protocol keepalives to
maintain reachability. There is also no routing protocol control messaging
going out over the underlying data links - it is simply data packets plus
occasional NUD messages.

I noticed that your document was from 1997, which is the same year I
started with SRI International. I think that was right around the time
you and I first met.

Thanks - Fred

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 9 Dec 2016 20:53:10 -0800

Fred,

On 12/9/2016 4:25 PM, Templin, Fred L wrote:
> of the entire IP forwarding table;
>
I wasn't assuming it did - therein lies the problem.

> it only keeps neighbor cache entries for its
>

But it would need to have the full-blown IP forwarding capabilities to
determine which next IP address is intended for a given packet handed to
it by the master IP forwarding table.

> going out over the underlying data links – it is simply data packets plus
>
> occasional NUD messages.
>
That only describes how the table is populated. There's the further
issue of how the table is indexed, which is a full-blown forwarding
lookup (with policy information as well).

> started with SRI International. I think that was right around the time

Not sure - it was presented in early 1997 at the GBN workshop at
Infocom, but also at a few DARPA PI meetings before.

FWIW, I didn't think we met until the IETF, which was in Dec in DC that
same year.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 12 Dec 2016 16:00:36 +0000

Hi Joe,

Whatever. You seem to keep implying that there are problems, but I can assure
you there are none. Why not have a look at the document, because I think you
will find the answers to your questions there.

Thanks - Fred

From: Joe Touch [mailto:[email-masked]]
Sent: Friday, December 09, 2016 8:53 PM
To: Templin, Fred L <[email-masked]>; Lucy yong <[email-masked]>; Brian E Carpenter <[email-masked]>; [email-masked]
Subject: Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels

Fred,

But it would need to have the full-blown IP forwarding capabilities to determine which next IP address is intended for a given packet handed to it by the master IP forwarding table.

That only describes how the table is populated. There's the further issue of how the table is indexed, which is a full-blown forwarding lookup (with policy information as well).

Not sure - it was presented in early 1997 at the GBN workshop at Infocom, but also at a few DARPA PI meetings before.

FWIW, I didn't think we met until the IETF, which was in Dec in DC that same year.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Dec 2016 11:17:23 -0800

Fred,

The question is not (yet) whether there are problems. The question is
whether a new solution is required where existing mechanisms suffice.

Your doc has only one paragraph that describes anything close to a use
case, but doesn't explain why AERO is *needed* to solve that case.

I.e., I've repeatedly looked and still don't find the answers there.

Joe

On 12/12/2016 8:00 AM, Templin, Fred L wrote:
> *From:*Joe Touch [mailto:[email-masked]]
> *Sent:* Friday, December 09, 2016 8:53 PM
> *To:* Templin, Fred L <[email-masked]>; Lucy yong
> <[email-masked]>; Brian E Carpenter
> *Subject:* Re: [Int-area] Some thoughts on
> draft-yong-intarea-inter-sites-over-tunnels
>
>  
>
> Fred,
>
>  
>
> determine which next IP address is intended for a given packet handed
> to it by the master IP forwarding table.
>
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 12 Dec 2016 19:37:15 +0000

Hi Joe,

The problem is, you continue to imply that there are problems. Unless you are willing
to read the document, cut it out.

About use cases, I think I said this before but here are three:

-          Corporate Mobile VPN users (cellphones, tablets, laptops, etc.)

-          Civil aviation networking

-          Unmanned Air Systems

That is only to name three. If you need more, let me know.

Thanks - Fred

From: Joe Touch [mailto:[email-masked]]
Sent: Monday, December 12, 2016 11:17 AM
To: Templin, Fred L <[email-masked]>; Lucy yong <[email-masked]>; Brian E Carpenter <[email-masked]>; [email-masked]
Subject: Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels

Fred,

The question is not (yet) whether there are problems. The question is whether a new solution is required where existing mechanisms suffice.

Your doc has only one paragraph that describes anything close to a use case, but doesn't explain why AERO is *needed* to solve that case.

Joe

Thanks - Fred

From: Joe Touch [mailto:[email-masked]]
Sent: Friday, December 09, 2016 8:53 PM
To: Templin, Fred L <[email-masked]><mailto:[email-masked]>; Lucy yong <[email-masked]><mailto:[email-masked]>; Brian E Carpenter <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels

Fred,

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 14 Dec 2016 00:50:05 +0000

Joe,

You specifically asked about how next-hop determination is done, and
as is said in the document this is the role of the AERO address. So if the
destination address is something like 2001:db8:1:2::1 then the next-hop
address is simply fe80::2001db8:1:2 (i.e., a link-local address with the
prefix of the destination in the interface identifier). So, next-hop
determination is stateless and requires no message exchanges.
Do you see a problem with that?

Thanks - Fred

From: Int-area [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Monday, December 12, 2016 11:37 AM
To: Joe Touch <[email-masked]>; Lucy yong <[email-masked]>; Brian E Carpenter <[email-masked]>; [email-masked]
Subject: Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels

Hi Joe,

-          Unmanned Air Systems

Thanks - Fred

From: Joe Touch [mailto:[email-masked]]
Sent: Monday, December 12, 2016 11:17 AM
To: Templin, Fred L <[email-masked]<mailto:[email-masked]>>; Lucy yong <[email-masked]<mailto:[email-masked]>>; Brian E Carpenter <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels

Fred,

Joe

Thanks - Fred

Fred,

Joe