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

From: Fred Baker <[email-masked]>
Date: Wed, 15 Apr 2009 11:27:24 -0400

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.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 15 Apr 2009 12:53:12 -0400

As I requested earlier, this draft should be changed form BCP to
Informational.

Thanks,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Fred Baker (fred)
Sent: Wednesday, April 15, 2009 11:27 AM
To: IPv6 Operations
Cc: [email-masked]; [email-masked]
Subject: draft-ietf-v6ops-cpe-simple-security-04 WGLC

---

From: james woodyatt <[email-masked]>
Date: Wed, 15 Apr 2009 13:32:31 -0700

> As I requested earlier, this draft should be changed form BCP to  

If the Working Group chair(s) direct me to change the category, then  
I'll change it.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Fred Baker <[email-masked]>
Date: Wed, 15 Apr 2009 16:35:24 -0400

Please do in your next revision. I think he argument holds. Barring  
updates as the result of last call comments, I don't think the setting  
in the draft is critical, though. The important point is not whether  
you mark it as standards vs informational tracks; it's what the IESG  
decides.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Apr 2009 11:27:01 +1200

IMHO this is an important document, and almost ready to be a BCP, but
a few points need attention:

It pains me to say it, but I think the following sentence in the
Overview section should simply be deleted:

  "It should be noted that NAT for IPv6 is both strictly forbidden by
   the standards documents and strongly deprecated by Internet
   operators."

There's no way this sentence won't be controversial at the IESG stage,
and any attempt to wordsmith it will be highly painful for all concerned.
Deleting it doesn't change the value or recommendations of the draft.

At the bottom of page 4:

  "As the latest revision of this document is being drafted,
   conventional stateful packet filters are activated as a side effect
   of outbound flow initiations from interior network nodes."

I can't parse this sentence. What does "are activated" mean? By who, in
which boxes? And does the first clause just mean "Today, " ?

"2.1.  Basic Sanitation

   In addition to the functions required of all Internet routers
   [RFC4294], residential gateways are expected to have basic stateless
   filters for prohibiting certains kinds of traffic with invalid
   headers, e.g. martian packets, spoofs, routing header type code zero,
   etc."

I think 'martian' needs a definition.

Also, should this section say something about ICMP in general?

In section 2.2:
  "To prevent Teredo from
   acquiring a utility that it was never meant to have on networks where
   both IPv4/NAT and native IPv6 services are available, gateways MUST
   impede Teredo tunnels by blocking clients from learning their mapped
   addresses and ports in the qualification procedure described in
   sections 5.2.1 and 5.2.2 of [RFC4380]."

Just to avoid silly misunderstandings, could we
s/gateways/gateways on such networks/ please?
Also, I don't think we can justify MUST; how about SHOULD?

Also, should this topic also cover 6to4? Hosts behind an IPv6 CPE
SHOULD NOT use host 6to4 based on RFC3068.

However, I have to wonder why this whole topic (Teredo+6to4) is
relevant to this document. Shouldn't it be in the CPE requirements
document instead?

  "R2: Packets bearing in their outer IPv6 headers multicast destination
   addresses of equal or narrower scope that the configured scope
   boundary level of the gateway MUST NOT be forwarded in any direction.
   The DEFAULT scope boundary level SHOULD be organization-local scope."

I can't find a definition of "organization-local scope" or even what
is meant by "configured scope boundary level". Probably the document needs
a short discussion of what it means by "scope".

  "R5: Packets MAY be discarded if the source and/or destination address
   in the outer IPv6 header is a unique local address.  By DEFAULT,
   gateways SHOULD NOT forward packets across unique local address scope
   boundaries."

I would insert a normative reference to RFC4193.

  "R28: If a gateway cannot determine whether the endpoints of a TCP
   connection are active, then it MAY abandon the state record if it has
   been idle for some time.  In such cases, the value of the
   "established connection idle-timeout" MUST NOT be less than two hours
   four minutes."

Two hours four minutes?

"3.3.2.  SCTP Filters"

Reading this section, I wondered whether there is anything to say
about SHIM6? A TCP session over SHIM6 could simply appear, with
no SYN/ACK, or disappear, as the shim switches addresses.

  "R31: Gateways MUST implement a protocol to permit applications to
   solicit inbound traffic without advance knowledge of the addresses of
   exterior nodes with which they expect to communicate.  This protocol
   MUST have a specification that meets the requirements of [RFC5378],
   [RFC3979], [RFC4748] and [RFC4879]."

It sounds good but it doesn't tell a CPE implementor what to code.
Also, is it really part of simple security?

I'm not sure that I have a constructive suggestion, but maybe the
hard requirement should be more firewallish: gateways must not
allow unsolicited inbound traffic by default? With the solicitation
mechanisms being out of scope for this document?

  "Much of the text describing the detailed requirements for TCP and UDP
   filtering is derived or transposed from [RFC5382] and [RFC4787], and
   some form of attribution here may therefore be appopriate."

I fear you will need to insert the pre-RFC5378 disclaimer.

  ** Obsolete normative reference: RFC 4748 (Obsoleted by RFC 5378)

  -- Obsolete informational reference (is this intentional?): RFC 3989
     (Obsoleted by RFC 5189)

   Brian

---

From: Fred Baker <[email-masked]>
Date: Fri, 17 Apr 2009 11:11:16 -0400

>   the standards documents and strongly deprecated by Internet

It is also untrue. The operators are not asking for NAT to go away. In  
fact, many enterprise administrations including Apple's and Cisco's  
are finding places where they specifically want to use NAT technology.

> I think 'martian' needs a definition.

Maybe you want to pick one of the following? I would go for the  
discussion in RFC 1208, or the one in RFC 1812.

http://www.ietf.org/rfc/rfc1208.txt
1208 A Glossary of Networking Terms. O.J. Jacobsen, D.C. Lynch. March
      1991. (Format: TXT=41156 bytes) (Status: INFORMATIONAL)

    Martian: Humorous term applied to packets that turn up unexpectedly
    on the wrong network because of bogus routing entries.  Also used as
    a name for a packet which has an altogether bogus (non-registered or
    ill-formed) Internet address.

http://www.ietf.org/rfc/rfc1542.txt
1542 Clarifications and Extensions for the Bootstrap Protocol. W.
      Wimer. October 1993. (Format: TXT=52948 bytes) (Obsoletes RFC1532)
      (Updates RFC0951) (Status: DRAFT STANDARD)

    Hosts and routers are usually required to silently discard incoming
    datagrams containing illegal IP source addresses.  This is generally
    known as "Martian address filtering."  One of these illegal  
addresses
    is 0.0.0.0 (or actually anything on network 0).  However, hosts or
    routers which support a BOOTP relay agent MUST accept for local
    delivery to the relay agent BOOTREQUEST messages whose IP source
    address is 0.0.0.0.  BOOTREQUEST messages from legal IP source
    addresses MUST also be accepted.

http://www.ietf.org/rfc/rfc1812.txt
1812 Requirements for IP Version 4 Routers. F. Baker, Ed.. June 1995.
      (Format: TXT=415740 bytes) (Obsoletes RFC1716, RFC1009) (Updated  
by
      RFC2644) (Status: PROPOSED STANDARD)

5.3.7 Martian Address Filtering

    Martian Filtering
         A packet that contains an invalid source or destination address
         is considered to be martian and discarded.

