who gets a /32 [Re: IPV6 renumbering painless?]

Tue Nov 30 02:02:48 UTC 2004

> Instead 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.
>
Please point me to where I can get a version of SSH that uses SCTP instead
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.

> Nonetheless having a simple and easily implementable spec is key to
> success and compatibility.  I know you can write, hmm, interesting
> and complex code...
>
Have you read the SCTP spec?  It is not especially simple, and, I would 
argue,
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.

> No, 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.
>
Actually, I have never written an IP stack, but, I've set up lots of 
internet
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.

> Because 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?

Paul may, but, I don't see the relevance of the above statement.  If they 
can
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20041129/8bbea3a4/attachment.sig>