On Wed, Sep 12, 2012 at 7:37 AM, Joe Touch <[email protected]> wrote: > On 9/11/2012 9:07 PM, Pars Mutaf wrote: > ... > > Why do you refuse to *read it?* >> > > From the paper: > > ----- > >> All nodes in all Internets are registered to the DNS. The following >> example designis illustrated in Figure 2. IP payload copier, IPPC, >> copies the payload in IPv4 packets to IPv6 packets, and vice versa. >> It is different from IP translators which translate header >> information. I discuss later how TCP can work over this scheme. >> >> 1. Node A makes a DNS request, obtains the destination address D and >> the IPaddress of the IPPC to reach the address D. In this example, >> the IPPC address is B. >> >> 2. Node A tunnels the packet to the IPPC. >> >> 3. IPPC creates state for the addresses A and D. >> >> 4. IPPC copies the payload found in IPv4 packets to IPv6 packets, and >> vice versa,between A and D. >> >> 5. Tunneling is done for the first packet only. >> > > ---- > > So the IPPC acts as a NAT, and the state is setup by the first request to > the DNS. > > 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. > > 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 > 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. > 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. > > (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. > 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. > > 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. IPsec doesn't work, multicast is gone. 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. It is not like modifying all Internet 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. We do not even know what we want. > > Joe > >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
