Sam Hartman wrote: >>>>>> "Keith" == Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> writes: > > Keith> It seems to me that the general problem is not multiple > Keith> interfaces, but multiple addresses per host. It doesn't > Keith> matter (much) whether those addresses result from multiple > Keith> physical interfaces, a combination of physical and virtual > Keith> network interfaces, multiple prefixes being advertised on > Keith> the network attached to any particular interface, or even a > Keith> mixture of v4 and v6. > > Keith> So that might have some impact on the name, particularly if > Keith> you want to attract the breadth of interests whom this > Keith> affects. Something like Hosts Addressed Multiply (HAM), > Keith> perhaps? > > > I'd actually appreciate focus on the multiple interfaces (or multiple > network providers) problem. I think that attacking this in full > generality is well beyond what we can manage. I think even a focused > problem may prove challenging. I certainly agree that it's challenging to attack the generalized version. However, if you try to solve each version of this problem separately, the result will be even more complex, less workable, and less realistic than if you try to look at it from a broader view. There's a strong potential for those different solutions to collide with one another. Or to put it another way, if you define a solution to a narrow version of the problem, it might not actually solve anything in the real world, and the WG's work will have been wasted. And from the POV of the application, or the transport layer, it really doesn't matter much _why_ the host (or peer) has multiple addresses - it still has to deal with them. As for whether "attacking this in full generality is well beyond what we can manage": Based on previous work that I have done in this area, I suspect that this is exactly the case. Which is why I think that it should be reasonable for the WG to look at the problem and come back and say "we haven't identified a good solution to this problem, and the best practices that we can recommend are to minimize the cases where a host or app has to deal with multiple addresses for itself or its peers". Of course, a better result would be for the WG to say "we recommend that the use of multiple addresses per host be limited to these specific cases, and avoided in other cases"... along with specific recommendations for networks, stacks, APIs, applications, etc. I think that this kind of output would be the most useful that the WG could produce. But it won't be able to produce a reasonable output if it looks at the problem through a narrow aperture. (Maybe this should really be in IRTF?) Keith _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf