Hi Nathan et al, Sorry I've been slack - travelling around the land of Eire at the moment with time-zones and flakey Internet causing some challenges. Alcatel-Lucent sponsored this research in association with WAND to investigate the SP-NAT option, and as Shane mentioned the results were quite revealing. One item we should mention is that the we did not correlate RADIUS Acct (or similar) with the captured traffic - this means we were unable to definitively identify unique individuals with a global ID (such as username), instead resorting to unique IP address. Second the source data may be now out of date. This really leaves the door open for more research - something that Alcatel-Lucent would be interested in discussing with ISP who are interested! We recognise the value of this data and I'm in complete agreement with Nathan on making it widely available - hence our presentation at APRICOT earlier this year on the subject. We have also been doing work with Bell Labs to look at the economics of SP-NAT, and of course we may have a trick or two up the proverbial sleeve which our development team are working on. The "net10" issue is by far the single biggest consideration for SP- NAT. Some ISP we have talked to are going to simply re-use an assignment many times within their organisation, some are looking towards IANA for a new assignment (see the drafts Brian posted), while for others even a /8 is not big enough. I expect both SP-NAT and approaches like dual-stack lite and sNAT (http://tools.ietf.org/html/draft-droms-softwires-snat-01 ) will be adopted. There is no "right" answer, but some options available to operators to continue limited IPv4 operations post exhaustion. One thing that is clear from the research - our expectations regarding the amount of unsolicited inbound traffic have been challenged. Both dual stack lite and SP-NAT/CGN all involve PAT, so the user experience will be identical (in our analysis). No amount of SP-NAT, Dual Stack Lite or tricks up sleeves will bring back the IPv4 experience we have today in which you and I have a global IPv4 address we can play with. IPv6 is clearly the only way forward and one we need to start the planning for now. Any interested parties please feel free to contact me off-list or via Shane if there is a research opportunity. Best Regards, David Miles (david.miles(a)alcatel-lucent.com) On 05/08/2008, at 6:13 AM, Shane Alcock wrote:
Responses can be found in-line.
Nathan Ward wrote:
Awesome, that saves me some effort.
Can you reveal what the profile of this particular ISP is?
Not really, for two reasons - 1) I don't want to say anything that would give away the ISP in question and 2) I don't really know. I referred to profile as more of a comparative thing - we'd need to do similar studies for other ISPs before we could say where a particular ISP might fall on the scale.
My main interest, is exploring the relationship between end users doing peer-to-peer on IPv4, and end users who have IPv6 (Teredo, 6to4). Do you have any numbers around that, or is it very hard to extract some?
I would say, looking out for IP protocol 41, and UDP port 3544 would do the trick.
So you just want to look at doing a similar study, except just looking at users who have demonstrated IPv6 capability? If so, I don't think I have that sort of data at hand, but it wouldn't be too hard to get it. The biggest difficulty is that it takes quite a while to process the packet traces (although I'm guessing you wouldn't need to look at the full four days worth of traffic).
Teredo of course uses non-standard ports for peer-to-peer, but that doesn't matter so much as it's always sending bubble packets to the server to keep NAT state open.
Your document talks about ports per session, do you have any data around ports per byte? I expect one would find that port 445 etc. drops down quite significantly in cases like that. What about session length, in seconds?
Again, I don't think I've been tracking these things specifically for incoming connections. I tracked a whole heap of stuff for outgoing flows, because that was what the Alcatel project was primarily focused on. But I could modify the code and re-run the processing to get that sort of stuff, if required.
I'm hoping to prove that with a bit of movement from a couple of application vendors (Skype, etc.) we can start doing SP-NAT and preserve end-to-end, but over IPv6 instead of IPv4.
Azureus is already doing IPv6 over IPv6, uTorrent has it coming in 1.8.
Ideally, I'd like to get some numbers around this IPv4 p2p / IPv6 p2p relationship regularly updated, as I suspect as more and more applications become IPv6 aware the numbers will change quite significantly.
Being able to do this sort of thing on a regular basis would be pretty neat. The set of traces we've been using for this are starting to get a little out-of-date now (February 2007). It's mainly a matter of getting a box in an appropriate location within an ISP to get some decent up-to-date traces.
Next big thing to watch out for is uTorrent 1.8 - by default it turns on IPv6(Teredo,6to4,etc.) in Windows when it is installed. Azureus only uses IPv6 if it's enabled already.
-- Nathan Ward
Ultimately, we can probably give sort out some numbers for you if you don't mind waiting for the data to be processed. If you're keen, let me know and we can start working out the exact specifics of what you want measured.
Shane Alcock
WAND Network Research Group University of Waikato _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog