[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-ietf-v6ops-cpe-simple-security-04 WGLC

While the exact timing is open to opinions, I would suspect the original mention derives from a combination of two things.
(1) When TCP was originally under development, in the 1970's, there was a sense that a datagram could float around for several minutes, which is why the TCP sequence space is as large as it is and why timers are what they are.
(2) KC Claffy's dissertation, published in part in SIGCOMM 1993, found that TCP sessions could stop sending for several seconds and then restart, such as due to an application running off to a back-end database or launching a process. She defined a microflow as having ended when no datagram in the microflow had been seen for 300 seconds. I pushed her to try a number of intervals, including 1, 2, 4, 8 seconds, 15, 30, 60, and 300. She in fact tested something akin to that (in her perl scripts, it was a matter of changing a variable and re-running the test on the same data), and she found that 8 seconds was a big change - the same session could originate a new datagram as late as 300 seconds later, but the probability was that if a session had not spoken for 8 seconds it was unlikely to speak again. Today, iPhoto uploading to Picasa (I have observed) can stall a pipelined TCP session for 15 seconds, so the interval is probably longer - for safety I would talk about 30-60 seconds.
Why two minutes? Probably safety, coupled with the fact that UDP has no counterpart to "RST" that can be interpreted to short-circuit a session being ended. 

On Apr 24, 2009, at 11:00 AM, Dan Wing wrote:





-----Original Message-----
From: owner-v6ops@ops.ietf.org
[mailto:owner-v6ops@ops.ietf.org] On Behalf Of
teemu.savolainen@nokia.com
Sent: Friday, April 24, 2009 4:46 AM
To: fred@cisco.com; v6ops@ops.ietf.org
Cc: kurtis@kurtis.pp.se; rbonica@juniper.net;
Basavaraj.Patil@nokia.com; jouni.korhonen@nsn.com
Subject: RE: draft-ietf-v6ops-cpe-simple-security-04 WGLC

Hi,

I believe this document is of operational utility.

Few comments/questions:
- 3.2.2. describes, as per RFC4787, that UDP mappings MUST
NOT expire in less than two minutes. As I don't know the
backgrounds of this decision,


It is probably from REQ-5 of
http://tools.ietf.org/html/rfc4787#section-4.3.


I wonder why the minimum time
could not be longer for IPv6? The longer the time the less
need to activate radio for keep-alive sending (on either side
of the firewall btw - consider a case where CPE has wireless
WAN). In CGN case short timeout is understandable due need to
save public ports, but that probably is not an issue in
simple IPv6 firewall. So why e.g. not two hours as for TCP?


Two hours seems a long time to leave your door open.
A longer timeout could be negotiated between the the host and its CPE router using whatever protocol exists and becomes a defacto standard on IPv6 networks 
(e.g., draft-woodyatt-ald, UPnP IGD version 2).

-d


- 3.2.5. Just to check that DSMIP6 is considered as one of
these other tunneling protocols mentioned in R22? How about
MIP6 route optimization, will that work through a device
implementing this specification?
- 3.4 says it remains to be seen if UPnP:IGD is to be
extended for IPv6. I would rather say that IPv6 is being
added to UPnP:IDG2. See:
"http://www.upnp.org/resources/documents/UPnPIGD2vsIGD1d100320
09.pdf  "UPnP Gateway committee: IGD:2 improvements over IGD:1"

Best regards,

	Teemu



-----Original Message-----
From: owner-v6ops@ops.ietf.org
[mailto:owner-v6ops@ops.ietf.org] On Behalf Of ext Fred Baker
Sent: 15 April, 2009 18:27
To: IPv6 Operations
Cc: kurtis@kurtis.pp.se; rbonica@juniper.net
Subject: draft-ietf-v6ops-cpe-simple-security-04 WGLC

This is to initiate a two week working group last call of
draft-ietf- v6ops-cpe-simple-security-04. Please read it now.
If you find nits (spelling errors, minor suggested wording
changes, etc), comment to the authors; if you find greater
issues, such as disagreeing with a statement or finding
additional issues that need to be addressed, please post your
comments to the list.

We are looking specifically for comments on the importance of
the document as well as its content. If you have read the
document and believe it to be of operational utility, that is
also an important comment to make.