rules matching ipv6 prefix addrs

rules matching ipv6 prefix addrs

[David Miller]

H. Peter Anvin just mentioned something interesting to me,
basically it's the fact that when your prefix addresses
change on an interface in ipv6, this can invalidate your
netfilter rules.

So it would be nice if there were some way to match "the
ipv6 prefix address on interface X", and through some
kind of caching this could be optimized so it wouldn't
really cost anything.

Thoughts?

Re: rules matching ipv6 prefix addrs

[Maciej Żenczykowski]

There isn't necessarily just one prefix...
I think this would be best served with a userspace daemon listening
for address adds/removes and updating rules as required.

Re: rules matching ipv6 prefix addrs

[Patrick McHardy]

On 02.11.2010 21:52, David Miller wrote:
> 
> H. Peter Anvin just mentioned something interesting to me,
> basically it's the fact that when your prefix addresses
> change on an interface in ipv6, this can invalidate your
> netfilter rules.
> 
> So it would be nice if there were some way to match "the
> ipv6 prefix address on interface X", and through some
> kind of caching this could be optimized so it wouldn't
> really cost anything.
> 
> Thoughts?

Perhaps something similar to the IPv4 addrtype match would work?
Basically it allows you to match on inet_addr_type() of the source
or destination address.

Re: rules matching ipv6 prefix addrs

[Pascal Hambourg]

Hello,

David Miller a écrit :
> H. Peter Anvin just mentioned something interesting to me,
> basically it's the fact that when your prefix addresses
> change on an interface in ipv6, this can invalidate your
> netfilter rules.
> 
> So it would be nice if there were some way to match "the
> ipv6 prefix address on interface X", and through some
> kind of caching this could be optimized so it wouldn't
> really cost anything.
> 
> Thoughts?

What would be a use case ?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rules matching ipv6 prefix addrs

[Jan Engelhardt]

On Wednesday 2010-11-03 10:29, Pascal Hambourg wrote:

>Hello,
>
>David Miller a écrit :
>> H. Peter Anvin just mentioned something interesting to me,
>> basically it's the fact that when your prefix addresses
>> change on an interface in ipv6, this can invalidate your
>> netfilter rules.
>> 
>> So it would be nice if there were some way to match "the
>> ipv6 prefix address on interface X",

"The prefix addr no.5 on X" <=>  -i X -d 2001:db8::/64

Or... `-A INPUT -i X`: by using INPUT, you know that the packet was 
going to a local destination, which means the pkt had a daddr that is 
configured on that interface (or you have tproxy).

>> Thoughts?
>
>What would be a use case ?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rules matching ipv6 prefix addrs

[David Miller]

From: Pascal Hambourg <pascal.mail@plouf.fr.eu.org>
Date: Wed, 03 Nov 2010 10:29:47 +0100

> What would be a use case ?

I thought it was painfully obvious but...  the use case is setting up
a rule that matches the prefix addresses and having such rules still
work properly when the link flaps onto a link with a different prefix

Re: rules matching ipv6 prefix addrs

[Jan Engelhardt]

On Wednesday 2010-11-03 13:19, David Miller wrote:
>
>> What would be a use case ?
>
>I thought it was painfully obvious but...  the use case is setting up
>a rule that matches the prefix addresses and having such rules still
>work properly when the link flaps onto a link with a different prefix

A link moving to another link.. you lost me there.
Links usually don't move, packets do. Can you provide `ip addr`-style 
output of Before and After, to better see what's being meant?

Re: rules matching ipv6 prefix addrs

[David Miller]

From: Jan Engelhardt <jengelh@medozas.de>
Date: Wed, 3 Nov 2010 13:32:42 +0100 (CET)

> On Wednesday 2010-11-03 13:19, David Miller wrote:
>>
>>> What would be a use case ?
>>
>>I thought it was painfully obvious but...  the use case is setting up
>>a rule that matches the prefix addresses and having such rules still
>>work properly when the link flaps onto a link with a different prefix
> 
> A link moving to another link.. you lost me there.
> Links usually don't move, packets do. Can you provide `ip addr`-style 
> output of Before and After, to better see what's being meant?