http://www.ietf.org/rfc/rfc2650.txt
2650 Using RPSL in Practice. D. Meyer, J. Schmitz, C. Orange, M.
      Prior, C. Alaettinoglu. August 1999. (Format: TXT=55272 bytes)
      (Status: INFORMATIONAL)

    Figure 18 presents some example route-set objects.  The set rs-uo
    contains two address prefixes, namely 128.223.0.0/16 and
    198.32.162.0/24.  The set rs-bar contains the members of the set rs-
    uo and the address prefix 128.7.0.0/16.  The set rs-martians
    illustrate the use of range operators.  0.0.0.0/0^32 are the length
    32 more specifics of 0.0.0.0/0, i.e. the host routes; 224.0.0.0/3^+
    are the more specifics of 224.0.0.0/3, i.e. the routes falling into
    the multicast address space.  For more complete list of range
    operators please refer to RFC-2622.

       route-set: rs-martians
       remarks: routes not accepted from any peer
       members: 0.0.0.0/0,              # default route
                0.0.0.0/0^32,           # host routes
                224.0.0.0/3^+,          # multicast routes
                127.0.0.0/8^9-32, . . .

    As part of the decapsulation the node SHOULD silently discard a
    packet with an invalid IPv4 source address such as a multicast
    address, a broadcast address, 0.0.0.0, and 127.0.0.1.  In general it
    SHOULD apply the rules for martian filtering in [18] and ingress
    filtering [13] on the IPv4 source address.

    After the decapsulation the node SHOULD silently discard a packet
    with an invalid IPv6 source address.  This includes IPv6 multicast
    addresses, the unspecified address, and the loopback address but  
also
    IPv4-compatible IPv6 source addresses where the IPv4 part of the
    address is an (IPv4) multicast address, broadcast address, 0.0.0.0,
    or 127.0.0.1.  In general it SHOULD apply the rules for martian
    filtering in [18] and ingress filtering [13] on the IPv4-compatible
    source address.

http://www.ietf.org/rfc/rfc3704.txt
3704 Ingress Filtering for Multihomed Networks. F. Baker, P. Savola.
      March 2004. (Format: TXT=35942 bytes) (Updates RFC2827) (Also
      BCP0084) (Status: BEST CURRENT PRACTICE)

    RFC 2827 recommends that ISPs police their customers' traffic by
    dropping traffic entering their networks that is coming from a  
source
    address not legitimately in use by the customer network.  The
    filtering includes but is in no way limited to the traffic whose
    source address is a so-called "Martian Address" - an address that is
    reserved [3], including any address within 0.0.0.0/8, 10.0.0.0/8,
    127.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/4, or
    240.0.0.0/4.

    The questionable benefit of Loose RPF is found in asymmetric routing
    situations: a packet is dropped if there is no route at all, such as
    to "Martian addresses" or addresses that are not currently routed,
    but is not dropped if a route exists.

    One case where Loose RPF might fit well could be an ISP filtering
    packets from its upstream providers, to get rid of packets with
    "Martian" or other non-routed addresses.

    If other approaches are unsuitable, loose RPF could be used as a  
form
    of contract verification: the other network is presumably certifying
    that it has provided appropriate ingress filtering rules, so the
    network doing the filtering need only verify the fact and react if
    any packets which would show a breach in the contract are detected.
    Of course, this mechanism would only show if the source addresses
    used are "martian" or other unrouted addresses -- not if they are
    from someone else's address space.

    Therefore, the use of Loose RPF cannot be recommended, except as a
    way to measure whether "martian" or other unrouted addresses are
    being used.

    o  Loose RPF primarily filters out unrouted prefixes such as Martian
       addresses.  It can be applied in the upstream interfaces to  
reduce
       the size of DoS attacks with unrouted source addresses.  In the
       downstream interfaces it can only be used as a contract
       verification, that the other network has performed at least some
       ingress filtering.

http://www.ietf.org/rfc/rfc3871.txt
3871 Operational Security Requirements for Large Internet Service
      Provider (ISP) IP Network Infrastructure. G. Jones, Ed.. September
      2004. (Format: TXT=151101 bytes) (Status: INFORMATIONAL)

       Per [RFC1208] "Martian: Humorous term applied to packets that  
