Discussion:
ipv6
Justin Cormack
2005-01-20 15:05:51 UTC
Permalink
Is anyone running any ipv6 trackers for anything?

Wanted to test ipv6 support.

Justin



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Olaf van der Spek
2005-01-20 15:14:28 UTC
Permalink
Post by Justin Cormack
Is anyone running any ipv6 trackers for anything?
Wanted to test ipv6 support.
Justin
IPv6 is impossible in combination with the compact tracker protocol.



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Justin Cormack
2005-01-20 15:15:46 UTC
Permalink
Post by Olaf van der Spek
Post by Justin Cormack
Is anyone running any ipv6 trackers for anything?
Wanted to test ipv6 support.
Justin
IPv6 is impossible in combination with the compact tracker protocol.
So?

Well:
1. then the compact tracker protocol is broken
2. not all trackers use it
3. trackers could detect if the incoming connection was on ipv6 and not use it
4. many other solutions

Actually I think P2P applications will drive uptake of ipv6, as hosts
need to be able to talk to each other directly. And it seems that recently
it has started to be available off the shelf in a fairly widespread way.

Justin



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Bill Cox
2005-01-20 15:34:38 UTC
Permalink
Post by Justin Cormack
Post by Olaf van der Spek
Post by Justin Cormack
Is anyone running any ipv6 trackers for anything?
Wanted to test ipv6 support.
Justin
IPv6 is impossible in combination with the compact tracker protocol.
So?
1. then the compact tracker protocol is broken
2. not all trackers use it
3. trackers could detect if the incoming connection was on ipv6 and not use it
4. many other solutions
Actually I think P2P applications will drive uptake of ipv6, as hosts
need to be able to talk to each other directly. And it seems that recently
it has started to be available off the shelf in a fairly widespread way.
Justin
Bram had mentioned in an old e-mail that IPv6 would require some other
fixes, not just a fix to compact tracker mode. I don't know what these
other issues are.

However, it would be fairly easy to have two returned keys: peers, and
peers_ipv6. I think that would solve the internet tracker problem.

In the meantime, why not just disable compact tracker mode on the
tracker to test your code?

Bill





Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Justin Cormack
2005-01-20 19:43:29 UTC
Permalink
Post by Bill Cox
Post by Justin Cormack
Post by Olaf van der Spek
Post by Justin Cormack
Is anyone running any ipv6 trackers for anything?
Wanted to test ipv6 support.
Justin
IPv6 is impossible in combination with the compact tracker protocol.
So?
1. then the compact tracker protocol is broken
2. not all trackers use it
3. trackers could detect if the incoming connection was on ipv6 and not use it
4. many other solutions
Actually I think P2P applications will drive uptake of ipv6, as hosts
need to be able to talk to each other directly. And it seems that recently
it has started to be available off the shelf in a fairly widespread way.
Justin
Bram had mentioned in an old e-mail that IPv6 would require some other
fixes, not just a fix to compact tracker mode. I don't know what these
other issues are.
I was vaguely under the impression that they had been fixed, but I am
not sure.
Post by Bill Cox
However, it would be fairly easy to have two returned keys: peers, and
peers_ipv6. I think that would solve the internet tracker problem.
I am not sure if you need to, as presumably any ipv6 capable client would
connect to the tracker by ipv6 if possible, and then could then just be
fed ipv6 addresses (including compatibility ipv4 addresses for ipv4 hosts),
while anyone making an ipv4 connection presumably cant cope with ipv6
addresses. But I need to test this. Will look at what the code does.
Post by Bill Cox
In the meantime, why not just disable compact tracker mode on the
tracker to test your code?
Yes, will do.

As no one has said they are running any ipv6 services I will put up a
few test torrents with just ipv6 and dual homed hosts.

j



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Elliott Mitchell
2005-01-21 00:15:34 UTC
Permalink
Post by Justin Cormack
Post by Bill Cox
However, it would be fairly easy to have two returned keys: peers, and
peers_ipv6. I think that would solve the internet tracker problem.
I am not sure if you need to, as presumably any ipv6 capable client would
connect to the tracker by ipv6 if possible, and then could then just be
fed ipv6 addresses (including compatibility ipv4 addresses for ipv4 hosts),
while anyone making an ipv4 connection presumably cant cope with ipv6
addresses. But I need to test this. Will look at what the code does.
This is not a certainty. Currently IPv6-only hosts are pretty well
non-existant, but assuming an IPv6 host can also handle IPv4 is even
more broken than ignoring IPv6.

