Kernel 2.6 IPV6 Busted

Kernel 2.6 IPV6 Busted

[Quantum Scientific]

After a week of intensive research and full-time study, it's become clear that 
IPV6 support, as it comes in standard Linux 2.6 kernels, is effectively 
non-functional.

I have a properly working firewall, but it appears there is no stateful 
filtering nor connection  tracking in the IPV6 stack.  I send out an 
echo-request, but have to open icmpv6-129 in order to get the response back.  
Same with http.  We can't open all our incoming ports.  There is no 
IP6_NF_CONNTRACK nor IP6_NF_MATCH_STATE in the kernel.  And if this 
functionality is supposed to be inherent in IPV6, it is not working.

The native IPV6 stack seems to come from oss.sgi.com .  Subscribing to your 
mailing list yields:
List context changed to 'netdev' by following command.
>> appsub netdev Info@Quantum-Sci.com 4221DB53:15AB.1:argqri
Subscribed.
---
Ecartis v1.0.0 - job execution complete.

AH!  But wait... there's no indication of what the list's address is.  Going 
to www.oss.sgi.com gives no indication of where the mailing lists are either.  
So this email is addressed to a guess.

OK, so I subscribed to USAGI.  It was recommended on that list that I install 
the USAGI kernel, but I want to only patch the Debian kernel.  So I DLed 
usagi.snap.split-tool-s20050214.tar.bz2
... however this has no kernel patch within.

So I DLed 
usagi.snap.kit-linux26-s20050214.tar.bz2
... and no kernel patch here either.  Only the kernel and tools.  I would have 
to run a USAGI-specific kernel, in order to have proper IPV6 support.  I must 
stay with the Debian kernel.

I can't believe the native kernel's IPV6 is so primitive.  I can't believe any 
kernel developers are actually using IPV6.  And I can't believe that anyone 
is actually using IPV6 with the Debian kernel.  The Debian IPV6 mailing list 
is full of spam, and brought viruses and scams to my door when I subscribed.  
No one I've asked questions of has mentioned any of this at all, so if there 
is an answer, it is clearly a secret.

So is there something I'm missing?  Am I completely fscked-up when I say that 
it doesn't work in practice, because there is no stateful packet filtering 
nor connection tracking?

Carl Cook

Re: Kernel 2.6 IPV6 Busted

[YOSHIFUJI Hideaki / 吉藤英明]

In article <200502270928.44402.Info@Quantum-Sci.com> (at Sun, 27 Feb 2005 09:28:44 -0600), Quantum Scientific <Info@Quantum-Sci.com> says:

> After a week of intensive research and full-time study, it's become clear that 
> IPV6 support, as it comes in standard Linux 2.6 kernels, is effectively 
> non-functional.

Sigh...

It is defenetely functional for me.


> usagi.snap.split-tool-s20050214.tar.bz2
> ... however this has no kernel patch within.
> 
> So I DLed 
> usagi.snap.kit-linux26-s20050214.tar.bz2
> ... and no kernel patch here either.  Only the kernel and tools.  I would have 
> to run a USAGI-specific kernel, in order to have proper IPV6 support.  I must 
> stay with the Debian kernel.

I believe you should cry at debian-ipv6 list.

And, you can find usagi kernel patch in split directory, and
you can even find (unsupported) daily kernel snapshot (diff).


> I can't believe the native kernel's IPV6 is so primitive.  I can't believe any 
> kernel developers are actually using IPV6.  And I can't believe that anyone 
> is actually using IPV6 with the Debian kernel.  The Debian IPV6 mailing list 
> is full of spam, and brought viruses and scams to my door when I subscribed.  
> No one I've asked questions of has mentioned any of this at all, so if there 
> is an answer, it is clearly a secret.

Sigh...

Even you can't believe, I actually use IPv6 in my daily life.

I use Debian kernel at first, but in most cases,
I upgrade it to latest usagi tree ASAP.
In this means, I don't usually use Debian IPv6 kernel. (sorry.)


> So is there something I'm missing?  Am I completely fscked-up when I say that 
> it doesn't work in practice, because there is no stateful packet filtering 
> nor connection tracking?

FYI, I hope nf_conntrack, which supports both ipv4 and ipv6, will be 
integrated in 2.6.12 time frame.