turn
       up unexpectedly on the wrong network because of bogus routing
       entries.  Also used as a name for a packet which has an  
altogether
       bogus (non-registered or ill-formed) Internet address."  For the
       purposes of this document Martians are defined as "packets having
       a source address that, by application of the current forwarding
       tables, would not have its return traffic routed back to the
       sender."  "Spoofed packets" are a common source of martians.

       A "spoofed packet" is defined as a packet that has a source
       address that does not correspond to any address assigned to the
       system which sent the packet.  Spoofed packets are often "bogons"
       or "martians".

2.5.6.  Support Automatic Discarding Of Bogons and Martians

       The device MUST provide a means to automatically drop all  
"bogons"
       (Section 1.8) and "martians" (Section 1.8).  This option MUST  
work
       in the presence of dynamic routing and dynamically assigned
       addresses.

    o  Support Automatic Discarding Of Bogons and Martians

http://www.ietf.org/rfc/rfc3964.txt
3964 Security Considerations for 6to4. P. Savola, C. Patel. December
      2004. (Format: TXT=83360 bytes) (Status: INFORMATIONAL)

    Alexey Kuznetsov brought up the implementation problem with IPv6
    martian checks.  Christian Huitema formulated the rules that rely on
    6to4 relays using only anycast.  Keith Moore brought up the point
    about reduced flexibility.  Brian Carpenter, Tony Hain, and  
Vladislav
    Yasevich are acknowledged for lengthy discussions.  Alain Durand
    reminded the authors about relay spoofing problems.  Brian Carpenter
    reminded the authors about the BGP-based 6to4 router model.
    Christian Huitema gave a push for a more complete threat analysis.
    Itojun Hagino spelled out the operators' fears about 6to4 relay

http://www.ietf.org/rfc/rfc4276.txt
4276 BGP-4 Implementation Report. S. Hares, A. Retana. January 2006.
      (Format: TXT=132864 bytes) (Status: INFORMATIONAL)

        Alcatel Y/N/O/Comments: Y
        Cisco   Y/N/O/Comments: N    Ignores the prefix in case of
                                     martian nexthop, and in case of
                                     length not equal to IPv4
                                     address-length, we send
                                     NOTIFICATION with error subcode
                                     Attribute Length error.
        Laurel  Y/N/O/Comments: Y
        NextHop Y/N/O/Comments: Y

http://www.ietf.org/rfc/rfc4379.txt
4379 Detecting Multi-Protocol Label Switched (MPLS) Data Plane
      Failures. K. Kompella, G. Swallow. February 2006. (Format:  
TXT=116872
      bytes) (Updates RFC1122) (Updated by RFC5462) (Status: PROPOSED
      STANDARD)

    Although this document makes special use of 127/8 address, these are
    used only in conjunction with the UDP port 3503.  Furthermore, these
    packets are only processed by routers.  All other hosts MUST treat
    all packets with a destination address in the range 127/8 in
    accordance to RFC 1122.  Any packet received by a router with a
    destination address in the range 127/8 without a destination UDP  
port
    of 3503 MUST be treated in accordance to RFC 1812.  In particular,
    the default behavior is to treat packets destined to a 127/8 address
    as "martians".

http://www.ietf.org/rfc/rfc4949.txt
4949 Internet Security Glossary, Version 2. R. Shirey. August 2007.
      (Format: TXT=867626 bytes) (Obsoletes RFC2828) (Also FYI0036)
      (Status: INFORMATIONAL)

    $ Martian
       (D) /slang/ A packet that arrives unexpectedly at the wrong
       address or on the wrong network because of incorrect routing or
       because it has a non-registered or ill-formed IP address. [R1208]

---

From: james woodyatt <[email-masked]>
Date: Fri, 17 Apr 2009 13:03:07 -0700

> Deleting it doesn't change the value or recommendations of the draft.