I dislike using two keys, but that might be the only way to handle it.
--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\ ( | ***@gremlin.m5p.com PGP 8881EF59 | ) /
\_ \ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
\___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/





Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Justin Cormack
2005-01-21 10:07:09 UTC
Permalink
Post by Elliott Mitchell
Post by Justin Cormack
Post by Bill Cox
However, it would be fairly easy to have two returned keys: peers, and
peers_ipv6. I think that would solve the internet tracker problem.
I am not sure if you need to, as presumably any ipv6 capable client would
connect to the tracker by ipv6 if possible, and then could then just be
fed ipv6 addresses (including compatibility ipv4 addresses for ipv4 hosts),
while anyone making an ipv4 connection presumably cant cope with ipv6
addresses. But I need to test this. Will look at what the code does.
This is not a certainty. Currently IPv6-only hosts are pretty well
non-existant, but assuming an IPv6 host can also handle IPv4 is even
more broken than ignoring IPv6.
I meant the ipv4 mappings to ipv6 addresses, so you always get an ipv6
address, even for a v4 host. Surely these always work?
Post by Elliott Mitchell
I dislike using two keys, but that might be the only way to handle it.
I think some testing is the only way to find out...

Justin



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Bill Cox
2005-01-21 15:25:24 UTC
Permalink
I thought a bit more about making a fuse based virtual file system for
BitTorrent. If there are no objections, how about calling the idea
BTFS, for BitTorrent File System?

A directory in BTFS would simply be a torrent file. Files within the
directory are just the files in the torrent. Files would read-only,
world readable, and only directories are executable. It would be
desirable to enhance this, but it may require extensions to BT.

A sub-directory is just an embedded .torrent file in a torrent. You can
cd to it and ls it, without downloading the torrent data, but if you
read a file, it will go get the needed data from the torrrent.

Link – This is a new file type, but does not extend the BT protocol.
Instead, BTFS clients would read these files and act on them. They are
recognized from their extension: .btlink. It's content is a bencoded
dictionary containing the following keys:

urls – List of URLs where the torrent file may be found.

signature – Optional. RSA signature of the author of the torrent file.
If this key is present, then the .torrent file must also be signed to be
opened. This key allows an author of a sub-directory to change it's
data, but still prove that it's his.

What do you think?

Bill





Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Justin Cormack
2005-01-21 15:54:59 UTC
Permalink
Post by Bill Cox
I thought a bit more about making a fuse based virtual file system for
BitTorrent. If there are no objections, how about calling the idea
BTFS, for BitTorrent File System?
A directory in BTFS would simply be a torrent file. Files within the
directory are just the files in the torrent. Files would read-only,
world readable, and only directories are executable. It would be
desirable to enhance this, but it may require extensions to BT.
The files in the torrent already may have a directory structure (although
this feature is not often used) and people rarely embed torrents in torrents
so just having a facility to mount torrents would be simpler.
Post by Bill Cox
A sub-directory is just an embedded .torrent file in a torrent. You can
cd to it and ls it, without downloading the torrent data, but if you
read a file, it will go get the needed data from the torrrent.
Link – This is a new file type, but does not extend the BT protocol.
Instead, BTFS clients would read these files and act on them. They are
recognized from their extension: .btlink. It's content is a bencoded
urls – List of URLs where the torrent file may be found.
signature – Optional. RSA signature of the author of the torrent file.
If this key is present, then the .torrent file must also be signed to be
opened. This key allows an author of a sub-directory to change it's
data, but still prove that it's his.
What do you think?
Bill
Implement the basic thing first then thonk about extensions like btlink
and signing...
Post by Bill Cox
Yahoo! Groups Links
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Konstantin 'Kosta' Welke
2005-01-21 23:41:44 UTC
Permalink
Post by Justin Cormack
The files in the torrent already may have a directory structure (although
this feature is not often used) and people rarely embed torrents in torrents
so just having a facility to mount torrents would be simpler.
Yeah, but listing a whole, big, directory structure in a single torrent
might be HUGE.

Kosta



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Nick Johnson
2005-01-23 23:44:36 UTC
Permalink
Post by Bill Cox
I thought a bit more about making a fuse based virtual file system for
BitTorrent. If there are no objections, how about calling the idea
BTFS, for BitTorrent File System?
...why? What exactly would the point of such a system be?
Your proposal is missing an essential part: Use Cases.

-Nick Johnson




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Bill Cox
2005-01-24 03:25:23 UTC
Permalink
Post by Nick Johnson
Post by Bill Cox
I thought a bit more about making a fuse based virtual file system for
BitTorrent. If there are no objections, how about calling the idea
BTFS, for BitTorrent File System?
...why? What exactly would the point of such a system be?
Your proposal is missing an essential part: Use Cases.
-Nick Johnson
I agree. The use cases are far-fetched. I'm mostly just throwing the
idea out on this forum to see if they spark any real interest.