Note: nf_conntrack framework is designed and written by Kozakai-san.

--yoshfuji

Re: Kernel 2.6 IPV6 Busted

[Quantum Scientific]

On Sunday 27 February 2005 10:10, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> > usagi.snap.split-tool-s20050214.tar.bz2
> > ... however this has no kernel patch within.
> > 
> > So I DLed 
> > usagi.snap.kit-linux26-s20050214.tar.bz2
> > ... and no kernel patch here either.  Only the kernel and tools.  I would 
have 
> > to run a USAGI-specific kernel, in order to have proper IPV6 support.  I 
must 
> > stay with the Debian kernel.
> 
> I believe you should cry at debian-ipv6 list.
> 
> And, you can find usagi kernel patch in split directory, and
> you can even find (unsupported) daily kernel snapshot (diff).

I have 'cried' to the Debian list, and no response. (except viruses)

And I have looked at every single file in the Split directory, and there are 
absolutely no .diff files.  .diff files are how patch files are identified in 
*nix, of course.  I thought, maybe I should copy the kernel files into my 
kernel tree by hand, for building.  But this doesn't make sense because the 
only file under usagi-split/kernel/usagi/net/ipv6 is utils.c .  This is not 
an IPV6 stack, nor ip6tables.  I see lots of apps, which likely have the 
USAGI improvements, but no kernel stack, patch, ipv6filters, etc.  And no 
mention of patching a non-USAGI kernel.  Split 20050214 appears to be 
utilities only.

Please show where could I be going wrong?

Carl Cook

Re: Kernel 2.6 IPV6 Busted

[YOSHIFUJI Hideaki / 吉藤英明]

In article <200502271029.02532.Info@Quantum-Sci.com> (at Sun, 27 Feb 2005 10:29:02 -0600), Quantum Scientific <Info@Quantum-Sci.com> says:

> And I have looked at every single file in the Split directory, and there are 
> absolutely no .diff files.  .diff files are how patch files are identified in 
> *nix, of course.  I thought, maybe I should copy the kernel files into my 
> kernel tree by hand, for building.  But this doesn't make sense because the 
> only file under usagi-split/kernel/usagi/net/ipv6 is utils.c .  This is not 
> an IPV6 stack, nor ip6tables.  I see lots of apps, which likely have the 
> USAGI improvements, but no kernel stack, patch, ipv6filters, etc.  And no 
> mention of patching a non-USAGI kernel.  Split 20050214 appears to be 
> utilities only.

Don't you find diff files?! e.g:
  ftp://ftp.linux-ipv6.org/pub/usagi/snap/split/usagi-linux26-s20050214-2.6.11-rc3.diff.bz2
is patch against linux-2.6.11-rc3.

--yoshfuji

Re: Kernel 2.6 IPV6 Busted

[Quantum Scientific]

On Sunday 27 February 2005 11:28, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> Don't you find diff files?! e.g:
>   
ftp://ftp.linux-ipv6.org/pub/usagi/snap/split/usagi-linux26-s20050214-2.6.11-rc3.diff.bz2
> is patch against linux-2.6.11-rc3.

I see.  I was talking about the downloadable split and kit archives, and you 
were talking about what's on FTP, which I didn't expect to be different.

I'm hoping some of my vociferous effort to make this go, will help improve 
things down the line.  IPV6 is extremely difficult to implement at the 
moment.

Here's hoping the USAGI linux-2.6.10-rc3 diff fits in Debian 
kernel-source-2.6.10-5.  Back to work...

Carl Cook

Re: Kernel 2.6 IPV6 Busted

[Horms]

On Sun, Feb 27, 2005 at 10:29:02AM -0600, Quantum Scientific wrote:
> On Sunday 27 February 2005 10:10, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> > > usagi.snap.split-tool-s20050214.tar.bz2
> > > ... however this has no kernel patch within.
> > > 
> > > So I DLed 
> > > usagi.snap.kit-linux26-s20050214.tar.bz2
> > > ... and no kernel patch here either.  Only the kernel and tools.  I would 
> have 
> > > to run a USAGI-specific kernel, in order to have proper IPV6 support.  I 
> must 
> > > stay with the Debian kernel.
> > 
> > I believe you should cry at debian-ipv6 list.
> > 
> > And, you can find usagi kernel patch in split directory, and
> > you can even find (unsupported) daily kernel snapshot (diff).
> 
> I have 'cried' to the Debian list, and no response. (except viruses)

