OK. See you there. Cheers, Pars On Wed, Sep 12, 2012 at 10:10 AM, Joe Touch <[email protected]> wrote:
> 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<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