In the realm of far-fetched ideas, a BTFS is used to distribute
operating systems, and bypasses much of the install process.

I plan to finish btslave before working on anything like this.

Bill





Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
mmarkjan
2005-01-29 09:14:18 UTC
Permalink
Post by Bill Cox
I thought a bit more about making a fuse based virtual file system for
BitTorrent. If there are no objections, how about calling the idea
BTFS, for BitTorrent File System?
Creating a filesystem just for having the capability of sharing files
over a network has problems:
- It shares a lot of functionality with a normal, local filesystem,
which everyone needs for operating system, runnable applications
and private documents.
- A filesystem needs to be hosted on a partition, and those are
usually fixed in size. Resizing them on the fly is not a standard
technique in 'filesystems' on all of todays OS's, and requires
a reboot.
- A bittorrent filesystem image, adapted to be variable in size,
loopback mounted on a local filesystem, might be resizeable, but
still has lots of problems to be solved (reading/writing, modifying
files, updating the hashes, versioning...).

Subversion-like versioning of torrent files, indexing them, and
distributing them is a totally different service. Having dependencies
between torrents etc sounds like miking a debian/PKG like system with
a pure file distribution protocol. That should be a different
project, on a different layer. Subversion is already king in
streaming changes to a directory structure efficiently over a
network, use the right tool for the job!


BitTorrent should be a pure file distribution protocol. It assumes
the same data must be shared, it doesn't do versioning or
transactional modfification of the file, it just gets the data and
ensures the integrety of the data against a .torrent, I think
the focus must be on that, and making it perform well.

So, I would say, extend the local operating systems filesystem
functionality (can be anything) to enhance the Bittorrent performance,
and benefit from that also other applications can take advantage of
the new features.
Post by Bill Cox
A sub-directory is just an embedded .torrent file in a torrent. You can
cd to it and ls it, without downloading the torrent data, but if you
read a file, it will go get the needed data from the torrrent.
This assumes a hierarchy in torrent files that is expected. You want
a kind of yahoo-style like directory of all torrent files ? Then,
please model a search feature that is distributed in a P2P manner,
but is also browseable. A distributed database...

Mark-Jan







Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Nick Johnson
2005-01-29 23:29:30 UTC
Permalink
Post by mmarkjan
- A filesystem needs to be hosted on a partition, and those are
usually fixed in size. Resizing them on the fly is not a standard
technique in 'filesystems' on all of todays OS's, and requires
a reboot.
Er, no it doesn't. Filesystems can be completely independant of actual
partitions on disk. For example, FUSE and LUFS in linux, and a large
number of applications that let you mount SCP/FTP/whatever services as
filesystems. Not to mention SMB and NFS.

-Nick Johnson



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Martin Nilsson
2005-01-21 11:17:12 UTC
Permalink
Post by Justin Cormack
I am not sure if you need to, as presumably any ipv6 capable client would
connect to the tracker by ipv6 if possible, and then could then just be
fed ipv6 addresses (including compatibility ipv4 addresses for ipv4 hosts),
while anyone making an ipv4 connection presumably cant cope with ipv6
addresses. But I need to test this. Will look at what the code does.
The problem is that if an ipv6 client isn't able to connect to the
tracker through ipv6 (either by not having a ipv6 route or the tracker
isn't on an ipv6 network at all) you will make the wrong assumption
about its capabilities.

/Martin Nilsson



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Justin Cormack
2005-01-24 13:22:13 UTC
Permalink
Post by Martin Nilsson
Post by Justin Cormack
I am not sure if you need to, as presumably any ipv6 capable client would
connect to the tracker by ipv6 if possible, and then could then just be
fed ipv6 addresses (including compatibility ipv4 addresses for ipv4 hosts),
while anyone making an ipv4 connection presumably cant cope with ipv6
addresses. But I need to test this. Will look at what the code does.
The problem is that if an ipv6 client isn't able to connect to the
tracker through ipv6 (either by not having a ipv6 route or the tracker
isn't on an ipv6 network at all) you will make the wrong assumption
about its capabilities.
Ah but as almost all trackers get the IP addresses from the connect socket
addresses (eg not the specified ip address field whose use is peculiar to
say the least), then a tracker that doesnt listen on ipv6 cant really
support ipv6 peers anyway. Most address lookups should give ipv6 addresses
first where they exist (I think), so it should just work. Its not entirely
clear though (something to cover in spec...)

Justin



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Christoph Hohmann
2005-01-20 19:46:25 UTC
Permalink
Post by Bill Cox
However, it would be fairly easy to have two returned keys: peers, and
peers_ipv6. I think that would solve the internet tracker problem.
The bigger problem I encountered when I tried to make an
IPv6 version of Bittorrent is that most trackers don't
accept IPs provided by the peer and use the source IP which
it also checked with the NAT check to verify that it is
correct. With this it is not possible for a peer to tell the
tracker it's IPv4 and IPv6 address. The IP the tracker
returns to other peers would depend on the IP protocol that
is used to talk to the tracker.

Additionally it would be better if the tracker would not
know about IPv4 or IPv6 and just group addresses into
categories which can be requested by the peer. Like this
even an IPv4 only tracker can provide IPv6 addresses when
the peer requests addresses from this category. The peers
would tell the tracker for each address it sends to the
tracker in which category it belongs.

If you want to keep a NAT check to make sure that Bittorrent
is not used to start DDoS attacks the actual NAT check would
have to be done by the other peers. An IPv4 only tracker can
not do NAT check for IPv6 clients. Only other IPv6 clients
could provide this information to the tracker. My idea was
to give each IP a trust value and when more peers report
that they successfully connected to the IP the trust
increases or decreases if the connection failed. The more
trust a peer has the more often it is returned to other
peers.

This would require an official extension of the tracker
protocol. Otherwise i doubt that any other implementation of
the tracker would implement it in the future.
--
http://reboot.animeirc.de (Personal Homepage)
http://sylpheed-claws.sourceforge.net/ (Open Source Mailer)



[Non-text portions of this message have been removed]




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Justin Cormack
2005-01-24 13:27:31 UTC
Permalink
Post by Christoph Hohmann
Post by Bill Cox
However, it would be fairly easy to have two returned keys: peers, and
peers_ipv6. I think that would solve the internet tracker problem.
The bigger problem I encountered when I tried to make an
IPv6 version of Bittorrent is that most trackers don't
accept IPs provided by the peer and use the source IP which
it also checked with the NAT check to verify that it is
correct. With this it is not possible for a peer to tell the
tracker it's IPv4 and IPv6 address. The IP the tracker
returns to other peers would depend on the IP protocol that
is used to talk to the tracker.
What does the NAT check do? Presumably it shouldnt be done for ipv6
as there is no NAT anyway...
Post by Christoph Hohmann
Additionally it would be better if the tracker would not
know about IPv4 or IPv6 and just group addresses into
categories which can be requested by the peer. Like this
even an IPv4 only tracker can provide IPv6 addresses when
the peer requests addresses from this category. The peers
would tell the tracker for each address it sends to the
tracker in which category it belongs.
This would have other advantages too: multihomed peers could give out
multiple IP addresses too.
Post by Christoph Hohmann
If you want to keep a NAT check to make sure that Bittorrent
is not used to start DDoS attacks the actual NAT check would
have to be done by the other peers. An IPv4 only tracker can
not do NAT check for IPv6 clients. Only other IPv6 clients
could provide this information to the tracker. My idea was
to give each IP a trust value and when more peers report
that they successfully connected to the IP the trust
increases or decreases if the connection failed. The more
trust a peer has the more often it is returned to other
peers.
Not sure if the complexity of this is manageable.
Post by Christoph Hohmann
This would require an official extension of the tracker
protocol. Otherwise i doubt that any other implementation of
the tracker would implement it in the future.
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Olaf van der Spek
2005-01-24 18:33:00 UTC
Permalink
Post by Justin Cormack
What does the NAT check do? Presumably it shouldnt be done for ipv6
as there is no NAT anyway...
It's more of a reachability check than a FW/NAT check.



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Justin Cormack
2005-01-24 18:53:16 UTC
Permalink
Post by Olaf van der Spek
Post by Justin Cormack
What does the NAT check do? Presumably it shouldnt be done for ipv6
as there is no NAT anyway...
It's more of a reachability check than a FW/NAT check.
right, check the port is open then, so that natted connections or ones
where the specified port is not open are ignored.

That shouldnt be a problem with ipv6 so long as an ipv6 capable tracker
has an ipv6 address (doesnt rely on ip field in tracker request, which
would be a bad idea really anyway).

I cant see any real advantage in being able to run a tracker for ipv6
clients if you dont have ipv6 connectivity, as they can always connect
with ipv4 (presumably they will look much like natted hosts then, will
check once I have some machines up with ipv6 but no ipv4 addresses).

Justin



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Christoph Hohmann
2005-01-24 21:10:01 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Justin Cormack
I cant see any real advantage in being able to run a tracker for ipv6
clients if you dont have ipv6 connectivity, as they can always connect
with ipv4 (presumably they will look much like natted hosts then, will
check once I have some machines up with ipv6 but no ipv4 addresses).
IPv6 clients should be able to talk to each other with IPv6
even if the tracker does not support it. Why should the
tracker restrict IPv6 clients to IPv4 only because it
doesn't support IPv6 itself?

- --
http://reboot.animeirc.de (Personal Homepage)
http://sylpheed-claws.sourceforge.net/ (Open Source Mailer)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFB9WQroHTSdnOy6+ERAldwAKCXUg8SKno1D1mWY4WGE9tL4NfYwwCghF4q
mnRBOxO26IOzlI19/GpduDM=
=TulP
-----END PGP SIGNATURE-----



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Justin Cormack
2005-01-24 22:22:36 UTC
Permalink
Post by Christoph Hohmann
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Justin Cormack
I cant see any real advantage in being able to run a tracker for ipv6
clients if you dont have ipv6 connectivity, as they can always connect
with ipv4 (presumably they will look much like natted hosts then, will
check once I have some machines up with ipv6 but no ipv4 addresses).
IPv6 clients should be able to talk to each other with IPv6
even if the tracker does not support it. Why should the
tracker restrict IPv6 clients to IPv4 only because it
doesn't support IPv6 itself?
Because it cant verify the ipv6 address, or even get the ip address at
all unless it happends to come via the ip field in the tracker query,
which is a very vaguely specified (and not really implemented widely)
part of the protocol.

If there is a clean way to do it you could convince me (and it supported
multihomed hosts well too), but I havent thought of how to do it yet.

Justin



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
John Hoffman
2005-01-25 02:28:48 UTC
Permalink
Post by Christoph Hohmann
Post by Justin Cormack
I cant see any real advantage in being able to run a tracker for ipv6
clients if you dont have ipv6 connectivity, as they can always connect
with ipv4 (presumably they will look much like natted hosts then, will
check once I have some machines up with ipv6 but no ipv4 addresses).
IPv6 clients should be able to talk to each other with IPv6
even if the tracker does not support it. Why should the
tracker restrict IPv6 clients to IPv4 only because it
doesn't support IPv6 itself?
Without the tracker's verifying the source IP, or at least checking the
IP for an active BitTorrent client, it would be possible for an attacker
to insert an IP into very active torrents, causing a DDoS situation.



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Martin Burggraf
2005-01-25 09:59:24 UTC
Permalink
Post by John Hoffman
Without the tracker's verifying the source IP, or at least checking the
IP for an active BitTorrent client, it would be possible for an attacker
to insert an IP into very active torrents, causing a DDoS situation.
How active should this swarm be?
If a client tries to connect and doesn't get a response, it should delete the
IP from it's internal list, so an IP without success is only tried once per
client.
Some of the most active torrents I've seen so far had about only 10000 peers,
and usually not all peers try to connect at once. So there are _at_most_ 10000
connections in about half an hour (until the tracker deletes the IP from it's
list because there is no update). I don't think this is enough for a DDoS.


bye
TSO



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Olaf van der Spek
2005-01-25 22:10:06 UTC
Permalink
Post by Martin Burggraf
Post by John Hoffman
Without the tracker's verifying the source IP, or at least checking the
IP for an active BitTorrent client, it would be possible for an attacker
to insert an IP into very active torrents, causing a DDoS situation.
How active should this swarm be?
If a client tries to connect and doesn't get a response, it should delete the
IP from it's internal list, so an IP without success is only tried once per
client.
Some of the most active torrents I've seen so far had about only 10000 peers,
and usually not all peers try to connect at once. So there are _at_most_ 10000
connections in about half an hour (until the tracker deletes the IP from it's
list because there is no update). I don't think this is enough for a DDoS.
Why would the 'attacker' restrict himself to a single torrent (or a
single tracker) or only one 'announce'?



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Martin Burggraf
2005-01-25 23:19:21 UTC
Permalink
Post by Olaf van der Spek
Why would the 'attacker' restrict himself to a single torrent (or a
single tracker) or only one 'announce'?
good point... however, I think a DDoS attack requires a certain amount of
coordination to work and in case of BT the 'attacker' has no guarantee when or
if the clients are going to connect to the victim. When a torrent gets more
peers, the possibility that the faked address is in the returned peer list
decreases, so the best targets are probably relatively small swarms, hence it
even requires more of those which implies more effort from the bad guy.
IHMO BT doesn't really guarantee the necessary coordination so the costs are
not worth it; there are definately more effective methods to carry out a DDoS.

I think its just an unnecessary waste of ressources to let the tracker do this
kind of check.
Or does someone know of an actual DDoS-Attack with BT which achieved the result?



bye
Martin



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Olaf van der Spek
2005-01-26 08:59:19 UTC
Permalink
Post by Martin Burggraf
Post by Olaf van der Spek
Why would the 'attacker' restrict himself to a single torrent (or a
single tracker) or only one 'announce'?
good point... however, I think a DDoS attack requires a certain amount of
coordination to work and in case of BT the 'attacker' has no guarantee when or
if the clients are going to connect to the victim. When a torrent gets more
peers, the possibility that the faked address is in the returned peer list
decreases, so the best targets are probably relatively small swarms, hence it
even requires more of those which implies more effort from the bad guy.
IHMO BT doesn't really guarantee the necessary coordination so the costs are
not worth it; there are definately more effective methods to carry out a DDoS.
It requires one announce to a tracker to a torrent with a swarm of 50
peers to get the victim IPA in the list for 30 - 45 minutes.
All other peer will announce at least once in those 30 minutes and will
get the victim IPA.
So at the cost of one announce you 'get' 50 TCP connects to the victim.
Isn't that a nice 'attack' multiplier waiting to be abused?
You can announce to as much torrents as you want.
Bigger swarms would also work, but not be more effective.
Post by Martin Burggraf
I think its just an unnecessary waste of ressources to let the tracker do this
kind of check.
Or does someone know of an actual DDoS-Attack with BT which achieved the result?
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Elliott Mitchell
2005-01-26 21:37:08 UTC
Permalink
Post by Olaf van der Spek
Post by Martin Burggraf
Post by Olaf van der Spek
Why would the 'attacker' restrict himself to a single torrent (or a
single tracker) or only one 'announce'?
good point... however, I think a DDoS attack requires a certain amount of
coordination to work and in case of BT the 'attacker' has no guarantee when or
if the clients are going to connect to the victim. When a torrent gets more
peers, the possibility that the faked address is in the returned peer list
decreases, so the best targets are probably relatively small swarms, hence it
even requires more of those which implies more effort from the bad guy.
IHMO BT doesn't really guarantee the necessary coordination so the costs are
not worth it; there are definately more effective methods to carry out a DDoS.
It requires one announce to a tracker to a torrent with a swarm of 50
peers to get the victim IPA in the list for 30 - 45 minutes.
All other peer will announce at least once in those 30 minutes and will
get the victim IPA.
So at the cost of one announce you 'get' 50 TCP connects to the victim.
Isn't that a nice 'attack' multiplier waiting to be abused?
You can announce to as much torrents as you want.
Bigger swarms would also work, but not be more effective.
Decent, but I think completely insufficient.

The attack swarm will need to have folks actively joining the swarm,
otherwise the peers may well be satisfied with their existing peers. The
attack swarm will also need at least 50 peers to do those 50 connects.
This cuts down the swarms that it is possible to use.

Then there is the raw number of swarms needed for attack. Going for the
pessimistic number, 50 connections for 5 minutes per swarm. So one
connection every 6 seconds. At this rate you need to locate 6000 swarms
to do this DoS.

The identification of trackers is an interesting task. They can be on any
IP address and any port. Then there is the issue of whether they meet the
above qualification. These two I think kill this as a serious attack
vector. If you don't test them for qualification then you'll be wasting
bandwidth on dud attack swarms. If you do test them for qualification
you'll be wasting massive bandwidth doing that testing, and likely less
than 1 in 50 swarms will qualify (based on the data pointed to in a
previous post, stating that small trackers are the rule).

A zombie army could be utilized to do this sort of scan, but once you've
got that army why not directly attack? Might protect your army, but it
will also cut down their attack power.
--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\ ( | ***@gremlin.m5p.com PGP 8881EF59 | ) /
\_ \ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
\___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/





Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Karst Bjorgson
2005-01-27 07:47:13 UTC
Permalink
Post by Olaf van der Spek
Post by Olaf van der Spek
It requires one announce to a tracker to a torrent
with a swarm of 50
Post by Olaf van der Spek
peers to get the victim IPA in the list for 30 -
45 minutes.
Post by Olaf van der Spek
All other peer will announce at least once in
those 30 minutes and will
Post by Olaf van der Spek
get the victim IPA.
...
Decent, but I think completely insufficient.
Maybe it is insufficient, maybe it is not. In any
case, getting IPv6 support on a tracker should not be
a very big issue. Trackers are supposed to not be
behind a NAT, and to have full use of a "clean" IPv4
address. Thus, they meet the requirement for running
the "6to4" protocol, which is supported by Windows XP,
Windows 2003, and most Unix systems.

So, in practice, it makes a lot of sense to assume
that a tracker can have "dual stack" support for IPv4
& IPv6. It could conceivably advertise an IPv4 address
in the DNS, accept declaration of IPv6 addresses, and
run a connectivity test over IPv6.

In fact, even if the system does not support IPv6, it
should still be possible to hack an IPv6 connectivity
test by handcoding IPv6 packets and sending them over
a raw socket.

-- Karst




__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Kenneth Porter
2005-01-28 05:03:46 UTC
Permalink
--On Wednesday, January 26, 2005 11:47 PM -0800 Karst Bjorgson
Post by Karst Bjorgson
In fact, even if the system does not support IPv6, it
should still be possible to hack an IPv6 connectivity
test by handcoding IPv6 packets and sending them over
a raw socket.
That assumes an IPv6-capable router on the segment. If you've only got an
IPv4 stack, then send your packet to the 6to4 anycast router.

Hacking packets shouldn't be done by high-level stuff, anyway. If your
tracker needs to worry about this, get an IPv6-capable platform and do it
right.



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Christoph Hohmann
2005-01-25 12:21:45 UTC
Permalink
Post by John Hoffman
Post by Christoph Hohmann
IPv6 clients should be able to talk to each other with IPv6
even if the tracker does not support it. Why should the
tracker restrict IPv6 clients to IPv4 only because it
doesn't support IPv6 itself?
Without the tracker's verifying the source IP, or at least checking the
IP for an active BitTorrent client, it would be possible for an attacker
to insert an IP into very active torrents, causing a DDoS situation.
Why don't you read the rest of the thread before you write
useless comments?
--
http://reboot.animeirc.de (Personal Homepage)
http://sylpheed-claws.sourceforge.net/ (Open Source Mailer)




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
John Hoffman
2005-01-25 22:22:23 UTC
Permalink
Post by Christoph Hohmann
Post by John Hoffman
Post by Christoph Hohmann
IPv6 clients should be able to talk to each other with IPv6
even if the tracker does not support it. Why should the
tracker restrict IPv6 clients to IPv4 only because it
doesn't support IPv6 itself?
Without the tracker's verifying the source IP, or at least checking the
IP for an active BitTorrent client, it would be possible for an attacker
to insert an IP into very active torrents, causing a DDoS situation.
Why don't you read the rest of the thread before you write
useless comments?
Why don't you use your brain before you flame?

If the tracker has no IPv6 access, it cannot accept incoming connections
from an IPv6 address to verify that address, nor can it connect back to
a peer claiming to be at an IPv6 address. Therefore it would have to
assume that peer was telling the truth about its being at that address.
A peer could therefore insert a bogus address, causing the tracker to
direct its peers to attempt to establish connections to that address.
In the case of a large swarm, this might cause problems with a server at
that address. This is called a DDoS. Got it?



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Elliott Mitchell
2005-01-25 23:32:16 UTC
Permalink
Post by John Hoffman
Post by Christoph Hohmann
Post by John Hoffman
Post by Christoph Hohmann
IPv6 clients should be able to talk to each other with IPv6
even if the tracker does not support it. Why should the
tracker restrict IPv6 clients to IPv4 only because it
doesn't support IPv6 itself?
Without the tracker's verifying the source IP, or at least checking the
IP for an active BitTorrent client, it would be possible for an attacker
to insert an IP into very active torrents, causing a DDoS situation.
Why don't you read the rest of the thread before you write
useless comments?
Why don't you use your brain before you flame?
If the tracker has no IPv6 access, it cannot accept incoming connections
from an IPv6 address to verify that address, nor can it connect back to
a peer claiming to be at an IPv6 address. Therefore it would have to
assume that peer was telling the truth about its being at that address.
A peer could therefore insert a bogus address, causing the tracker to
direct its peers to attempt to establish connections to that address.
In the case of a large swarm, this might cause problems with a server at
that address. This is called a DDoS. Got it?
While Christoph did go into flame mode way too quickly, his stance does
have some strength as pointed out by Martin Burggraf. The best you can do
is a low-level DDoS against a large group of IP addresses, or destruction
of the swarm by flooding it with bogus IP addresses.

Sure, a swam might consist of 100,000 peers, but how many of them are
going to attempt to connect to your DoS target? Very few of them, since
most of the time the tracker will give out the other 100,000 valid peers.
On average you will only provoke a number of connection attempts
equivalent to the average number of peers each peer attempts to obtain.
This is so small an average system will laugh at the modest few
connection attempts you provoke.

What can happen is I can attempt to flood the tracker's list of peers
with bogus ones, resulting in the tracker giving out mostly bogus peers
and killing the swarm. This is hard to do as a good tracker will note
that hundreds of peers are being added by one host, and thereby ignore
them. I think attacks along this line are a valid concern, but they are
against the swarm, not a particular peer.
--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\ ( | ***@gremlin.m5p.com PGP 8881EF59 | ) /
\_ \ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
\___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/





Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Kenneth Porter
2005-01-26 01:31:33 UTC
Permalink
--On Tuesday, January 25, 2005 3:32 PM -0800 Elliott Mitchell
Post by Elliott Mitchell
What can happen is I can attempt to flood the tracker's list of peers
with bogus ones, resulting in the tracker giving out mostly bogus peers
and killing the swarm. This is hard to do as a good tracker will note
that hundreds of peers are being added by one host, and thereby ignore
them. I think attacks along this line are a valid concern, but they are
against the swarm, not a particular peer.
This could be dealt with using a protocol extension that allows a peer to
report to the tracker the validity of an address it's given. The tracker
uses the swarm to validate the addresses it receives. The probability that
an address is given out is weighted by the votes for and against that
address by the swarm.

This of course leads to a different kind of attack, in which a peer votes
against every address given it. Any ideas on how to deal with that? Perhaps
thresholding the votes with a minimum count needed for consensus.





Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Christoph Hohmann
2005-01-25 23:32:02 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by John Hoffman
Post by Christoph Hohmann
Why don't you read the rest of the thread before you write
useless comments?
Why don't you use your brain before you flame?
[...]
Bla bla bla, I already wrote all that.

- --
http://reboot.animeirc.de (Personal Homepage)
http://sylpheed-claws.sourceforge.net/ (Open Source Mailer)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFB9tb2oHTSdnOy6+ERAprWAJkBNT8AOi01pUfsr90zowgxKdd4hwCfYzAC
hyaHGMU34dt0kA0dhnCqJ80=
=agfE
-----END PGP SIGNATURE-----



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Christoph Hohmann
2005-01-24 14:17:14 UTC
Permalink
Post by Justin Cormack
Post by Christoph Hohmann
The bigger problem I encountered when I tried to make an
IPv6 version of Bittorrent is that most trackers don't
accept IPs provided by the peer and use the source IP which
it also checked with the NAT check to verify that it is
correct.
What does the NAT check do? Presumably it shouldnt be done for ipv6
as there is no NAT anyway...
As fas as I know the tracker connects to the peer and
validates the peer id. If that fails the peer is remembered
as being behind a NAT gateway and is not returned to other
peers. The NAT check is done for the source IP of the
tracker connection and in most cases the IP that is provided
by the peer is ignored. Even if the IP is not ignored and
tested that will not work for IPv4 only trackers when they
receive IPv6 addresses by a peer.
Post by Justin Cormack
Post by Christoph Hohmann
If you want to keep a NAT check to make sure that Bittorrent
is not used to start DDoS attacks the actual NAT check would
have to be done by the other peers. An IPv4 only tracker can
not do NAT check for IPv6 clients. Only other IPv6 clients
could provide this information to the tracker. My idea was
to give each IP a trust value and when more peers report
that they successfully connected to the IP the trust
increases or decreases if the connection failed. The more
trust a peer has the more often it is returned to other
peers.
Not sure if the complexity of this is manageable.
The NAT check is also a security check. Imagine that a peer
provides a false IP of some webserver of a company and
suddenly hundrets of peers connect to this webserver. When
the tracker should accept IPs that it can not validate the
check has to be done by someone else.
--
http://reboot.animeirc.de (Personal Homepage)
http://sylpheed-claws.sourceforge.net/ (Open Source Mailer)




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
guanying_wang
2005-01-22 13:14:33 UTC
Permalink
Post by Justin Cormack
Is anyone running any ipv6 trackers for anything?
Wanted to test ipv6 support.
Justin
Check the following links, I wish it will help
http://6net.iif.hu/index.php?mn=3&sm=9&lg=en
http://6net.iif.hu/index.php?mn=3&sm=10&lg=en







Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Justin Cormack
2005-01-24 09:56:18 UTC
Permalink
Post by guanying_wang
Post by Justin Cormack
Is anyone running any ipv6 trackers for anything?
Wanted to test ipv6 support.
Justin
Check the following links, I wish it will help
http://6net.iif.hu/index.php?mn=3&sm=9&lg=en
http://6net.iif.hu/index.php?mn=3&sm=10&lg=en
Thanks thats very useful, will do some testing shortly.

Justin



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Justin Cormack
2005-01-24 13:15:58 UTC
Permalink
Post by guanying_wang
Post by Justin Cormack
Is anyone running any ipv6 trackers for anything?
Wanted to test ipv6 support.
Justin
Check the following links, I wish it will help
http://6net.iif.hu/index.php?mn=3&sm=9&lg=en
http://6net.iif.hu/index.php?mn=3&sm=10&lg=en
This seems to be working fine, thanks very much.

Havent tested incoming connections yet but will do shortly as soon as I
have more machines configured for ipv6.

About compact, as far as I can see so long as your client doesnt request
compact=1 it should never get compact format, so any ipv6 enabled client
can just ignore compact and it shouldnt cause problems.

Justin



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Loading...