If you have feedback on the Debian kernel, debian-kernel@lists.debian.org 
is the place. Though your problems seem to mostly relate to 
the Kernel.Org kernel, so this is probably a better fourum.

-- 
Horms

Re: Kernel 2.6 IPV6 Busted

[Andre Tomt]

Quantum Scientific wrote:
> After a week of intensive research and full-time study, it's become clear that 
> IPV6 support, as it comes in standard Linux 2.6 kernels, is effectively 
> non-functional.
> 
> I have a properly working firewall, but it appears there is no stateful 
> filtering nor connection  tracking in the IPV6 stack.  I send out an 
> echo-request, but have to open icmpv6-129 in order to get the response back.  
> Same with http.  We can't open all our incoming ports.  There is no 
> IP6_NF_CONNTRACK nor IP6_NF_MATCH_STATE in the kernel.  And if this 
> functionality is supposed to be inherent in IPV6, it is not working.

Connection tracking (as in stateful firewalling) do not a useful ipv6 
stack make.. The stack works fine, at least the stack provided in 2.6 
kernels. The 2.4 stack is severely out of date, however, but should "work".

Connection tracking is on the way, currently a implementation exists in 
the netfilter.org patch-o-matic svn.

<snip>

> I must stay with the Debian kernel.

Debian ships 2.6.8 with ipv6 enabled in Sarge. Not sure about Woody, but 
its ought to be rather outdated by now ;-)

> I can't believe the native kernel's IPV6 is so primitive.  I can't believe any 
> kernel developers are actually using IPV6.  And I can't believe that anyone 
> is actually using IPV6 with the Debian kernel.  The Debian IPV6 mailing list 
> is full of spam, and brought viruses and scams to my door when I subscribed.  
> No one I've asked questions of has mentioned any of this at all, so if there 
> is an answer, it is clearly a secret.

> So is there something I'm missing?  Am I completely fscked-up when I say that 
> it doesn't work in practice, because there is no stateful packet filtering 
> nor connection tracking?

You seem to be fixed on the idea that a ipv6 stack has to have stateful 
firewalling, or else its utter crap, correct? :-)

Not all hosts need firewalling at all, or firewalling is provided by 
routers/firewalls for them. I use ipv6 in production networks, on Linux, 
without special patches.

Re: Kernel 2.6 IPV6 Busted

[Quantum Scientific]

On Sunday 27 February 2005 11:40, Andre Tomt wrote:
> Connection tracking (as in stateful firewalling) do not a useful ipv6 
> stack make.. The stack works fine, at least the stack provided in 2.6 
> kernels.
...
> You seem to be fixed on the idea that a ipv6 stack has to have stateful 
> firewalling, or else its utter crap, correct? :-)

No, I'll try to say this clearer.

The stack works fine in.  And out.  But for a useful virtual circuit you must 
have something like connection tracking.

Remember what my issue is:  
- I have a very tight firewall,
- I ping6 out,
- The firewall blocks the reply back, because the connection is stateless!
- Same with http, etc.

This means that I have to open for incoming, virtually every port I send 
outgoing to, or else I do not get any replies. This is what I call 
non-functional, because one does not open incoming ports, for the most part.

Why are you not having this problem?


> Connection tracking is on the way, currently a implementation exists in 
> the netfilter.org patch-o-matic svn.

Is this reasonably solid?  Does this operate on Layer 3, rather than Layer 2?


> Not all hosts need firewalling at all, or firewalling is provided by 
> routers/firewalls for them. I use ipv6 in production networks, on Linux, 
> without special patches.

Sorry, I disagree.  The whole point of IPV6 is ubiquitous addressing.  So 
every single node must have a good firewall.  In fact my router is 
firewalling as well, so my LAN nodes are double-firewalled.

It is irresponsible to not firewall all nodes, as they are supposed to be 
universally available with this paradigm.

Carl Cook

Re: Kernel 2.6 IPV6 Busted

[Jeff Garzik]

