Hi, Pars,
On 9/11/2012 11:36 PM, Pars Mutaf wrote:
Hi Joe, all,
We really shouldn't enter in design questions before we understand what
we want.
Sure. However, INT-AREA isn't the place for this sort of discussion. You
might consider trying at [email protected], which is the
typical place where end-to-end discussions on architecture are first made.
The IETF is a place for engineering solutions, not research. The IRTF
serves that purpose, and the above list is the original IRTF list for
these sorts of discussions.
You (and others) are welcome to take this discussion there, but I expect
the thread has lost its usefulness to the INTAREA WG.
Joe
Please question everything you learned, even the research method.
As I see it, the following research style would be ideal:
-I propose that we do not touch the core Internet.
-People should be free to choose the IP version that they wish because
deciding for others is a technology blocker. IETF designs IPv6, IETF
blocks its development. Because IETF does not give freedom of choice.
This is not normal. Some entities may use IPv6 others IPv4 yet others
IPv7 for unknown reasons. Everybody may agree on IPv6, or not. We do not
know. We do not have to.
-To give such freedom of choice, we need to change the end-nodes.
-This is the end-to-end principle.
Here is a picture:
http://htmlimg3.scribdassets.com/2hdm1jwfcw1sxm1y/images/4-5930b39cea.jpg
Is this the model that we would prefer? Could we first answer this
question? Anything can be designed. The hard part of research is
deciding on the best solution.
Thanks,
Pars
On Wed, Sep 12, 2012 at 8:35 AM, Joe Touch <[email protected]
<mailto:[email protected]>> wrote:
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
