And please don't add any more layering violations. It makes implementors
life painful and kills any architectual cleaniess in operating systems.
i have long wished for and sometimes needed a way to renumber a host w/o
killing or restarting its active tcp flows. this isn't a layering
violation. tcp should be able to know about endpoint-renumber events.
Paul Vixie wrote:
And please don't add any more layering violations. It makes implementors
life painful and kills any architectual cleaniess in operating systems.
i have long wished for and sometimes needed a way to renumber a host w/o
killing or restarting its active tcp flows. this isn't a layering
violation. tcp should be able to know about endpoint-renumber events.
Unfortunately this sounds like a good target for people to mess up implementations and introduce huge security issues into TCP stacks. (along the theme of the one which started the recent MD5 discussion)
But obviously, implemeted properly that would be very useful. The problem then becomes, how an ISP can signal a renumber.
Pete
Paul Vixie wrote:
And please don't add any more layering violations. It makes implementors
life painful and kills any architectual cleaniess in operating systems.i have long wished for and sometimes needed a way to renumber a host w/o
killing or restarting its active tcp flows. this isn't a layering
violation. tcp should be able to know about endpoint-renumber events.
This is a layering violation and has endless security implications.
You can solve the renumber thingie by having all TCP connecting to/from
an official IP on the loopback interface. Then the routing code could
do its work and route the packets through some some other or renumbered
interface.
Try to get your TCP automatic renumbering stuff implemented from spec by
five different people in five different codebases in a compatible way
within two month time... No way.
KISS KISS KISS KISS !!!
Why is the telephone (POTS/Mobile) so popular? Easy answer: Even the
most stupid person on earth capable of correctly reading digits is able
to punch in a number. As simple as it gets.
Have you ever worked in luser techsupport? I did for the fun of it.
It's not pretty. And that's why IPv6 is not going to fly. It's broken
by design in so many places that it's impossible to explain it by phone
to Joe Average (with IQ100, I'm not even talking about the average US high
school dropout flipping burger in your favorite fast food chain).
Paul Vixie wrote:
>>And please don't add any more layering violations. It makes implementors
>>life painful and kills any architectual cleaniess in operating systems.
>
> i have long wished for and sometimes needed a way to renumber a host w/o
> killing or restarting its active tcp flows. this isn't a layering
> violation. tcp should be able to know about endpoint-renumber events.This is a layering violation and has endless security implications.
Full Ack. IMHO SCTP and HIP are the way to go at the moment. Both
support both IPv4 and IPv6 btw. New technologies are required to solve
old problems, which is not that odd now is it ? 
<SNIP>
Have you ever worked in luser techsupport? I did for the fun of it.
Most people would refuse it
It's not pretty. And that's why IPv6 is not going to fly. It's broken
by design in so many places that it's impossible to explain it by phone
to Joe Average (with IQ100, I'm not even talking about the average US high
school dropout flipping burger in your favorite fast food chain).
I am not flipping burgers, but did once work in a cheese factory (Gouda
cheese anyone? :), I am wondering how you could keep this piggie from
flying though. Could you elaborate or point me to a doc where you most
likely already did?
Greets,
Jeroen
> i have long wished for and sometimes needed a way to renumber a host
> w/o killing or restarting its active tcp flows. this isn't a
> layering violation. tcp should be able to know about
> endpoint-renumber events.This is a layering violation and has endless security implications.
as i told someone in private e-mail earlier this morning, tcp's notion
of a flow-identifying tuple includes network addresses, and so, the
ability to change these on the fly will absolutely affect tcp. when
you bind a session to an address, as tcp currently does, you cause the
community to waste ipv4 /32's or ipv6 /128's as loopback aliases just
to have something they can virtualize, manage, move around, play with.
let me put that another way, in case it's not clear enough as stated:
tcp's existing reference to network addresses are a layering violation,
and so anything we do to improve the situation will also be a layering
violation, but what of it? deciding against making tcp "less pure" is
not going to meet the needs and demands of the community -- and those
needs and demands WILL be met, and probably in even less pure ways.
google for a product or feature called "3TCP" to see what i mean.
You can solve the renumber thingie by having all TCP connecting
to/from an official IP on the loopback interface. Then the routing
code could do its work and route the packets through some some other
or renumbered interface.
see above. we do that now. however, it limits the scope of mobility to
"same autonomous system" and often "same campus" so it's not useful for
any wide area purpose. the internet's target area is very wide indeed.
Try to get your TCP automatic renumbering stuff implemented from spec
by five different people in five different codebases in a compatible
way within two month time... No way.
where i come from that's called "the fallacy of the straw man" and is
not a well respected technique for debate or discussion. the process
i'm thinking of would take years to reach deployability, and more years
to reach wide scale deployment.
KISS KISS KISS KISS !!!
Why is the telephone (POTS/Mobile) so popular? Easy answer: Even the
most stupid person on earth capable of correctly reading digits is able
to punch in a number. As simple as it gets.
i guess i was expecting smart people to write kernels and "lusers" to
just run working code. this seems to work for apple and suse and redhat
and sun and microsoft. or is this another straw man thing? certainly
my kids think their mac/os/x machine is as easy to use as a telephone,
and if you asked them how the routing table worked they wouldn't care.
So how do you renumber the loopback interface?
ifconfig le0:1 <newaddr> netmask <newmask>
YMMV depending on your operating system.
Owen
ifconfig le0:1 <newaddr> netmask <newmask>
YMMV depending on your operating system.
If the old address is removed, then TCP sessions established with the old address as an endpoint will break; hence plumbing TCP sessions to loopback addresses is not a solution to TCP survival over renumbering attempts.
That was my point.
Right... Well... The point of the loopback thingy was that you don't
renumber the loopback. The address assigned to the loopback is used
as the session endpoint identifier, while, the address assigned to
the network interface is used as the routing endpoint identifier. So,
BGP takes care of deailing with the consequences of renumbering the
routing endpoint identifier, and, lo0 remains a consistent session endpoint
identifier.
This will not scale, but, it does work (e.g. anycast).
Owen
Paul Vixie wrote:
let me put that another way, in case it's not clear enough as stated:
tcp's existing reference to network addresses are a layering violation,
and so anything we do to improve the situation will also be a layering
violation, but what of it? deciding against making tcp "less pure" is
not going to meet the needs and demands of the community -- and those
needs and demands WILL be met, and probably in even less pure ways.
google for a product or feature called "3TCP" to see what i mean.
But doesn't HIP fix that in a way that is already specified and it just needs to be pushed forward if the community feels it fixes the "next generation TCP" issue?
Pete
Right... Well... The point of the loopback thingy was that you don't
renumber the loopback.
This is not any kind of answer to the problem of TCP session survivability across renumbering events; it's an answer to the non-problem of TCP session survivability when there are no renumbering events.
[how to suck eggs]
Joe
Paul Vixie wrote:
i have long wished for and sometimes needed a way to renumber a host
w/o killing or restarting its active tcp flows. this isn't a
layering violation. tcp should be able to know about
endpoint-renumber events.This is a layering violation and has endless security implications.
as i told someone in private e-mail earlier this morning, tcp's notion
of a flow-identifying tuple includes network addresses, and so, the
ability to change these on the fly will absolutely affect tcp. when
you bind a session to an address, as tcp currently does, you cause the
community to waste ipv4 /32's or ipv6 /128's as loopback aliases just
to have something they can virtualize, manage, move around, play with.
So?
let me put that another way, in case it's not clear enough as stated:
tcp's existing reference to network addresses are a layering violation,
and so anything we do to improve the situation will also be a layering
violation, but what of it? deciding against making tcp "less pure" is
not going to meet the needs and demands of the community -- and those
needs and demands WILL be met, and probably in even less pure ways.
google for a product or feature called "3TCP" to see what i mean.
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.
You can solve the renumber thingie by having all TCP connecting
to/from an official IP on the loopback interface. Then the routing
code could do its work and route the packets through some some other
or renumbered interface.see above. we do that now. however, it limits the scope of mobility to
"same autonomous system" and often "same campus" so it's not useful for
any wide area purpose. the internet's target area is very wide indeed.
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.
Oops, the remote end switched IP addresses too and you are lost.
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? 
And the other, more serious, question is whether IP addresses are something
that you only use temporarily or permanently?
Try to get your TCP automatic renumbering stuff implemented from spec
by five different people in five different codebases in a compatible
way within two month time... No way.where i come from that's called "the fallacy of the straw man" and is
not a well respected technique for debate or discussion. the process
i'm thinking of would take years to reach deployability, and more years
to reach wide scale deployment.
Nonetheless having a simple and easily implementable spec is key to
success and compatibility. I know you can write, hmm, interesting
and complex code...
KISS KISS KISS KISS !!!
Why is the telephone (POTS/Mobile) so popular? Easy answer: Even the
most stupid person on earth capable of correctly reading digits is able
to punch in a number. As simple as it gets.i guess i was expecting smart people to write kernels and "lusers" to
just run working code. this seems to work for apple and suse and redhat
and sun and microsoft. or is this another straw man thing? certainly
my kids think their mac/os/x machine is as easy to use as a telephone,
and if you asked them how the routing table worked they wouldn't care.
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.
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?
#ifconfig lo0 down
#ifconfig lo0 ::2
#ifconfig lo0 up
is one way...
--bill