From: cr88192@hotmail.com
"Rick Jones" wrote in message
news:he23tm$u58$1@usenet01.boi.hp.com...
> BGB / cr88192 wrote:
>
>> this way, ones' task would be in steps:
>
>> alternate packet format which can handle larger addresses, but
>> which: handles old addresses transparently; is still routable via
>> stupid hardware
>
> Stupid hardware would be able to deal with the destination network
> address now being 32 bits farther into the header than it was before?
> (Or did I miss something or should have read-on futher to the below?)
>
they could get the packets where they needed to go, at least in the case
where both the network and host are still identifiable via an IPv4 address.
otherwise, things get a little messier, and some level of hackery could be
needed, such as setting up "trampolines" and setting them up to "bounce"
messages which happen to hit them to the correct hosts, for example, as a
result of stupid routers.
I will not claim that this would have been without problems, but at least it
could have gotten deployed easier.
>> one option for this could have been to create a special IP protocol tag,
>> which would have contained an "IP extension header", which could have
>> contained:
>> the added middle 32-bits for the to/from addresses;
>> possibly either a new "protocol" or "next header" field, ...
>
> The new parts would then have to be proper subsets of the old parts
> no? Anything in the middle of your new 192.168.0.0.0.0.0.1 would have
> to be in the same routing path as 192.168.0.1 for it to be handled by
> older equipment right? Wouldn't that only serve to give more
> addresses to those who already have them rather than spread addresses
> out among more recipients?
>
even this is better than the present state...
basically, a person/company/... could have a server set up as a trampoline,
and stupid routers would ram their traffic into the trampoline, which would
then "bounce" it to hosts with addresses assigned outside of the IPv4
addressable range.
later on, smarter routers could be used, which would inspect the packet and
route it directly, eliminating the trampoline server from the mix.
splitting up the address this way, it could also be possible to "trampoline"
the network as well.
as a downside, this scheme would likely require a complicated (as in,
non-linear) scheme for address allocation and assignment (as well as only
being able to assign new addresses within the range currently reachable via
a given trampoline).
closely related to a trampoline would be a device similar in form to a NAT
router, only that it would differ in how it would redirect packets (a
trampoline would "bounce" packets to other hosts on a local network, whereas
a NAT-like router would contain the expanded network on its inside edge).
another possiblity would be more of an expansion of modern NAT (although, it
would require different protocol+router firmware, ... so it is no-go at this
point), would be to expand the address at the NAT border, and hack the
protocol to route this way:
15.191.23.45:192.168.55.223
again, likely involving shimming an extra header in there somewhere...
the great problem here is that there is not that much ability (in general)
to modify NAT-router firmware, or in some cases, where the user does not
even control the NAT they end up with (for example, in my case, Qwest
supplied the modem/router, and little can be done about it...).
likewise (another likely pointless idea):
'IP:port' trampoline, where a message hits a given IP:port (wrapped in UDP),
and is essentially unwrapped and "bounced" to a local target (with a little
tweaking, this could be made to work in a manner similar to teredo, and be
routable through NAT).
actually, this idea could do IPv6, and make use of teredo, but would mostly
differ on the local edge (the computer at the endpoint would need to set
itself up as a v6 router). I tried to pull off something similar to this
with WinXP before, was unable to get Windows to do this (although, it could
be possible with a custom server deamon). I have not investigated if other
OS's (Vista or Linux) can do this, or if software exists for this.
(decided to remove a lot of stuff, not really relevant to the topic in
general, only some stuff specific to my own case, and issues with a
Qwest-provided NAT router which apparently drops local v6 packets even on
the LAN, meaning v6 is only possible over secondary wired links, as well as
further Windows' annoying-but-unchangable behaviors...).
>> (thus the new format would have been a hacked form of the old
>> format...).
>
>> granted, this is far from perfect, but could have likely been
>> deployed more rapidly.
>
> I suspect the router types (who, near as I can tell/recall were very
> influential in IPv6) would have gone ape over that.
>
it is not too much unlike the sorts of hacks usually used to expand the x86
ISA, ... while still retaining backwards compatibility...
granted, understood, reality is not always exactly convinient, and I realize
that most of the ideas I have here are a moot point at this point in
history...
> rick jones
> --
> firebug n, the idiot who tosses a lit cigarette out his car window
> these opinions are mine, all mine; HP might not want them anyway... :)
> feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