This issue was expressed to me by H. Peter Anvin, let's CC: him
to get some specific examples.

HPA?

Re: rules matching ipv6 prefix addrs

[H. Peter Anvin]

The prefix is set by the ISP and can change at any time.  In IPv4 this is generally masked by NAT, but in IPv6 it affects every host.

What changes (in the normal case) is the common prefix of the network, i.e. the fraction delegated by the ISP.  If your ISP gives you a /56, for example, those 56 bits can change at any time, and that will affect all the hosts on your network.


"David Miller" <davem@davemloft.net> wrote:

>From: Jan Engelhardt <jengelh@medozas.de>
>Date: Wed, 3 Nov 2010 13:32:42 +0100 (CET)
>
>> On Wednesday 2010-11-03 13:19, David Miller wrote:
>>>
>>>> What would be a use case ?
>>>
>>>I thought it was painfully obvious but...  the use case is setting up
>>>a rule that matches the prefix addresses and having such rules still
>>>work properly when the link flaps onto a link with a different prefix
>> 
>> A link moving to another link.. you lost me there.
>> Links usually don't move, packets do. Can you provide `ip addr`-style
>
>> output of Before and After, to better see what's being meant?
>
>This issue was expressed to me by H. Peter Anvin, let's CC: him
>to get some specific examples.
>
>HPA?

-- 
Sent from my mobile phone.  Please pardon any lack of formatting.

Re: rules matching ipv6 prefix addrs

[Jan Engelhardt]

On Wednesday 2010-11-03 23:36, H. Peter Anvin wrote:

>The prefix is set by the ISP and can change at any time.

I take it you mean a setup where addresses are automatically assigned 
(DHCPv6, PPP).

Still I don't see the problem - any security-conscious person would use 
a drop-by-default ruleset. So a change of prefix address would, if 
anything, cause packets to get dropped in FORWARD. (What do we have the 
"ip6table_filter.forward" module option for? Right. And why is it set to 
ACCEPT by default? *headshakethere*)

>In IPv4 this is generally masked by NAT, but in IPv6 it affects every 
>host.

Different scenario. Because packets from Internet are 
only destined for your home gateway address, they would get locally 
delivered in the normal case, and any forwarding is an opt-in 
process on the admin's behalf.

If you used a FORWARD-DROP policy in IPv6, forwarding also becomes the 
same opt-in process. So it's not like NAT would be any magic.

Re: rules matching ipv6 prefix addrs

[H. Peter Anvin]

On 11/03/2010 06:52 PM, Jan Engelhardt wrote:
>
> I take it you mean a setup where addresses are automatically assigned
> (DHCPv6, PPP).
>

DHCPv6, PPP, RA, anything.  Keep in mind that "expect prefix changes" is 
a deliberate part of the IPv6 systems design.

> Still I don't see the problem - any security-conscious person would use
> a drop-by-default ruleset. So a change of prefix address would, if
> anything, cause packets to get dropped in FORWARD. (What do we have the
> "ip6table_filter.forward" module option for? Right. And why is it set to
> ACCEPT by default? *headshakethere*)
 >
>> In IPv4 this is generally masked by NAT, but in IPv6 it affects every
>> host.
>
> Different scenario. Because packets from Internet are
> only destined for your home gateway address, they would get locally
> delivered in the normal case, and any forwarding is an opt-in
> process on the admin's behalf.
 >
> If you used a FORWARD-DROP policy in IPv6, forwarding also becomes the
> same opt-in process. So it's not like NAT would be any magic.
> On Wednesday 2010-11-03 23:36, H. Peter Anvin wrote:

Sorry this is nonsense.  There is a huge difference -- with IPv6, the 
local prefix affect the addresses *on your internal network*, whereas 
with IPv4/NAT, they do not.  In theory, IPv4 with dynamically assigned 
publically routable blocks would have the same problem, but in practice 
those simply do not exist.