My next revision deletes the entire paragraph containing this sentence.

> which boxes? And does the first clause just mean "Today, " ?

It's a tough sentence to make work.  The idea I'm trying to describe  
here is the conventional method of creating state at the time of  
forwarding the initial packet for a new outbound flow to permit  
reverse path traffic to flow inbound.  I've got a candidate phrase in  
the next revision.

> I think 'martian' needs a definition.

Hmmm.  That could be an interesting tangent.  I thought I mostly  
covered the bases of what constitutes the martian addresses in IPv6 in  
section 3.1, but I suppose I could have added an explicit prohibition  
of packets with V4MAPPED addresses.  I didn't think that was  
necessary, and the design team didn't consider it, but I wouldn't  
object to adding it if there were calls for it here.

> s/gateways/gateways on such networks/ please?

No problem.

> Also, I don't think we can justify MUST; how about SHOULD?

I have no objection.

> SHOULD NOT use host 6to4 based on RFC3068.

My assumption was that residential IPv6 CPE would normally prevent  
this by using RFC 1918 addressing behind their IPv4 NAT.  An explicit  
deprecation would only seem necessary in the case of IPv4/NAT gateways  
that translate between global addresses across the realm boundary.  I  
don't think those are very common, are they?

> I would insert a normative reference to RFC4193.

Good idea.

>   "established connection idle-timeout" MUST NOT be less than two  

The same reasoning as in RFC 5382, hence the informative reference.   
I'll insert an explicit reference into the recommendation paragraph.

>   [RFC3979], [RFC4748] and [RFC4879]."

I think I should relax both these MUST instances to SHOULD instances  
here.  The second sentence should probably have an 'if implemented'  
conditional phrase after the subject.

> It sounds good but it doesn't tell a CPE implementor what to code.

We can't very well tell them to code UPnP IGD for IPv6 until the UPnP  
Forum publishes a specification that meets our requirements.  We can't  
tell them to code ALD, because it's just a draft, and an expired one  
at that.  We might try to tell them to code MIDCOM, but I say good  
luck with that.

This recommendation is basically a stand-in for a more concrete  
recommendation once some kind of de facto standard, if any, emerges.

> Also, is it really part of simple security?

I would argue it is.  Specifically, it's a constraint on simple  
security to ensure that applications are not prevented from soliciting  
inbound flows without knowing in advance the remote addresses of their  
peers.

> I fear you will need to insert the pre-RFC5378 disclaimer.

Why do you think this may be necessary?

>  -- Obsolete informational reference (is this intentional?): RFC 3989

Thanks for catching these.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Apr 2009 13:51:56 +1200

James,

Eliding the points that seem to be resolved...

> On Apr 16, 2009, at 16:27, Brian E Carpenter wrote:

...
> Hmmm.  That could be an interesting tangent.  I thought I mostly covered
> the bases of what constitutes the martian addresses in IPv6 in section
> 3.1, but I suppose I could have added an explicit prohibition of packets
> with V4MAPPED addresses.  I didn't think that was necessary, and the
> design team didn't consider it, but I wouldn't object to adding it if
> there were calls for it here.

A forward ref to section 3.1 would cover it just fine.

>> Also, should this section say something about ICMP in general?

Still open.

>> In section 2.2:
...
> My assumption was that residential IPv6 CPE would normally prevent this
> by using RFC 1918 addressing behind their IPv4 NAT.  An explicit

Maybe it doesn't need to be formally deprecated - just point out
that host 6to4 isn't expected to be relevant when there's an IPv6 CPE.

>> relevant to this document. Shouldn't it be in the CPE requirements

Still open.

>> a short discussion of what it means by "scope".

Still open.

>> no SYN/ACK, or disappear, as the shim switches addresses.

Still open.

> tell them to code ALD, because it's just a draft, and an expired one at
> that.  We might try to tell them to code MIDCOM, but I say good luck
> with that.
> 

