Some time ago Linux was first OS to have full RFC complaint IPv4 stack.
Linux still has superior networking, but protocol of the future is IPv6.
IPv6 stack in mainline is currently far from perfect. There is a hope,
however. Full IPv6 stack is beeing mantained by USAGI project. It's
clear, that USAGI's project will be integrated into mainline kernel.
What worries me - it's planned for 2.7, what is _BAD_ and late.
IMO, it can be included in any time. The sooner is better.
Marcelo - would you include full IPv6 stack in 2.4.20 if you get patches?
Please - it's important for Linux to be network OS choice in future.
It's barely possible with current IPv6 implementation.
My another concern is that Linux on Sparc machines is very unstable,
and main polish 6bone router - beeing a sparc machine - is not very
reliable. But that's another story.
--
Tomasz Torcz Zjadanie martwych dzieci
[email protected] jest barbarzynstwem!
From: "Tomasz Torcz, BG" <[email protected]>
Date: Mon, 19 Aug 2002 06:39:41 +0200
Linux still has superior networking, but protocol of the future is IPv6.
That is your opinion. This is what people have been saying since some
6 or 7 years ago, and ipv6 has not moved much further out of
experimental state since then.
Full IPv6 stack is beeing mantained by USAGI project.
Yes, and based upon previous attempts to get them to merge their work
into the mainline, we believe at this point that they actually enjoy
being a totally seperate project and not merging completely is a
feature for them.
USAGI may only accept that comment, and the only way they may
disprove it is to merge their code to us as we have continually
requested them to do so.
In my opinion, USAGI has been given more than adequate opportunities
to merge their entire work into the mainline. Alexey Kuznetsov has
asked them repeatedly over the years to merge with him, yet they
always fail to do so completely. Occaisionally one or two trivially
bug fixes they are able to merge, but otherwise their efforts always
fall short.
They claim they wish to merge so badly, yet act in opposite manner.
It is almost disgraceful and I am so tired of this continual public
propaganda that tries to make it look as if Alexey and myself are to
blame for this.
On Sun, Aug 18, 2002 at 09:37:19PM -0700, David S. Miller wrote:
>
> In my opinion, USAGI has been given more than adequate opportunities
> to merge their entire work into the mainline. Alexey Kuznetsov has
> asked them repeatedly over the years to merge with him, yet they
> always fail to do so completely. Occaisionally one or two trivially
> bug fixes they are able to merge, but otherwise their efforts always
> fall short.
what's about with:
o Full compliance with IPv6 (Alexey Kuznetzov, Jun Murai, Yoshifuji Hideaki, USAGI team)
in things mos likely to be merged in 2.5 (http://kerneltrap.org/node.php?id=348)?
I thought that Alexey and USAGI were cooperating.
--
Tomasz Torcz Zjadanie martwych dzieci
[email protected] jest barbarzynstwem!
From: "Tomasz Torcz, BG" <[email protected]>
Date: Mon, 19 Aug 2002 07:16:23 +0200
I thought that Alexey and USAGI were cooperating.
Alexey is asking USAGI folks for patches, they are not
responding.
On Mon, Aug 19, 2002 at 06:39:41AM +0200, Tomasz Torcz, BG wrote:
Linux still has superior networking, but protocol of the future is
IPv6.
Nope, not anytime soon.
--cw
On Mon, 2002-08-19 at 05:39, Tomasz Torcz, BG wrote:
>
> Some time ago Linux was first OS to have full RFC complaint IPv4 stack.
There are no fully RFC compliant IPv4 stacks. The Linux networking stack
is not capable of jumping over tall buildings.
On 19 Aug 2002, Alan Cox wrote:
> On Mon, 2002-08-19 at 05:39, Tomasz Torcz, BG wrote:
> >
> > Some time ago Linux was first OS to have full RFC complaint IPv4 stack.
>
> There are no fully RFC compliant IPv4 stacks. The Linux networking stack
> is not capable of jumping over tall buildings.
aha, but it is faster than a speeding bullet, and more powerful than a
locomotive!
Hi,
On Sun, 18 Aug 2002, David S. Miller wrote:
> Linux still has superior networking, but protocol of the future is IPv6.
>
> That is your opinion. This is what people have been saying since some
> 6 or 7 years ago, and ipv6 has not moved much further out of
> experimental state since then.
We're using it for years now. Works well, made me incredibly happy ever
since. Just too cool thing.
Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-
From: Thunder from the hill <[email protected]>
Date: Mon, 19 Aug 2002 17:34:51 -0600 (MDT)
We're using it for years now. Works well, made me incredibly happy ever
since. Just too cool thing.
The keyword is "you", you are using is locally at your site.
There are zero backbone ipv6 routers, everyone is still tunneling
or has a custom network layout for their usage.
On Mon, 19 Aug 2002, David S. Miller wrote:
> From: Thunder from the hill <[email protected]>
> Date: Mon, 19 Aug 2002 17:34:51 -0600 (MDT)
>
> We're using it for years now. Works well, made me incredibly happy ever
> since. Just too cool thing.
>
> The keyword is "you", you are using is locally at your site.
>
> There are zero backbone ipv6 routers, everyone is still tunneling
> or has a custom network layout for their usage.
Errr, not quite:
>From a presentation entitled "Commercial IPV6 at Worldcom"
Page 6
vBNS+ IPv6 Service Overview
* Native (not tunneled) IPv6-over-ATM
backbone since July 1998
* Dedicated hardware (Cisco 4700s and a
7507 with OC3/ATM) for IPv6 routing.
* Full mesh of ATM PVCs among the IPv6
routers.
* Backbone provider (pTLA) for the global
6bone.
There are other backbone ipv6 routers, too, that are non-tunneled.
--Dan
Daniel Berlin responded to:
> David S. Miller, who wrote:
> >
> > There are zero backbone ipv6 routers, everyone is still tunneling
> > or has a custom network layout for their usage.
>
> Errr, not quite:
>
> From a presentation entitled "Commercial IPV6 at Worldcom"
True, and we're starting to plan a migration to IPv6 on our statewide
network. Lots of advantages to IPv6. I'd love to have decent
support in the kernel -- i've tried various configurations and never
was able to keep anything stable, direct or tunneled.
On Tue, 2002-08-20 at 00:23, David S. Miller wrote:
> From: Thunder from the hill <[email protected]>
> Date: Mon, 19 Aug 2002 17:34:51 -0600 (MDT)
>
> We're using it for years now. Works well, made me incredibly happy ever
> since. Just too cool thing.
>
> The keyword is "you", you are using is locally at your site.
>
> There are zero backbone ipv6 routers, everyone is still tunneling
> or has a custom network layout for their usage.
That will begin to change. The twenty year expiry for all the potential
lunatic submarine patents on IPv6 stuff will expire in a few years. And
while many vendors and big carriers won't publically admit it that is
one of the current major concerns.
3G phones might help too, although they seem to have gone down the
cosmic toilet pan in the short term
On Mon, 19 Aug 2002, David S. Miller wrote:
> There are zero backbone ipv6 routers, everyone is still tunneling
> or has a custom network layout for their usage.
Actually, there are a few sites busy shutting down most of
their tunnels since they've got good enough native ipv6
peering now.
It's true that 90% of the internet doesn't have native ipv6
yet, but don't underestimate the rest of the net.
It would be nice if Linux was better at ipv6 ;)
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
On Mon, Aug 19, 2002 at 01:25:35PM +0100, Alan Cox wrote:
> On Mon, 2002-08-19 at 05:39, Tomasz Torcz, BG wrote:
> >
> > Some time ago Linux was first OS to have full RFC complaint IPv4 stack.
>
> There are no fully RFC compliant IPv4 stacks. The Linux networking stack
> is not capable of jumping over tall buildings.
And you'd know that if you'd played the TCP/IP drinking game:
http://www.nmt.edu/~val/tcpip.html
You're not cool unless you've submitted a question. All the other
kids are doing it!
-VAL
Hi,
On Mon, 19 Aug 2002, David S. Miller wrote:
> The keyword is "you", you are using is locally at your site.
>
> There are zero backbone ipv6 routers, everyone is still tunneling
> or has a custom network layout for their usage.
Not quite (see other posts). And, not to mention, there are lots of other
huge networks than the Internet, some of them already are on IPv6. There
are also parts of the Internet that are just tunneling your IPv4
connection over IPv6. But you won't exactly notice.
Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-
Hello!
> It would be nice if Linux was better at ipv6 ;)
Linux IPv6 is parallel to IP, except for some minor scalability issues.
Shortly, it is not better and not worse.
Alexey
On Mon, 19 Aug 2002, David S. Miller wrote:
> From: Thunder from the hill <[email protected]>
> Date: Mon, 19 Aug 2002 17:34:51 -0600 (MDT)
>
> We're using it for years now. Works well, made me incredibly happy ever
> since. Just too cool thing.
>
> The keyword is "you", you are using is locally at your site.
>
> There are zero backbone ipv6 routers, everyone is still tunneling
> or has a custom network layout for their usage.
And it's the condescending, "Nobody else uses it, why should I?" attitude
that will prevent it from gaining more popularity. There are people using
it. There are people who want to see it mainstreamed. Face it, IPv4 is
inadequate for today's needs. What happens when the entire IPv4 addressing
space is exhausted? Move to NAT? I don't think so. NAT is a temporary solution
to a permanent problem, and IMO the wrong solution. There are still
applications out there where bona fide end-to-end transparency is still a
requirement. NAT destroys that, and therefore makes those applications
either unusable, or difficult to use without special configurations.
No, IPv6 may not be mainstream yet, but there *are* people who want to use
it. Just because you don't, doesn't mean that nobody else should. I, for
one, will welcome IPv6's adoption with open arms.
Kelsey Hudson [email protected]
Software Engineer/UNIX Systems Administrator
Compendium Technologies, Inc (619) 725-0771
---------------------------------------------------------------------------
In article <Pine.LNX.4.44.0208211316480.6621-100000@betelgeuse.compendium-tech.com> you wrote:
> it. There are people who want to see it mainstreamed. Face it, IPv4 is
> inadequate for today's needs. What happens when the entire IPv4 addressing
> space is exhausted? Move to NAT? I don't think so.
Well, I think the worlds oil ressources will be exhausted before the IPv4
Space is exhausted. There are a lot of possible ways.
> requirement. NAT destroys that, and therefore makes those applications
> either unusable, or difficult to use without special configurations.
well.. another option is, to write sane applications.
> No, IPv6 may not be mainstream yet, but there *are* people who want to use
> it. Just because you don't, doesn't mean that nobody else should. I, for
> one, will welcome IPv6's adoption with open arms.
i am using it on my personal family lan and to connect to irc servers, but I
dont see it becoming mainstream this decade. Hell, even there is no accepted
DNS standard, yet.
Greetings
Bernd
Hi,
On Wed, 21 Aug 2002, Bernd Eckenfels wrote:
> well.. another option is, to write sane applications.
When you'll have to connect through a NAT wall to a server, you'll be damn
ot of luck. And the possibility to achieve something in a weird way
through a ten thousand of backdoors does not justify the dismissal of a
cool technology that would make it just too easy to handle. Not to
mention IPv4 is far too dangerous. I've had to write heaps of reports
saying that you can spoof a personality using IPv4 security holes, just
because some person was under accusation of things he's never done.
Remember Rubin Carter, 1976?
> Hell, even there is no accepted DNS standard, yet.
I'm getting through with bind9 pretty well, actually.
Well, one can argue about the advantages of extended technology, but as
long as they can save lifes (philosophically speaking), no way to argue
with me. I'd never let people get arrested because I don't have ganas to
introduce newer technologies! Do you understand my point?
Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-
On Wed, Aug 21, 2002 at 03:44:41PM -0600, Thunder from the hill wrote:
> I'm getting through with bind9 pretty well, actually.
ip6.int? nibbles? reverse byte? ip6.arpa? A6? AAAA?
Greetings
Bernd
On Wed, 2002-08-21 at 22:44, Thunder from the hill wrote:
> When you'll have to connect through a NAT wall to a server, you'll be damn
> ot of luck. And the possibility to achieve something in a weird way
> through a ten thousand of backdoors does not justify the dismissal of a
> cool technology that would make it just too easy to handle. Not to
> mention IPv4 is far too dangerous. I've had to write heaps of reports
> saying that you can spoof a personality using IPv4 security holes, just
> because some person was under accusation of things he's never done.
> Remember Rubin Carter, 1976?
With the exception that IPv6 avoids the IPsec/fragmentation required
contradiction its no more secure. Network security is basically nil.
When you look at the kind of web of trust required to fix it and how
easily 'trusted' crypto companies are scammed I dont think its fixable
So IPv6 neither helps nor hinders
On Thu, Aug 22, 2002 at 12:03:13AM +0200, Bernd Eckenfels wrote:
> On Wed, Aug 21, 2002 at 03:44:41PM -0600, Thunder from the hill wrote:
> > I'm getting through with bind9 pretty well, actually.
>
> ip6.int? nibbles? reverse byte? ip6.arpa? A6? AAAA?
There are numerous self-consistent comments by people in the know (who
are even working on some of the standards) about the current direction
that the above is going.
If you need some URLs, ask me off list and I'll send you some of the
ones that represent the current practice.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Thu, Aug 22, 2002 at 12:13:01AM +0100, Russell King wrote:
> If you need some URLs, ask me off list and I'll send you some of the
> ones that represent the current practice.
i nkow the current practise, the fact is, that the current practise isnt
worth half a year of experience.
greetings
bernd
Hi,
On Thu, 22 Aug 2002, Bernd Eckenfels wrote:
> ip6.int? nibbles? reverse byte? ip6.arpa? A6? AAAA?
Give it an AAAA entry. Works.
Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-
Hi,
On 21 Aug 2002, Alan Cox wrote:
> So IPv6 neither helps nor hinders
Well, it's not too easy any more to say "I am the Alan Cox client. Send me
naked children." If you were ever hit by that or similar, you'd certainly
think differently, once you've seen that these "tools" for IPv4 are
mainstream, while the tools for IPv6 are rather rare, and the fake packets
got discarded anyway. If they're unlikely to be discarded -- I can't
agree. They just were.
Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-
On Thu, 22 Aug 2002, Thunder from the hill wrote:
> On 21 Aug 2002, Alan Cox wrote:
> > So IPv6 neither helps nor hinders
>
> Well, it's not too easy any more to say "I am the Alan Cox client. Send me
> naked children." If you were ever hit by that or similar, you'd certainly
> think differently, once you've seen that these "tools" for IPv4 are
> mainstream, while the tools for IPv6 are rather rare, and the fake packets
> got discarded anyway. If they're unlikely to be discarded -- I can't
> agree. They just were.
Filtering is a question of proper ingress/egress setup by
the ISPs. This is fairly common in the ipv4 world, but
not yet common enough.
The ipv6 world hasn't yet started _route filtering_, let
alone ingress/egress filtering ;)
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
On Thu, 2002-08-22 at 07:12, Thunder from the hill wrote:
> Well, it's not too easy any more to say "I am the Alan Cox client. Send me
> naked children." If you were ever hit by that or similar, you'd certainly
> think differently, once you've seen that these "tools" for IPv4 are
Its trivial. IPv4 or IPv6 it takes a couple of minutes of fiddling from
a suitably connected point. I wouldnt actually bother with that anyway,
the people who maintain web cache logs are normally paid so little that
$1000 for running a provided script really would be less hassle for your
budding organised criminal or government agent.
There is no difference in the security between IPv4 and IPv6. None at
all.
In article <[email protected]> you wrote:
> Well, it's not too easy any more to say "I am the Alan Cox client. Send me
> naked children." If you were ever hit by that or similar, you'd certainly
> think differently, once you've seen that these "tools" for IPv4 are
> mainstream, while the tools for IPv6 are rather rare,
do you mean ipspoofing tools for v4 are mainstream and for v6 are not, thats
why v6 is more secure?
v6 isnt more secure than v4, and i suspect ipsec is more widely used in v4
than in v6, and i doubt it will ever be used on default.
Greetings
Bernd
On Thu, Aug 22, 2002 at 08:26:49PM +0200, Bernd Eckenfels wrote:
> v6 isnt more secure than v4, and i suspect ipsec is more widely used in v4
> than in v6, and i doubt it will ever be used on default.
Remember also that our v6 firewall infrastructure isn't as advanced as
its v4 counterpart. v6 connection tracking? sorry, we don't have that.
IMHO v6 firewalling code is currently where the 2.2 kernels are.
(Disclaimer: I'm not going to get into a discussion about the advantages /
disadvantages of connection tracking wrt security.)
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Thu, 22 Aug 2002, Bernd Eckenfels wrote:
> On Wed, Aug 21, 2002 at 03:44:41PM -0600, Thunder from the hill wrote:
> > I'm getting through with bind9 pretty well, actually.
>
> ip6.int? nibbles? reverse byte? ip6.arpa? A6? AAAA?
It looks like nibble format and quad-A records are the de-facto standard.
I'd expect them to become a finalized standard here shortly. BIND supports
all these, however...
Kelsey Hudson [email protected]
Software Engineer/UNIX Systems Administrator
Compendium Technologies, Inc (619) 725-0771
---------------------------------------------------------------------------
On Mon, Aug 26, 2002 at 11:55:29AM -0700, Kelsey Hudson wrote:
> It looks like nibble format and quad-A records are the de-facto standard.
> I'd expect them to become a finalized standard here shortly. BIND supports
> all these, however...
which is exactly what i am saying. IPv6 is not yet standardized enough.
Greetings
Bernd
On Mon, Aug 26, 2002 at 11:55:29AM -0700, Kelsey Hudson wrote:
> On Thu, 22 Aug 2002, Bernd Eckenfels wrote:
> > On Wed, Aug 21, 2002 at 03:44:41PM -0600, Thunder from the hill wrote:
> > > I'm getting through with bind9 pretty well, actually.
> > ip6.int? nibbles? reverse byte? ip6.arpa? A6? AAAA?
> It looks like nibble format and quad-A records are the de-facto standard.
> I'd expect them to become a finalized standard here shortly. BIND supports
> all these, however...
Yes, and no.
Yes, quad-A and reversed nibbles. Seems that A6 is rapidly
becoming deprecated (formally deprecated by the IETF, IIRC). Only thing
is that the 6bone is using .ip6.int for reverse lookup zones and the final
ietf decision fell to go with .ip6.arpa for reverse lookups. :-( Most
of the RIRs are now supporting both reverse lookup zones but, if you are
trying to work on the 6Bone, as I am, you are in trouble with the ip6.int
zone since the resolver libraries (at least on RedHat and a couple of
other related distros) are only checking ip6.arpa and not checking ip6.int.
Currently 6bone (3ffe::/16) is broken for ip6.arpa while the production
allocations (2001::/16) are functional for ip6.arpa and the resolver
libraries are only supporting ip6.arpa and not ip6.int. Therefore,
6Bone is broken for reverse lookups in current distros.
A STUPID side effect of the ip6.int / ip6.arpa brokeness is
that the "getaddrinfo" call returns the ipv6 address string of the
host in the "ai_canonname" structure element rather than the host name.
Which then makes for some BOGUS hacks (string search for multiple ':' in
"ai_canonname" and replace with hostname if present) if one wants to resolve
an ipv6 host name and display the cannonical name (if the reverse lookup
fails, I would expect to get the host name back, not its address - others
may disagree with me on that point). I'm fighting with this little
"problem" for the fetchmail ip6 code now. It's going to result in a
BUTT UGLY hack, but I'm stuck with it. Personally, I think that code
is broken along with the ip6.int / ip6.arpa dicotomy. I really don't
think that a canonical name should depend critically on having a reachable
reverse lookup in place. Think of the mayhem that would take place if
that were true in ipv4 space. :-/
My only other annoynance right now is the default ip6 route on my
ipv6 router (RedHat 7.3). It's not working (or doesn't seem to be)! I
have a 6bone allocation from Freenet6 (3ffe:b80:c84::/48) with about a
half a dozen SLA subnets and several routers. If I assign a default route
(::/0) on the main router back down my Freenet6 tunnel, weird things happen.
If I ping the other end of the tunnel from the gateway, my other leaf
systems can access the rest of the ip6 internet (6Bone and production).
If I stop pinging the other end of the tunnel from the gateway, access
fails a minute or two later with an error saying the target network
(whatever I'm trying to reach) can not be reached and the error is being
reported back from the lo interface on the gateway, even though the
actual default route still shows up in the routing table under
"ip -6 route ls". This also happens on my subnet routers back to my
main gateway as well.
If, OTOH, I set up a "half default route" of ::/1 (upper bit of
the 128 bit address is zero, which covered both 3ffe::/16 and 2001::/16
and doesn't trip over site local or link locals) on the router it works
perfect! (Yes, I also have to set up routes on the subnet routers for
the site locals, fce0::/16, to get routed between the subnets as well
when I do this). So I have to define my ip6 default routes on my ipv6
routers to actually be ::/1 instead of ::/0 to get them to work reliably.
This has been noticed and mentioned by others on the 6bone and freenet6
lists. Seems to be peculiar to Linux.
The default routers on the leaf workstations (autoconfigured from
router advertisements) seem to work fine though. It's just the linux
systems which are being used as ipv6 routers with manually configured
interfaces and running radvd to advertise themselves that seem to get
screwed up.
Jump ball question for anyone in the know...
Where do all the strange ipv6 routes like the following come from?
] unreachable 2002:a00::/24 dev lo metric 1024 error -101 mtu 16436 advmss 16376unreachable 2002:7f00::/24 dev lo metric 1024 error -101 mtu 16436 advmss 16376
] unreachable 2002:a9fe::/32 dev lo metric 1024 error -101 mtu 16436 advmss 16376
] unreachable 2002:ac10::/28 dev lo metric 1024 error -101 mtu 16436 advmss 16376
] unreachable 2002:c0a8::/32 dev lo metric 1024 error -101 mtu 16436 advmss 16376
] unreachable 2002:e000::/19 dev lo metric 1024 error -101 mtu 16436 advmss 16376
(There are piles more)
These show up on all my systems when I configure the ipv6 interface
but they are not in any configuration files I've been able to find, yet.
Anyone know what they are there for? Are they hard coded in some
code somewhere?
Here is what I have for default routes on one of my leaf nodes:
] default via fe80::280:c8ff:feca:6c8e dev eth0 proto kernel metric 1024 expires 23sec mtu 1500 advmss 1440
] unreachable default dev lo metric -1 error -101
Ok... That first one is the CORRECT one. I believe that it's that
second one that is causing all the problems on the routers but I don't
know where it is coming from. Obviously a ::/1 dev * route will override
that ::/0 dev lo route so I understand why the half default route fixes the
problem, even if it is a half ass hack (pun intended).
> Kelsey Hudson [email protected]
> Software Engineer/UNIX Systems Administrator
> Compendium Technologies, Inc (619) 725-0771
> ---------------------------------------------------------------------------
Mike
--
Michael H. Warfield | (770) 985-6132 | [email protected]
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
On Mon, Aug 26, 2002 at 05:51:23PM -0400, Michael H. Warfield wrote:
> My only other annoynance right now is the default ip6 route on my
> ipv6 router (RedHat 7.3). It's not working (or doesn't seem to be)! I
> have a 6bone allocation from Freenet6 (3ffe:b80:c84::/48) with about a
> half a dozen SLA subnets and several routers. If I assign a default route
> (::/0) on the main router back down my Freenet6 tunnel, weird things happen.
the linux kernel does ignore the ::/0 route if it is in forwarding not, I
guess this is since it is asumed, that the user knows what he is doing and
does not want to do that. You can use 2000::/2 instead.
> This has been noticed and mentioned by others on the 6bone and freenet6
> lists. Seems to be peculiar to Linux.
it is by intention, yes.
> The default routers on the leaf workstations (autoconfigured from
> router advertisements) seem to work fine though.
yes it deoeds on the ipforward setting.
BTW: i am working a bit on net-tools and ipv6, like:
calista:~# netstat -tl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:1024 *:* LISTEN
tcp 0 0 *:5269 *:* LISTEN
...
tcp 0 0 calista.inka.de:domain *:* LISTEN
tcp6 0 0 *:auth *:* LISTEN
tcp6 0 0 *:ssh *:* LISTEN
tcp6 0 0 *:smtp *:* LISTEN
i am not yet sure about the wildcard address and the port separator, but I
like the tcp6 :)
ifconfig may get a more BSDish look, also:
# ./ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 metric 1
inet 10.0.0.3 netmask 255.255.255.0 broadcast 10.0.0.255
inet6 3ffe:400:4f0:ffff::3 prefixlen 112 scopeid 0x0<global>
inet6 fe80::2e0:7dff:fe92:1f0b prefixlen 10 scopeid 0x20<link>
ether 00:e0:7d:92:1f:0b txqueuelen 100 (Ethernet)
RX packets 2581434 bytes 1632512018 (1.5 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2031678 bytes 1202569629 (1.1 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 9 base 0x9000
Greetings
Bernd
On Tue, Aug 27, 2002 at 01:48:04AM +0200, Bernd Eckenfels wrote:
> On Mon, Aug 26, 2002 at 05:51:23PM -0400, Michael H. Warfield wrote:
> > My only other annoynance right now is the default ip6 route on my
> > ipv6 router (RedHat 7.3). It's not working (or doesn't seem to be)! I
> > have a 6bone allocation from Freenet6 (3ffe:b80:c84::/48) with about a
> > half a dozen SLA subnets and several routers. If I assign a default route
> > (::/0) on the main router back down my Freenet6 tunnel, weird things happen.
> the linux kernel does ignore the ::/0 route if it is in forwarding not, I
^^^
mode?
> guess this is since it is asumed, that the user knows what he is doing and
> does not want to do that. You can use 2000::/2 instead.
It's ignoring something because it's assuming the user knows
what he's doing and not wanting it to do that? Does not compute. I
installed the route. If I know what I'm doing, why would I want it to
ignore the route that I installed? I think I prefer to have it do what
I tell it to and not what it thinks I want it to do.
Is that a typo where you wrote 2000::/2? Isn't 2000::/2 the same
as ::/2 (the upper two bits are zero)? Both would be equivalent and both
would cover both the 6bone (3ffe::/16) and production (2001::/16) TLAs.
Did you mean 2000::/3 (first two bits zero, next bit 1)? That would
also cover both the 6bone and production allocations under a slightly
tighter mask. The /2 would cover :: through 3fff: but the /3
would cover 2000: through 3fff:. Any reaon why we should care about
the ::/3 band (:: through 1fff:)?
> > This has been noticed and mentioned by others on the 6bone and freenet6
> > lists. Seems to be peculiar to Linux.
> it is by intention, yes.
It's confusing. It introduces unexpected behavior (behavior
dependent on other influences) and is, AFAIK, inconsistent with other
implimentations (Solaris, BSD, Windows, etc...).
> > The default routers on the leaf workstations (autoconfigured from
> > router advertisements) seem to work fine though.
> yes it deoeds on the ipforward setting.
Cool... At least I understand why it's doing this and what it
depends on. If that's the way it works, this needs to be documented
in bright glowing radioactive letters so it can't be missed.
> BTW: i am working a bit on net-tools and ipv6, like:
> calista:~# netstat -tl
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address Foreign Address State
> tcp 0 0 *:1024 *:* LISTEN
> tcp 0 0 *:5269 *:* LISTEN
> ...
> tcp 0 0 calista.inka.de:domain *:* LISTEN
> tcp6 0 0 *:auth *:* LISTEN
> tcp6 0 0 *:ssh *:* LISTEN
> tcp6 0 0 *:smtp *:* LISTEN
> i am not yet sure about the wildcard address and the port separator, but I
> like the tcp6 :)
Does that imply ipv6 only or does that include ipv4 on those
tcp6 listens? I assume that the "tcp" lines are v4 only. If that's
true then the tcp6 lines should be the v6 only listens. If that's
true, what do you get if it's listening on both (bind is very weird
here with some strange warnings)? Would you get two entries? One
for tcp and one for tcp6?
I'm not sure I like the tcp6, since it's not tcp that's
changed, just the ip layer underneath it. I assume you would also
have udp6 as well?
> ifconfig may get a more BSDish look, also:
>
> # ./ifconfig
> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 metric 1
> inet 10.0.0.3 netmask 255.255.255.0 broadcast 10.0.0.255
> inet6 3ffe:400:4f0:ffff::3 prefixlen 112 scopeid 0x0<global>
> inet6 fe80::2e0:7dff:fe92:1f0b prefixlen 10 scopeid 0x20<link>
> ether 00:e0:7d:92:1f:0b txqueuelen 100 (Ethernet)
> RX packets 2581434 bytes 1632512018 (1.5 GiB)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 2031678 bytes 1202569629 (1.1 GiB)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
> device interrupt 9 base 0x9000
Hmmm... Just be careful not to break too many scripts. Freenet6
has a template script with their tsp package that, I think, tries to do
some parsing on that stuff. That script is also broken due to the
default route sillyness, and I'm going to let them know to change their
route add from ::/0 to a route add for something between ::/1 and 2000::/3
(season to taste) to get the default routes working properly.
> Greetings
> Bernd
Mike
--
Michael H. Warfield | (770) 985-6132 | [email protected]
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
In article <[email protected]> you wrote:
> It's ignoring something because it's assuming the user knows
> what he's doing and not wanting it to do that? Does not compute.
well, it was not my idea, and i dont think I fully understand all that Scope
stuff in IPv6, but I wanted to say:
The kernel is asuming, that a gateway (ie forward=1) is administrated by a
experienced admin, who knows how to set up all those special V6 prefixes,
but wants to defend internet from admins who do not know.
for a single hoomed host a default route does no harm, compared to a gateway
with wrong site or lionk local scope prefix routes.
> Did you mean 2000::/3 (first two bits zero, next bit 1)? That would
> also cover both the 6bone and production allocations under a slightly
> tighter mask. The /2 would cover :: through 3fff: but the /3
> would cover 2000: through 3fff:. Any reaon why we should care about
> the ::/3 band (:: through 1fff:)?
yes, because it does not maks the link and site local prefix starting with
FE and FF (like fe80::/10)
> Does that imply ipv6 only or does that include ipv4 on those
> tcp6 listens?
well, depends on the kernel we are talking about. I plan to have tcp,tcp46
and tcp6 (of course udp and icmp, too) entries, like BSD has.
> I'm not sure I like the tcp6, since it's not tcp that's
> changed, just the ip layer underneath it. I assume you would also
> have udp6 as well?
yes
> Hmmm... Just be careful not to break too many scripts. Freenet6
> has a template script with their tsp package that, I think, tries to do
> some parsing on that stuff. That script is also broken due to the
> default route sillyness, and I'm going to let them know to change their
> route add from ::/0 to a route add for something between ::/1 and 2000::/3
> (season to taste) to get the default routes working properly.
tspc works fine for me, but you are right breaking scripts is a bit ugly.
Well on the other hand, it wil lalso unbreak some bsd scripts :)
Greetings
Bernd
On Wed, Aug 28, 2002 at 09:14:46PM +0200, Bernd Eckenfels wrote:
> In article <[email protected]> you wrote:
> > It's ignoring something because it's assuming the user knows
> > what he's doing and not wanting it to do that? Does not compute.
> well, it was not my idea, and i dont think I fully understand all that Scope
> stuff in IPv6, but I wanted to say:
> The kernel is asuming, that a gateway (ie forward=1) is administrated by a
> experienced admin, who knows how to set up all those special V6 prefixes,
> but wants to defend internet from admins who do not know.
> for a single hoomed host a default route does no harm, compared to a gateway
> with wrong site or lionk local scope prefix routes.
Actually, I realized some time ago that this sillyness over
the ::/0 default route may have been a kludge to deal with limiting
the routing range of the site locals and link locals. Obviously, you
can enforce limiting link locals to the local subnet by not providing
routes for them through any routers and limit site locals by not providing
routes for them through any border routers. The way you described it
this time merely confirmed my long standing suspicion in that regard.
I'm not sure I wouldn't prefer to have that safety check burried deeper,
though, incase some loser DOES define a router for f000::/4 out
somewhere. Leaving site-local and link-local policies to the whims
of the routing tables and statics routes may work but just seems like
the whole 10-net deal all over again.
This all does raise another question, though. Why don't link local
addresses work... Link local scoped addresses should be valid and work
between hosts on the same "link" or subnet (colision zone, flat network,
whatever you want to call it).
Observe when I "ping6" the same host on the global, site local,
and link local addresses. I'm pinging my system "wittsend" from my
system "alcove" which are both on the same subnet or link...
First the global scope address:
] [root@alcove mhw]# ping6 -c 2 3ffe:b80:c84:8200:280:c8ff:fecf:bf06
] PING 3ffe:b80:c84:8200:280:c8ff:fecf:bf06(3ffe:b80:c84:8200:280:c8ff:fecf:bf06) from 3ffe:b80:c84:8200:2a0:24ff:feda:d2f3 : 56 data bytes
] 64 bytes from 3ffe:b80:c84:8200:280:c8ff:fecf:bf06: icmp_seq=1 ttl=64 time=0.406 ms
] 64 bytes from 3ffe:b80:c84:8200:280:c8ff:fecf:bf06: icmp_seq=2 ttl=64 time=0.367 ms
]
] --- 3ffe:b80:c84:8200:280:c8ff:fecf:bf06 ping statistics ---
] 2 packets transmitted, 2 received, 0% loss, time 1012ms
] rtt min/avg/max/mdev = 0.367/0.386/0.406/0.027 ms
Now the site local scope address:
] [root@alcove mhw]# ping6 -c 2 fec0::8200:280:c8ff:fecf:bf06
] PING fec0::8200:280:c8ff:fecf:bf06(fec0::8200:280:c8ff:fecf:bf06) from fec0::8200:2a0:24ff:feda:d2f3 : 56 data bytes
] 64 bytes from fec0::8200:280:c8ff:fecf:bf06: icmp_seq=1 ttl=64 time=0.812 ms
] 64 bytes from fec0::8200:280:c8ff:fecf:bf06: icmp_seq=2 ttl=64 time=0.401 ms
]
] --- fec0::8200:280:c8ff:fecf:bf06 ping statistics ---
] 2 packets transmitted, 2 received, 0% loss, time 1009ms
] rtt min/avg/max/mdev = 0.401/0.606/0.812/0.206 ms
Now the link local scope address:
] [root@alcove mhw]# ping6 -c 2 fe80::8200:280:c8ff:fecf:bf06
] connect: Invalid argument
Opps...
Ok... So why did I get "Invalid arguement" on the link local
address? Here is what is on the other system, "wittsend", interface...
] [mhw@wittsend mhw]$ /sbin/ifconfig eth1
] eth1 Link encap:Ethernet HWaddr 00:80:C8:CF:BF:06
] inet addr:130.205.0.3 Bcast:130.205.0.255 Mask:255.255.255.0
] inet6 addr: fec0::8200:280:c8ff:fecf:bf06/64 Scope:Site
] inet6 addr: fe80::280:c8ff:fecf:bf06/10 Scope:Link
] inet6 addr: 3ffe:b80:c84:8200:280:c8ff:fecf:bf06/64 Scope:Global
] UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
] RX packets:164532 errors:1 dropped:0 overruns:0 frame:0
] TX packets:24261 errors:3 dropped:0 overruns:0 carrier:3
] collisions:6352 txqueuelen:100
] RX bytes:20567703 (19.6 Mb) TX bytes:14418737 (13.7 Mb)
] Interrupt:9 Base address:0xa000
Should that third ping6 (the link local) worked just as well
as the first two? I noticed that the link local mask is /10 unlike
the other two which are /64. Since router advertisements and
solicitation is all mandated to work through the link locals, the
addresses themselves must be working correctly. Are they merely not
being allowed up to the application space level?
> > Did you mean 2000::/3 (first two bits zero, next bit 1)? That would
> > also cover both the 6bone and production allocations under a slightly
> > tighter mask. The /2 would cover :: through 3fff: but the /3
> > would cover 2000: through 3fff:. Any reaon why we should care about
> > the ::/3 band (:: through 1fff:)?
> yes, because it does not maks the link and site local prefix starting with
> FE and FF (like fe80::/10)
Yeah, I understood that... We only want to route addresses with
the upper bit zero. I was just wondering about the /2 vs /3 and the 2000::
you had specified.
> > Does that imply ipv6 only or does that include ipv4 on those
> > tcp6 listens?
> well, depends on the kernel we are talking about. I plan to have tcp,tcp46
> and tcp6 (of course udp and icmp, too) entries, like BSD has.
> > I'm not sure I like the tcp6, since it's not tcp that's
> > changed, just the ip layer underneath it. I assume you would also
> > have udp6 as well?
> yes
> > Hmmm... Just be careful not to break too many scripts. Freenet6
> > has a template script with their tsp package that, I think, tries to do
> > some parsing on that stuff. That script is also broken due to the
> > default route sillyness, and I'm going to let them know to change their
> > route add from ::/0 to a route add for something between ::/1 and 2000::/3
> > (season to taste) to get the default routes working properly.
> tspc works fine for me, but you are right breaking scripts is a bit ugly.
> Well on the other hand, it wil lalso unbreak some bsd scripts :)
:->
tspc works fine for me, too, other than the broken add route for
::/0 when I'm requesting a /48. :-> I just want to make sure I keep
it that way. >;->=>
> Greetings
> Bernd
Mike
--
Michael H. Warfield | (770) 985-6132 | [email protected]
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
On Wed, Aug 28, 2002 at 10:05:01PM -0400, Michael H. Warfield wrote:
> This all does raise another question, though. Why don't link local
> addresses work... Link local scoped addresses should be valid and work
> between hosts on the same "link" or subnet (colision zone, flat network,
> whatever you want to call it).
they work only if you specify a device. Which is logical if you have more
than one device, it is less so, if you have only one.
> ] [root@alcove mhw]# ping6 -c 2 fe80::8200:280:c8ff:fecf:bf06
> ] connect: Invalid argument
you need to give -I eth1 like it is decribed in the ping6 manpage:
-I interface address
Set source address to specified interface address. Argu?
ment may be numeric IP address or name of device. When
pinging IPv6 link-local address this option is required.
Greetings
Bernd
--
(OO) -- [email protected] --
( .. ) ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
o--o *plush* 2048/93600EFD eckes@irc +497257930613 BE5-RIPE
(O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Dear diary, on Mon, Aug 19, 2002 at 06:37:19AM CEST, I got a letter,
where "David S. Miller" <[email protected]> told me, that...
> Full IPv6 stack is beeing mantained by USAGI project.
>
> Yes, and based upon previous attempts to get them to merge their work
> into the mainline, we believe at this point that they actually enjoy
> being a totally seperate project and not merging completely is a
> feature for them.
>
> USAGI may only accept that comment, and the only way they may
> disprove it is to merge their code to us as we have continually
> requested them to do so.
...
FYI, early at this morning (UTC), Yuji Sekiya <[email protected]> wrote on
the USAGI list:
======
> Is there any chance the work of the USAGI project will
> be included in the vanilla kernel(2.4?/2.5?) in the near
> future? Will we see better ipv6 support in 2.6 ?
Yes, we will send patches to mainline kernel.
At least we will send the below patches by end of Setpember.
We are now working.
- IPv6 default route fix
- Source address seletcion
- Privacy extension
- IPv4/IPv6 double bind
- NDP timer improvement
- IPsec for IPv6
======
So, let's watch them and hope that they will fulfill this and send some usable
patches to you..
PS: Sorry for replying to such an old thread, I only thought that people not
subscribed on the USAGI mailing list may be still interested in this.
--
Petr "Pasky" Baudis
* ELinks maintainer * IPv6 guy (XS26 co-coordinator)
* IRCnet operator * FreeCiv AI occassional hacker
.
<Beeth> Girls are like internet domain names, the ones I like are already taken.
<honx> Well, you can still get one from a strange country :-P
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/
From: Petr Baudis <[email protected]>
Date: Thu, 12 Sep 2002 17:06:09 +0200
- IPsec for IPv6
Without ipv4 part and stackable destination cache, we do
not see any way in which they could make this cleanly and
properly and thus make patch acceptable.
All of IPSEC is a routing and data representation problem, so unless
routing code of ipv6 was rewritten by USAGI folks to support
representation of security database (this means addition of
protocol/source_port/dest_port route demux selectors and also
RTA_IPSEC routing attribute for actual ESP/AH rule insertion), the
patch is not likely to be accepted.
So if done right, ipv4 would be just as easy to support and thusly
I make parallel ipv6/ipv4 support a requirement for any ipsec
implementation that goes into the tree.
I also want ipsec to be implemented using rtnetlink which doubly means
that it must be solved at the routing level.
This also means that PF_KEY socket implementation is merely translator
into rtnetlink messages and nothing more and that "ip" tool would be
used for manual keying.
The fact that I have so much to say about the implementation details
of ipsec might suggest something if you're paying attention :-) And
that's where I'll leave the topic of ipsec at the moment.
Otherwise I look forward to seeing their other patches, but I find it
strange that it takes them on the order months to submit things, which
I have maintained from the start. They work on this stuff nearly full
time and it is very important to them, they also have high claims as
to it's readiness, so what could possibly take so long?