[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt
On Tue, Jul 10, 2001 at 02:17:12PM -0400, Bill Sommerfeld wrote:
> > Also I would think that the 5 minute default is too long. If VPN
> > wasn't involved the "server" wouldn't normally be able to connect
> > back to the "client" after 5 minutes so I'm not sure why this
> > capability should be provided for VPN. One or two keepalive
> > packets after the last SA has been deleted should be more than
> > sufficient as the default.
>
> 5 minutes seems like a reasonable default to me; it's comparable in
> length to the (as specified) TCP TIME_WAIT interval.
>
> I think you want to attempt to keep things alive across a brief loss
> in connectivity (between the NAT and the outside-the-nat peer); 30
> second outages while BGP does its thing are not uncommon..
>
> > There is probably a better solution to this than sending a packet
> > every 20 seconds for TCP connections that are idle for a very long
> > time.
>
> Yes there is: get rid of the NAT :-)
>
> For what it's worth, it seems like the impact on the network of the
> NAT-keepalives could be reduced by sending them with a reduced IP TTL
> (so that they die just beyond the last NAT being traversed).
> Unfortunately there doesn't seem to be an easy way to figure out what
> that TTL should be..
Doesn't it, then, mean that the router (where the TTL hits zero)
would react and send back an ICMP? What are we trying to solve
with reducing the TTL?
Ramin
>
> - Bill
Follow-Ups:
References: