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 _______________________________________________ Int-area mailing list Intemail@example.com https://www.ietf.org/mailman/listinfo/int-area