Consider for example the case where I get from my ISP the netblock 
2001:0db8:ac10::/48.  I subnet this internally with subnet numbers 
prefixed by /52 security domains, i.e 2001:0db8:ac10:0000::/52, 
2001:0db8:ac10:1000::/52 and so forth.  Accordingly, my ip6tables would 
contain rules as to what kind of traffic can flow between these prefixes.

Now, the upstream (ISP-assigned) prefix changes to 2001:6b2f:1705::/48. 
  RA will handle reassigning addresses to actual downstream hosts, but 
things that explicitly encode IPv6 addresses need to be changed, and 
that includes ip6tables, in this case these rules now need to refer to 
2001:6b2f:1705:0000::/52, 2001:62bf:1705:1000::/52 and so on.

> Different scenario. Because packets from Internet are
> only destined for your home gateway address, they would get locally
> delivered in the normal case, and any forwarding is an opt-in
> process on the admin's behalf.
>
> If you used a FORWARD-DROP policy in IPv6, forwarding also becomes the
> same opt-in process. So it's not like NAT would be any magic.

You're assuming (a) that I'm talking about a home gateway here (which 
may be, but is far from certain -- the dynamic prefixes are a design 
feature of the entire IPv6 Internet, and any entity that is not large 
enough to have direct access to BGP6 is required to handle arbitrary 
prefix changes), and (b) that I'm only concerned about entry/egress 
control, but this also affects internal control.

	-hpa

Re: rules matching ipv6 prefix addrs

[Patrick McHardy]

On 04.11.2010 03:12, H. Peter Anvin wrote:
> On 11/03/2010 06:52 PM, Jan Engelhardt wrote:
>>
>> I take it you mean a setup where addresses are automatically assigned
>> (DHCPv6, PPP).
>>
> 
> DHCPv6, PPP, RA, anything.  Keep in mind that "expect prefix changes" is
> a deliberate part of the IPv6 systems design.

Do we have a way to identify the prefix(es) in question for the ruleset?
IOW, do the userspace daemons replace the existing prefix or adds a new
one and removes the old one?

The kernel itself seems to make sure the autoconfigured local address
is always the first one on the interface. If userspace does the same
this should be pretty easy.

Re: rules matching ipv6 prefix addrs

[Jan Engelhardt]

On Thursday 2010-11-04 03:12, H. Peter Anvin wrote:
>
>Consider for example the case where I get from my ISP the netblock
>2001:0db8:ac10::/48.  I subnet this internally with subnet numbers prefixed by
>/52 security domains, i.e 2001:0db8:ac10:0000::/52, 2001:0db8:ac10:1000::/52
>and so forth.  Accordingly, my ip6tables would contain rules as to what kind of
>traffic can flow between these prefixes.
>
>Now, the upstream (ISP-assigned) prefix changes to 2001:6b2f:1705::/48.  RA
>will handle reassigning addresses to actual downstream hosts, but things that
>explicitly encode IPv6 addresses need to be changed, and that includes
>ip6tables, in this case these rules now need to refer to
>2001:6b2f:1705:0000::/52, 2001:62bf:1705:1000::/52 and so on.

Now that helps, thanks :)

You could use

 ip6tables -A FORWARD -d 0:0:0:1000::/0:0:0:ffff::

to ignore the changing prefix part.

>You're assuming (a) that I'm talking about a home gateway here (which may be,
>but is far from certain -- the dynamic prefixes are a design feature of the
>entire IPv6 Internet, and any entity that is not large enough to have direct
>access to BGP6 is required to handle arbitrary prefix changes),

I was just assuming this because I would find it highly disturbing if
my rented-servers-in-a-datacenter suddenly had their prefix changed,
for then that would also necessitate a change in the DNS zone.
If you self-host your own DNS zone to which the ISP has no write
access then goodluck.

Re: rules matching ipv6 prefix addrs

[H. Peter Anvin]

Guess what... other services like DNS needs to deal with this too, and so far has not; this is part of what needs to happen before nontrivial scale IPv6 deployment happens...

"Jan Engelhardt" <jengelh@medozas.de> wrote:

>
>On Thursday 2010-11-04 03:12, H. Peter Anvin wrote:
>>
>>Consider for example the case where I get from my ISP the netblock
>>2001:0db8:ac10::/48.  I subnet this internally with subnet numbers
>prefixed by
>>/52 security domains, i.e 2001:0db8:ac10:0000::/52,
>2001:0db8:ac10:1000::/52
>>and so forth.  Accordingly, my ip6tables would contain rules as to
>what kind of
>>traffic can flow between these prefixes.
>>
>>Now, the upstream (ISP-assigned) prefix changes to
>2001:6b2f:1705::/48.  RA
>>will handle reassigning addresses to actual downstream hosts, but
>things that
>>explicitly encode IPv6 addresses need to be changed, and that includes
>>ip6tables, in this case these rules now need to refer to
>>2001:6b2f:1705:0000::/52, 2001:62bf:1705:1000::/52 and so on.
>
>Now that helps, thanks :)
>
>You could use
>
> ip6tables -A FORWARD -d 0:0:0:1000::/0:0:0:ffff::
>
>to ignore the changing prefix part.
>
>>You're assuming (a) that I'm talking about a home gateway here (which
>may be,
>>but is far from certain -- the dynamic prefixes are a design feature
>of the
>>entire IPv6 Internet, and any entity that is not large enough to have
>direct
>>access to BGP6 is required to handle arbitrary prefix changes),
>
>I was just assuming this because I would find it highly disturbing if
>my rented-servers-in-a-datacenter suddenly had their prefix changed,
>for then that would also necessitate a change in the DNS zone.
>If you self-host your own DNS zone to which the ISP has no write
>access then goodluck.

-- 
Sent from my mobile phone.  Please pardon any lack of formatting.

Re: rules matching ipv6 prefix addrs

[Jan Engelhardt]

On Thursday 2010-11-04 12:36, H. Peter Anvin wrote:

>Guess what... other services like DNS needs to deal with this too, and 
>so far has not; this is part of what needs to happen before nontrivial 
>scale IPv6 deployment happens...

Despite what the RFCs say, IPv6 has big enough an address space that 
static addresses (prefixes) are much more likely to be handed out.

Nevertheless, did you consider

>> ip6tables -A FORWARD -d 0:0:0:1000::/0:0:0:ffff::
>>
>>to ignore the changing prefix part.

Re: rules matching ipv6 prefix addrs

[H. Peter Anvin]

On 11/04/2010 07:53 AM, Jan Engelhardt wrote:
> On Thursday 2010-11-04 12:36, H. Peter Anvin wrote:
>
>> Guess what... other services like DNS needs to deal with this too, and
>> so far has not; this is part of what needs to happen before nontrivial
>> scale IPv6 deployment happens...
>
> Despite what the RFCs say, IPv6 has big enough an address space that
> static addresses (prefixes) are much more likely to be handed out.
>

Uhm... no.  The reason we'll see dynamic prefixes isn't because of lack 
of address space but because of mandatory route aggregation (which *is* 
being implemented from the start) -- to keep BGP6 and the core routing 
tables from melting down.

> Nevertheless, did you consider
>
>>> ip6tables -A FORWARD -d 0:0:0:1000::/0:0:0:ffff::
>>>
>>> to ignore the changing prefix part.

I did, but it means reducing the level of protection given; I'd consider 
it an emergency hack.

	-hpa

Re: rules matching ipv6 prefix addrs

[Pascal Hambourg]

H. Peter Anvin a écrit :
> 
> Uhm... no.  The reason we'll see dynamic prefixes isn't because of lack 
> of address space but because of mandatory route aggregation (which *is* 
> being implemented from the start) -- to keep BGP6 and the core routing 
> tables from melting down.

Sorry to be a bit off-topic, but could you (or anyone) please explain
the relationship between dynamic prefixes and route aggregation ?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rules matching ipv6 prefix addrs

[Pascal Hambourg]

H. Peter Anvin a écrit :
> Guess what... other services like DNS needs to deal with this too,
> and so far has not; this is part of what needs to happen before nontrivial scale
> IPv6 deployment happens...

