Subject: [Taps] Fwd: IPv6 address usage problem statement?

From: Aaron Falk <[email-masked]>
Date: Tue, 13 Feb 2018 21:15:34 +0000

Are there folks in TAPS who want to discuss IPv6 address selection?
Fernando has a draft on the topic and is wondering if TAPS would be a good
home.

--aaron

---------- Forwarded message ---------
From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, Nov 27, 2017 at 8:50 AM
Subject: Fwd: IPv6 address usage problem statement?
To: <[email-masked]>
Cc: Fernando Gont <[email-masked]>

Dear TAPsters,

Fernando Gont is working on a draft with recommendations about address
selection, and 6MAN thought he should also be talking to people in TSV. I
offered to connect him with you folks, because it seems like this is part
of the transport selection problem that TAPS was chartered to work on, so
perhaps relevant to your work.

Could you let Fernando know how you'd like for him to proceed?

Thanks!

Spencer

---------- Forwarded message ----------
From: Fernando Gont <[email-masked]>
Date: Wed, Nov 22, 2017 at 6:24 PM
Subject: Re: IPv6 address usage problem statement?
To: Spencer Dawkins at IETF <[email-masked]>
Cc: "[email-masked]" <[email-masked]>

Hello, Spencer,

Thanks so much for your prompt response! Please find my comments in-line...

On 11/22/2017 06:38 AM, Spencer Dawkins at IETF wrote:
> Hi, Fernando,
>
> On Sat, Nov 18, 2017 at 9:17 PM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Folks,
>
>     I presented our document draft-gont-6man-address-usage-recommendations
>     at the 6man meeting during the IETF week in Singapore. During my
>     presentation, it was mentioned that the Transport area might be
>     interested in this work, too/alternatively. -- IIRC, somebody
mentioned
>     the TAPS wg, specifically.
>
>
> It's up to the working groups, of course, but TAPS is certainly a
> reasonable suggestion.
>
> TAPS was originally chartered to pay little or no attention to security,
> just to limit the scope of what was being investigated, but they've made
> enough progress that we're discussing an updated charter that will more
> clearly emphasize that investigating the security properties of
> transport protocols - which, if you write an application to the TAPS
> API, the API implementation would be making its own decisions about path
> selection as part of selecting transport protocols.
>
> IIUC, of course.
>
> Want me to contact the chairs, or let you?

I guess if you would that would be better.

Thanks so much!

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

-- 
--aaron

=====Short message from my phone=====

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 13 Feb 2018 15:04:17 -0800

Yes, I think this topic is very relevant to the work that can be done in updated transport APIs, specifically around Path Selection. This is relevant both for initial connection establishment (when we’re racing various transport protocols across different paths, we need to know which local addresses to use), and maintenance of connections that support migration or multipath (which addresses can they use for new flows). The address selection can also be inferred from other properties of the transport connection, such as how long-lived the connection needs to be.

Fernando, what’s your plan for your draft? It seems like a great reference for our drafts, and something we need to consider in our list of application preferences when creating transport connections.

Thanks,
Tommy

> On Feb 13, 2018, at 1:15 PM, Aaron Falk <[email-masked]> wrote:
> 
> Are there folks in TAPS who want to discuss IPv6 address selection?  Fernando has a draft on the topic and is wondering if TAPS would be a good home.
> 
> --aaron
> 
> From: Spencer Dawkins at IETF <[email-masked] <mailto:[email-masked]>>
> To: <[email-masked] <mailto:[email-masked]>>
> Cc: Fernando Gont <[email-masked] <mailto:[email-masked]>>
> 
> 
> Dear TAPsters,
> 
> Fernando Gont is working on a draft with recommendations about address selection, and 6MAN thought he should also be talking to people in TSV. I offered to connect him with you folks, because it seems like this is part of the transport selection problem that TAPS was chartered to work on, so perhaps relevant to your work.
> 
> From: Fernando Gont <[email-masked] <mailto:[email-masked]>>
> To: Spencer Dawkins at IETF <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> 
> 
> 
> Hello, Spencer,
> 
> > On Sat, Nov 18, 2017 at 9:17 PM, Fernando Gont <[email-masked] <mailto:[email-masked]>
> > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >
> >     Folks,
> >
> >     interested in this work, too/alternatively. -- IIRC, somebody mentioned
> e-mail: [email-masked] <mailto:[email-masked]>
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Fernando Gont <[email-masked]>
Date: Tue, 13 Feb 2018 20:15:35 -0300