Quantum Scientific wrote:
> On Sunday 27 February 2005 11:40, Andre Tomt wrote:
> 
>>Connection tracking (as in stateful firewalling) do not a useful ipv6 
>>stack make.. The stack works fine, at least the stack provided in 2.6 
>>kernels.
> 
> ...
> 
>>You seem to be fixed on the idea that a ipv6 stack has to have stateful 
>>firewalling, or else its utter crap, correct? :-)
> 
> 
> No, I'll try to say this clearer.
> 
> The stack works fine in.  And out.  But for a useful virtual circuit you must 
> have something like connection tracking.
> 
> Remember what my issue is:  
> - I have a very tight firewall,
> - I ping6 out,
> - The firewall blocks the reply back, because the connection is stateless!
> - Same with http, etc.
> 
> This means that I have to open for incoming, virtually every port I send 
> outgoing to, or else I do not get any replies. This is what I call 
> non-functional, because one does not open incoming ports, for the most part.
> 
> Why are you not having this problem?

Connection tracking doesn't scale.  It's impossible to hash the entire 
Internet.

	Jeff

Re: Kernel 2.6 IPV6 Busted

[Quantum Scientific]

On Sunday 27 February 2005 12:59, Jeff Garzik wrote:
> Connection tracking doesn't scale.  It's impossible to hash the entire 
> Internet.

I have read this.  

And I've seen inferences that IPV6 takes care of this problem somehow 
automatically.  But no one seems to know how.

Carl Cook

Re: Kernel 2.6 IPV6 Busted

[Jeff Garzik]

Quantum Scientific wrote:
> On Sunday 27 February 2005 12:59, Jeff Garzik wrote:
> 
>>Connection tracking doesn't scale.  It's impossible to hash the entire 
>>Internet.
> 
> 
> I have read this.  
> 
> And I've seen inferences that IPV6 takes care of this problem somehow 
> automatically.  But no one seems to know how.

The solution is to not use connection tracking.

You don't want to break the end-to-end connection model that founded the 
Internet.

	Jeff

Re: Kernel 2.6 IPV6 Busted

[Quantum Scientific]

Are you not understanding that I need to receive packets back?  I am not going 
to open incoming firewall ports to do this.  If you have a way to receive 
IPV6 response packets back without opening up your firewall, please enlighten 
us.

This is a problem everyone else has too, if they are using the standard kernel 
2.6 IPV6 stack.

I am skeptical about this assertion that the whole internet needs to be hashed 
if connection tracking.  This does not seem to be true on its face.  Only 
those nodes which are in active virtual circuits would need to be hashed.  
This is well within most machines' capability.  So barring some inherent IPV6 
way of doing this, connection tracking is on.

Carl Cook



On Sunday 27 February 2005 13:58, Jeff Garzik wrote:
> Quantum Scientific wrote:
> > On Sunday 27 February 2005 12:59, Jeff Garzik wrote:
> > 
> >>Connection tracking doesn't scale.  It's impossible to hash the entire 
> >>Internet.
> > 
> > 
> > I have read this.  
> > 
> > And I've seen inferences that IPV6 takes care of this problem somehow 
> > automatically.  But no one seems to know how.
> 
> The solution is to not use connection tracking.
> 
> You don't want to break the end-to-end connection model that founded the 
> Internet.
> 
>  Jeff

Re: Kernel 2.6 IPV6 Busted

[David S. Miller]

On Sun, 27 Feb 2005 14:10:39 -0600
Quantum Scientific <Info@quantum-sci.com> wrote:

> I am skeptical about this assertion that the whole internet needs to be hashed 
> if connection tracking.

Connection tracking and NAT broke entirely the end-to-end host
assumption that used to be valid on the internet.

There are many very important optimizations we've had to disable
by default just in TCP alone because of NAT.

Re: Kernel 2.6 IPV6 Busted

[Denis Vlasenko]

On Sunday 27 February 2005 23:35, David S. Miller wrote:
> On Sun, 27 Feb 2005 14:10:39 -0600
> Quantum Scientific <Info@quantum-sci.com> wrote:
> 
> > I am skeptical about this assertion that the whole internet needs to be hashed 
> > if connection tracking.
> 
> Connection tracking and NAT broke entirely the end-to-end host
> assumption that used to be valid on the internet.
> 
> There are many very important optimizations we've had to disable
> by default just in TCP alone because of NAT.