Right, which is why I wonder whether it is a recommendation at all.
It seems more like a placeholder.

> Why do you think this may be necessary?

"  Much of the text describing the detailed requirements for TCP and UDP
   filtering is derived or transposed from [RFC5382] and [RFC4787], and
   some form of attribution here may therefore be appopriate."

Do you have permissions from those authors? If not, you need the disclaimer.

    Brian

---

From: <[email-masked]>
Date: Fri, 24 Apr 2009 13:45:30 +0200

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, 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?
- 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/UPnPIGD2vsIGD1d10032009.pdf  "UPnP Gateway committee: IGD:2 improvements over IGD:1"

Best regards,

	Teemu

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Fred Baker
>Sent: 15 April, 2009 18:27
>To: IPv6 Operations
>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.
>
>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 24 Apr 2009 11:00:46 -0700

> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Friday, April 24, 2009 4:46 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: draft-ietf-v6ops-cpe-simple-security-04 WGLC
> 
> Hi,
> 
> - 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
> 
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 24 Apr 2009 11:24:31 -0700

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.

---

From: james woodyatt <[email-masked]>
Date: Fri, 24 Apr 2009 11:51:58 -0700

> (e.g., draft-woodyatt-ald, UPnP IGD version 2).

Alternatively, the "simple" security functions could be disabled to  
facilitate applications that can't afford to send keep-alive packets.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 24 Apr 2009 12:10:04 -0700

> facilitate applications that can't afford to send keep-alive packets.

Sure, but that causes them to wake up their radio whenever a 
packet is received.  I don't know which is worse.

-d

---

From: <[email-masked]>
Date: Tue, 28 Apr 2009 16:17:41 +0200

>From: ext Dan Wing [mailto:[email-masked]] 
>Sent: 24 April, 2009 21:01
>
>> 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?
>

True, but my main intent was to ask why the 2 minutes time period was chosen, and not e.g. 100% longer of four minutes. 

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

Good point - not only create pinholes for listen sessions, but also for outgoing connections.

Best regards,

	Teemu

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 28 Apr 2009 07:52:28 -0700

[email-masked] wrote:
>>> timeout is understandable due need to save public ports,

Having multiple assumed possibilities for timeouts means as an
application developer you can only use the lowest one, at least if you
want your stuff to work.

> but that

---

From: james woodyatt <[email-masked]>
Date: Tue, 28 Apr 2009 10:34:20 -0700

On Apr 28, 2009, at 07:52, Joel Jaeggli wrote:
>>>> 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,
>
> application developer you can only use the lowest one, at least if  
> you want your stuff to work.

All true.  I copied the two-minute timer from RFC 4787 on the general  
idea that duplicating the filtering behavior of IPv4 NAT is the basic  
frame of what we're doing.

> True, but my main intent was to ask why the 2 minutes time period  
> was chosen, and not e.g. 100% longer of four minutes.

I agree that a longer DEFAULT timeout for IPv6 state records may be  
more reasonable given that we don't have a port conservation problem  
caused by address amplification.  I have no problem with four  
minutes.  Longer than that, however, and I would object.  Two hours is  
just completely out of the question for a connectionless transport.

So, can the working group give me a more reasonable number to use in  
the -06 revision I'm composing today?  Otherwise, I'll just increase  
it from two to four minutes, and we'll revisit in -07 if necessary.

---

From: Fred Baker <[email-masked]>
Date: Tue, 28 Apr 2009 12:15:19 -0700

in this context, I think copying IPv4 expectations is reasonable. They  
are, after all, not really IPv4 expectations - they are how IPv4  
systems are implemented having observed transports and applications  
that could ride on either. Those applications and transports won't  
complain about having longer timeouts from IPv6, but they're not  
likely to benefit much either, IMHO.

> it from two to four minutes, and we'll revisit in -07 if necessary.

I would suggest leaving it the same and referencing the source RFC.