In this case, wouldn't a daemon listening for address changes and
managing all related operations such as ruleset or DNS updates, as
someone suggested in this thread, be a more generic approach ?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rules matching ipv6 prefix addrs

[Stephen Clark]

On 11/03/2010 10:12 PM, H. Peter Anvin wrote:
> On 11/03/2010 06:52 PM, Jan Engelhardt wrote:
>>
>> I take it you mean a setup where addresses are automatically assigned
>> (DHCPv6, PPP).
>>
>
> DHCPv6, PPP, RA, anything.  Keep in mind that "expect prefix changes" 
> is a deliberate part of the IPv6 systems design.
>
>> Still I don't see the problem - any security-conscious person would use
>> a drop-by-default ruleset. So a change of prefix address would, if
>> anything, cause packets to get dropped in FORWARD. (What do we have the
>> "ip6table_filter.forward" module option for? Right. And why is it set to
>> ACCEPT by default? *headshakethere*)
> >
>>> In IPv4 this is generally masked by NAT, but in IPv6 it affects every
>>> host.
>>
>> Different scenario. Because packets from Internet are
>> only destined for your home gateway address, they would get locally
>> delivered in the normal case, and any forwarding is an opt-in
>> process on the admin's behalf.
> >
>> If you used a FORWARD-DROP policy in IPv6, forwarding also becomes the
>> same opt-in process. So it's not like NAT would be any magic.
>> On Wednesday 2010-11-03 23:36, H. Peter Anvin wrote:
>
> Sorry this is nonsense.  There is a huge difference -- with IPv6, the 
> local prefix affect the addresses *on your internal network*, whereas 
> with IPv4/NAT, they do not.  In theory, IPv4 with dynamically assigned 
> publically routable blocks would have the same problem, but in 
> practice those simply do not exist.
>
> Consider for example the case where I get from my ISP the netblock 
> 2001:0db8:ac10::/48.  I subnet this internally with subnet numbers 
> prefixed by /52 security domains, i.e 2001:0db8:ac10:0000::/52, 
> 2001:0db8:ac10:1000::/52 and so forth.  Accordingly, my ip6tables 
> would contain rules as to what kind of traffic can flow between these 
> prefixes.
>
> Now, the upstream (ISP-assigned) prefix changes to 
> 2001:6b2f:1705::/48.  RA will handle reassigning addresses to actual 
> downstream hosts, but things that explicitly encode IPv6 addresses 
> need to be changed, and that includes ip6tables, in this case these 
> rules now need to refer to 2001:6b2f:1705:0000::/52, 
> 2001:62bf:1705:1000::/52 and so on.
>
Won't this break existing tcp connections if all of a sudden you get a 
new address?

>> Different scenario. Because packets from Internet are
>> only destined for your home gateway address, they would get locally
>> delivered in the normal case, and any forwarding is an opt-in
>> process on the admin's behalf.
>>
>> If you used a FORWARD-DROP policy in IPv6, forwarding also becomes the
>> same opt-in process. So it's not like NAT would be any magic.
>
> You're assuming (a) that I'm talking about a home gateway here (which 
> may be, but is far from certain -- the dynamic prefixes are a design 
> feature of the entire IPv6 Internet, and any entity that is not large 
> enough to have direct access to BGP6 is required to handle arbitrary 
> prefix changes), and (b) that I'm only concerned about entry/egress 
> control, but this also affects internal control.
>
>     -hpa
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)

Re: rules matching ipv6 prefix addrs

[Pascal Hambourg]

Stephen Clark a écrit :
>
> Won't this break existing tcp connections if all of a sudden you get a 
> new address?

Yes, but the same happened already with a variable IPv4 address, so this
is not a new problem. As I understand HPA, the new problem is that with
IPv6 the whole prefix can change.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rules matching ipv6 prefix addrs

[Stephen Clark]

