Subject: [Taps] Progress on address usage documents

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Aug 2018 10:58:44 +0200

Folks,

There has been some discussion over time about

* draft-gont-taps-address-usage-problem-statement
* draft-gont-taps-address-analysis

The former describes problems we're facing nowaadys as a result of
limited APIs, whereas the second discuss different properties of
addresses, hopefully shedding some light on how we could make a better
usage of the available addreses.

Chairs: Do you think it would be reasonable to poll the wg for adoption
of these two documents?

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Aaron Falk" <[email-masked]>
Date: Mon, 06 Aug 2018 16:02:11 -0400

Hi Fernando-

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.

If the working group speaks up, I can be persuaded otherwise.

--aaron

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Aug 2018 22:51:50 +0200

On 08/06/2018 10:02 PM, Aaron Falk wrote:
>     statement by identifying and analyzing gaps that prevent systems and
> make recommendations. 

FWIW, these doc don't try to make recommendations, but rather discuss
the topic. Me, I see your point. Although, based on recent discussions
on the taps list, it seems folks are willing to e.g. make
decisions/recommendations regarding e.g. how to use addresses by default.

> Indeed, I see TAPS as a consumer of this doc more

FWIW, I brought this to taps upon suggestion I got on 6man...

Thanks!

CHeers,

---

From: Ole Troan <[email-masked]>
Date: Tue, 7 Aug 2018 13:59:34 +0200

> 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.

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 07 Aug 2018 16:26:53 +0100

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:
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Ole Troan <[email-masked]>
Date: Tue, 7 Aug 2018 18:09:34 +0200

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-masked]> 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
> 
> 
> 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
>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Aug 2018 18:26:43 +0200

Hello, Gorry,

>  draft-gont-taps-address-analysis)

For the most part, address types are specified, but there's not much
guidance on how to use them. Depending on the perspective, I guess one
might argue that guidance should come from internet area (6man for the
ipv6 specific case, and intarea for ipv4... or even both).

>From another POV, this sees to be related with TAPs. If you hve an api,
there's not much you will be able to do (at least in a proper way :-) ),
without appropriate guidance.

> that is transport guidance, 

That's mostly a problem statement: we don't have appropriate APIs to
fully leverage IPv6 addressing.

[....]
> draft though in TAPS to achieve this.

Could you please rovide a reference to the document so that I can take a
look and review?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Aug 2018 18:27:37 +0200

> 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. 

FWIW, that's my take as well.

Thanks,

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 07 Aug 2018 10:00:58 -0700

> On Aug 7, 2018, at 9:26 AM, Fernando Gont <[email-masked]> wrote:
> 
> Hello, Gorry,
> 

The GitHub for the documents is:

https://github.com/taps-api/drafts

https://taps-api.github.io/drafts/draft-ietf-taps-arch.html
https://taps-api.github.io/drafts/draft-ietf-taps-interface.html
https://taps-api.github.io/drafts/draft-ietf-taps-impl.html

I imagine that we could have a *brief* mention in the architecture, but more importantly provide a path selection property in the Interface/API document, with an implementation considerations section in the Implementation document. Having an internet area draft to refer to from the API specification would be useful.

Tommy

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 07 Aug 2018 18:04:32 +0100

On 07/08/2018, 18:00, Tommy Pauly wrote:
>
>> On Aug 7, 2018, at 9:26 AM, Fernando Gont<[email-masked]>  wrote:
>>
>> Hello, Gorry,
>>
> I imagine that we could have a *brief* mention in the architecture,
To be clear - this is what I had in mind, that we ensure we mention that 
source interface selection is something that the arch can handle - 
whether it be by properties, or the way security expectations are 
satisfied, the available PvDs etc. But nothing much.
> but more importantly provide a path selection property in the Interface/API document, with an implementation considerations section in the Implementation document. Having an internet area draft to refer to from the API specification would be useful.
A little here also could make sense.

Gorry

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Aug 2018 19:11:48 +0200

> https://taps-api.github.io/drafts/draft-ietf-taps-impl.html

Will review and send comments. Thanks!

> I imagine that we could have a *brief* mention in the architecture, but more importantly provide a path selection property in the Interface/API document> with an implementation considerations section in the Implementation
document. Having an internet area draft to refer to from the API
specification would be useful.

One of the questions is: where to pursue this?

Thanks,