Subject: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC

From: [email-masked]
Date: Sun, 20 Sep 2015 11:00:02 -0700

The working group last call for this draft announced last week
continues for another week.  Please feel free to comment on it.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 21 Sep 2015 15:38:44 +0200

I agree with the recommendation: in case DHCP is used then deliver more
than just one address to the Host.

My last comment is: if a prefix is delivered with DHCP-PD then how does
the Host form an address out of it?

Alex

Le 20/09/2015 20:00, [email-masked] a écrit :
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 21 Sep 2015 15:46:52 +0200 (CEST)

> the Host form an address out of it?

Well, that's up to the host.

If it gets a /64, null route that /64, then it could configure an 
additional loopback address with a /96 and start adding IPv6 addresses to 
that /96, and then use those for outgoing communication.

It might be that there is a need for some kind of recommendation document 
in this area, because I think it's not obvious to all implementors how to 
do this. I have historically advocated to not have a WAN IPv6 address but 
instead just use PD to home gateways, and the amount of opposition I have 
had on this proposal is quite substantial, so I think it might make sense 
to give out recommendation in this area, how to handle a delegated prefix 
when you do not have an IPv6 GUA/ULA address on the interface wherefrom 
you received the delegation.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 21 Sep 2015 15:55:16 +0200

Mikael,

I agree that it is up to the Host how to make that address, and how to 
set it on its (virtual) interfaces.  Even simple things like forming an 
IID and pasting it along the prefix are not specified other than for 
SLAAC.  It might be they deserve making into a recommendation.

Alex

Le 21/09/2015 15:46, Mikael Abrahamsson a écrit :
>> My last comment is: if a prefix is delivered with DHCP-PD then how
>> does the Host form an address out of it?
>
> additional loopback address with a /96 and start adding IPv6 addresses
> to that /96, and then use those for outgoing communication.
>
> It might be that there is a need for some kind of recommendation
> document in this area, because I think it's not obvious to all
> implementors how to do this. I have historically advocated to not have a
> WAN IPv6 address but instead just use PD to home gateways, and the
> amount of opposition I have had on this proposal is quite substantial,
> so I think it might make sense to give out recommendation in this area,
> how to handle a delegated prefix when you do not have an IPv6 GUA/ULA
> address on the interface wherefrom you received the delegation.
>

---

From: Erik Kline <[email-masked]>
Date: Mon, 21 Sep 2015 22:55:03 +0900

On 21 September 2015 at 22:46, Mikael Abrahamsson <[email-masked]> wrote:
> If it gets a /64, null route that /64, then it could configure an additional
> loopback address with a /96 and start adding IPv6 addresses to that /96, and
> then use those for outgoing communication.
>
> It might be that there is a need for some kind of recommendation document in
> this area, because I think it's not obvious to all implementors how to do
> this. I have historically advocated to not have a WAN IPv6 address but
> had on this proposal is quite substantial, so I think it might make sense to
> give out recommendation in this area, how to handle a delegated prefix when
> you do not have an IPv6 GUA/ULA address on the interface wherefrom you
> received the delegation.

I wouldn't support any one methodology, but I do think that perhaps
it's important to say what requirements any chosen methodology would
have to meet.

For example, the node would clearly not have to perform DAD for any
address it creates within the prefix by the usual method of sending
packets off-host and detecting conflicts.  However, it might be
important to perform some sort of node-local DAD if there are multiple
VMs amongst which the host is bridging the received prefix.

It's not immediately clear to me if such discussion is purely
operational, or if it might stray into 6man territory.

---

From: Mark Smith <[email-masked]>
Date: Tue, 22 Sep 2015 18:50:52 +1000

Hi Alex,

> the Host form an address out of it?

One way it can be implemented is that the host is conceptually
considered a 'one-armed' router, and the delegated prefix/delegated
prefix addresses are present on an internal virtual interface, with
routing/forwarding occurring between the external/internal interfaces.
The addresses on the internal virtual interface would then preferred
as source/destination addresses by the host (for the purposes of
address selection, including announcing/advertising for referral
purposes) over the address(es) present on the host's single physical
interface.

Strictly that means that all traffic from the host has been forwarded
one hop as it leaves the host, as it conceptually originated from the
internal virtual interface, and then was forwarded/routed onto the
physical interface. The Hop Count should be decremented for this
internal to external hop, however it probably isn't necessary to and
worthwhile not doing so. Similarly in theory the hop count should be
decremented when the host forwards the packets it receives from the
external interface to the internal virtual interface, before
delivering them to the upper layers.

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 22 Sep 2015 11:03:08 +0200 (CEST)

> one hop as it leaves the host, as it conceptually originated from the

Sounds to me that this is just an incarnation of the weak host model, and 
I haven't heard anyone state that TTL should be decremented in that 
scenario?

---

From: Mark Smith <[email-masked]>
Date: Tue, 22 Sep 2015 22:50:30 +1000

On 22 September 2015 at 19:03, Mikael Abrahamsson <[email-masked]> wrote:
> Sounds to me that this is just an incarnation of the weak host model, and I
> haven't heard anyone state that TTL should be decremented in that scenario?
>

I've never been completely sure whether IPv6 supports the weak or
strong host model, or whether it is possible for a host/implementation
to be one or the other.

I find RFC4291 a bit confusing in this regard:

"IPv6 addresses of all types are assigned to interfaces, not nodes.
   An IPv6 unicast address refers to a single interface.  Since each
   interface belongs to a single node, any of that node's interfaces'
   unicast addresses may be used as an identifier for the node."

This seems to be fundamentally saying weak host model, however the
strong statement about addresses being assigned to interfaces not
nodes suggests strong host model.

II think it would be good for there to be an explicit statement about
IPv6 hosts being strong or weak host model or supporting either host
model, if one doesn't already exist that I'm aware of, just to remove
any ambiguity.

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 22 Sep 2015 15:22:30 +0200 (CEST)

On Tue, 22 Sep 2015, Mark Smith wrote:

> I've never been completely sure whether IPv6 supports the weak or strong 
> host model, or whether it is possible for a host/implementation to be 
> one or the other.

I'd say a bit of both.

I find that systems that will respond to an arp query for its eth1 address 
and the arp request comes in on eth0 to be fundamentally broken. Some 
people do not agree. From this aspect, I'd say my take is that IPv6 uses 
the strong hos model.

However, most hosts will glady send out traffic sourced from eth0 IPv6 
address via eth1, if that happens to be the best default route for the 
node, indicating weak host model.

With hosts implementing MIF, I hope most things will be strong host model 
only.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 22 Sep 2015 14:08:27 +0000

> I find that systems that will respond to an arp query for its eth1 address and
> the arp request comes in on eth0 to be fundamentally broken. Some people
> do not agree. From this aspect, I'd say my take is that IPv6 uses the strong
> hos model.
> 
> address via eth1, if that happens to be the best default route for the node,
> indicating weak host model.
> 

RFC 7084 requires (requirements copied below) CE routers to support the weak host model. Extensive discussion around the creation of these requirements suggested that anything trying to use an address from an assigned PD to originate and respond to messages across its WAN interface would have to use the weak model. Actually attaching one of these addresses to the WAN interface is strictly forbidden by some RFC (I can't remember which). So the address is attached to a LAN or internal interface.
Barbara

   WAA-7:   If the IPv6 CE router does not acquire a global IPv6
            address(es) from either SLAAC or DHCPv6, then it MUST create
            a global IPv6 address(es) from its delegated prefix(es) and
            configure those on one of its internal virtual network
            interfaces, unless configured to require a global IPv6
            address on the WAN interface.
   
   WAA-9:   As a router, the IPv6 CE router MUST follow the weak host
            (Weak End System) model [RFC1122].  When originating packets
            from an interface, it will use a source address from another
            one of its interfaces if the outgoing interface does not
            have an address of suitable scope.

---

From: David Farmer <[email-masked]>
Date: Tue, 22 Sep 2015 12:43:54 -0500

>            have an address of suitable scope.

Just like IPv4, IPv6 the protocol itself is neither weak or strong, or both weak and strong, depending on your point of view.  The point being that it's the "weak or strong host model" it's a property of the host not of the protocol (IPv4 or IPv6) itself, in general IPv6 hosts can be weak or strong, some situations and address types dictate to one extent or another one behavior or the other.  

But it's more complicated than just simple weak or strong host model though, primarily because IPv6 supports multiple addresses per-interface, and it's even normally expected there will be multiple addresses in most cases, then combined that with multiple interfaces and the potential for multiple default routes, then things get complicated quick.

I think this draft should probably note that if the DHCPv6-PD option discussed is used some form of IPv6 router requirements will apply to the host, beyond just the normal host requirements for IPv6.  In other words, it's not just as simple as host requesting a /64 and going on it mary way.

Thanks.
-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

---

From: 神明達哉 <[email-masked]>
Date: Tue, 22 Sep 2015 11:20:36 -0700

(I guess this is already off-topic from discussions on
host-addr-availability draft, so we may want to change the subject if
this subtopic continues)

At Tue, 22 Sep 2015 15:22:30 +0200 (CEST),

> people do not agree. From this aspect, I'd say my take is that IPv6 uses

The IPv6 counterpart of this example is Neighbor Discovery.  And I
believe it's already pretty clear that ND adopts the strong host
model.  But that does not necessarily mean IPv6 in general uses the strong
host model, and I thought we basically only talks about more general
cases in this context.  So I suspect the case about ARP/ND is not a
good example to draw the conclusion.

I vaguely recall this topic was discussed very long time ago.  A quick
google gave me this link:
http://www.ietf.org/ietf-ftp/ipngwg/ipngwg-minutes-96dec.txt
(nearly 20 years ago!)
which says:

  Concludes that unicast SHOULD use weak model, but with
  source-address selection rules that ensure that source address
  differs from origination interface address only in unusual
  circumstances, e.g., when responding to a ping of a receive-only
  interface.
  ...
  Noted that the weak model is "less weak" in IPv6 than in IPv4 --
  even in the weak model, must not violate IPv6 address scope
  constraints (link-local, site-local).  However, this does *not* mean
  that source and destination addresses must have the same scope, and
  Deering recommended not adopting such an unnecessary constraint.
  ...
  Strong support for weak addressing model with strong scoping rules.

I don't remember if this is the very latest consensus on this topic
though.

Regarding whether this is explicitly documented somewhere, I don't
really remember, but I think RFC4007 (if implicitly) reflects the
sense of the "less weak" model.  RFC6724 also implicates we allow the
weak model (otherwise it would say "MUST use outgoing interface"
instead of "Prefer outgoing interface").

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 23 Sep 2015 11:05:16 +0200

Hi,

Regarding the models, and M. Abrahamsson comments on this topic earlier.

Le 22/09/2015 20:20, 神明達哉 a écrit :
> At Tue, 22 Sep 2015 15:22:30 +0200 (CEST), Mikael Abrahamsson
> <[email-masked]> wrote:
>
>>> I've never been completely sure whether IPv6 supports the weak
>>> or strong host model, or whether it is possible for a
>>> host/implementation to be one or the other.
>>
>> I'd say a bit of both.
>>
>> I find that systems that will respond to an arp query for its eth1
>> address and the arp request comes in on eth0 to be fundamentally
>> broken. Some people do not agree. From this aspect, I'd say my
>> take is that IPv6 uses the strong hos model.
>
> model.

I think there are use-cases where ND follows a stricter model than other
use-cases.

For example, an NA containing a MAC address in the target link-layer
address different than the one in Ethernet header src address (aka proxy
ND) can be qualified as a very weak model, if I understand correctly.

But, an RA containing a prefix of a link of another interface on same
Router, instead of the on-link prefix, is probably just a weak model.

(are there strong/weak Router models?)

Alex

> But that does not necessarily mean IPv6 in general uses the strong
> I vaguely recall this topic was discussed very long time ago.  A
> quick google gave me this link:
> http://www.ietf.org/ietf-ftp/ipngwg/ipngwg-minutes-96dec.txt (nearly
> 20 years ago!) which says:
>
> interface. ... Noted that the weak model is "less weak" in IPv6 than
> in IPv4 -- even in the weak model, must not violate IPv6 address
> scope constraints (link-local, site-local).  However, this does *not*
> mean that source and destination addresses must have the same scope,
> and Deering recommended not adopting such an unnecessary constraint.
> ... Strong support for weak addressing model with strong scoping
> rules.
>
> -- JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Thu, 24 Sep 2015 11:18:30 +1000

>> I've never been completely sure whether IPv6 supports the weak or strong
host model, or whether it is possible for a host/implementation to be one
or the other.
> I find that systems that will respond to an arp query for its eth1
address and the arp request comes in on eth0 to be fundamentally broken.
Some people do not agree. From this aspect, I'd say my take is that IPv6
uses the strong hos model.

I agree, and I think it is probably because I first got exposed to
multi-address issues on routers, and they followed the strong "host" model.
Addresses are assigned to interfaces, and if the interface goes down or is
taken down, the associated addresses become unavailable. I find that very
intuitive because the address state follows the interface state.

only.

OTOH, if an interface suffers a transient fault, should all of the sockets
that are using the interface's addresses be immediately destroyed? I'd say
no, but that then means the weak host model is the better and more robust
one.

Actually, this has reminded me of probably what I'd prefer on hosts. Weak
host model by default, meaning addresses and associated sockets survive
transient link faults, strong host model if interfaces are administratively
taken down, so addresses and associated sockets disappear when intended by
an operator or process.

I think this starts to uncover two different behaviours behind the strong
and weak host models:

- is an address still available for a host to use/listen to if the
interface the address is associated with goes down and/or is taken down
administratively?

- if the address is still available when the associated interface is down,
should packets using that address be routed out other interfaces, or should
they be dropped.

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 24 Sep 2015 06:42:52 +0200 (CEST)

On Thu, 24 Sep 2015, Mark Smith wrote:

> OTOH, if an interface suffers a transient fault, should all of the 
> sockets that are using the interface's addresses be immediately 
> destroyed? I'd say no, but that then means the weak host model is the 
> better and more robust one.

I brought this up on the IETF TCP lists a few years back, that there 
should be some kind of analysis of this. For instance, if I know that an 
interface will always give me a new IP address, I would like to configure 
my connection manager to kill all TCP sessions that terminate on IP 
addresses on that interface. It's not going to be a transient error, 
because if that interface goes down, those IP addresses are gone forever.

> Actually, this has reminded me of probably what I'd prefer on hosts. 
> Weak host model by default, meaning addresses and associated sockets 
> survive transient link faults, strong host model if interfaces are 
> administratively taken down, so addresses and associated sockets 
> disappear when intended by an operator or process.

Because of BCP38, using the weak model doesn't really work, and anyhow, 
how are you going to get the packets there if the interface is down?

> - if the address is still available when the associated interface is 
> down, should packets using that address be routed out other interfaces, 
> or should they be dropped.

Most of the time, you won't be able to get packets back (if the interface 
is down) so making sure you can send out the packets is of limited 
practical use.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 24 Sep 2015 13:45:35 +0900