On 11/04/2010 07:29 AM, Pascal Hambourg wrote:
> Stephen Clark a écrit :
>    
>> Won't this break existing tcp connections if all of a sudden you get a
>> new address?
>>      
> Yes, but the same happened already with a variable IPv4 address, so this
> is not a new problem. As I understand HPA, the new problem is that with
> IPv6 the whole prefix can change.
>
>    
Yes but when it happens there some kind of well defined event - like 
dhcp giving you a new address
and can trigger scripts that do the necessary updating of whatever needs 
to be updated. Also
I have a dynamic address that might change once or twice a year since I 
leave my system on 24/7.
This sounds like all of a sudden the ISP gives you a new prefix and "RA" 
(router advertisements ?)
let you know that you have a new address.

-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)



--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rules matching ipv6 prefix addrs

[Pascal Hambourg]

Stephen Clark a écrit :
> On 11/04/2010 07:29 AM, Pascal Hambourg wrote:
>> Stephen Clark a écrit :
>>    
>>> Won't this break existing tcp connections if all of a sudden you get a
>>> new address?
>>>      
>> Yes, but the same happened already with a variable IPv4 address, so this
>> is not a new problem. [...]
>>    
> Yes but when it happens there some kind of well defined event - like 
> dhcp giving you a new address
> and can trigger scripts that do the necessary updating of whatever needs 
> to be updated.

Right, but that does not help much to deal with broken TCP connections.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rules matching ipv6 prefix addrs

[Jozsef Kadlecsik]

On Thu, 4 Nov 2010, Stephen Clark wrote:

> > Consider for example the case where I get from my ISP the netblock
> > 2001:0db8:ac10::/48.  I subnet this internally with subnet numbers prefixed
> > by /52 security domains, i.e 2001:0db8:ac10:0000::/52,
> > 2001:0db8:ac10:1000::/52 and so forth.  Accordingly, my ip6tables would
> > contain rules as to what kind of traffic can flow between these prefixes.
> > 
> > Now, the upstream (ISP-assigned) prefix changes to 2001:6b2f:1705::/48.  RA
> > will handle reassigning addresses to actual downstream hosts, but things
> > that explicitly encode IPv6 addresses need to be changed, and that includes
> > ip6tables, in this case these rules now need to refer to
> > 2001:6b2f:1705:0000::/52, 2001:62bf:1705:1000::/52 and so on.
> > 
> Won't this break existing tcp connections if all of a sudden you get a new
> address?

Actually, not: according to the IPv6 design, the old prefix and 
address(es) should be kept until there's a single existing connection (and 
the old addresses must not be assigned to new connections of course). That 
gives a smooth path to change prefix anytime.

However, as others already expressed, that does not mean upstream should 
change the prefix anytime. The whole process is to make possible to change 
*ISP* anytime so the administrators are fully aware that there's a prefix 
issue.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: rules matching ipv6 prefix addrs

[H. Peter Anvin]

On 11/04/2010 07:08 AM, Stephen Clark wrote:
>>
>> Now, the upstream (ISP-assigned) prefix changes to
>> 2001:6b2f:1705::/48. RA will handle reassigning addresses to actual
>> downstream hosts, but things that explicitly encode IPv6 addresses
>> need to be changed, and that includes ip6tables, in this case these
>> rules now need to refer to 2001:6b2f:1705:0000::/52,
>> 2001:62bf:1705:1000::/52 and so on.
>>
> Won't this break existing tcp connections if all of a sudden you get a
> new address?
>

Yes.  Welcome to the brave new world of IPv6.  One of many reasons why 
IPv6 IMO is seriously misdesigned, but it's what we have and we no 
longer have the time to do anything else.

	-hpa

RE: rules matching ipv6 prefix addrs

[Jeff Haran]