I don't think future Internet will be safe enough to open
corporate networks. I definitely won't do it.
NAT firewall in front of my net is an absolute requirement
for me.

However, IPv6 in Internet won't happen tomorrow,
no rush...
--
vda

Re: Kernel 2.6 IPV6 Busted

[Quantum Scientific]

On Tuesday 01 March 2005 4:07, Denis Vlasenko wrote:
> I don't think future Internet will be safe enough to open
> corporate networks. I definitely won't do it.
> NAT firewall in front of my net is an absolute requirement
> for me.

I agree that security is an absolute must.  It's irresponsible to contend 
otherwise.

But black-box NAT is just *simulating* what a well-made ip6tables firewall 
does much better.  There's no reason every node can't be secure, except the 
expertise of the script designer.  This is why I wish Shorewall would support 
IPV6.

Carl Cook

Re: Kernel 2.6 IPV6 Busted

[Jeff Garzik]

Denis Vlasenko wrote:
> On Sunday 27 February 2005 23:35, David S. Miller wrote:
> 
>>On Sun, 27 Feb 2005 14:10:39 -0600
>>Quantum Scientific <Info@quantum-sci.com> wrote:
>>
>>
>>>I am skeptical about this assertion that the whole internet needs to be hashed 
>>>if connection tracking.
>>
>>Connection tracking and NAT broke entirely the end-to-end host
>>assumption that used to be valid on the internet.
>>
>>There are many very important optimizations we've had to disable
>>by default just in TCP alone because of NAT.
> 
> 
> I don't think future Internet will be safe enough to open
> corporate networks. I definitely won't do it.
> NAT firewall in front of my net is an absolute requirement
> for me.
> 
> However, IPv6 in Internet won't happen tomorrow,
> no rush...

You don't need NAT to secure a corporate network.

Just write sane firewall rules that don't allow incoming.

	Jeff

Re: Kernel 2.6 IPV6 Busted

[Tomasz Torcz]

On Tue, Mar 01, 2005 at 11:26:34AM -0500, Jeff Garzik wrote:
> Just write sane firewall rules that don't allow incoming.

 Isn't this thread about non-working stateful firewalling? Specifically
situation where -m state --state RELATED or ESTABLISHED isn't allowin
any packets because there is no connection tracking? Without allowing
incoming packets there could be no 2-way communication (for UDP at
least).

-- 
Tomasz Torcz               "Never underestimate the bandwidth of a station
zdzichu@irc.-nie.spam-.pl    wagon filled with backup tapes." -- Jim Gray

Re: Kernel 2.6 IPV6 Busted

[Quantum Scientific]

On Tuesday 01 March 2005 14:46, Tomasz Torcz wrote:
> On Tue, Mar 01, 2005 at 11:26:34AM -0500, Jeff Garzik wrote:
> > Just write sane firewall rules that don't allow incoming.
> 
>  Isn't this thread about non-working stateful firewalling? Specifically
> situation where -m state --state RELATED or ESTABLISHED isn't allowin
> any packets because there is no connection tracking? Without allowing
> incoming packets there could be no 2-way communication (for UDP at
> least).

Right.  Nor for any of the other protocols.  No incoming packets.

Carl Cook

Re: Kernel 2.6 IPV6 Busted

[Denis Vlasenko]

On Tuesday 01 March 2005 18:26, Jeff Garzik wrote:
> >>There are many very important optimizations we've had to disable
> >>by default just in TCP alone because of NAT.
> > 
> > I don't think future Internet will be safe enough to open
> > corporate networks. I definitely won't do it.
> > NAT firewall in front of my net is an absolute requirement
> > for me.
> > 
> > However, IPv6 in Internet won't happen tomorrow,
> > no rush...
> 
> You don't need NAT to secure a corporate network.

I don't want outside world to even KNOW that I have a network
behind the firewall box. I don't want them to know
internal hosts' IPs.
--
vda

Re: Kernel 2.6 IPV6 Busted

[Jeff Garzik]