> because if that interface goes down, those IP addresses are gone forever.

That's certainly what Android does.

https://android.googlesource.com/platform/system/netd/+/master/server/NetlinkHandler.cpp#80

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Sep 2015 22:00:13 -0700

Hi, all,

Catching up...

> strong host model, or whether it is possible for a host/implementation

Hosts are generally weak at the IP layer (whether v4 or v6) and strong
at the Ethernet layer.

However, strong/weak deals with two assumptions:

	1) the addresses are bound
		i.e., if an interface goes *down*, then neither
		model will preserve a connection bound to that
		address

	2) strong/weak focuses on incoming messages
		the rules for setting the source address of
		outgoing messages *whose source address is absent*
		are different, e.g., RFC1122 gives rules
		in which routes select an outgoing interface
		then that interface's IP address is used
		as the source

		none of these apply when both source is
		already set; in that case, AFAICT strong model
		layers/hosts need to send the message out the
		matching interface whereas weak model/layers
		might allow other behaviors

IPv4, IPv6, and Ethernet all support multiple addresses per interface,
FWIW. I don't see that as incompatible with either the strong or weak
model, except that the set of addresses associated with a single
interface is - by definition - weak within that set, but strong is
usually a per-interface concept anyway and thus does not apply within
the set of addresses for an interface.

Joe

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 24 Sep 2015 07:58:35 +0200 (CEST)

> https://android.googlesource.com/platform/system/netd/+/master/server/NetlinkHandler.cpp#80

I got shot down pretty well when I suggested this, good that someone 
agrees with me anyway. They kept suggesting that I should use TCP 
keepalives instead, but over for instance mobile, that would be really bad 
for battery life.

Generally I think it's better to fail early and then instead let upper 
layers handle the reconnections. Having TCP timeouts in tens of minutes or 
even hours isn't really useful for most uses of the network nowadays. Most 
things that users do are interactive and if it hasn't happened in 10 
seconds, most users will give up anyway.

Also, failing more often would mean the upper level application developers 
would be more often exposed to errors and they'd make sure that they could 
handle it properly.

Mosh (https://mosh.mit.edu/) is still pretty much ideal kind of 
interactive experience for me, I would really like more things to work 
like it, at least the ones that required interactivity.

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Sep 2015 13:33:35 -0700

On 9/23/2015 10:58 PM, Mikael Abrahamsson wrote:
> keepalives instead, but over for instance mobile, that would be really
> bad for battery life.

There are two separate issues:

1) shutting down an app that isn't making progress

2) cleaning up TCP state

#1 can be done at the app layer; some apps don't do much if the
connection is dead, whereas others do. that's for the app to decide.

#2 isn't needed unless the OS needs to reclaim memory consumed with idle
TCP states; more often, that TCP state is cleaned up when a new
connection starts that uses the same socket pair.

TCP keepalives are a way for an app to force a TCP connection to either
stay up or die when a path might go down. They can be important when the
path might go down even though the local network interface remains up.
E.g., your WIFI works fine but your cable modem dropped the connection
to your service provider.

There's no panacea, though - the decision on whether to try to keep an
app up or let it fail when a path dies depends on the app.

Joe

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 25 Sep 2015 07:14:35 +0200 (CEST)

> connection starts that uses the same socket pair.

I don't understand your reasoning here.

What is the use to keep any TCP connection that is anchored at an IP 
address that we know won't come back? (and yes we know, because the 
connection manager has been told this by policy)

> app up or let it fail when a path dies depends on the app.

We're not talking about a path here, we're talking about an interface IP 
address that went away and won't come back.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 25 Sep 2015 14:36:51 +0900

On Fri, Sep 25, 2015 at 2:14 PM, Mikael Abrahamsson <[email-masked]>
wrote:

> There's no panacea, though - the decision on whether to try to keep an app
>> up or let it fail when a path dies depends on the app.
>>
>

I think the point is that you don't know whether it will come back without
the ability to predict the future. For example, if you lose link on a wifi
network but then 30 seconds later roam into coverage again, you may be able
to reuse the same addresses you had before.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 25 Sep 2015 08:37:59 +0200 (CEST)

> to reuse the same addresses you had before.

For some interfaces this is true, for some it's not.

If I *know* with 99.999% certainty (because the DHCP pool is pretty large 
in my mobile operator) that when the PDP context goes down, when it's 
brought up again, I will not get the same address again, why on earth 
wouldn't I just immediately invalidate all TCP connections anchored at 
that address, when the mobile interface goes down?

So my point here is that yes, if you're looking at a solution that needs 
to work for everything, then the prudent path is the classic path, just 
let it stay until someone decides it shouldn't, and let's have hours of 
timeouts.

But for some interfaces, this just isn't true anymore, so why don't we use 
that information and give the users a better experience?

Also, punting this to the application developers without giving them a 
general framework to work with is just not realistic... and the POSIX 
socket interface hasn't seen any development for 10+ years as far as I can 
tell, not in any significant manner that can even get close to what Apple 
and Google are offering their respective application developers.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 25 Sep 2015 15:40:12 +0900

On Fri, Sep 25, 2015 at 3:37 PM, Mikael Abrahamsson <[email-masked]>
wrote:

> to work for everything, then the prudent path is the classic path, just let
> it stay until someone decides it shouldn't, and let's have hours of
> timeouts.
>

To be clear: I'm not saying that TCP sockets should stay alive when their
IP address goes away. I think that's a bad plan, because it causes apps to
get stuck. Particular in mobile networks, I don't know if any popular OSes
do it.

---

From: Joe Touch <[email-masked]>
Date: Fri, 25 Sep 2015 10:25:54 -0700

On 9/24/2015 10:14 PM, Mikael Abrahamsson wrote:
>> #2 isn't needed unless the OS needs to reclaim memory consumed with
>> idle TCP states; more often, that TCP state is cleaned up when a new

I'm talking about the TCP protocol spec, which does not *require* a
mechanism to take down the state of an idle connection unless keepalives
are used. The TCP spec is based on the principle that old connections
are taken down only when new events occur - e.g., the next time you want
to send a packet and it fails because the interface is down.

> address that went away and won't come back.

You can't possibly know that.

If you want to declare "if it's gone more than 4 minutes then it's not
coming back", then you really want a keepalive with a 4-minute timeout.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 25 Sep 2015 10:28:53 -0700

On 9/24/2015 11:37 PM, Mikael Abrahamsson wrote:
...
> If I *know* with 99.999% certainty (because the DHCP pool is pretty
> large in my mobile operator) that when the PDP context goes down, when
> it's brought up again, I will not get the same address again, why on
> earth wouldn't I just immediately invalidate all TCP connections
> anchored at that address, when the mobile interface goes down?

You can, as an implementer, make that decision.

The TCP spec does not *require* you to do so, nor should it. The only
time TCP requires that state be taken down for a dead connection is when
the connection is known dead by a failed attempt to send a new message.

> But for some interfaces, this just isn't true anymore, so why don't we
> use that information and give the users a better experience?
> 
> socket interface hasn't seen any development for 10+ years as far as I
> can tell, not in any significant manner that can even get close to what
> Apple and Google are offering their respective application developers.

If you want an implementation to take down connections when the
interface disappears, that's fine.

It should not be part of a spec. And yes, I think the specification of
an abstract API *is* part of a spec (e.g., RFC793 does specify one).

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 25 Sep 2015 10:34:03 -0700