> From: netfilter-devel-owner@vger.kernel.org
[mailto:netfilter-devel-owner@vger.kernel.org] On Behalf Of H. Peter
Anvin
>
> On 11/04/2010 07:08 AM, Stephen Clark wrote:
>>>
>>> Now, the upstream (ISP-assigned) prefix changes to 
>>> 2001:6b2f:1705::/48. RA will handle reassigning addresses to actual 
>>> downstream hosts, but things that explicitly encode IPv6 addresses 
>>> need to be changed, and that includes ip6tables, in this case these 
>>> rules now need to refer to 2001:6b2f:1705:0000::/52,
>>> 2001:62bf:1705:1000::/52 and so on.
>>>
>> Won't this break existing tcp connections if all of a sudden you get
a 
>> new address?
>>
>
>Yes.  Welcome to the brave new world of IPv6.  One of many reasons why
>IPv6 IMO is seriously misdesigned, but it's what we have and we no
longer have the time to do anything else.
>
>	-hpa

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.

Jeff Haran
Bytemobile

Re: rules matching ipv6 prefix addrs

[H. Peter Anvin]

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

Re: rules matching ipv6 prefix addrs

[Jan Engelhardt]

On Thursday 2010-11-04 15:41, H. Peter Anvin wrote:
> On 11/04/2010 07:08 AM, Stephen Clark wrote:
>>>
>>> Now, the upstream (ISP-assigned) prefix changes to
>>> 2001:6b2f:1705::/48. RA will handle reassigning addresses to actual
>>> downstream hosts, but things that explicitly encode IPv6 addresses
>>> need to be changed, and that includes ip6tables, in this case these
>>> rules now need to refer to 2001:6b2f:1705:0000::/52,
>>> 2001:62bf:1705:1000::/52 and so on.
>>>
>> Won't this break existing tcp connections if all of a sudden you get a
>> new address?
>
>Yes.  Welcome to the brave new world of IPv6.  One of many reasons why IPv6 IMO
>is seriously misdesigned, but it's what we have and we no longer have the time
>to do anything else.

Well we know academia is evil as they never talk to us on linux-netdev
when designing protocols behind closed doors.

One could also argue that IPv6 just does what it does, and that any
extra feature is layered... what you want sounds like Shim6.

Re: rules matching ipv6 prefix addrs

[H. Peter Anvin]

On 11/04/2010 03:24 PM, Jan Engelhardt wrote:
>
> On Thursday 2010-11-04 15:41, H. Peter Anvin wrote:
>> On 11/04/2010 07:08 AM, Stephen Clark wrote:
>>>>
>>>> Now, the upstream (ISP-assigned) prefix changes to
>>>> 2001:6b2f:1705::/48. RA will handle reassigning addresses to actual
>>>> downstream hosts, but things that explicitly encode IPv6 addresses
>>>> need to be changed, and that includes ip6tables, in this case these
>>>> rules now need to refer to 2001:6b2f:1705:0000::/52,
>>>> 2001:62bf:1705:1000::/52 and so on.
>>>>
>>> Won't this break existing tcp connections if all of a sudden you get a
>>> new address?
>>
>> Yes.  Welcome to the brave new world of IPv6.  One of many reasons why IPv6 IMO
>> is seriously misdesigned, but it's what we have and we no longer have the time
>> to do anything else.
>
> Well we know academia is evil as they never talk to us on linux-netdev
> when designing protocols behind closed doors.
>
> One could also argue that IPv6 just does what it does, and that any
> extra feature is layered... what you want sounds like Shim6.

Or Mobile IPv6 or whatever... however, it's unlikely that whatever 
solution is going to be universal.

	-hpa

Re: rules matching ipv6 prefix addrs

[Pascal Hambourg]

H. Peter Anvin a écrit :
> On 11/03/2010 06:52 PM, Jan Engelhardt wrote:
>> I take it you mean a setup where addresses are automatically assigned
>> (DHCPv6, PPP).

6to4 with the prefix based on a variable IPv4 address, fail-over setup
using links with different prefixes...

> DHCPv6, PPP, RA, anything.

AFAIK PPP only assigns the IPv6 link local addresses so it is not an
issue, and the global prefix must be configured by other means such as
DHCPv6.

> Keep in mind that "expect prefix changes" is 
> a deliberate part of the IPv6 systems design.

I have been using IPv6 for a few years now, and was not aware this was a
design feature. I know two ISPs here that provide IPv6, both assign a
fixed prefix. Also AFAIK IPv6 tunnel brokers assign fixed prefixes. In
my mind, "dynamic" does not necessarily mean "variable".

