netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Jeff Haran <jharan@bytemobile.com>
Cc: sclark46@earthlink.net, Jan Engelhardt <jengelh@medozas.de>,
	David Miller <davem@davemloft.net>,
	pascal.mail@plouf.fr.eu.org, netfilter-devel@vger.kernel.org
Subject: Re: rules matching ipv6 prefix addrs
Date: Thu, 04 Nov 2010 14:45:05 -0400	[thread overview]
Message-ID: <4CD2FF31.5050404@zytor.com> (raw)
In-Reply-To: <6F5DE7538AFCDA45A114F5E7510424A70225758A@hq-exchange01.bytemobile.com>

On 11/04/2010 01:35 PM, Jeff Haran wrote:
>
> Ideally, your ISP wouldn't do this to you. Ideally, they would advertise
> the new prefix as preferred and deprecate the old one. So connections
> using the old prefix would continue to work while new connections should
> start using the new prefix. By the time the old prefix is invalid there
> should be no TCP connections using it since most TCP connections don't
> last as long as the valid lifetime. But since TCP doesn't define a
> maximum connection duration, it's still a possibility that long lived
> connections could be dropped, no matter how hard the ISP tries to
> prevent it. But it does mean that any reasonable IPv6 firewall setup
> should deal with multiple prefixes. And it also means that if you have
> an application that won't well tolerate dropped connections, you should
> probably code it to do a clean close and restart whenever the address at
> your end of the socket transitions from preferred to deprecated state.
>

Ideally, yes, although I don't realistically believe that will happen. 
Now, to deal with multiple prefixes in parallel is even more complex 
than switching prefixes.

There is obviously no such thing as a maximum TCP duration, and therein 
lies a huge problem; the only way to deal with it sanely would have been 
to separate routing from endpoint identity, but the IPv6 architects 
chose to not go that route, partly because they seriously misestimated 
the timescale of the transition.

	-hpa

  reply	other threads:[~2010-11-04 18:46 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-02 20:52 rules matching ipv6 prefix addrs David Miller
2010-11-02 21:24 ` Maciej Żenczykowski
2010-11-03  7:37 ` Patrick McHardy
2010-11-03  9:29 ` Pascal Hambourg
2010-11-03 10:51   ` Jan Engelhardt
2010-11-03 12:19   ` David Miller
2010-11-03 12:32     ` Jan Engelhardt
2010-11-03 21:55       ` David Miller
2010-11-03 22:36         ` H. Peter Anvin
2010-11-03 22:52           ` Jan Engelhardt
2010-11-04  2:12             ` H. Peter Anvin
2010-11-04  4:14               ` Patrick McHardy
2010-11-04  8:58               ` Jan Engelhardt
2010-11-04 11:36                 ` H. Peter Anvin
2010-11-04 11:53                   ` Jan Engelhardt
2010-11-04 14:41                     ` H. Peter Anvin
2010-11-04 20:02                       ` Pascal Hambourg
2010-11-04 12:07                   ` Pascal Hambourg
2010-11-04 11:08               ` Stephen Clark
2010-11-04 11:29                 ` Pascal Hambourg
2010-11-04 12:07                   ` Stephen Clark
2010-11-04 12:19                     ` Pascal Hambourg
2010-11-04 13:34                 ` Jozsef Kadlecsik
2010-11-04 14:41                 ` H. Peter Anvin
2010-11-04 17:35                   ` Jeff Haran
2010-11-04 18:45                     ` H. Peter Anvin [this message]
2010-11-04 19:24                   ` Jan Engelhardt
2010-11-04 19:26                     ` H. Peter Anvin
2010-11-04 11:55               ` Pascal Hambourg
2010-11-04 14:42                 ` H. Peter Anvin
2010-11-04 20:00                   ` Pascal Hambourg
2010-11-03 12:56     ` Pascal Hambourg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CD2FF31.5050404@zytor.com \
    --to=hpa@zytor.com \
    --cc=davem@davemloft.net \
    --cc=jengelh@medozas.de \
    --cc=jharan@bytemobile.com \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pascal.mail@plouf.fr.eu.org \
    --cc=sclark46@earthlink.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).