On 9/24/2015 11:40 PM, Lorenzo Colitti wrote:
> On Fri, Sep 25, 2015 at 3:37 PM, Mikael Abrahamsson <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     So my point here is that yes, if you're looking at a solution that
>     needs to work for everything, then the prudent path is the classic
>     path, just let it stay until someone decides it shouldn't, and let's
>     have hours of timeouts.
> 
> To be clear: I'm not saying that TCP sockets should stay alive when
> their IP address goes away.

This goes to the key point:

	an OS socket is an OS issue

	TCP uses the term "socket" to refer to the IP address/port pair,
	i.e., a connection is defined by a socket pair. TCP sockets
	might be mapped to OS sockets (e.g., using the Unix bind()
	call), but they don't have a direct correlation.

*TCP* sockets don't go up or down; they're just a pair of values.

Interfaces go up or down, sockets are created or destroyed, etc. The
impact of those events on TCP is not specified by TCP.

TCP connection state persists during idle - there's no inherent
mechanism in TCP to "clean up" -- it always waits until a new packet
needs to go out to decide what to do. When the packet fails to transmit,
only then does TCP decide to clean up state. The same is true for when
an OS socket disappears - *TCP* does not dictate that the TCP state
disappear at the same time.

An *implementation* can do otherwise for many reasons, e.g., to reclaim
valuable memory or to force a connection down by edict.

Joe

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 25 Sep 2015 19:46:45 +0200 (CEST)

> the connection is known dead by a failed attempt to send a new message.

So here we again have the problem that most of the IETF protocol groups do 
not have an "*ops" group that actually deals with real world interaction. 
v6ops seems to be one of the few. Why don't we have more of them?

Where is the "TCP ops" WG that could actually take real world scenarios 
and give guidance to implementors?

> an abstract API *is* part of a spec (e.g., RFC793 does specify one).

So this is the problem, protocol spec meets real world. Where do I discuss 
this in the IETF? Obviously not in the TCP working groups, because there 
are only people who deal in abstracts and theory there, not practical 
implementation issues.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 26 Sep 2015 02:48:51 +0900

> valuable memory or to force a connection down by edict.

... or to avoid apps staying blocked in read calls for tens of seconds, or
even minutes, on connections that are extremely unlikely to ever become
usable again.

---

From: Joe Touch <[email-masked]>
Date: Fri, 25 Sep 2015 11:28:39 -0700

On 9/25/2015 10:46 AM, Mikael Abrahamsson wrote:
> So here we again have the problem that most of the IETF protocol groups
> do not have an "*ops" group that actually deals with real world
> interaction. v6ops seems to be one of the few. Why don't we have more of
> them?
> 

Well, I might blame the IETF for so heavily discounting the need to
document abstract APIs for so many years. That appears to be getting
better, esp. with things like the TAPS WG.

> So this is the problem, protocol spec meets real world. Where do I
> discuss this in the IETF? Obviously not in the TCP working groups,
> because there are only people who deal in abstracts and theory there,
> not practical implementation issues.

Actually, they would help deal with both, or at least would be a place
to start. There are many RFCs from TCPM, TSVWG, etc. that have dealt
with implementation issues - they tend to be documented as BCPs.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 25 Sep 2015 18:35:22 +0000

Hi, giving end user devices a /64 (or shorter) using DHCPv6 PD has been specified
by AERO for a long time now. There is now also running code that does this:

https://mailarchive.ietf.org/arch/msg/int-area/4Pqp6NYZIkBYn5xZILN7kQQqDHU

Once the end user device gets the /64, it can configure as many addresses as it
likes and assign them to a host interface so that IP forwarding need not even be
enabled because DHCPv6 PD occurs over the AERO interface and not the host
interface.

The AERO implementation works in conjunction with the excellent kea DHCPv6
server from ISC. Kea now supports all of the standard DHCPv6 mechanisms
needed by AERO and the kea team has been very responsive to incorporating
new features.

Thanks - Fred
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Fri, 25 Sep 2015 14:18:42 -0700

On 9/25/2015 10:48 AM, Lorenzo Colitti wrote:
> On Sat, Sep 26, 2015 at 2:34 AM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> ... or to avoid apps staying blocked in read calls for tens of seconds,
> or even minutes, on connections that are extremely unlikely to ever
> become usable again.

IMO, that's a failure of the app writer to account for such failures -
yes, it's fine for the OS implementer to decide they want to help out
such apps, but again that's not the responsibility of the TCP spec to
mandate.

Joe

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 26 Sep 2015 12:37:39 +0900

> such apps, but again that's not the responsibility of the TCP spec to

But how would apps do this, though? They can listen to IP address changes
themselves, but that's a fair bit of code, and the code will be different
for different platforms. They can send more frequent keepalives, but that
increases data usage and battery usage, and even then, their connections
can still stall for a keepalive interval.

And even if the apps do address the problem, they're in exactly the same
boat as the OS. They can't predict the future, so the only real option is
to close the connection.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 26 Sep 2015 06:06:24 +0200 (CEST)

> with implementation issues - they tend to be documented as BCPs.

Well, they gave me the same answer you did, so I don't see them as 
operational. They just said "this is up to the application, there is no 
need to change anything" and also said "use TCP keepalives" which means 
they obviously have no idea about power usage on wireless devices.

---

From: Joe Touch <[email-masked]>
Date: Fri, 25 Sep 2015 21:21:47 -0700

> On Sep 25, 2015, at 8:37 PM, Lorenzo Colitti <[email-masked]> wrote:
> 
> But how would apps do this, though? They can listen to IP address changes themselves, but that's a fair bit of code, and the code will be different for different platforms. They can send more frequent keepalives, but that increases data usage and battery usage, and even then, their connections can still stall for a keepalive interval.

Non blocking I/O.  Sleep mode between polling intervals or wake-on-packet.  The point is that TCP doesn't need a keep alive unless you care about being idle.  As long as you're ok with being idle, it doesn't t need to cost much. 

> And even if the apps do address the problem, they're in exactly the same boat as the OS. They can't predict the future, so the only real option is to close the connection.

Yup.  If the cost of keeping the app is too high and nothing is going on, it's always an option to do this..

Again, none of this is in TCPs court - all of these decisions can be olé enter in various places and there is no single "best" answer.  It depends on the app.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 25 Sep 2015 21:28:51 -0700

> On Sep 25, 2015, at 9:06 PM, Mikael Abrahamsson <[email-masked]> wrote:
> 
>> Actually, they would help deal with both, or at least would be a place to start. There are many RFCs from TCPM, TSVWG, etc. that have dealt with implementation issues - they tend to be documented as BCPs.
> 
> Well, they gave me the same answer you did, so I don't see them as operational. They just said "this is up to the application, there is no need to change anything"

In TCP...

> and also said "use TCP keepalives" which means they obviously have no idea about power usage on wireless devices.

Keepalives are needed only if you care if the app is idle. If you do, it's the only way to KNOW things are down.

Why do you care? It depends on the app whether and why you do.  

The TSV explored interface signals several times -  trigtran was one - and concluded there were too many cases where they won't work to be useful.. The fact that one interface is down for a time is almost never useful information unless the app must make progression its communication.  Idle app + down interface is rarely a useful event to act on - routing being the primary counterexample. That's where keepalives come in and why.

Joe

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 26 Sep 2015 06:48:09 +0200 (CEST)

> In TCP...

TCP doesn't live in a vacuum with nothing around it.

> Keepalives are needed only if you care if the app is idle. If you do, it's the only way to KNOW things are down.

No, it's not. If your only world is TCP it might be the only way, but 
that's not the world we live in. In the real world there are IP addresses 
that are bound to interfaces that go down, so that TCP could be told that 
the IP address used isn't valid anymore.

> Why do you care? It depends on the app whether and why you do.

Because right now we have a substandard user experience because this isn't 
being handled.

> The TSV explored interface signals several times - trigtran was one - 
> and concluded there were too many cases where they won't work to be 
> useful.. The fact that one interface is down for a time is almost never 
> useful information unless the app must make progression its 
> communication.  Idle app + down interface is rarely a useful event to 
> act on - routing being the primary counterexample. That's where 
> keepalives come in and why.

Ok, let me give you a concrete example:

Let's say I run ssh. I have a terminal window. I have a 3GPP USB dongle. I 
have ssh terminal session up to a server. 3GPP dongle interface goes down.

Now, I know for a fact that when it comes up again, it'll have a different 
IP address. So this TCP session that TCP is running over is just useless.

Why do I have to go to a different terminal window to kill the ssh 
process, because it's now stuck waiting for input (even if I press enter 
in the session it won't die, even after the 3GPP dongle interface comes 
back up again). This process is just stuck for at least minutes or hours.

And no, I don't want to run keepalives because that takes a lot of 
battery.

I can't understand why you seriously seem to believe that the best 
solution here is for the individual application developers to insert a lot 
of code in each application to handle this, when it would instead fix all 
applications to do it in the operating system or connection manager.

---

From: Joe Touch <[email-masked]>
Date: Fri, 25 Sep 2015 23:28:44 -0700

> On Sep 25, 2015, at 9:48 PM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> No, it's not. If your only world is TCP it might be the only way, but that's not the world we live in. In the real world there are IP addresses that are bound to interfaces that go down, so that TCP could be told that the IP address used isn't valid anymore.

There is nothing stopping you from implementing this.  It's only that there is *nothing*in TCP that requires this either.

> Because right now we have a substandard user experience because this isn't being handled.

If you handle this outside the app without the app asking for this feature, then you could break an app that will work fine elsewhere.  Again, that's your call.

> Let's say I run ssh. I have a terminal window. I have a 3GPP USB dongle. I have ssh terminal session up to a server. 3GPP dongle interface goes down.
> 
> Now, I know for a fact that when it comes up again, it'll have a different IP address.

If that's a strict requirement of 3GPP then maybe.  But if you hav a tunnel that runs over that interface maybe not.

> So this TCP session that TCP is running over is just useless.

It is dormant.

> Why do I have to go to a different terminal window to kill the ssh process, because it's now stuck waiting for input (even if I press enter in the session it won't die, even after the 3GPP dongle interface comes back up again). This process is just stuck for at least minutes or hours.

That is because our ssh client used blocking reads.  Otherwise it would wait - when you type something, it would shut down *then*. Shutting down when you try to send over the down interface is what I would expect from TCP.

> And no, I don't want to run keepalives because that takes a lot of battery.
> 
> I can't understand why you seriously seem to believe that the best solution here is for the individual application developers to insert a lot of code in each application to handle this, when it would instead fix all applications to do it in the operating system or connection manager.

Non blocking reads are hardly a lot of code.

Having the OS always drop the socket is making a decision for all apps, including those that would be just as happy waiting if the connection come back up.

Joe

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 26 Sep 2015 19:46:02 +0200 (CEST)

> If that's a strict requirement of 3GPP then maybe.  But if you hav a tunnel that runs over that interface maybe not.

That doesn't make any sense what so ever. The /32 IPv4 address and the /64 
IPv4 prefix is gone, I won't get it again. What tunnel? If you have some 
kind of tunnel interface that has dynamic over different IPv4/IPv6 
addresses, then that tunnel interface doesn't go down as the 3GPP 
prefix/address changes, then that's got nothing to do with what I just 
wrote.

>> So this TCP session that TCP is running over is just useless.

In my example it's bound to the 3GPP WAN interface address that just went 
away. It's not coming back. I know this.

> That is because our ssh client used blocking reads.  Otherwise it would 
> wait - when you type something, it would shut down *then*. Shutting down 
> when you try to send over the down interface is what I would expect from 
> TCP.

That doesn't work with any operating system I know of. Linux, Windows, 
OSX, none of them work like that.

> Having the OS always drop the socket is making a decision for all apps, 
> including those that would be just as happy waiting if the connection 
> come back up.

I never said "always". I said this applied to *some* interfaces. Policy. I 
know for a fact the connection IP address will never return. Never. So the 
TCP connection bound to that address is useless. It will never come back 
to life. This is a dead parrot. Dead. It's not sleeping, it's DEAD! Gone. 
Forever. No coming back. Forever. Useless.

---

From: Mark Smith <[email-masked]>
Date: Sun, 27 Sep 2015 09:27:35 +1000

On 27 Sep 2015 03:46, "Mikael Abrahamsson" <[email-masked]> wrote:
>> If that's a strict requirement of 3GPP then maybe.  But if you hav a
tunnel that runs over that interface maybe not.
>
>
> That doesn't make any sense what so ever. The /32 IPv4 address and the
/64 IPv4 prefix is gone, I won't get it again.

I'm curious how you know you won't get it back again? I'd that something
inherent in the 3GPP spec's? If have thought it would be a network operator
policy decision (and I've also seen it be a vendor default on a BRAS if it
is choosing addresses to hand out).

What tunnel? If you have some kind of tunnel interface that has dynamic
over different IPv4/IPv6 addresses, then that tunnel interface doesn't go
down as the 3GPP prefix/address changes, then that's got nothing to do with
what I just wrote.
>> Having the OS always drop the socket is making a decision for all apps,
including those that would be just as happy waiting if the connection come
back up.
>
>
> I never said "always". I said this applied to *some* interfaces. Policy.
I know for a fact the connection IP address will never return. Never. So
the TCP connection bound to that address is useless. It will never come
back to life. This is a dead parrot. Dead. It's not sleeping, it's DEAD!
Gone. Forever. No coming back. Forever. Useless.
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 27 Sep 2015 07:31:46 +0200 (CEST)

On Sun, 27 Sep 2015, Mark Smith wrote:

> inherent in the 3GPP spec's? If have thought it would be a network 
> operator policy decision (and I've also seen it be a vendor default on a 
> BRAS if it is choosing addresses to hand out).

Empirical evidence. No, it's not inherent in 3GPP, but I have yet to run 
into a mobile operator that will give you back your IP address next time 
you connect. But again, I am talking on per-operator policy here on the 
phone. Policy I, as end user, set. So if I use an operator that actually 
gives me the same address again, I can change that policy setting.

With mobile phones, this could be included in the "carrier settings" that 
configures a lot of other aspects of the mobile interface on the phone.

---

From: Matthew Petach <[email-masked]>
Date: Sat, 26 Sep 2015 23:20:31 -0700

On Sat, Sep 26, 2015 at 10:31 PM, Mikael Abrahamsson <[email-masked]> wrote:
> into a mobile operator that will give you back your IP address next time you
> connect. But again, I am talking on per-operator policy here on the phone.
> Policy I, as end user, set. So if I use an operator that actually gives me
> the same address again, I can change that policy setting.
>

If this is something that varies from network to
network, it hardly seems like it would be
proper to define behaviours in any type
of RFC or internet draft for lower-layer
protocols.  At best, it sounds like having
a socket option for fast_teardown in the
OS domain *might* be applicable, so
the OS can decide to drop the socket
binding immediately on any interface
transition; but that's not a TCP-level
issue, really, at least not as far as I
can tell from this point of view.

Matt

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 27 Sep 2015 17:13:12 +0200 (CEST)

On Sat, 26 Sep 2015, Matthew Petach wrote:

> If this is something that varies from network to network, it hardly 
> seems like it would be proper to define behaviours in any type of RFC or 
> internet draft for lower-layer protocols.  At best, it sounds like 
> having a socket option for fast_teardown in the OS domain *might* be 
> applicable, so the OS can decide to drop the socket binding immediately 
> on any interface transition; but that's not a TCP-level issue, really, 
> at least not as far as I can tell from this point of view.

So if it's not TCP related, where should this kind of discussion be had in 
the IETF?

Also, why do you think that a socket option is applicable? If the OS knows 
that this TCP session is anchored at an IP address that will never become 
available again, what's the use in keeping this TCP session around? Why 
only do this for applications that set this fast_teardown option?

---

From: Joe Touch <[email-masked]>
Date: Sun, 27 Sep 2015 10:50:35 -0700

On 9/26/2015 10:31 PM, Mikael Abrahamsson wrote:
>> I'm curious how you know you won't get it back again? I'd that
>> something inherent in the 3GPP spec's? If have thought it would be a
>> network operator policy decision (and I've also seen it be a vendor
>> default on a BRAS if it is choosing addresses to hand out).
> 
> you connect.

The key issue is that:

1) you really don't KNOW you won't get the same IP address when you
reconnect that interface

2) IP addresses aren't defined solely by interface; from the Internet
specification view, if you brought up a different interface you *could*
get that IP address again

What you appear to want is a link between the network interface and the
OS socket such that when the link goes down the socket disconnects or
fails. That's strictly an OS issue.

>From TCP's viewpoint, the OS socket is where the TCP address/port pair
attaches to a process; until the process goes away or the TCP connection
is torn down, there's no reason to strictly disconnect the two. On the
network side, TCP is bound to an IP address and port, *NOT* to an interface.

As to your question of where this sort of thing might be
discussed/developed as a mechanism, there are several OS development
venues (e.g., Usenix for Unix variants) that might be useful to explore.

But, as we've noted, this is neither a deficiency nor an opportunity
(IMO) for Internet standards modification.

Joe

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 27 Sep 2015 20:00:24 +0200 (CEST)

> 1) you really don't KNOW you won't get the same IP address when you

So let's say my provider uses 100.64.0.0/10 generally, and they now use 
/14 out of that per GGSN as a pool, and they implement a 5 minute 
"quarantine" before re-use of existing address. The odds of me getting my 
IPv4 address back is miniscule. So with this knowledge in mind, I pretty 
much KNOW that when the PDP context goes down, that IP address I had is no 
longer of any use and I might as well kill all sockets associated with 
that IP address.

> fails. That's strictly an OS issue.

So where should this be discussed in the IETF? Or is your view that this 
isn't worth discussing? Or it's just not worth discussing in the IETF?

---

From: Joe Touch <[email-masked]>
Date: Sun, 27 Sep 2015 11:12:52 -0700

On 9/27/2015 11:00 AM, Mikael Abrahamsson wrote:
> "quarantine" before re-use of existing address. The odds of me getting
> my IPv4 address back is miniscule. So with this knowledge in mind, I
> pretty much KNOW that when the PDP context goes down, that IP address I
> had is no longer of any use and I might as well kill all sockets
> associated with that IP address.

That's an internal OS decision.

>> What you appear to want is a link between the network interface and
>> the OS socket such that when the link goes down the socket disconnects
>> or fails. That's strictly an OS issue.
> 

My view is that it's out of scope for the IETF. What you're proposing is
that:

	a) an IP address is strictly bound to a particular interface
		that runs counter to RFC1122; it's OK for you to
		make that assumption in an implementation based
		on a particular interface and ISP, but it's not
		something that would be appropriate to generalize IMO

	b) when an interface goes down, an OS socket should go down
	with it
		that's an OS issue; there's nothing to specify here
		that has to do with IP or TCP

	c) TCP connections should go down anytime an address becomes
	unavailable due to an interface change
		TCP is actually designed to do the opposite; to stay
		up until a message fails to go out, not to come down
		as soon as that possibility can't happen

The last one is a biggie, IMO - it's based on the Postel Principle (be
liberal in what you accept, be conservative in what you do). In this
context, it would mean:

	don't assume a failure when you can assume a interruption
	that doesn't impact you yet

There have been protocols or applications that do care about such
interruptions - which is exactly why TCP has a keepalive mechanism
(which sends nothing if you're already sending, but tests to see if a
message could go out if not). But that's from TCP's viewpoint -- you
don't want TCP to do anything, which is why this isn't an IETF issue.

What you want is the *OS* to do something - specifically, when the
interface goes down (not a protocol event), you want the OS socket to go
down too (not a protocol event either). That's exactly why this is an OS
issue, not a TCP, IP, or IETF one, IMO.

Joe

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 27 Sep 2015 21:16:13 +0200 (CEST)

> issue, not a TCP, IP, or IETF one, IMO.

Do you oppose IETF doing things like RFC7084 and other similar documents 
that aren't pure protocol matters?

---

From: Joe Touch <[email-masked]>
Date: Sun, 27 Sep 2015 12:48:02 -0700

On 9/27/2015 12:16 PM, Mikael Abrahamsson wrote:
>> interface goes down (not a protocol event), you want the OS socket to
>> go down too (not a protocol event either). That's exactly why this is
>> an OS issue, not a TCP, IP, or IETF one, IMO.
> 

Protocols are more than just the format of messages "on the wire";
they're also the constellation of rules and behaviors that govern those
messages.

It's not that your concern isn't a "pure" protocol matter. It's simply
not a protocol matter at all.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 28 Sep 2015 08:48:55 +1300

On 28/09/2015 07:12, Joe Touch wrote:
> My view is that it's out of scope for the IETF. 

I disagree. We're talking about implementation and operational practice
to make the system more robust from an end2end point of view. If we can't
talk about that in the iEtf, where's the E gone?

> What you're proposing is

Statistically, it's a valid generalisation. Most end-user addresses are
ephemeral these days, and very unlikely to re-occur on a different interface.
RFC1122 was written before we even had DHCP; addresses were statically
configured and highly unlikely to change on the fly.

> 		that has to do with IP or TCP

True, in terms of their protocol state machines and messages. But
that isn't this WG's business.

> 		as soon as that possibility can't happen

Yes, and that was a reasonable approach to robustness when addresses
were static and would definitely still be valid after somebody changed
the Ethernet card on the VAX or moved a cable to the Cisco instead of
the Proteon. For a 2015-vintage Android device jumping from Wi-Fi to Wi-Fi
as it walks around the city, it's the worst possible approach.

> don't want TCP to do anything, which is why this isn't an IETF issue.

You don't want the TCP state machine to do anything, but you do
want the stack to do something, which *is* a v6ops issue (in terms of
implementation guidance).

> issue, not a TCP, IP, or IETF one, IMO.

We disagree on your assumption about IETF scope.

   Brian

---

From: Joe Touch <[email-masked]>
Date: Sun, 27 Sep 2015 13:06:51 -0700

> talk about that in the iEtf, where's the E gone?

It's not about E, it's about whether there is a protocol issue here at all.

> ephemeral these days, and very unlikely to re-occur on a different interface.

That's not true for private addresses. It might also easily be true in a
cellphone environment if (when) most devices are NAT'd by the carrier.

But I don't care if you want to break your OS this way. If you think
it's a protocol issue, please explain *why*.

I.e., there are separate issues:

	a) is it a good idea? (I think not, but don't care whether
	we agree)

	b) is this a protocol issue? (clearly not)

...
> that isn't this WG's business.