> Consider for example the case where I get from my ISP the netblock 
> 2001:0db8:ac10::/48.  I subnet this internally with subnet numbers 
> prefixed by /52 security domains, i.e 2001:0db8:ac10:0000::/52, 
> 2001:0db8:ac10:1000::/52 and so forth.

/52 is quite unusual. AFAIK stateless autoconfiguration requires a
prefix length of /64.

> Accordingly, my ip6tables would 
> contain rules as to what kind of traffic can flow between these prefixes.
>
> Now, the upstream (ISP-assigned) prefix changes to 2001:6b2f:1705::/48. 
> RA will handle reassigning addresses to actual downstream hosts, but 
> things that explicitly encode IPv6 addresses need to be changed, and 
> that includes ip6tables, in this case these rules now need to refer to 
> 2001:6b2f:1705:0000::/52, 2001:62bf:1705:1000::/52 and so on.

Are you talking about rules on the router which subnets the block, or on
downstream hosts ?
Also, is each subnet prefix on a separate link ?
Could you provide an example of such rules ?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rules matching ipv6 prefix addrs

[H. Peter Anvin]

On 11/04/2010 07:55 AM, Pascal Hambourg wrote:
>
>> Consider for example the case where I get from my ISP the netblock
>> 2001:0db8:ac10::/48.  I subnet this internally with subnet numbers
>> prefixed by /52 security domains, i.e 2001:0db8:ac10:0000::/52,
>> 2001:0db8:ac10:1000::/52 and so forth.
>
> /52 is quite unusual. AFAIK stateless autoconfiguration requires a
> prefix length of /64.
>

The implication in the example is that the /52 security domains each 
contain a number of /64 subnets.

>> Accordingly, my ip6tables would
>> contain rules as to what kind of traffic can flow between these prefixes.
>>
>> Now, the upstream (ISP-assigned) prefix changes to 2001:6b2f:1705::/48.
>> RA will handle reassigning addresses to actual downstream hosts, but
>> things that explicitly encode IPv6 addresses need to be changed, and
>> that includes ip6tables, in this case these rules now need to refer to
>> 2001:6b2f:1705:0000::/52, 2001:62bf:1705:1000::/52 and so on.
>
> Are you talking about rules on the router which subnets the block, or on
> downstream hosts ?
> Also, is each subnet prefix on a separate link ?
> Could you provide an example of such rules ?

I'm talking about rules on the internal router(s) which separate the 
security domains.  I can probably come up with a concrete ruleset, but 
it'll take a few days since I'm travelling at the moment.

	-hpa

Re: rules matching ipv6 prefix addrs

[Pascal Hambourg]

H. Peter Anvin a écrit :
>>>
>>> Now, the upstream (ISP-assigned) prefix changes to 2001:6b2f:1705::/48.
>>> RA will handle reassigning addresses to actual downstream hosts, but
>>> things that explicitly encode IPv6 addresses need to be changed, and
>>> that includes ip6tables, in this case these rules now need to refer to
>>> 2001:6b2f:1705:0000::/52, 2001:62bf:1705:1000::/52 and so on.
>>
>> Are you talking about rules on the router which subnets the block, or on
>> downstream hosts ?
>> Also, is each subnet prefix on a separate link ?
>> Could you provide an example of such rules ?
> 
> I'm talking about rules on the internal router(s) which separate the 
> security domains.

Isn't it enough to match the input and/or output interface(s) ?

> I can probably come up with a concrete ruleset, but 
> it'll take a few days since I'm travelling at the moment.

I am not asking for a complete ruleset, rather a few sample rules and
their purpose.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rules matching ipv6 prefix addrs

[Pascal Hambourg]

David Miller a écrit :
> 
> I thought it was painfully obvious but...  the use case is setting up
> a rule that matches the prefix addresses and having such rules still
> work properly when the link flaps onto a link with a different prefix

Sure, but what would be a use case of a rule that matches the prefix
addresses ?
Also, how is this specific to IPv6 ?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html