Hello, Tommy,

On 02/13/2018 08:04 PM, Tommy Pauly wrote:
> Yes, I think this topic is very relevant to the work that can be done in
> updated transport APIs, specifically around Path Selection. This is
> relevant both for initial connection establishment (when we’re racing
> various transport protocols across different paths, we need to know
> which local addresses to use), and maintenance of connections that
> support migration or multipath (which addresses can they use for new
> flows). The address selection can also be inferred from other properties
> of the transport connection, such as how long-lived the connection needs
> to be.
> 
> Fernando, what’s your plan for your draft? It seems like a great
> reference for our drafts, and something we need to consider in our list
> of application preferences when creating transport connections.

Thanks so much for your comments!

I this work is of interest to the TAPS WG, we could try to move this one
forward in this wg, and also think of a subsequent I-D with
recommendations (more on this later).

Thoughts?

Thanks!

Cheers,

---

From: Erik Kline <[email-masked]>
Date: Tue, 13 Feb 2018 15:30:09 -0800

> recommendations (more on this later).

When it comes to "recommendations" I'm not in favor of the node-based
recommendations in the NOTE in section 7.3.  I think we should let
nodes create and use addresses as they see fit, and leave it to the
apps to figure out what they want to do (given the proper information
via useful APIs).

---

From: Fernando Gont <[email-masked]>
Date: Wed, 28 Feb 2018 03:31:35 -0300

On 02/13/2018 08:30 PM, Erik Kline wrote:
> recommendations in the NOTE in section 7.3. 

This document is moving away from making recommendations, and just
focusing on the problem statement.

We'll remove the "Note" you referenced.

> I think we should let

The above said (i.e., the note will be removed in the next rev of this
document), I think the "note" still gives control to the node to do what
it pleases -- it was suggesting configuration of profiles for different
types of networks (which would be a node-configuration setting, as
opposed to network-induced configuration)

Thoughts?

Thanks!

Best regards,

---

From: Erik Kline <[email-masked]>
Date: Wed, 28 Feb 2018 16:49:54 +0900

> opposed to network-induced configuration)

I think there's still a difference between having a node-wide policy
and enabling per-app policies.  The former could be used to
unnecessarily preclude the latter, and I think it's better to work
toward enabling choice in the apps.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 28 Feb 2018 09:52:50 -0300

> toward enabling choice in the apps.

I agree with that. However, there are scenarios in which, unfortunately,
you might need to limit application choice: some enterprise deployments
are known for that: disabling support for temporary addresses is a
widespread practice in such deployments.

How could one accommodate such deployments?  (ignoring them eventually
means that the network admins needs to figure out his own hack)

Thanks,

---

From: Erik Kline <[email-masked]>
Date: Thu, 1 Mar 2018 15:30:50 +0900

> means that the network admins needs to figure out his own hack)

Such deployments may well be going against the spirit of BCP 204.  If
so, I'm not sure I see much reason to further encourage such a thing.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 1 Mar 2018 07:51:34 +0100 (CET)

> means that the network admins needs to figure out his own hack)

In my discussion with people who have that requirement, I always advice 
them in the direction of prefix per host (/64). Most of the time they 
haven't even considered this option, but instead still think in terms of 
addresses and not prefixes. They still do not like the suggestion because 
it typically involves doing other tracking than via DHCP server logs.

Otoh when I ask them if they do BCP38 DHCP inspection to make sure people 
can't change addresses, I often get a negative answer. So it's often my 
conclusion that the whole tracking thing is a checkboxing requirement and 
not a hard requirement that means assurance that it's accurate.

-- 
Mikael Abrahamsson    email: [email-masked]