Not sure what you mean here. Are you agreeing that this is out of scope?

The IETF used to prohibit work on APIs because they were "implementation
details". That was a mistake, as they're part of the specification of a
protocol. However, the way in which the protocol endpoint ties into the
OS is an OS issue. It has nothing to do with the protocol.

> as it walks around the city, it's the worst possible approach.

It might make the endpoint more robust - able to tolerate periods when
the interface is down but comes back with the same address. The DHCP
client can even be configure to prefer to try to renew an old allocation
rather than jumping to a new one.

Remember that we're talking about TCP connections that are idle when the
link goes down; if they're active, they'd already fail.

Further, if you don't think this is the right approach to TCP, I
encourage you to design a new transport that behaves differently (maybe
there's already one that does). This is how TCP is already spec'd.

> implementation guidance).

The socket isn't part of the stack; it's an OS construct to connect a
process to the protocol.

> We disagree on your assumption about IETF scope.

Who's "we"?

---

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 27 Sep 2015 23:28:02 +0200 (CEST)

> link goes down; if they're active, they'd already fail.

No, that is not what happens in real life.

If I lose my existing IPv4 address and get a new IPv4 address and press 
return in my ssh session bound to the old address, it doesn't terminate 
the TCP session (on Linux or OSX for instance). That session will keep 
retrying for a long long long time from a user perspective, uselessly 
long. I'd imagine it's hours, I haven't bothered to wait. I always give up 
after 60-120 seconds, kill the ssh process.

Or rather not, because nowadays I run mosh because that actually has a 
useful way of handling connections. I grew tired of having to kill the ssh 
session whenever I left sleep or moved between networks.

---

From: Joe Touch <[email-masked]>
Date: Sun, 27 Sep 2015 15:52:10 -0700

On 9/27/2015 2:28 PM, Mikael Abrahamsson wrote:
> long. I'd imagine it's hours, I haven't bothered to wait. I always give
> up after 60-120 seconds, kill the ssh process.

If TCP isn't timing out fast enough, then you needed your SSH
implementation to set a shorter TCP user timeout as per RFC5482. And
check as to whether SSH is using blocking send() calls or not; if not,
then again that's the fault of the application and/or OS - not TCP.

I.e., when you have a TCP connection and you write to it, the OS makes a
packet and tries to send it out of an existing interface. If there
aren't existing interfaces, then the OS could easily decide to fail that
operation.

However, TCP doesn't and can't know any better. It has a source IP
address in the control block and it just uses it. That gets sent to IP.
IP is allowed to lose packets; TCP doesn't care why or where. It just
retransmits them until either it times out or you disconnect. So you
don't like how long that takes, but there are plenty of other people -
esp. those taking trains through tunnels - who are very happy that the
connections just come alive after such interruptions.

E.g., I checked my SSH (Windows cygwin) and took the network interface
down then up. The connection stalled until I reconnected. The
intervening writes were queued up and sent when an available interface
came up. That's a decision of how the implementers designed SSH, not a
failure of TCP.

The point is that it's up to the application as to what semantics are
desired, and up to the OS as to what semantics are provided.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 28 Sep 2015 12:56:15 +1300

On 28/09/2015 09:06, Joe Touch wrote:
...
>> We disagree on your assumption about IETF scope.

I meant you and me, although I guess Mikael and I agree.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 28 Sep 2015 09:54:45 +0900

> then again that's the fault of the application and/or OS - not TCP.

Lest anyone think this is a good idea, let me state that in many cases,
it's a terrible idea.

Having x independent apps each send TCP keepalives every y seconds is
terrible for battery life. Depending on how unsynchronized the apps are,
due to natural hysteresis cycles and dormancy timers you might end up
keeping the radio in a high-power state all the time, even when there is no
real traffic to send and receive.

It's also quite bad for total network bandwidth - wireless networks such as
802.11 and LTE are optimized for bursts and have substantial channel
acquisition costs.

TCP keepalives will work on plugged-in workstations connected to wired
networks, but I think that's not how most users use the Internet these days.

---

From: Havard Eidnes <[email-masked]>
Date: Mon, 28 Sep 2015 09:32:56 +0200 (CEST)

> Statistically, it's a valid generalisation. Most end-user addresses
> are ephemeral these days, and very unlikely to re-occur on a
> different interface.

That's probably true.  But tweak the statement slightly, and change
"different interface" to "same interface", and I'm not sure I agree:
in my experience most DHCP servers I meet on WiFi networks are quite
likely to re-assign the same IP address after a blip in reachability
or an interface down/up transition on the WiFi-connected device.

If address assignment in mobile networks is different, and there's a
specific policy preventing the re-assignment of the same IP address to
the same device should it re-surface again shortly after a network
reachability transition, that's another thing.

I'm wondering if this forced address churn won't reduce the usability
of long-lived TCP connections from a device tehtered behind a cell
phone.

Best regards,

- Håvard

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 28 Sep 2015 17:08:22 +0900

> or an interface down/up transition on the WiFi-connected device.

Please everyone realize that the whole point is that when wifi goes away,
the next opportunity to connect will be well within a few hundred
milliseconds, *on a different network* - i.e., cellular data.

That network is almost certainly going to have a different IP address, and
any OS, stack or application has exactly two choices: 1) get stuck, hoping
that the previous connection will magically show up again, and 2) reconnect.

For a mobile device, the smart choice is almost always #2.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 28 Sep 2015 15:14:32 +0000

Hi Lorenzo,

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Monday, September 28, 2015 1:08 AM
To: Havard Eidnes
Cc: [email-masked] WG
Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC

On Mon, Sep 28, 2015 at 4:32 PM, Havard Eidnes <[email-masked]<mailto:[email-masked]>> wrote:

Please everyone realize that the whole point is that when wifi goes away, the next opportunity to connect will be well within a few hundred milliseconds, *on a different network* - i.e., cellular data.

That network is almost certainly going to have a different IP address, and any OS, stack or application has exactly two choices: 1) get stuck, hoping that the previous connection will magically show up again, and 2) reconnect.

These concerns vanish when the mobile device configures a tunnel and gets a
stable IP address (or prefix) that never changes even if the underlying interface
addresses change dynamically. In that way, apps may see a blip when the mobile
changes its access network connection (e.g., from WiFi to cellular) but they will
continue to see the same IP address and continue to operate without having
to shut down and restart.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Sep 2015 10:05:22 -0700

On 9/27/2015 5:54 PM, Lorenzo Colitti wrote:
> On Mon, Sep 28, 2015 at 7:52 AM, Joe Touch <[email-masked]
> terrible for battery life.

We all agree on that. However, RFC5482 is about setting the timeout when
TCP 'gives up' on a connection. You can set that shorter without using
TCP keepalives.

Joe

---

From: Gert Doering <[email-masked]>
Date: Mon, 28 Sep 2015 19:52:20 +0200

Hi,

> v6ops seems to be one of the few. Why don't we have more of them?

Because the amount of real-world exposure is not something IETF would
be able to stomach.   As is evident from this thread.

gert
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Sep 2015 11:26:00 -0700

> be able to stomach.   As is evident from this thread.

Shall we open a thread on process management? Memory garbage collection?

All of these are real-world issues warranting serious consideration.

A network interface goes down. That's a network interface event. This is
an issue in the RTG and INT areas, but the reason it's not a transport
issue is clear - nothing changed as far as the transport protocol is
concerned.

The real disconnect here is "when an interface goes away, it *takes away
my IP address".

No, it really doesn't. DCHP revocation can take away an IP address, as
does IPv6 duplicate address detection. But these are network events, not
transport events. An interface going down may or may not take down the
corresponding IP address.