Denis Vlasenko wrote:
> On Tuesday 01 March 2005 18:26, Jeff Garzik wrote:
> 
>>>>There are many very important optimizations we've had to disable
>>>>by default just in TCP alone because of NAT.
>>>
>>>I don't think future Internet will be safe enough to open
>>>corporate networks. I definitely won't do it.
>>>NAT firewall in front of my net is an absolute requirement
>>>for me.
>>>
>>>However, IPv6 in Internet won't happen tomorrow,
>>>no rush...
>>
>>You don't need NAT to secure a corporate network.
> 
> 
> I don't want outside world to even KNOW that I have a network
> behind the firewall box. I don't want them to know
> internal hosts' IPs.

  ...thus breaking the end-to-end connection model, and various protocols.

	Jeff

Re: Kernel 2.6 IPV6 Busted

[Andre Tomt]

Quantum Scientific wrote:
> On Sunday 27 February 2005 11:40, Andre Tomt wrote:
>>You seem to be fixed on the idea that a ipv6 stack has to have stateful 
>>firewalling, or else its utter crap, correct? :-)
> 
> 
> No, I'll try to say this clearer.
> 
> The stack works fine in.  And out.  But for a useful virtual circuit you must 
> have something like connection tracking.
> 
> Remember what my issue is:  
> - I have a very tight firewall,
> - I ping6 out,
> - The firewall blocks the reply back, because the connection is stateless!

Never, ever, filter ICMP. Or at least be extremely careful doing so. You 
may end up breaking things like PMTU and error notification mechanisms.

> - Same with http, etc.
> 
> This means that I have to open for incoming, virtually every port I send 
> outgoing to, or else I do not get any replies. This is what I call 
> non-functional, because one does not open incoming ports, for the most part.
> 
> Why are you not having this problem?

Because I tend to use the oldskool way of doing it when there is not 
other option, by matching on SYN. It's a bit trickier with UDP, but 
doable for most UDP based protocols.

Also on a per-system basis I tend to prefer to secure services rather 
than firewall them; by for example just shutting them off/uninstalling 
them if not used, binding to localhost, use tcpwrappers.. that sort of 
thing.

Don't get me wrong; I'd *love* to see connection tracking integrated 
with ipv6 netfilter. It would simplify some of my setups greatly. But it 
would also be out of the question on a lot of my other setups; as 
connection tracking is a *severe* bottleneck when faced with any real 
amounts of load.

It's not The universal solution, and the lack of it is not *that* bad.

>>Connection tracking is on the way, currently a implementation exists in 
>>the netfilter.org patch-o-matic svn.
> 
> 
> Is this reasonably solid?  Does this operate on Layer 3, rather than Layer 2?

It operates like the IPv4 state matches. Solid? Well, I guess testers 
are welcome :)

Re: Kernel 2.6 IPV6 Busted

[Quantum Scientific]

On Tuesday 01 March 2005 15:50, Andre Tomt wrote:
> > Remember what my issue is:  
> > - I have a very tight firewall,
> > - I ping6 out,
> > - The firewall blocks the reply back, because the connection is stateless!
> Never, ever, filter ICMP. Or at least be extremely careful doing so. You 
> may end up breaking things like PMTU and error notification mechanisms.

Care to propose some rules?  Maybe not.

 
> Also on a per-system basis I tend to prefer to secure services rather 
> than firewall them; by for example just shutting them off/uninstalling 
> them if not used, binding to localhost, use tcpwrappers.. that sort of 
> thing.

Of course.  This is implicit.  But closing everything is best, to avert investigative activity.

Carl Cook

Re: Kernel 2.6 IPV6 Busted

[Jeff Garzik]

Quantum Scientific wrote:
> After a week of intensive research and full-time study, it's become clear that 
> IPV6 support, as it comes in standard Linux 2.6 kernels, is effectively 
> non-functional.

Strange how I use this non-functional support every day.


> I have a properly working firewall, but it appears there is no stateful 
> filtering nor connection  tracking in the IPV6 stack.  I send out an 

> So is there something I'm missing?  Am I completely fscked-up when I say that 
> it doesn't work in practice, because there is no stateful packet filtering 
> nor connection tracking?

Yes.  IPv6 does not need NAT'ing.  Everyone should have a global 
address.  Connection tracking is not needed.

	Jeff