Hi Joe, all, We really shouldn't enter in design questions before we understand what we want. 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]> 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
