INET6 required for SCTP in 7.0?
Andy Dills
Hi there,
I'm not interested in enabling support for IPv6 for now.
When I remove INET6 from the kernel configuration, I cannot compile the
kernel without disabling SCTP. With fresh 7.0-STABLE source, here's the
error output (INET6 disabled, but SCTP enabled):
uipc_syscalls.o(.text+0x3c1): In function `sctp_generic_recvmsg':
/usr/src/sys/kern/uipc_syscalls.c:2608: undefined reference to
`sctp_sorecvmsg'
uipc_syscalls.o(.text+0x21a2): In function `sctp_generic_sendmsg_iov':
/usr/src/sys/kern/uipc_syscalls.c:2486: undefined reference to
`sctp_lower_sosend'
uipc_syscalls.o(.text+0x249d): In function `sctp_generic_sendmsg':
/usr/src/sys/kern/uipc_syscalls.c:2379: undefined reference to
`sctp_lower_sosend'
uipc_syscalls.o(.text+0x266c): In function `sctp_peeloff':
/usr/src/sys/kern/uipc_syscalls.c:2246: undefined reference to
`sctp_can_peel_off'
uipc_syscalls.o(.text+0x28e6):/usr/src/sys/kern/uipc_syscalls.c:2287:
undefined reference to `sctp_do_peeloff'
rtsock.o(.text+0xb7d): In function `rt_newaddrmsg':
/usr/src/sys/net/rtsock.c:897: undefined reference to `sctp_addr_change'
in_proto.o(.data+0xa8): undefined reference to `sctp_input'
in_proto.o(.data+0xb0): undefined reference to `sctp_ctlinput'
in_proto.o(.data+0xb4): undefined reference to `sctp_ctloutput'
in_proto.o(.data+0xbc): undefined reference to `sctp_init'
in_proto.o(.data+0xc8): undefined reference to `sctp_drain'
in_proto.o(.data+0xcc): undefined reference to `sctp_usrreqs'
in_proto.o(.data+0xdc): undefined reference to `sctp_input'
in_proto.o(.data+0xe4): undefined reference to `sctp_ctlinput'
in_proto.o(.data+0xe8): undefined reference to `sctp_ctloutput'
in_proto.o(.data+0xfc): undefined reference to `sctp_drain'
in_proto.o(.data+0x100): undefined reference to `sctp_usrreqs'
in_proto.o(.data+0x110): undefined reference to `sctp_input'
in_proto.o(.data+0x118): undefined reference to `sctp_ctlinput'
in_proto.o(.data+0x11c): undefined reference to `sctp_ctloutput'
in_proto.o(.data+0x130): undefined reference to `sctp_drain'
in_proto.o(.data+0x134): undefined reference to `sctp_usrreqs'
Is this intended and/or a known issue?
Thanks,
Andy
---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"
Mark Andrews
> Hi Xin LI!
>
> On Mon, 03 Mar 2008 16:50:33 -0800; Xin LI wrote about 'Re: INET6 required fo
> r SCTP in 7.0?':
>
> >> I'm not interested in enabling support for IPv6 for now.
> >>
> >> When I remove INET6 from the kernel configuration, I cannot compile the
> >> kernel without disabling SCTP. With fresh 7.0-STABLE source, here's the
> >> error output (INET6 disabled, but SCTP enabled):
>
> Will it be fixed? Any time soon?
It would be better to remove the option all together. IPv6
is no longer a protocol under development. There is no
need to make it optional any more. Having it there really
sends the wrong signal.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
Vadim Goncharov
On Mon, 03 Mar 2008 16:50:33 -0800; Xin LI wrote about 'Re: INET6 required for SCTP in 7.0?':
>> I'm not interested in enabling support for IPv6 for now.
>>
>> When I remove INET6 from the kernel configuration, I cannot compile the
>> kernel without disabling SCTP. With fresh 7.0-STABLE source, here's the
>> error output (INET6 disabled, but SCTP enabled):
> Yes, INET6 is (currently) required if you enable SCTP.
Will it be fixed? Any time soon?
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_n...@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
Robert Watson
On Tue, 4 Mar 2008, Vadim Goncharov wrote:
> On Mon, 03 Mar 2008 16:50:33 -0800; Xin LI wrote about 'Re: INET6 required
> for SCTP in 7.0?':
>
>>> I'm not interested in enabling support for IPv6 for now.
>>>
>>> When I remove INET6 from the kernel configuration, I cannot compile the
>>> kernel without disabling SCTP. With fresh 7.0-STABLE source, here's the
>>> error output (INET6 disabled, but SCTP enabled):
>> Yes, INET6 is (currently) required if you enable SCTP.
>
> Will it be fixed? Any time soon?
It's considered a bug, and hopefully it will be fixed by the SCTP maintainers
soon. However, they've been fairly busy with another project so I'm not sure
there's a specific timeline. I would like to see it fixed by 7.1.
Robert N M Watson
Computer Laboratory
University of Cambridge
Vadim Goncharov
On Wed, 05 Mar 2008 00:07:56 +1100; Mark Andrews wrote about 'Re: INET6 required for SCTP in 7.0?':
>>>> I'm not interested in enabling support for IPv6 for now.
>>>>
>>>> When I remove INET6 from the kernel configuration, I cannot compile the
>>>> kernel without disabling SCTP. With fresh 7.0-STABLE source, here's the
>>>> error output (INET6 disabled, but SCTP enabled):
>>> Yes, INET6 is (currently) required if you enable SCTP.
>>
>> Will it be fixed? Any time soon?
> It would be better to remove the option all together. IPv6
> is no longer a protocol under development. There is no
> need to make it optional any more. Having it there really
> sends the wrong signal.
I strongly disagree. I want to keep my machines without IPv6 as long as
possible due to protocol (not implementation) architectural bugs.
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_n...@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
_______________________________________________
Andy Dills
> It would be better to remove the option all together. IPv6
> is no longer a protocol under development. There is no
> need to make it optional any more. Having it there really
> sends the wrong signal.
With all due respect, let's face a couple of facts.
IPv4 is going to be the primary protocol for several years to come. There
are a few critical reasons, and few people like to point out just how
naked the emperor is:
- Providing IPv6 currently (and for the forseeable future) provides no
return on investment (ROI). Service Providers can't make more money with
IPv6, businesses do not get any sort of competitive or perceived advantage
from deploying IPv6, and end users certainly don't want to deal with it.
- To route IPv6 with the same features and packet forwarding rate as with
IPv4, nearly every network will be forced to purchase expensive router
upgrades with no other real benefit beyond IPv6 connectivity (which again
provides no ROI to justify the capex). Nobody is going to do forklift
upgrades just for IPv6, but as routers get normally upgraded IPv6
functionality will indeed slowly expand.
- IPv6 provides almost no technological upgrades beyond additional address
space. DHCP addressed the auto configuration feature, VPNs addressed
IPsec.
- IPv4 address spaces will eventually transition to a market commodity
model, providing a financial incentive that will encourage significant
optimization and provide motive for providers to audit their allocations,
and for businesses to part with IP space that they no longer properly
utilize. The cost of acquiring IPv4 space will be less than the cost of
upgrading to IPv6.
Therefore, given a lack of ROI or sufficient technological motivation, and
given the significant potential for optimization of existing IPv4 space
both via technology and financial incentive, I see a minimum of five years
before IPv6 is common.
In the meantime, I'd like to only enable IPv6 on IPv6 enabled networks.
Andy
---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---
Andy Dills
> O.K., have snipped all the above IPv4 stuff, which actually seems quite
> reaosnable (though appears to foorget about STF), but this line...
>
> > In the meantime, I'd like to only enable IPv6 on IPv6 enabled networks.
>
> ...I fail to see how not wanting to enable it leads to you wanting
> to remove it from the kernel entirely ? That is the bit I don't understand
> about all of this discussion. Theres probably hundereds of bits in the kernel
> you havent enabled and don't use, why specificly do you want an option
> to take IPV6 out ?
>
> I am genuinely piuzzled - why isn't "ipv6_enabled="NO" sufficient ? That's
> what I do on IPv4 networks and it works fine for me.
That's actually a good point. I've had a hard time shedding my "trim
everything I don't use out of the kernel" mentality over the years.
Mark Andrews
> On Wed, 5 Mar 2008, Mark Andrews wrote:
>
> > It would be better to remove the option all together. IPv6
> > is no longer a protocol under development. There is no
> > need to make it optional any more. Having it there really
> > sends the wrong signal.
>
> With all due respect, let's face a couple of facts.
>
> IPv4 is going to be the primary protocol for several years to come. There
> are a few critical reasons, and few people like to point out just how
> naked the emperor is:
>
> - Providing IPv6 currently (and for the forseeable future) provides no
> return on investment (ROI). Service Providers can't make more money with
> IPv6, businesses do not get any sort of competitive or perceived advantage
> from deploying IPv6, and end users certainly don't want to deal with it.
care which protocol version is in the header. What they
should be worried about is ensuring that they are here in
4 years time.
It actually takes time to fill in the missing pieces and
the only way to find the missing pieces is to bring up IPv6
networks.
Most end users won't even know that they are running IPv6
connections. I had to look at netstat to see which protocol
was being choosen on my father's box. I'm sure he had zero
knowledge that he was using IPv6 (6-to-4).
An IPv6 network really is as easy if not easier to run than
a IPv4 network.
> - To route IPv6 with the same features and packet forwarding rate as with
> IPv4, nearly every network will be forced to purchase expensive router
> upgrades with no other real benefit beyond IPv6 connectivity (which again
> provides no ROI to justify the capex). Nobody is going to do forklift
> upgrades just for IPv6, but as routers get normally upgraded IPv6
> functionality will indeed slowly expand.
And the same arguement was put out 6 years ago. The backbone
really has gone dual stack while you wern't paying attention.
What's needed now is the SOHO CPE equipment sold to the non
Asian market to catch up.
> - IPv6 provides almost no technological upgrades beyond additional address
> space. DHCP addressed the auto configuration feature, VPNs addressed
> IPsec.
That extra address space really is a big advantage. It
really is so much better to be able to get to machines you
need to without have to manually setup application relays
because you couldn't get enough address space to be able
to globally address everything want to.
> - IPv4 address spaces will eventually transition to a market commodity
> model, providing a financial incentive that will encourage significant
> optimization and provide motive for providers to audit their allocations,
> and for businesses to part with IP space that they no longer properly
> utilize. The cost of acquiring IPv4 space will be less than the cost of
> upgrading to IPv6.
>
> Therefore, given a lack of ROI or sufficient technological motivation, and
> given the significant potential for optimization of existing IPv4 space
> both via technology and financial incentive, I see a minimum of five years
> before IPv6 is common.
>
> In the meantime, I'd like to only enable IPv6 on IPv6 enabled networks.
So make the network IPv6 enabled. Both my home network and
the office networks have bee IPv6 enabled for years now.
My ISP doesn't support IPv6 yet though I know that have
IPv6 netbocks for themselves now if not for the customers
at this stage.
There is a reasonable chance that this mail will leave here
over IPv6 for some of the recipients. It will almost
certainly travel over IPv6 for at least one hop.
Mark
> Andy
>
>
> ---
> Andy Dills
> Xecunet, Inc.
> www.xecu.net
> 301-682-9972
> ---
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
Vadim Goncharov
On Wed, 5 Mar 2008 08:40:20 -0500 (EST); Andy Dills wrote about 'Re: INET6 required for SCTP in 7.0?':
>> O.K., have snipped all the above IPv4 stuff, which actually seems quite
>> reaosnable (though appears to foorget about STF), but this line...
>>
>>> In the meantime, I'd like to only enable IPv6 on IPv6 enabled networks.
>>
>> ...I fail to see how not wanting to enable it leads to you wanting
>> to remove it from the kernel entirely ? That is the bit I don't understand
>> about all of this discussion. Theres probably hundereds of bits in the kernel
>> you havent enabled and don't use, why specificly do you want an option
>> to take IPV6 out ?
>>
>> I am genuinely piuzzled - why isn't "ipv6_enabled="NO" sufficient ? That's
>> what I do on IPv4 networks and it works fine for me.
> That's actually a good point. I've had a hard time shedding my "trim
> everything I don't use out of the kernel" mentality over the years.
Makes it harder to debug, etc. Don't want to see anything IPv6 related in
command output, to let programs to bind on IPv6 addresses, etc.
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_n...@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
_______________________________________________
Ruben van Staveren
--Apple-Mail-75-935427659
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
On 5 Mar 2008, at 15:32, Mark Andrews wrote:
>> - IPv6 provides almost no technological upgrades beyond additional
>> address
>> space. DHCP addressed the auto configuration feature, VPNs addressed
>> IPsec.
>
> That extra address space really is a big advantage. It
> really is so much better to be able to get to machines you
> need to without have to manually setup application relays
> because you couldn't get enough address space to be able
> to globally address everything want to.
Please see http://www.youtube.com/watch?v=_y36fG2Oba0
This song exactly explains why you should care about IPv6 :)
I don't get this "anti IPv6" behaviour. If people are not willing to
adopt it, it will not get tested which in turn will make other people
hesitating to jump on the bandwagon. Having it compiled in your system
does not cause harm if you don't configure it and for everything else
there are traffic filters. Just like IPv4.
- Ruben
--Apple-Mail-75-935427659
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
iD8DBQFHzrJaZ88+mcQxRw0RApDAAJ0TgaZHpxbiWa6smndzowk1ih0AIgCfV2kG
kfOed70fpateOIIjw7bkBCs=
=6X+h
-----END PGP SIGNATURE-----
--Apple-Mail-75-935427659--
Peter Wemm
> On Wed, Mar 5, 2008 at 6:32 AM, Mark Andrews <Mark_A...@isc.org> wrote:
> > There is a reasonable chance that this mail will leave here
> > over IPv6 for some of the recipients. It will almost
> > certainly travel over IPv6 for at least one hop.
> >
> > Mark
>
> drugs.dv.isc.org -> IPv6 -> mx1.freebsd.org -> IPv6 -> hub.freebsd.org
> -> Mailman -> localhost -> hub.freebsd.org -> IPv6 -> mx2.freebsd.org
> -> IPv6 -> me
>
> The only IPv4 hop in this path was when Mailman connected to localhost
> (127.0.0.1) to reinject the email. And that is because I had
> 127.0.0.1 hard coded in a config file.
Oh, one more thing. If you are IPv6-enabled, you get to bypass the 10
minute greylisting delay on mx1.freebsd.org. Your email goes through
instantly instead of potentially being delayed by 10-30 minutes.
--
Peter Wemm - pe...@wemm.org; pe...@FreeBSD.org; pe...@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
Peter Wemm
> There is a reasonable chance that this mail will leave here
> over IPv6 for some of the recipients. It will almost
> certainly travel over IPv6 for at least one hop.
>
> Mark
It did:
drugs.dv.isc.org -> IPv6 -> mx1.freebsd.org -> IPv6 -> hub.freebsd.org
-> Mailman -> localhost -> hub.freebsd.org -> IPv6 -> mx2.freebsd.org
-> IPv6 -> me
The only IPv4 hop in this path was when Mailman connected to localhost
(127.0.0.1) to reinject the email. And that is because I had
127.0.0.1 hard coded in a config file.
--
Andy Dills
> Service providers get paid to push IP packets. They shouldn't
> care which protocol version is in the header. What they
> should be worried about is ensuring that they are here in
> 4 years time.
Sure they should. The ASICs in the vast majority of production routers are
setup for IPv4. Add in the fact that you can get very capable routers
reasonably cheap on the secondary market and compound it with the lack of
revenue driven demand, and economics overwhelms.
Very precisely because we are worried about being here in four years time,
we spend our money wisely. We spend today's money today. Throwing money at
something with no demonstrable or projectable ROI is exactly how you wind
up gone in four years.
> Most end users won't even know that they are running IPv6
> connections. I had to look at netstat to see which protocol
> was being choosen on my father's box. I'm sure he had zero
> knowledge that he was using IPv6 (6-to-4).
This is true, but illustrates my point. If users had to be dragged kicking
and screaming into using digital television, which is obviously a huge
upgrade that provides a significantly enhanced experience, why would they
want to pay for a new CPE that works fine and will work fine for many
years? Which also in turn provides them with more IP addresses than they
can use via NAT?
> > - To route IPv6 with the same features and packet forwarding rate as with
> > IPv4, nearly every network will be forced to purchase expensive router
> > upgrades with no other real benefit beyond IPv6 connectivity (which again
> > provides no ROI to justify the capex). Nobody is going to do forklift
> > upgrades just for IPv6, but as routers get normally upgraded IPv6
> > functionality will indeed slowly expand.
>
> And the same arguement was put out 6 years ago. The backbone
> really has gone dual stack while you wern't paying attention.
Portions of it, yes. But this is expected; "the backbone" frequently has
to upgrade for a variety of reasons, ranging from new and valuable
technology (MPLS, DWDM, etc) to shady behavior by Cisco (forcing people to
get the SUP720-3BXL to handle >255k prefixes).
Every step you take away from public corporations who are spending
stockholder money and have revenue driven infrastructure upgrades, you
move toward companies who have a much slower growth rate with much fewer
changes in network requirements, and who have to get capex approved by the
person who's money is actually being spent on the improvements.
> > - IPv6 provides almost no technological upgrades beyond additional address
> > space. DHCP addressed the auto configuration feature, VPNs addressed
> > IPsec.
>
> That extra address space really is a big advantage. It
> really is so much better to be able to get to machines you
> need to without have to manually setup application relays
> because you couldn't get enough address space to be able
> to globally address everything want to.
So much better? Sure. Does it justify IPv6? I'm not convinced.
I'm hoping some genius devises a new protocol that solves the growing
issue of inter-domain routing scalability by eliminating the need for
forwarding paths for every prefix in the global routing table, while also
creating true network portability, allowing individuals to obtain personal
IP space which they can utilize independant of their service provider,
without requiring any knowledge of routing protocol.
THAT is worth a forklift upgrade. THAT would be rapidly adopted.
IPv6 at this point looks very poorly thought out in the face of such
obviously incremental solutions such as:
- Utilizing the rarely used 16 bit Identification field or the useless 32
bit Options field in the existing IPv4 header to include a private routing
identifier.
- Existing routers are compatibile, as they merely route the /32 to the
NAT device, don't care about those fields.
- The NAT device rewrites the packet based on the private routing
identifier, without user intervention in configuring mapped addresses or
ports.
- The private routing identifier can either be a new DNS record or stuffed
into TXT records.
Initially, "important" devices would not rely on the private routing
identifier, enabling fringe users to use as a "best effort" upgrade while
network stacks and resolver libraries get upgraded. All software upgrades,
all leaving the core untouched.
That's just something I threw together while responding. Imagine what
could happen if somebody smart focused on it.
> So make the network IPv6 enabled. Both my home network and
> the office networks have bee IPv6 enabled for years now.
> My ISP doesn't support IPv6 yet though I know that have
> IPv6 netbocks for themselves now if not for the customers
> at this stage.
Oh, they have them for the customers. They just don't want to upgrade
their routers.
> There is a reasonable chance that this mail will leave here
> over IPv6 for some of the recipients. It will almost
> certainly travel over IPv6 for at least one hop.
s/IPv6/uucp/ ;)
Andy
---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---
Kevin Oberman
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
> Date: Wed, 5 Mar 2008 13:42:25 -0800
> From: "Peter Wemm" <pe...@wemm.org>
> Sender: owner-free...@freebsd.org
>
> On Wed, Mar 5, 2008 at 1:39 PM, Peter Wemm <pe...@wemm.org> wrote:
> > On Wed, Mar 5, 2008 at 6:32 AM, Mark Andrews <Mark_A...@isc.org> wrote:
> > > There is a reasonable chance that this mail will leave here
> > > over IPv6 for some of the recipients. It will almost
> > > certainly travel over IPv6 for at least one hop.
> > >
> > > Mark
> >
> > It did:
> > drugs.dv.isc.org -> IPv6 -> mx1.freebsd.org -> IPv6 -> hub.freebsd.org
> > -> Mailman -> localhost -> hub.freebsd.org -> IPv6 -> mx2.freebsd.org
> > -> IPv6 -> me
> >
> > The only IPv4 hop in this path was when Mailman connected to localhost
> > (127.0.0.1) to reinject the email. And that is because I had
> > 127.0.0.1 hard coded in a config file.
>
> Oh, one more thing. If you are IPv6-enabled, you get to bypass the 10
> minute greylisting delay on mx1.freebsd.org. Your email goes through
> instantly instead of potentially being delayed by 10-30 minutes.
Cool! That explains why most postings seem to take so long.
Hopefully this message made it through with no IPv4 hops.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: obe...@es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
--==_Exmh_1204784019_29660P
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (FreeBSD)
Comment: Exmh version 2.5 06/03/2002
iD8DBQFHz4uTkn3rs5h7N1ERAq88AKCIBTb89MmKGUmDdqJFoMVq9tYyOgCgpTcO
+VFtm0GLt+zYC206+GEluso=
=e9Hy
-----END PGP SIGNATURE-----
--==_Exmh_1204784019_29660P--
Randall Stewart
Robert/All:
One of my colleagues has been working on this in the background.
Its not so much as a design choice that has haunted us for
many years now. The stack originally was written for KAME and
as morphed over time.. this is just one thing we have not fixed.
Its in process.. I will check with Michael and see what h is status
is on it..
Thanks
R
Robert Watson wrote:
>
> On Tue, 4 Mar 2008, Vadim Goncharov wrote:
>
>> On Mon, 03 Mar 2008 16:50:33 -0800; Xin LI wrote about 'Re: INET6
>> required for SCTP in 7.0?':
>>
>>>> I'm not interested in enabling support for IPv6 for now.
>>>>
>>>> When I remove INET6 from the kernel configuration, I cannot compile
>>>> the kernel without disabling SCTP. With fresh 7.0-STABLE source,
>>>> here's the error output (INET6 disabled, but SCTP enabled):
>>> Yes, INET6 is (currently) required if you enable SCTP.
>>
>> Will it be fixed? Any time soon?
>
> It's considered a bug, and hopefully it will be fixed by the SCTP
> maintainers soon. However, they've been fairly busy with another
> project so I'm not sure there's a specific timeline. I would like to
> see it fixed by 7.1.
>
> Robert N M Watson
> Computer Laboratory
> University of Cambridge
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"
>
--
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)