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

[Joe Touch <[e-mail]>]

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.

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.


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

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

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