Gorry, Good points. Or it could be repositioned to a statement from the Internet area to the upper layer working groups. “IPv6 Network layer addresses properties and behaviors, please be aware.”
To me at least there seems to be a disconnect. Address properties, selection and lifetimes are not dealt with well (if at all) by transport layer and application implementations. Cheers Ole > On 7 Aug 2018, at 17:26, Gorry Fairhurst <[email protected]> wrote: > > To me, this topic is tricky to position, and there are still multiple parts > across the two documents. > > One way could be to agree the properties of different address types on scope > and stability, devoid of API and Application-considerations - I at the > moment don't currently understand this enough to say if this is a new > statement about the network layer or is restating what has been said before, > so to me at least this seems to need network-layer clue. I see there may be > a network layer security concern that may drive some considerations (seems > more like that part is in > > > draft-gont-taps-address-analysis) > > . > > To answer the immediate question: I think this doesn't look like TAPS should > adopt that document. If this ID needs transport clue and spans multiple > transport protocols, that could be reviewed by TSVWG if this had already > strong support elsewhere? > > There is a mention of an API and usage concern. I haven't worked out if that > is transport guidance, or whether the required mechanisms actually resembles > PvD usage, and therefore looks more like a network-issue, (of course this is > without a need for signalling from the network to identify properties). > > Possibly there is also a need for a new API, and if that needs the IETF to do > new work, then to me that does look a lot like source address selection in > TAPS. There could be useful input here to a few paras in the TAPS > architecture. It's not clear to me that would require a new draft though in > TAPS to achieve this. > > Gorry > > On 07/08/2018, 12:59, Ole Troan wrote: >>> 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 > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
