> > i guess we are living with very different assumptions. > > > it's just that the needs of applications vary as widely as the needs of > users. it's not as if all Internet users do nothing but email and the > web, and neither is it as if all Internet applications are like HTTP or ssh. if you are not under NDA, could you please be more specific? source code, RFC/draft for the protocol, whatever? i'm getting tired of this guessing games. > > sorry, you are, too lazy. remember the days when we had bitnet, > > decnet and compuserve (niftyserve in japan) in email world. > > we had a lot of technologies, or tricks i would say, to make emails > > get delivered from/to arbitrary networks. > > > > in this analogy, IPv4 is bitnet/decnet/compuserve and IPv6 is the > > Internet. of course. > > > yes, I remember those, and I also remember the problems we had trying to > make all of that work well - in particular, the problem of rewriting > addresses so that the mail would still be replyable after it crossed > multiple gateway boundaries. (actually I wrote a thesis on the topic). > I'm sure my experience with email addressing and gateways is part of why > I could see the problems with NAT earlier than most people. > > of course, it's not as if every application in the v4/v6 world is like > email. at least some of those email protocols were designed to be > store-and-forward and to allow email to be transmitted across networks > without end-to-end connectivity. store-and-forward isn't appropriate > for every applications protocol. (and I'd even argue that it probably > shouldn't be used for email anymore, at least not in the way that SMTP > currently does it, because it's really hard to arrange for errors to be > reliably reported to the party that needs to know about them.) well, i'm sure there still are instances of Lotus Notes running in ancient enterprises. once you run ALG (which i guess you do not like) IPv6-to-IPv4 or IPv4-to- IPv6 looks much like SMTP relaying. if you could give v6ops people your comments from your experiences, it would be helpful. i know we have been trying and tired to death, but this year is THE right time. > > without giving out the details of your "correct model" we cannot > > discuss. go by mathematical rules, first you give me axioms and > > then we talk about your theories. do not call theories a "fact" > > or "correct model" because we cannot define them. > > > I don't think there is a single "correct model" for all apps that works > in a network where hosts have multiple addresses and the performance can > vary significantly depending on which address pair you choose. yup, there's no single truth. we agree on that. > ideally, from the application's point-of-view, the network would always > perform well enough to suit the needs of the application and it wouldn't > matter which source and destination address were used. also, any > address would be reachable from any point in the network. the > traditional IPv4 network approximately fulfilled both conditions; the > current IPv4 network with NATs still mostly fulfills the first one. > having multiple addresses per host/network be the normal case in IPv6 > threatens to remove the first condition, and having a mixed v4/v6 > network nixes the second one. > > if you want PTR, MX and NS records, use res_send and stuff. > > > > use getnameinfo NI_NAMEREQD and getaddrinfo AI_NUMERICHOST if you > > want DNS resolution to happen for certain. > > > I don't recall that this guaranteed by the API specification. do not underestimate my paranoid-ness, i'm an OpenBSD developer, and i'm proud of it! i've met both Steve Mann and Richard Stallman face to face, though i don't think they remember me. - getaddrinfo/getnameinfo standards do not say a thing about DNS lookup so you cannot trust it. of course if analyze the source code, you may. - res_send/res_query are not a standard so the behavior is not defined in documents. of course if analyze the source code, you may. - even if you write code that plays with UDP/TCP socket, you are unsure if there's any tricks inside OS kernel, like host firewall blocking or rewriting your queries/responses. of course if analyze the source code, you may. - even if you trust your OS kernel, you cannot trust your router, especially when it implements NAT and you are using it with NAT disabled. of course if analyze the source code, you may, but the likelyhood of getting source code is rather low. - even if you trust your router, you would not be able to trust your ISP, or peering ISPs. now it became impossible to look at source code, and/or configuration of all the routers. - even if you trust your L3 stuff, you cannot trust DNS trees. (1) how can you trust your libc resolver? it is the first 3 bullets above. (2) how can you trust your recursive resolver, the address listed in /etc/resolv.conf? even if you run recursive resolver, can you trust guys behind Paul Vixie or djb? (3) can you trust recursive responses from random name servers, when we do not have DNSSEC deployed? (4) even if you have DNSSEC, how can you be sure that you are using the right root DNS server/DNSSEC signing chain, and how can you be sure that all of the signing keys are not compromised? > > ok, you need bump-in-the-stack (hitachi) or bump-in-the-library (erik > > nordmark/sun microsystems). > > > nah. basically it's easy to port either system to a pure IPv6 network, > and this might have already been done; it's just hard to run an app that > expects complete connectivity among all nodes on a mixed IPv4/IPv6 > network. please contain yourself from using "complete", "fact", "truth", "god", and whatever. in Japan there are 8,000,000 god*s* and father of jesus could be one of them. > >> what is the problem you have with "multiple-addresses-per-host" problem? > >> i never had any problem even with IPv4. > >> > it's the fact that in IPv6 if you don't select the best source and > destination address to talk to a node, you might either fail to get a > connection (and have to wait a long time for a timeout), or you might > get a connection that performs much worse than some other > source/destination address pair you could have used. this was true for > IPv4 nodes with multiple interfaces also, but this was mostly solved in > IPv4 by not having multiple active network interfaces. (people tried > it, it didn't work well, so they stopped doing it.) In IPv6 the normal > situation for hosts on multihomed networks is to have multiple > addresses, and there are several pressures to have additional addresses > - like for mobility, or using ULIAs for local apps on enterprise > networks so that they won't be affected by renumbering. so address > selection becomes more important in IPv6 than it was in IPv4. ok, so you are basically worried about uRPF, performance difference, and/or firewalling policy differences when you have multiple exit links. do not take it as a self-promotion, but my take on this is in RFC3178. > > describe what is "complete connectivity" in your definition. > > are you talking about QoS? > > > if you are building a distributed computation system and you want it to > perform well then any node should be able to send packets to any other > node, even if some of those nodes are IPv4 only and others are IPv6 only. > > > if you are the IPv6 guy in Skype, we need to talk :-) > > > yeah, I think I see how to make Skype dual stack too, since they already > have the infrastructure needed to relay packets between two nodes that > are both behind NAT - they could use the same kind of infrastructure to > relay packets between v4 and v6 realms. but I'm not the ipv6 guy in > Skype. :) so i can solve problem for Skype, so i guess i can solve problem for your "distributed computation system". want to hire a consultant? :-P itojun _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf