Remi Despres wrote: In this mail, I assume readers have read the original paper on the end to end principle by Saltzer et. al. and understand the implications of "completely and correctly" mentioned in the paper.
However, talking about THE solution seems to me too much: - The SAM approach (to be soon renamed Mesh-softwire lite - MSL) avoids your requirement that hosts run BGP,
As is discussed in my ID, BGP is not my requirement.
and support the full worldwide routing table.
That is not my requirement, either, though small full routing table helps to guess the best address to try.
- Named based extensions of socket APIs seem IMHO to have more potential than multiple address APIs.
As was proven in my previous mail, as IP layer (hostnames belongs to IP layer) is connectionless and does not support notion of time out, proposals not involving transport layer of end systems are broken. They must, like legacy NAT, guess transport layer time out. The guesses, not using "knowledge and help" of end systems, are not done "completely and correctly" as is discussed in the original end to end paper of Saltzer et. al.
It is clear that UDP is adequate only if E2E paths are not too frequently broken, and if broken connections are acceptable if they are rare.
Connection? UDP, in general, is connectionless and applications like vanilla DNS works with request and reply without establishing connection, at least not TCP-like connection. Still, note that RFC1035 requires DNS implement end to end multihoming.
To change connection addresses on the fly,
If you think DNS an important application, never say connection.
NAT-like approaches to solve the problem at the IP layer are all broken.
But note that the SAM-MSL approach is not in this category.
Anything relying on incorrect and incomplete guesses on route failure is NAT-like and violates the end to end principle.
With 4B or 6B port numbers, the problem can be solved as address/port allocation polices of port restricted IPv4.
Such a drastic evolution, only justified to avoid IPv6, would be unreasonable.
As changes required to support IPv6 is a lot more drastic, you successfully deny IPv6.
In IPv6, fragmentation errors being an end-to-end matter,
In IPv6, fragmentation is end to end. However, as fragmentation errors are generated by intermediate routers, fragmentation handling of IPv6 is not at all end to end. As such, path MTUs guessed by end hosts are "incomplete and incorrect", which is why path MTU discovery performs poorly violating the end to end principle. For example, end hosts can not directly know path MTU increase, which is "incomplete and incorrect".
ISPs that don't support IPv6 multicast themselves are not concerned.
The ISPs must filter fragmentation errors, to protect their customers from ICMP implosion caused by 1500B multicast packets sent from other ISPs with forged source addresses.
E2E fragmentation is IMHO one of the significant pluses of IPv6.
E2E fragmentation relies on PMTUD. If only PMTUD, which is not end to end, had worked.
Applications are and must remain unaware of whether their datagrams are transmitted in single or multiple fragments.
Applications over UDP like DNS should be aware, just as TCP is aware. `
The IP layer introduces per se no constraint on DNS-message lengths.
Please simply answer the following question: With 1280B of path MTU, how many bytes, do you think, are assured to be carried over UDP over IPv6 without fragmentation?
Native IPv6 is deployed today and, for its users, works fine for a number of applications (without harm to other applications that use IPv4 as before).
Then, you should be able to answer the question above. Please.
With IPv4, header length of which is at most 60B long, fragmentation is always possible. With IPv6, you can expect nothing.
I don't understand what you mean.
Read RFC791, how well IPv4 is designed with its fragmentation.
To me, extending the specification of IPv4 NATs and of IPv4-capable hosts is a modification of the IPv4 protocol suite.
That's not a useful definition.
The important fact is that existing products generally support IPv6 basic functions, and generally AFAIK don't support E2E-NAT.
That's not an important fact that port restricted IP, including but not limited to E2E NAT, is not supported by most equipment, because port restricted IP can be deployed locally and still interact with the rest of the world. On the other hand, IPv6 deployment requires IPv6 deployment at the network and at both ends, which is, as you can see even 15 years after RFC1883, impossible.
The fact that they don't support multicast can be reason why their IPv6 service works nicely.
See above for a possible ICMP implosion DOS attack.
I am not familiar enough with this issue to discuss it more. A good reference about it would be appreciated.
RFC2463 (ICMPv6 spec.).
Thanks to indefinitely lengthy optional headers, no applications work safely over IPv6.
This statement seems to me completely ideological!
Then, try to answer my simple question above.
There exists today, and in the real world, applications that DO WORK safely over IPv6.
People working on DNSSEC seriously (though DNSSEC is bogus) want to know how long messages can be safely sent over UDP over IPv6. Your answer to my question will be quite helpful for them.
Are you ignoring it? Or willing to deny it?
I'm afraid you have been ignoring UDP and DNS, which are my examples to deny IPv6.
If a host has a native IPv6 address, its real world OS (Windows, OS X, Linux etc) does not add options that might create problems. (AFAIK, the only option used is for fragmentation.)
As I already mentioned, optional headers are added with MIPv6.
It's time, IMHO, to avoid fighting the lost battle against IPv6 being deployed and used.
IPv6 was wrongly specified, vigorously implemented, partially deployed, partially used and totally failed, partly because of broken specification. That's all. Masataka Ohta