On 9/11/2012 10:20 PM, Pars Mutaf wrote:
...
Known problems, in no specific order:
a) like NAT, this fails for all protocols that use in-band
identifiers (e.g., FTP) unless the entire body of the packet
is translated too, and that might not be possible for some
services
I don't understand. I just copy the whole payload. Or, replace the IPv4
header with an IPv6 header. I don't have to know what's in the payload.
If the payload includes an IP address (take a look at how FTP works),
then you have to translate that. That's how current NATs work for *many*
protocols.
b) you fail to explain why this needs to happen for the
first packet and not all subsequent packets, or what to do
with subsequent packets (and what happens when the second
packet arrives - e.g., at the translator or elsewhere -
before the first one?)
1. I send the first packet to the copier. In the same message, I tell
the destination IPv6 address that I learned using DNS for example. (this
is not exactly a tunnel I don't have to speak IPv6)
3. The copier creates state for my IPv4 address and destination IPv6
address.
4. Forwards packets in both directions
Why does the second packet not also need to be tunneled?
FWIW, what happens if the second packet shows up at the copier before
the first one? Keep in mind that many protocols (including some variants
of TCP) don't wait for an exchange to complete before sending the
second, third, etc., packets.
c) the first packet won't be tunneled unless you upgrade
the source endpoint node to speak your new version of things;
if we could do that, everyone would be speaking IPv6
Yes it is not a tunnel exactly. This is my bad. The first packet is a
special packet, call it a Discrete IP packet, telling the copier the
destination IPv6 address.
Is this from the DNS or the source?
And if this is a signalling packet, it's not a tunnel at all, FWIW.
d) what name/ID are you looking up in the DNS?
the node application already did a lookup for the
destination, and you now need to rewrite every application
to use your solution instead
I assume a new host identifier, other than IP address.
Have you considered the implications of this assumption? Aren't you then
assuming that this identifier *never changes* as you deploy new versions
of IP, e.g.? Why do you think that will be true if it wasn't for IPv4?
(i.e., right now the DNS use is decoupled from network
packet processing; you want to integrate it - have you
seen Cheriton's I3 proposal along these lines?)
I am not sure if it should be integrated.
e) which DNS do you register endpoints in? (answer: all of
them, except that you can't know where the ones outside your
"IP version" bubble are) so basically you're never going to
find the endpoints in other bubbles anyway
You do not know what we can or cannot do yet. We didn't even discuss if
we want my proposal.
We attacked the details.
I do know that you need to register in every DNS or you won't find the
name (or you need to tie the DNSes together - and if you do that, you
provably already have a common internetworking layer, but you can't
assume a common internetworking layer in your solution to provide one).
Until you prove otherwise.
Having a blank margin and a claim didn't work for Fermat, and it isn't
sufficient here either.
f) which payload-only are you forwarding? the one in the
tunneled packet includes headers the next bubble doesn't
understand; if you strip off those headers, you lose a lot
of state
No. The copier copies IPv4 payload to the IPv6 header that it creates
itself.
OK, so that's just a NAT at that point.
Again, from your paper: "We do not need to use NATs anymore" only
because you don't call them that, but you're implementing a stateful
NAT as a translator.
The question is not they are like NATs or not, we are changing the
architecture. I can reuse yahoo's global IP address at home.
You claim:
---
We do not touch the core network, i.e. the current IPv4
infrastructurewhich works. Those who wish, add additional
infrastructure
if necessary(IPv4, IPv6, etc.)
You change the DNS and add translators on that IPv4 network.
I change DNS, I also change TCP.
DNS is part of the core of the network - at least it's in-network
infrastructure, not an end service on the user's host.
IPsec doesn't work, multicast is gone.
How do you restore those capabilities? Or will security not work here?
But this is a trade-off:
We are now free from core Internet's IP version decisions forever. This
is the real discussion that we should have here. Do we want this
approach or not? Once we decided that it is desirable, anything is
designable. Because we do not depend on core network anymore, we change
the end points. This is the end-to-end principle.
Do we want to be free from this IP version problem forever? What can we
sacrifice to solve this problem?
We modify the end-hosts only
Your translators are not end-hosts.
It is not a modification. People add them and remove them as they wish.
If I remove them - all of them - then the system won't work. You need to
have them for your solution.
It is not like modifying all Internet routers.
It's a lot like installing new boxes that act a lot like routers, except
that you refuse to call them routers and they're not nearly as robust or
useful as routers.
We do not have worry about others' IP version preferences, we do
not have to implement IPv6 for example
Your translators have to worry a lot about version preference.
They are designed for that. And it is not big deal, they just copy payload.
---
Please read the Catenet paper.
You are treating each IP version as a link layer, your translators
are IP routers, and your DNS works like ARP.
Unfortunately, that doesn't remove the need for an end-to-end
internetworking layer with global addresses, which you don't have
and don't address at all.
Let's first discuss what we want. We may have a host identification
layer above IP for example but it is early to discuss technical details.
That's not a technical detail; that's the key to the solution. That IS
what IP *is*. That's why shifting from IPv4 to IPv6 is hard.
We do not even know what we want.
Then write a paper on the requirements. But you cannot expect to satisfy
a want you *agree* we do not currently understand.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
