When are overlapping fragments created and why? Is there any legitimate scenario in which they are used or are they just used by attackers, like in the teardrop attack? And how is receiver suppose to reassemble such fragments (since there is more than one way to do that)?
IPv4 Fragmentation – Understanding Overlapping Fragments
fragmentationipv4
Related Solutions
Answers to your questions:
No, just because device supports IPv6 it doesn't mean it support IPv4<>IPv6 transition mechanisms - they're not part of IPv6 protocol specification. So, it may support translating traffic from IPv4 to IPv6 and vice versa but it needs to support mechansism like NAT64.
Nodes communicate with the protocol of their choice, depending on the higher layer calls. If your browser points to a name, and the name resolves to IPv4 only, IPv4 will be called in to service it. If it resolves to both IPv6 and IPv4, IPv6 should take precedence, but a lot was done in recent years to make both calls simultaneusly and check which one is faster.
You need to have node that is dual-stacked, so supports both IPv4 and IPv6 or have support of translating between protocols somewhere along the way. If your router supports it - fine, if your ISP supports it - it's also fine.
You should see IPv6 as it should take precedence. If not, your IPv6 connectivity, at least to this specific site is broken. If you can use only IPv6 (you are not dual stacked) you can only reach around 4-5k prefixes around the internet, which is very small percent (out of 500k for IPv4). Normally, hosts are dual-stacked however, so you should be fine - using IPv6 for IPv6-enabled services, and IPv4 for all the rest.
That depends on the type of the service your ISP provides. You may have private IPv4 assigned to your internet interface, and it gets translated somewhere at the ISP edge. You may have public IPv4.
For SSL/TLS you're using names, not IPs directly. You should be fine.
Yes, while there are still works to provide NAT services for IPv6, general idea about IPv6 was to stop doing NAT, and provide global connectivity. It means that with IPv6 assignment, your entire internal network may be directly reachable from other parts of the internet, if you're using IPv6 addresses from the Global Unicast space. For IPv6 you can use other types, like for example Link Local only, which would provide internal connectivity, but block ability to access from remote locations. Generally, you should filter the traffic at the edge of your network if you don't want the internet to access your resources/nodes.
Unfortunately, I don't understand the question. Cloud services are usually OK with IPv6, Amazon at least is.
Start from here: http://test-ipv6.com/
Suppose I'm receiving IPv4 UDP packets whose payload is less than 18 octets, so when they are transmitted over Ethernet they have some trailing padding. The equipment generating said packets includes the length of the padding in the IP header's total length field. So, for example, a packet with a 7-octet-long payload will not have an IP total length of 35, but rather 46.
Where did you get that idea?
Ethernet is a layer-2 protocol, and it doesn't know about the layer-3 protocol. Ethernet can carry any number of layer-3 protocols (IPv4, IPX, IPv6, AppleTalk, etc.), and it knows nothing about the layer-3 protocols or headers for the layer-3 protocols, so it has no way to change a field in a layer-3 header.
Conversely, the layer-3 protocol has no idea which layer-2 protocol (ethernet, Wi-Fi, token ring, frame relay, ATM, PPP, etc.) carries its packets.
The ethernet padding is for ethernet frames at layer-2, not the layer-3 packets.
Edit:
You completely changed the meaning of the question, which is very bad form, especially when you already got an answer to the original question. You should start a new question for a different question, not change the original question.
The device in the middle that changes the IPv4 header total length field must change the IPv4 header checksum, and the UDP checksum (if it used, but it is optional for IPv4, and it is often not used) is not computed using the IPv4 total length field or checksum, so it would not change.
If the IPv4 total length field is changed, then IPv4 will send its original payload (the UDP datagram) and the padding to UDP.
The UDP header has its own length field. If the device does not modify this field, then the UDP will be correct and UDP will send the correct number of octets (not including the padding) to the application, but if the device changes the UDP length field, then the UDP checksum will be recomputed and UDP will send the original UDP payload, plus the padding to the application, possibly causing a problem for the application.
Best Answer
Overlapping fragments shouldn't occur for "normal" traffic. They are usually a sign of someone trying to circumvent some security system.
You are right that there are different ways to reassemble them. Different implementations behave differently, which is why the attack can be used to circumvent firewalls and make those different systems "see" different things.
Another way to do that without overlapping fragments is by sending a TCP packet with a TTL that is too low to reach the destination host, but which is high enough to pass the firewall. The firewall will see the packet, but the destination host won't. If the firewall is naive in its implementation it will cache what it saw. Then if you retransmit the same TCP packet but with different data the firewall will think it's a normal retransmit and not examine the packet again, but for the host it will be the first time it receives that TCP data and it will use the second version.
There are many ways to mislead firewalls. Overlapping fragments is one of them. A good firewall should detect such behaviour and block the session.