|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: who gets a /32 [Re: IPV6 renumbering painless?]
Please point me to where I can get a version of SSH that uses SCTP insteadInstead of hacking the nice and working TCP we have now you should move on to greener grass and use SCTP instead. It does what you want, at least in the specification. I don't know how many implementors have managed to code it properly. of TCP and talks to the existing SSHD services using TCP with flow survivability. If the TCP library changes underneath SSH and provides this capability, it will get deployed. If we need to completely rewrite all the applications to support TCP and SCTP in some sort of split-brained idea of how the world should work, then, adoption is less likely. Personally, I agree that TCP is the wrong place to solve this. I think instead of moving up the stack we need to move down the stack and solve this entirely at layer 3 by recognizing that IP addresses as currently implemented (both in v4 and v6) are better as endpoint identifiers and as such should be migrated to layer 4 with layer three being built on a new series of addresses that are topologically derived and do not need to remain consistent during a session for the session to continue. The further this thread goes, the more I am convinced that the telcos have the key. There are actually two phone numbers associated with each end of any given call. One is the endpoint identifier (Dialed Number/Billing Number), the other is the routing identifier (I don't know the SS7 term for this). In most cases, it turns out that these are the same, but, that is purely a matter of architectural convenience resulting mostly from the prevalence of incumbent local carriers and geographic hierarchy. There is no real need for any correlation between the two addressing schemes even though they use the same address format and limitations. Yea, but what is a surviving TCP good if you put your laptop to sleep and wake it up somewhere else? It can't pre-announce the next IP address it will use. Instead at the new location it will have to convince somehow the remote host that he is he indeed. No way without cryptography. IPSEC will break too. There are lots of ways to solve this. Simple X.509 certificate based authentication over a separate stateless service among them. However, if we separate the routing identifier entirely from the endpoint identifier, then, this question is moot except for the generic case of endpoint authentication which we either don't bother with today (mostly) or, which we can use the existing solutions for. Oops, the remote end switched IP addresses too and you are lost. Not if we separate endpoint identifier from routing identifier. In that case, we just need to learn the new mapping between the same endpoint identifier and it's new routing identity. The question is whether renumbering while moving active TCP sessions to the new IP address is a problem at all other than a nice-to-have dream of 'propellerhead' Paul? ;) Well... If you want to get entirely away from PI space in v6 and preserve hierarchical addressing as the primary goal (as stated by the IETF, ICANN, and RIR policies), then, it is an absolute requirement. If you are willing to concede that given the existing implementations, this goal shouldn't be the primary goal any more and there are tradeoffs to be made to meet real world requirements, then, this can become less important. And the other, more serious, question is whether IP addresses are something that you only use temporarily or permanently? Depends. Endpoint Identifiers need to be something you can use permanently in enough situations that as long as IP addresses are endpoint identifiers I would say permanently (or at least nearly permanently). If we can use something else as endpoint identifiers and use IP addresses strictly as routing identifiers, then, IP addresses can be temporary, and, it is the other endpoint identifiers that must be permanent. Have you read the SCTP spec? It is not especially simple, and, I would argue,Nonetheless having a simple and easily implementable spec is key to success and compatibility. I know you can write, hmm, interesting and complex code... not particularly easy to implement. How many known interoperable implementations of SCTP exist today? How many can be put in place as a DSO replacement for the existing TCP DSOs? How much recoding is necessary at the application level to get a daemon to listen for both SCTP and TCP connections? How much recoding is necessary at the application level to get a client to attempt and SCTP and TCP connection and use the best one that answers? How much delay is introduced when connecting to an SCTP unaware site that doesn't send back ICMP unreachables for SCTP? KISS KISS KISS KISS !!! Yep... There loses SCTP. Actually, I have never written an IP stack, but, I've set up lots of internetNo, they don't mind just using the computer because you set up the internet connection. Have them call your favorite ADSL provider and order an ADSL line and then have them set up some DSLWLAN thingie plus a printer connected via ethernet. And using the Apple offerings is cheating, take the average cheap windooze stuff. connections. In most cases, there is no requirement to know how the routing table works to get connected to the internet. Try again. Even if you inflict the pain of doing this in a Whine-D0ze environment (you're right, even FreeBSD is easier these days), using a ZyXel toaster, the web interface to get it all running just isn't that hard. Oh, and, BTW, once you put a complete setup together, the Apple stuff turns out not to be any more expensive than the "cheap" whine-doze stuff. Paul may, but, I don't see the relevance of the above statement. If they canBecause all this worked so well they want to run their own webserver on their computer and others from the internet should be able to connect... You see? get reasonable DNS, this shouldn't be an issue as long as their provider will provide an address that doesn't change rapidly or often. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. Attachment:
pgp00132.pgp
|