im using he.net tunnel services for testing purposes. i think is important knowing how to deploy and configure as many services as i can over ipv6. some people cant stop annoying me about he waste of bandwith of ipv6 brokers. i dont care about that. the benneffits are more than the disadvantages. i know the theory, more or less, the encapsulation and the bigger size of headers in ipv6. but simple tests as bandwith test doesnt show a high lose of bandwith. he.not does not use compression, is this true? and please could anyone point me to the right way to test what is the real bandwith lose.
thanks and sorry for my english.
No compression, no encryption. What are "they" saying the disadvantages are and who are "they". Name and shame. You could use iperf to test throughput.
thanks, by the way im using iperf with this command: iperf -c 2001:xxx -V -p 5001 -P 10 -t 240 whats worng? i can ping the ip but iperf allways return Unknown host. the -V is for ipv6 as i see in the manpage.
Unknown host sounds like perhaps whatever version you are using can't handle IPv6 literals? I just tested that command against my own machines and it worked fine.
iperf version 2.0.5 (08 Jul 2010) pthreads
Quote from: prietus on March 06, 2013, 05:57:45 AMi know the theory, more or less, the encapsulation and the bigger size of headers in ipv6.
Let's do the math.
For IPv4 let's assume an MTU of 1500, anything higher than that is not widely available. A typical TCP payload packet ends up with 20 bytes IPv4 header, 32 bytes TCP header, 1448 bytes payload data. Percentage of capacity used for data 96.5%
For IPv6 let's assume an MTU of 1280, which is guaranteed on every IPv6 link. A typical TCP payload packet ends up with 20 bytes IPv4 header, 40 bytes IPv6 header, 32 bytes TCP header, 1208 bytes payload data. Percentage of capacity used for data 93%
Divide those two numbers to find that IPv6 gives you 96% of the payload throughput that you got with IPv4. Those few bytes used on extra headers and the reduced MTU is no problem for bandwidth usage.
Where there are some real concerns is in the different (probably longer) route your traffic takes when using a tunnel. I am working on a fix for that. Alternatively you could just go native IPv6.
Additionally in some cases the bottleneck on routers is not the bandwidth but rather the number of packets per second. In such a case a reduction of the IPv6 MTU from the 1480 bytes you could have gotten in a tunnel down to only 1280 is more of an issue. You'd be wasting 13.5% of the capacity just on that.
I'd only expect the later concern to be relevant to backbone routers transferring data for many different users. Anybody who is worried about this should go over their network looking for faults that break PMTU discovery and fix those. Because if PMTU works there isn't any reason to use only 1280 bytes on a link that could take 1480 bytes.
thanks for the clarification has been very helpful as allways in this forum.
Quote from: kasperd on March 06, 2013, 11:19:46 AM
For IPv4 let's assume an MTU of 1500, anything higher than that is not widely available. A typical TCP payload packet ends up with 20 bytes IPv4 header, 32 bytes TCP header, 1448 bytes payload data. Percentage of capacity used for data 96.5%
For IPv6 let's assume an MTU of 1280, which is guaranteed on every IPv6 link. A typical TCP payload packet ends up with 20 bytes IPv4 header, 40 bytes IPv6 header, 32 bytes TCP header, 1208 bytes payload data. Percentage of capacity used for data 93%
Divide those two numbers to find that IPv6 gives you 96% of the payload throughput that you got with IPv4. Those few bytes used on extra headers and the reduced MTU is no problem for bandwidth usage.
But be aware that in real traffic there are many packets that don't carry anywhere near a full payload. For small packets (acknowlagements, VOIP DNS etc) the increase in overhead will be much higher.
Quote from: plugwash on March 08, 2013, 01:09:59 AMBut be aware that in real traffic there are many packets that don't carry anywhere near a full payload. For small packets (acknowlagements, VOIP DNS etc) the increase in overhead will be much higher.
True, but for those use cases where bandwidth efficiency is important, full size TCP packets should be the majority of packets.
QuoteFor IPv6 let's assume an MTU of 1280, which is guaranteed on every IPv6 link. A typical TCP payload packet ends up with 20 bytes IPv4 header, 40 bytes IPv6 header, 32 bytes TCP header, 1208 bytes payload data. Percentage of capacity used for data 93%.
This computation is wrong because one does NOT add the IPv4 header size to the IPv6 packet. The IPv4 packet header is OUTSIDE of the IPv6 header as it is an encapsulating header, not an encapsulated header.
Encapsulated IPv6 packets of 1280 bytes are inside IPv4 packets with a size of 1300 (1280 + 20). The payload capacity of a 1280 byte IPv6 packet is 1248 bytes after stripping the TCP header. That's 97.5%, not 93% (sic - should be 94.375%). The overall data/packet ratio of IPv4 encapsulating an IPv6 packet is 96% (1248/1300).
Quote from: snarked on March 08, 2013, 11:45:13 AMThis computation is wrong
I used the correct number of bytes for the IPv6 header in my calculation, you did not.
And you included the IPv4 header size when you should not have.
Quote from: snarked on March 09, 2013, 03:15:55 PM
And you included the IPv4 header size when you should not have.
Wrong again. The question was about bandwidth usage of native IPv4 compared to IPv6 tunnelled over IPv4. In both cases there is an IPv4 header, which must be accounted for.
Yes, but you subtracted the IPv4 header size from the IPv6 MTU when you should have added it as it's NOT part of the IPv6 MTU size.
Quote from: snarked on March 10, 2013, 12:56:46 PMyou subtracted the IPv4 header size from the IPv6 MTU
No, I did not.
You explicitly included it in your list of subtracted values from 1280 to arrive at 1208. Read your message.
Quote from: snarked on March 11, 2013, 11:15:17 AMYou explicitly included it in your list of subtracted values from 1280 to arrive at 1208.
I never said anything about subtracting the IPv4 header size from 1280.
Quote from: snarked on March 11, 2013, 11:15:17 AMRead your message.
I have read it. Have you?
You listed it among the other subtractions. That was clear. Your computation implied comparing 1280 to 1208, not 1300 to 1208.
Quote from: snarked on March 12, 2013, 11:34:37 AMYour computation implied comparing 1280 to 1208
I was not implying that. And if you look at the other numbers in my comment, it should be clear I was implying no such thing.
Bottom line is, when you were saying it was wrong, you were referring to your own assumptions, and not what I had written.