[DavidXanatos]

Hi,

I'm looking forward to adding IPv6 support to my ed2k/eMule capable File Sharing client.

And remembering how protocol extension Development worked in the past:
like with ISP-Traversal of NeoMule, where despite of a finished protocol encryption eMule decided to do an own incompatible implementation.

I would like to start here first a thread and hopefully agree on a design so that if in future eMule (or any of its mods) should add IPv6 support it wont do an own imcompatible version but a compatible one.

So any one interested in some preliminary thoughts on the subject,
or should I just post a draft proposal and wait for feedback?

David X:

[Neoo26]

My english is very bad, but if you're asking about add IPv6 in eMule.... there are more chances that the world will end tomorrow

[Ejack79]

It's been years for discussion on IPv6. And it seems impossible to apply to eMule...

IMHO, eMule needs change on these points:
Distributed L2L: Truly client-based LowToLow. As FTTx spread more and more users become LowID;
IPv6: You know that;
de-MFC(rewrite for multi-environment): Windows is in danger, it's not kidding. So are MFC-based applications;
Distributed Credit System: I prefer this than WiZaRd's ClientAnalyzer. The logic: you can hardly tell a stranger to be a bad guy, but you can always tell a familiar good guy. So the good one can tell you another half-trusted good guy.

[Neoo26]

eMule will never change nothing... developers say it is perfect. Ahahah.

[DavidXanatos]

"LowToLow" a.k.a. Nat-Traversal will also be included in my client.

"Distributed Credit System" thats a bad idea, any "Credit System" is imho counter productive .

David X.

[fox88]

Neoo26, you already made two posts of negative value.
But the topic was intended to be a technical discussion, hence clowns are not welcome.

This post has been edited by fox88: 13 January 2013 - 05:05 PM

[Some Support]

Quote

de-MFC(rewrite for multi-environment): Windows is in danger, it's not kidding. So are MFC-based applications;

MFC based application will stay for quite a while imho. Not that I would recommend starting one today, but existing one will run on PCs for a few decades. And sure tablets (Android, IOS) or eating up Windows market share, but removing MFC (which basically means rewriting eMule) isn't going to help here.

As for IPv6: As stated in other threads several issues in Kad are not resolved yet. But the main point is that it is unlikely that we have time to rework the protocol of ed2k and kad to properly support IPv6. If we would do so, we wouldn't use an existing implementation as again it would mean rewriting the better part of the protocol, but as I said the truth is that it is unlikely to happen from our side at this point.
Without downplaying the importantance of IPv6 (there is no doubt that it would be nice for eMule to support it properly and find a way to work out its problems in Kad), IPv4 will stay arround for a long time to come, so it will not effect the usability for most users.

[DavidXanatos]

Quote

If we would do so, we wouldn't use an existing implementation as again it would mean rewriting the better part of the protocol,

Well this are not so many changes, you basically need to have a altered packet version with an IPv6 instead of an IP v4 for Hello(answer), PubIP, and Source exchange eider a secondary packet with IPv6 adresses or a new format that can for each node store boot addresses.

And of cause Kad. But since I wont be doing any Kad changes (in a part of the network it would be pointless) thats not relevant in that thread.

Neo will use its own Kad to find IPv6 ed2k sources.

So the main changes are in the hello packet as well as in the source exchange system.
For the hello aside of sending a 128 bit ID and a IPv6 server address it would be needed to also send the ipv4/ipv6 address (so on a v4 channel the v6 addr and vice versa) so the clients get to know all IP's of any other client.

As about source exchange I would suggest using a tag based format so that for any client arbitrary data can be stored in his particular entry, like i do now already in the NeoLoader version.

Than there would be SUI but than I don t care about that as Neo does not implement it.

So if I'm not mistaken that war already all packets that needs altering.


So if we could agree on a specification for the new Hello packet we would have the most already done.
a specs for the Pub IP packet (OP_PUBLICIP_ANSWER) would also be nice,
here I would suggest to put the IP into the hello packet so we always tell the client we are talking to on which Ip we are doing that (bt does it this way).
So actually we would need only to update the hello(answer) specs and the part critical for compatibility would be set.


David X.

[Neoo26]

Quote

Neoo26, you already made two posts of negative value.
But the topic was intended to be a technical discussion, hence clowns are not welcome.

If you live in your unreal world where eMule is perfect, and who use uTorrent is egomaniac, is not my problem and I don't understand why I should not wrote my opinion about adding or not a certain feature in the offi client.

IMHO Yes, developer should implement IPv6, but I know that probably they don't agree... can't I say that? What's wrong?

@Xanatos: Would be nice if when you finished your code from neo, someone compile an emule with this code implemented (surely it need some modification, expecially if we want SUI) and do some test. After would be easly decide if work correctly and better implement in eMule public release or not. (would be nice do that aslo with a lot of other features/changes...)

This post has been edited by Neoo26: 13 January 2013 - 05:39 PM

[DavidXanatos]

Neoo26, on 13 January 2013 - 05:38 PM, said:

