> draft-gont-taps-address-usage-problem-statement says > > This document analyzes the impact of a number of properties of IPv6 > addresses on areas such as security and privacy, and analyzes how > IPv6 addresses are curently generated and employed by different > operating systems and applications. Finally, it provides a problem > statement by identifying and analyzing gaps that prevent systems and > applications from fully-leveraging IPv6 addressing capabilities, > setting the basis for further work that could fill those gaps. > > I think the applicability of this work goes potentially far beyond TAPS as it > applies to any application's use of IPv6 addresses. I'm a little worried that > this wg doesn't contain sufficiently broad perspective to make > recommendations. Indeed, I see TAPS as a consumer of this doc more than > source of the recommendations. My opinion is that this is kind of out of > scope for our wg. I would support another group with the right expertise to > support it (maybe 6MAN or V6OPS). I think TAPS would provide some valuable > input but I don't think we should be the venue for it's development.
In 6man we have specifed how addresses are assigned to a link, different “types” of address and a set of properties that can be associated with an address (or prefix). E.g: - addresses have lifetimes, (but they can be ripped away from under you with little notice) - the choice of source address essentially chooses exit path in the network - addresses have different privacy properties. statically configured and in DNS, versus randomly generated changing every hour - addresses have different reachability, e.g. link-local, ULA and global. - an IPv6 interface can have many addresses of different properties assigned to it From a 6man perspective, that’s where our competency ends. We do not know how this should be exposed to applications or how the transport layers should deal with it. It might not be taps, but this is something we’d sorely want to punt up from the networking layer. Best regards, Ole 6man co-chair. _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
