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

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

Hi Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Thursday, December 01, 2016 11:47 AM
> To: Templin, Fred L <[e-mail]>; Lucy yong <[e-mail]>; Brian E Carpenter
> <[e-mail]>; [e-mail]
> Subject: Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels
> 
> 
> 
> On 12/1/2016 11:27 AM, Templin, Fred L wrote:
> > Hi Joe,
> >
> >> ...
> >>> 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.
> >> 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.
> > 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.
> 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.

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

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

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

> > ....
> >> It acts exactly like one NMBA link on which your endpoint has multiple
> >> virtual interfaces.
> > 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.
> 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.

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.

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

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.

> >  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.
> 
> 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
[e-mail]

> >>>> - 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.
> >>> The document size and number of revisions are irrelevant. By making it
> >>> 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.
> > 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?
> It wasn't a WG doc either.
>
> Yes, individua submissionl is another option.
> 
> Joe
>