@Xanatos: Would be nice if when you finished your code from neo, someone compile an emule with this code implemented (surely it need some modification, expecially if we want SUI) and do some test. After would be easly decide if work correctly and better implement in eMule public release or not. (would be nice do that aslo with a lot of other features/changes...)

Well,
if there would be really enough demand for an eMule mod that features only IPv6 NAT-T and some other protocol extensions, as well as the NeoKad module as a separate process I could consider making such a mod.
But really I would have to know that the work wont be waisted and that sufficient many users would use it.

David X.

[Neoo26]

Quote

if there would be really enough demand for an eMule mod that features only IPv6 NAT-T and some other protocol extensions

Why not with a 0.50a based NeoMule with IPv6 ??

I'm sure all mod users will appreciate this!

[]Axl[]

DavidXanatos, on 13 January 2013 - 08:58 PM, said:

Well,
if there would be really enough demand for an eMule mod that features only IPv6 NAT-T and some other protocol extensions, as well as the NeoKad module as a separate process I could consider making such a mod.
But really I would have to know that the work wont be waisted and that sufficient many users would use it.

David X.

Very interesting idea!
You have all my support (not for code writing...I'am not able!)

[achilles863]

I've recently tried Neoloader, and it shows huge promise. David is working on functionality in his client that I have not seen in most other emule clients. Thanks for you hard work David!

[DavidXanatos]

A draft for IPv6 is can be found here: http://piratenpad.de/p/ed2kIPv6

David X.

[stoatwblr]

Some Support, on 13 January 2013 - 04:40 PM, said:

IPv4 will stay arround for a long time to come, so it will not effect the usability for most users.

Don't bank on that. Parts of the world (eg: China) already have large tracts of netspace in ipv6-only allocations and the only way to talk to them is to be on ipv6 yourself.

The asia-pacific region ran out of ipv4 space last year. Europe will move to ipv6-only allocations at the end of this month and the USA won't be far behind.

The issue isn't about keeping ipv4, it's about being able to make contact with ipv6 users. There are a number of ipv6-ipv4 gateways, but as these will have literally millions of possible hosts behind each visible IPv4 address, kad gets badly broken. Once you add Carrier-grade NAT onboard (where the IPv4 changes rapidly) things get even more badly broken.

My personal opinion is that moving to ipv6 will be like a damburst - it's been held off for more than a decade by kludges such as dynamic IP assignment, NAT and a few other tricks, but once more than about 5% of the world is using it there's going to be a lot of demand to switch away from legacy ipv4. It's likely that by this time next year at least 25% of the world's computers will be running ipv6.

Don't forget ipv4 was a "hacky kludge" designed to tide things over until better protocols were developed. 4 billion ip addresses was felt to be enough for the intended lifetime of the protocol - about 5-10 years - at a time when there were fewer than 500,000 internet connected computers.

A couple of notes:

1: IPv4 addressing is a subset of ipv6, so a ipv6-Kad implementation can include all ipv4 kad values if needed (this covers contacting clients via ipv6-ipv4 gateways)

2: The standard allocation to endusers is intended to be a /64 (ie, anything at finer resolution is multiple clients on the same LAN), so in a pinch calculations could be kept to 64bits (I don't recommend this, as things like dorm LANs are quite likely to have multiple kad clients on them)

3: However you code, please keep it portable. Some of us are running variants such as aMule and it's better if the code can be easily ported to multiple platforms/endianness without too much gnashing of teeth

Here's hoping you can make it work. It'd be a pity if the change to ipv6 means killing emule.

This post has been edited by stoatwblr: 15 February 2013 - 03:11 AM

[DavidXanatos]

@stoatwblr
I agree, that the spread speed of IPv6 is most likely underestimated.

But I feel that the devs target audience is central Europe and US, actually I'd even assert that its mostly Germany at least thats what I conclude basing on their particular attitude towards Source Saver Features. They operate on the assumption that almost every user has a forced disconnect and IP change at least once every 24 hours, thats a common praxis for German ISP's to prevent operating servers on private lines, but to my knowledge its not a praxis common in the rest of Europe and definitely not common in the US where they have mostly cable.

Well and the IPv4 issue is just not that pressing for countries like Germany or many other central Europe countries.

Quote

Here's hoping you can make it work. It'd be a pity if the change to ipv6 means killing emule.

I'm quite sure it wont, it will just cut the file sharing landscape in to camps. Countries with old infrastructure that will keep IPv4 for possibly a long time as they will already have all the IP's they need, as its known the demographic isn't growing in this countries anymore its even shrinking in some. And the rest of the world that is using IPv6.

But I agree that we need to go to IPv6 especially to enable developing countries to use eMule to fight US Copyright regime, as they have the balls to give the finger to the US instead of sticking deep in the pockets of US lobbyists as many central Europe politicians are.

David X.

[intser]

David,

Would you explain how I can add special emule server in NeoLoader?

[DavidXanatos]

intser, on 20 February 2013 - 05:52 PM, said:

David,

Would you explain how I can add special emule server in NeoLoader?

NeoLoader does not support servers, only kad.