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