So what exactly would you have the OS do?

a) the OS socket could disappear when the IP address does
	we've already pointed out how that would negatively
	impact apps when a device has intermittent connectivity

b) the OS could tell the app that a write would fail
	but writes to TCP are buffered; they're not necessarily
	directly correlated to segment emission unless PSH is set

Recall that the IETF used to indicate that APIs were off-limits; it has
since admitted that at least abstract APIs (such as are spec'd in
RFC793) are in-scope.

However, what's clear about the cases above is that this is neither an
abstract API issue nor a protocol issue. It's an OS implementation
issue. It may be an important one, as is the issue of "how to write a
robust app that behaves as the user wants".

But the IETF isn't where that's discussed. It's taught in network classes.

Joe

---

From: Gert Doering <[email-masked]>
Date: Mon, 28 Sep 2015 20:35:30 +0200

Hi,

> But the IETF isn't where that's discussed. It's taught in network classes.

Thanks for so evidently emphasizing my point.

gert

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 28 Sep 2015 19:02:50 +0000

Hi Joe,

There is an ongoing discussion in the Distributed Mobility Management (DMM)
working group where they are documenting three different address types:

  1) Nomadic
  2) Sustained
  3) Fixed (or stable)

A nomadic address is one that is discovered when the app connects over
a network interface. If the interface goes down and comes back up, or if
the node switches over to using a different interface, then the original
address is deprecated and the app is obliged to use a new address. This
is what typically happens when a handset switches over from WiFI to
Cellular.

A fixed (or stable) address is one that never changes even if the underlying
network interfaces change. An interface can go down and come back up
with a different address, or the node can switch over to using a different
interface, but the fixed address remains unchanged and the app does not
need to reconnect. This is the type of address the node gets when it
configures a tunnel (or, VPN) over the underlying network interfaces. So,
if you want an app to survive a network handover, this is the type of
arrangement you should use.

A "sustained" address is one that remains unchanged during the app's
connection lifetime. But, after the connection terminates, the app may
discover and utilize a different sustained address for future connections.
Personally, I believe this type of address is mythical as I don't see any
practical way of implementing it.

IMHO, if you want a stable address that never changes, and/or the
ability to configure multiple addresses, use DHCPv6 PD over tunnels.

Thanks - Fred

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Monday, September 28, 2015 11:26 AM
> To: Gert Doering; Mikael Abrahamsson
> Cc: v6ops list

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Sep 2015 09:15:51 +1300

> milliseconds, *on a different network* - i.e., cellular data.

Or even a different Wi-Fi. In a crowded downtown with many free Wi-Fi
SSIDs around, I've seen my Android device switching between SSIDs rather
frequently.

    Brian

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Sep 2015 13:47:13 -0700

Hi, Fred,

On 9/28/2015 12:02 PM, Templin, Fred L wrote:
> a network interface.

TCP doesn't bind to an "interface"; it either binds to INADDR_ANY or to
a specific address.
 When INADDR_ANY is indicated, an algorithm selects the source IP
address based on a set of rules - e.g., as per RFC6724 for IPv6. That IP
address is determined by the outgoing interface selected by the
forwarding rules for the destination address coupled with some other
context and policy information.

I.e., TCP doesn't pick an interface; the OS does -- *because* the app
has indicated that it wants this operation.

(RFC793 talks about this as well - TCP binds to an address, but not an
interface per se).

> If the interface goes down and comes back up, or if
> address is deprecated and the app is obliged to use a new address.

If the OS indicates that the *address* (note - not the interface) is no
longer available, then it might be reasonable to signal the socket to
fail. But that would make the TCP connection fail; whether the app will
try with a *new* socket on a new address depends on how the app is written.

> This

Isn't that just "one network interface coming up and another going
down"? Why is that useful to describe as "nomadic"? What makes an
interface - or an address - nomadic?

> practical way of implementing it.

What do you call a WiFi interface that can go down, come back, and gets
the same IP - and then all applications that were active prior to the
interruption come back? That's how WiFi works in Windows, FWIW.

AFAICT:

a) interfaces go down, taking addresses with them
b) interfaces come up, yielding either new addresses or reusing
previously assigned ones
c) interfaces stay up

I don't know what the difference between these is until either you see a
change. A-priori, you can't really know the difference - a cellular
interface might sit in one place and be on all the time (e.g., to
support smart power meters). A tunnel can be torn down.

And TCP apps that set the local address to INADDR_ANY fall into your
"sustained address" category.

I don't see any of this as useful to describe in terms of addresses or
interfaces.

> ability to configure multiple addresses, use DHCPv6 PD over tunnels.

If the tunnel is created using a virtual interface, then it's possible
to assign an address and never need to release that interface. Tunnels
can also be created addresses bound to existing physical interfaces, and
those tunnels would come down when the interface did, however.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 28 Sep 2015 21:08:53 +0000

Hi Joe,

> to assign an address and never need to release that interface.

That is what I am saying, which no one else has been saying - that
tunneling can be used to maintain one or more fixed (stable) address
that never change even if the underlying interface addresses change.

FWIW, if you don't like the terms "nomadic", "sustained" and "fixed"
the place to comment on that is in the DMM mailing list.

Thanks - Fred

> From: Joe Touch [mailto:[email-masked]]
> Sent: Monday, September 28, 2015 1:47 PM
> To: Templin, Fred L; Gert Doering; Mikael Abrahamsson
> Cc: [email-masked]; v6ops list

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Sep 2015 14:21:48 -0700

> that never change even if the underlying interface addresses change.

Oh, absolutely.

> the place to comment on that is in the DMM mailing list.

Sorry - I don't have enough cycles (it's not clear there *are* enough
cycles to fix every such issue in the IETF).

Joe

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 29 Sep 2015 13:53:50 +0200

Le 28/09/2015 09:32, Havard Eidnes a écrit :
[...]
>  specific policy preventing the re-assignment of the same IP address
> to the same device should it re-surface again shortly after a network

Depends how that tethering is done.  The tethering of RFC727 aka
"64share" will break all TCP connections of the tethered device upon
change in IP address of the main device - be they TCP or other.  BEcause
a new address assigned to the main device involves renumbering the
tethering device as well.

The tethering that uses Mobile IP (RFC3963) will maintain the address
fixed on the tethered device despite the change in address of the main
device.  And this will not break the long-lived connections on the
tethered device even if the main device changes its address.

One can also consider other translation, routing, address updating or
tunnelling techniques (non-MIP and non-64share) to achieve maintenance
of long-lived TCP connections on the tethered device.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 29 Sep 2015 16:25:52 +0000

Hi Joe,

> Sent: Monday, September 28, 2015 2:22 PM

Here is how to do DHCPv6 Prefix Delegation from a host so that the host
can assign multiple addresses from the delegated prefix:

   "AERO Clients typically configure a TUN/TAP interface [TUNTAP] as a
   point-to-point linkage between the IP layer and the AERO interface.
   The IP layer therefore sees only the TUN/TAP interface, while the
   AERO interface provides an intermediate conduit between the TUN/TAP
   interface and the underlying interfaces.  AERO Clients that act as
   hosts assign one or more IP addresses from their ACPs to the TUN/TAP
   interface, i.e., and not to the AERO interface."

So, the host performs DHCPv6 PD as a Requesting Router over the AERO
interface but it assigns addresses derived from the delegated prefix to
the TUN/TAP interface. In that way, applications can use the addresses
assigned to the TUN/TAP interface without having to adhere to the
weak end system model, since the AERO interface is not visible to
the IP layer.

Thanks - Fred