UDP over IPv4/IPv6
karthikbalaguru
If the UDP runs over IPv4, there is field called
'protocol' (bits 72 to 80) in header. But, if the UDP
runs over IPv6, the 'protocol' field is not present in IPv6
header.
Any specific reasons for the introduction and use of
'Next Header' field to represent the 'protocol' value
in IPv6 header ?
Thx in advans,
Karthik Balaguru
Philip Paeps
It's easier to parse.
The IPv6 header is fixed-length and the next-header field allows
implementations to easily only pick out the headers they're interested in.
- Philip
--
Philip Paeps Please don't email any replies
phi...@paeps.cx I follow the newsgroup.
I think the Defiant had some quantum torpedoes, or did it?
-- Mark
karthikbalaguru
> karthikbalaguru <karthikbalagur...@gmail.com> wrote:
> > Hi,
> > If the UDP runs over IPv4, there is field called
> > 'protocol' (bits 72 to 80) in header. But, if the UDP
> > runs over IPv6, the 'protocol' field is not present in IPv6
> > header.
> > Any specific reasons for the introduction and use of
> > 'Next Header' field to represent the 'protocol' value
> > in IPv6 header ?
>
> It's easier to parse.
>
> The IPv6 header is fixed-length and the next-header field allows
> implementations to easily only pick out the headers they're interested in.
>
Thx for the info.
The RFC 2460 specification appears to convey
that the 'Next Header' has been introduced mainly to support
extension headers.
Interestingly, the RFC 2460 also states that the extension headers
must be processed strictly in the order they appear in the packet.
Refer to the below snapshot from RFC2460 (Section 4) -
" The contents and semantics of each extension header determine
whether or not to proceed to the next header. Therefore, extension
headers must be processed strictly in the order they appear in the
packet; a receiver must not, for example, scan through a packet
looking for a particular kind of extension header and process that
header prior to processing all preceding ones. "
But, i wonder why IPv4 does not have Extension header support ?
Any specific reasons/constraints for the absence of Extension header
support in IPv4 ?
Jorgen Grahn
...
> But, i wonder why IPv4 does not have Extension header support ?
> Any specific reasons/constraints for the absence of Extension header
> support in IPv4 ?
You're basically asking "why doesn't this old version of IP solve
certain problems exactly like this new version does?" I guess it was
an improvement, and by definition you don't find those in the version
which was improved upon.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
karthikbalaguru
> On Sun, 2009-11-15, karthikbalaguru wrote:
>
> ...
>
> > But, i wonder why IPv4 does not have Extension header support ?
> > Any specific reasons/constraints for the absence of Extension header
> > support in IPv4 ?
>
> You're basically asking "why doesn't this old version of IP solve
> certain problems exactly like this new version does?" I guess it was
> an improvement, and by definition you don't find those in the version
> which was improved upon.
>
:-) :-)
Yes, It is just an improvement that is brought over the IPv4
and infact IPv6 was brought to quench the address problem.
Though IPv4 clock is ticking fast, Internet is predominantly
based on IPv4 with few IPv6 implementations.
If they have introduced those features with an IPv4 variant,
it would have been good ! Hence, I am eager to know the
reasons for the IPv4 not being modified/upgraded to support
Extension header functionalities.
Char Jackson
<karthikb...@gmail.com> wrote:
>Though IPv4 clock is ticking fast, Internet is predominantly
>based on IPv4 with few IPv6 implementations.
Is the IPv4 clock indeed ticking fast? I've been hearing that we're
close to exhaustion for quite a few years now, but I've suspected that
the slow migration to IPv6 is an indicator that we're finding better
ways to allocate IPv4 address, in effect slowing the ticking clock
considerably. Thoughts?
Jorgen Grahn
People who know more will have to correct me, but I think you *do*
have that functionality in IPv4. You have the IP options, and you can
stick a header between the IP header and the UDP or TCP header (like
IPSEC does). It's just less elegant and efficient (I think someone
upthread mentioned that).
Martijn Lievaart
>
> People who know more will have to correct me, but I think you *do* have
> that functionality in IPv4. You have the IP options, and you can stick a
> header between the IP header and the UDP or TCP header (like IPSEC
> does). It's just less elegant and efficient (I think someone upthread
> mentioned that).
There are tcp options and as a special case, the ipv6 header chaining is
used in ipv4 for ipsec, and for ipsec only.
M4
Albert Manfredi
I think both responses are true, but I think the simple answer to the
original post is that the "next header" field in IPv6 accomplishes
also the same function as the "protocol" field of IPv4. And it even
uses the same numerical values to denote the protocol that follows.
So, if the IPv6 basic header is immediately followed by UDP, then the
UDP protocol ID 17 (decimal).
See:
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
Bert
Barry Margolin
<680722e9-0fbe-4c16...@y10g2000prg.googlegroups.com>,
Albert Manfredi <bert...@hotmail.com> wrote:
The v6 next-header field accomplishes what's done in v4 by encapsulating
protocols within the data field of other protocols. The v6 designers
noticed that there was quite a bit of encapsulation going on, in
protocols like IP-in-IP, GRE, etc. This is inefficient, because lots of
redundant processing has to be done, but it's done this way because the
v4 designers never anticipated the way protocols would be layered.
The v6 designers had the advantage of this hindsight. As noted, it
accomplishes everything we already do with the protocol field, but also
uses the same mechanism to replace encapsulation.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
robert...@yahoo.com
> On Sun, 15 Nov 2009 08:40:41 -0800 (PST), karthikbalaguru
>
> >Though IPv4 clock is ticking fast, Internet is predominantly
> >based on IPv4 with few IPv6 implementations.
>
> Is the IPv4 clock indeed ticking fast? I've been hearing that we're
> close to exhaustion for quite a few years now, but I've suspected that
> the slow migration to IPv6 is an indicator that we're finding better
> ways to allocate IPv4 address, in effect slowing the ticking clock
> considerably. Thoughts?
It is. All the conservation measures have pushed back the problem
further than most of us thought possible a decade ago. Unfortunately
we're still headed towards tilt, with little in the way of meaningful
solutions left in the bag of tricks.
At current rates, the central (IANA) pool of unassigned address space
will run out in less than two years. At that eliminates there will be
no pool of additional addresses to be allocated to the regional
registries. The first RIR will run out its currently allocated space,
plus what it will likely get from the central registry, in
approximately three years. The first ISPs should start running out
shortly after that.
It's likely that even stricter conservation measures, and ongoing
efforts to reclaim some allocated space will extend that a bit, but it
won't be a huge change. Running out will initially mostly hurt new
users, who will find it difficult to get even small allocations.
Jorgen Grahn
> On Nov 15, 11:08�am, Char Jackson <n...@none.invalid> wrote:
>> On Sun, 15 Nov 2009 08:40:41 -0800 (PST), karthikbalaguru
>>
>> <karthikbalagur...@gmail.com> wrote:
>> >Though IPv4 clock is ticking fast, Internet is predominantly
>> >based on IPv4 with few IPv6 implementations.
>>
>> Is the IPv4 clock indeed ticking fast? I've been hearing that we're
>> close to exhaustion for quite a few years now, but I've suspected that
>> the slow migration to IPv6 is an indicator that we're finding better
>> ways to allocate IPv4 address, in effect slowing the ticking clock
>> considerably. Thoughts?
>
> It is. All the conservation measures have pushed back the problem
> further than most of us thought possible a decade ago. Unfortunately
> we're still headed towards tilt, with little in the way of meaningful
> solutions left in the bag of tricks.
And we've already used some really harmful solutions. Involuntary NAT
has caused a lot of damage, forcing centralized solutions to problems
which ought to be solved peer-to-peer.
karthikbalaguru
Interesting. Can you pls let me know how NAT has caused lot of
damage ?
Moe Trin
<7vc0g51s00aq9ph45...@4ax.com>, Char Jackson wrote:
><karthikb...@gmail.com> wrote:
>>Though IPv4 clock is ticking fast, Internet is predominantly
>>based on IPv4 with few IPv6 implementations.
>Is the IPv4 clock indeed ticking fast?
1917 An Appeal to the Internet Community to Return Unused IP Networks
(Prefixes) to the IANA. P. Nesser II. February 1996. (Format:
TXT=23623 bytes) (Also BCP0004) (Status: BEST CURRENT PRACTICE)
Note the date of publication. Looking at the date-stamps in RIR stat
data, on 1/1/1996 there were 44077 allocations/assignments by the
Regional registries totalling 1,374,740,706 IPv4 addresses. That's
about 39.75 percent of the non-RFC3330 address space. On 1/1/2001,
the numbers were 54938 and 1,698,877,890 or 45.83 percent, and on
1/1/2006 it was 72599 and 2,246,643,418 or 60.61 percent. As of close
of business last Friday, the numbers were 98705 and 2,949,025,768 - or
79.56 percent. Do you want to try to forecast from that?
>I've been hearing that we're close to exhaustion for quite a few
>years now,
Above - those are good hand-waving numbers, but in reality reflect
networks opened "then" that still exist "now".
>but I've suspected that the slow migration to IPv6 is an indicator
>that we're finding better ways to allocate IPv4 address, in effect
>slowing the ticking clock considerably. Thoughts?
Same source, IPv6 didn't appear on the registries until August 1999.
By 1/1/2001, there were 52 allocations/assignments, 1410 by 1/1/2006
and 3941 last Friday. Trying to put percentages and IPv6 address
counts out is meaningless, as the _smallest_ allocation/assignment
by an RIR is a /64 or 18,446,744,073,709,551,616 addresses, but in
fact addresses allocated/assigned is a mere 0.026 percent of the
non-RFC5156 address space. You may want to read RFC1606 and 1607
for more perspective.
For what it's worth, a casual observation suggests that the five RIRs
are being much more close about the size of the blocks being handed
out. "New" blocks smaller than 16384 addresses (255.255.192.0,
0xffffc000 or /19) are more common than blocks larger than that.
Old guy
robert...@yahoo.com
wrote:
It breaks the basic notion of universal connectivity. For example,
you cannot do good peer-to-peer "remote desktop" type of support if
both sides are NAT’d without some central relay point. Even with one
side having a "real" address, it takes some convolutions to get up and
running. Any sort of "push" type delivery is impossible.
NAT more-or-less works because most things clients do are outbound.
And there are hacks around some of the other issues. Of course that's
somewhat self-reinforcing, since no service that require inbound
connections is possible, so maybe there's something we're all
missing. VOIP telephony is actually a contender for this category –
as a general concept you can’t generally make a “phone call” from your
computer directly to mine without some intermediate host. Same for
things like instant messaging or teleconferencing. Obviously there
*are* workarounds, but they all impose central control – which may be
what you want *some* of the time, but surely not always.
Note that I'm not suggesting that any inbound connection be allowed,
some sort of security device (firewall, etc.) is entirely appropriate,
but that still leaves opening a hole as a possibility. If you're a
home user and you've got a private address from your ISP, it's
basically impossible.
BGB / cr88192
"Char Jackson" <no...@none.invalid> wrote in message
news:7vc0g51s00aq9ph45...@4ax.com...
NAT, bleh...
what could help the cause of IPv6?...
maybe the people who run ISPs and write router firmware bothering to support
it.
as is, someone like me is left having to use something like Freenet6 (or,
more correctly, it is now called GoGo6), or similar...
granted, personally a less-overly-large address format would have been
preferable (say, going to 64 bits), since likely this would have had less
bandwidth impact. maybe if it had been designed with a little nicer of a
migration path, things would have also been better.
for example, rather than completely redesigning the protocol, a hack could
have been added to expand the address space while still keeping raw IPv4
packets as a de-facto transport (only, with plans in place to eventually
dissolve it in a piecewise manner), such that the network would have been up
and running quickly, rather than very slowly and in bits and pieces.
but, alas, the past is gone, and the world as it is, is waiting for eventual
adoption, hopefully to eventually slay the NAT demon...
even then, it is likely that IPv4 will not completely die in the present
state of things, but rather that a lot of stuff may end up "virtualizing"
IPv4 (once the migration gets under way), such that legacy remains (as in, a
world with a very NAT'ed and gradually decomposing IPv4 internet, and with
local "bubbles" of IPv4 being routed over v6).
so, as I see it, the likely main problem with v6 was that people fell too
far into the temptation of radical redesign, and so made the cost of
migration overly high. as I have observed, radical redesign is rarely
something which turns out ideally in practice.
Le Chaud Lapin
> "Char Jackson" <n...@none.invalid> wrote in message
> what could help the cause of IPv6?...
> maybe the people who run ISPs and write router firmware bothering to support
> it.
Many prominent researchers have been saying for years that lack of
adoption of IPv6 is the fault of ISP's. My personal view is that IPv6
is a bit hackish, and ISP legitimately do not understand what they get
for integrating it. The "documentation" is necessarily monstrous,
spread-out over many RFC's, but the problem is not so much the
documentation, but the underlying model, and a lack of new
applications that ride on the model.
IPv6 also suffers from "Lack of Sufficient Specificity" (LOSS). This
is what happens when a group of designers does not yet have a clear
understanding of a problem or its solution. Their approach is to
provide egregiously copious amounts of "flexibility" in the the
specification. Then, the specification allows so much flexibility that
the size of the implementation space explodes combinatorially. The
likelihood of incompatibility rises to certainty, unless every
implementation includes all reachable points in the system space,
which would then, by definition, remove the flexibility originally
sought, lest end-to-end principle be compromised. As an example
consider the possible modes of IPv6 security. It appears there is
great flexibility, until one realizes that the set intersection of
supported modes must not be empty for two systems to communicate,
which implies that, if every system is to be able to communicate with
every other system, the universal set of modes must be present in each
system. So lack of specificity in a specification is not virtuous.
The "flexibility" is actually disservice to the implementor.
> granted, personally a less-overly-large address format would have been
> preferable (say, going to 64 bits), since likely this would have had less
> bandwidth impact. maybe if it had been designed with a little nicer of a
> migration path, things would have also been better.
I remember the week when 128-bit was finally chosen over 64-bit. It
seemed to me that the primary reason, more than fundamental technical
considerations, was that "One cannot go wrong with 128, even if we do
not have everything figured out yet." IPv6 candidates like SIP, TUBA,
and NIMROD were still being evaluated. The 128 address space of IPv6
was very much in its early stages of design, even though 128 bits had
already been chosen.
Surely, after a certain size, it does not matter so much as how big
the address is (256-bits anyone?), but what the address represents -
the contextual model in which it fits. It seems that too much
attention has been given to the size of the address, and not enough to
what the addresses represent. The contextual model, one that is
soundly theoretical, whose regular form is readily apparent
retrospectively, has not yet been devised.
I think, once someone finds this model for computer networking, they
can then ask the question "Ok, now that we understand what is going
on, how big should the addresses should be?", and the model itself
will reveal the answer. My gut feeling is that the answer is "64".
> for example, rather than completely redesigning the protocol, a hack could
> have been added to expand the address space while still keeping raw IPv4
> packets as a de-facto transport (only, with plans in place to eventually
> dissolve it in a piecewise manner), such that the network would have been up
> and running quickly, rather than very slowly and in bits and pieces.
Yes, this is possible. Since routing is fundamental, and routing today
requires IPv4 headers [mostly], then any non-disruptive solution will
need to piggy-back on IPv4 in some way.
1. One could create an entirely new protocol stack, then use IPv4 in
"bitch mode" (tunneling).
2. One could skip tunneling and embed IPv4 addresses in IPv6-like
addresses, a kind of hybrid addressibility that does not explicitly
use tunneling but still uses IPv4.
The distinction is subtle, but important. In the former case, there is
a truly new protocol stack that is using IPv4 tunnels as point-to-
point links. No link, no network. The links, if replaced by point to
point Ethernet links, would eliminate IPv4 from the network, so the
intermediate routers must be routing the new protoocol.
In the latter case, IPv4 remains endemic to the new stack. This
distinction becomes pertinent when trying to solve other networking
problems, like mobility and multicast. #1 is the method by which
mobility/multicast would be unimpeded by the use of IPv4, whereas #2
would prevent [regular] mobility and [regular] multicast.
> but, alas, the past is gone, and the world as it is, is waiting for eventual
> adoption, hopefully to eventually slay the NAT demon...
I wonder if anyone would be interested in trying a new protocol stack
that is not IPv4 and not IPv6? I have been tinkering with protocol
design off and on over the years. I was thinking of starting a little
mini-network sometime in 2010 among people with interested in network
protocol design.
> even then, it is likely that IPv4 will not completely die in the present
> state of things, but rather that a lot of stuff may end up "virtualizing"
> IPv4 (once the migration gets under way), such that legacy remains (as in, a
> world with a very NAT'ed and gradually decomposing IPv4 internet, and with
> local "bubbles" of IPv4 being routed over v6).
I think you're right. IPv4 needs to be here for a while. Some of you
might think this is crazy, but I think "Big Switch" is the best
approach:
1. Find regular solutions to the eight or so major problems of
computer networking. IMO, this has not been done.
2. Pretend that TCP/IP software does not exist. The hardware yes, but
not the software.
3. Imagine a protocol stack that runs over the new bare-bones-no-TCP/
IP Internet as it would be in a New and Glorious World of computer
networking. This is only possible, I believe, if one does #2 first.
There is growing concensus regarding this last statement. See end of
message.
4. Implement the protocol stack for a few computers. Think, do, test,
repeat.
5. Back to reality - acknowledge the existence of TCP/IP.
6. Examine the repertoire of problems solved by the new stack.
Incrementally select those solutions that are fundamentally
incompatible with the existing Internet [true multicast, true
mobility].
7. Disable these solutions in new stack but do not remove them. Just
leave them dormant.
8. Tweak the new stack addresses so that they allow end-to-end
routability using IPv4.
9. Write one or two killer apps that require existence of features of
new stack [generalized security and access control, for example].
Deploy these applications and stack simultaneously.
10. Build more applications that require new applications. Do this for
a few years so that user appreciate the relationship between solved
problems and better applications.
11. When there is sufficient saturation of new stack, flip the Big
Switch. Turn on the mobility and multicast features of new stack. Dump
the address tweakage. The cost of disruption will be viewed by each
entity within the context of itself. A home user, for example, will
regard the 30 second disruption of service as a minor inconvenience if
the end result is true mobility/multicast.
Admittedly, this is wishful thinking. It presumes that the solutions
for are found, that killer apps are made, that the public will even
want the applications, and that a mechanism for flipping the switch
quickly is possible.
> so, as I see it, the likely main problem with v6 was that people fell too
> far into the temptation of radical redesign, and so made the cost of
> migration overly high. as I have observed, radical redesign is rarely
> something which turns out ideally in practice.
I think radical design and changeover might be, counterintuitively,
the least painful method. I am hoping to jump on the "clean slate"
bandwagon with a new miniature protocol stack if I ever get time to
finish it. A lot are trying to make new clean-slate models, btw:
http://en.wikipedia.org/wiki/Future_Internet
-Le Chaud Lapin-
BGB / cr88192
"Le Chaud Lapin" <jaibu...@gmail.com> wrote in message
news:dafe9b6f-baaa-477f...@b2g2000yqi.googlegroups.com...
On Nov 16, 10:27 pm, "BGB / cr88192" <cr88...@hotmail.com> wrote:
> "Char Jackson" <n...@none.invalid> wrote in message
> what could help the cause of IPv6?...
> maybe the people who run ISPs and write router firmware bothering to
> support
> it.
<--
Many prominent researchers have been saying for years that lack of
adoption of IPv6 is the fault of ISP's. My personal view is that IPv6
is a bit hackish, and ISP legitimately do not understand what they get
for integrating it. The "documentation" is necessarily monstrous,
spread-out over many RFC's, but the problem is not so much the
documentation, but the underlying model, and a lack of new
applications that ride on the model.
IPv6 also suffers from "Lack of Sufficient Specificity" (LOSS). This
is what happens when a group of designers does not yet have a clear
understanding of a problem or its solution. Their approach is to
provide egregiously copious amounts of "flexibility" in the the
specification. Then, the specification allows so much flexibility that
the size of the implementation space explodes combinatorially. The
likelihood of incompatibility rises to certainty, unless every
implementation includes all reachable points in the system space,
which would then, by definition, remove the flexibility originally
sought, lest end-to-end principle be compromised. As an example
consider the possible modes of IPv6 security. It appears there is
great flexibility, until one realizes that the set intersection of
supported modes must not be empty for two systems to communicate,
which implies that, if every system is to be able to communicate with
every other system, the universal set of modes must be present in each
system. So lack of specificity in a specification is not virtuous.
The "flexibility" is actually disservice to the implementor.
-->
granted, I don't believe IPv6 is exactly perfect, but alas it is probably
still better than the world of multi-layered NAT we are likely to soon be
running into...
> granted, personally a less-overly-large address format would have been
> preferable (say, going to 64 bits), since likely this would have had less
> bandwidth impact. maybe if it had been designed with a little nicer of a
> migration path, things would have also been better.
<--
I remember the week when 128-bit was finally chosen over 64-bit. It
seemed to me that the primary reason, more than fundamental technical
considerations, was that "One cannot go wrong with 128, even if we do
not have everything figured out yet." IPv6 candidates like SIP, TUBA,
and NIMROD were still being evaluated. The 128 address space of IPv6
was very much in its early stages of design, even though 128 bits had
already been chosen.
Surely, after a certain size, it does not matter so much as how big
the address is (256-bits anyone?), but what the address represents -
the contextual model in which it fits. It seems that too much
attention has been given to the size of the address, and not enough to
what the addresses represent. The contextual model, one that is
soundly theoretical, whose regular form is readily apparent
retrospectively, has not yet been devised.
I think, once someone finds this model for computer networking, they
can then ask the question "Ok, now that we understand what is going
on, how big should the addresses should be?", and the model itself
will reveal the answer. My gut feeling is that the answer is "64".
-->
more or less agreed.
for anything where addresses are assigned, 64 bits is likely more than
enough, and 128 likely just wastes bandwidth...
granted, if IPv6 were a self-organizing system based around the large-scale
use of random number generators, 128 bits would make more sense, but alas it
is not...
> for example, rather than completely redesigning the protocol, a hack could
> have been added to expand the address space while still keeping raw IPv4
> packets as a de-facto transport (only, with plans in place to eventually
> dissolve it in a piecewise manner), such that the network would have been
> up
> and running quickly, rather than very slowly and in bits and pieces.
<--
Yes, this is possible. Since routing is fundamental, and routing today
requires IPv4 headers [mostly], then any non-disruptive solution will
need to piggy-back on IPv4 in some way.
1. One could create an entirely new protocol stack, then use IPv4 in
"bitch mode" (tunneling).
2. One could skip tunneling and embed IPv4 addresses in IPv6-like
addresses, a kind of hybrid addressibility that does not explicitly
use tunneling but still uses IPv4.
The distinction is subtle, but important. In the former case, there is
a truly new protocol stack that is using IPv4 tunnels as point-to-
point links. No link, no network. The links, if replaced by point to
point Ethernet links, would eliminate IPv4 from the network, so the
intermediate routers must be routing the new protoocol.
In the latter case, IPv4 remains endemic to the new stack. This
distinction becomes pertinent when trying to solve other networking
problems, like mobility and multicast. #1 is the method by which
mobility/multicast would be unimpeded by the use of IPv4, whereas #2
would prevent [regular] mobility and [regular] multicast.
-->
yeah.
what I had immagined essentially combined both options.
I guess an issue at the present time, with the current NAT mess, is that
directly basing a network on a v4 address is problematic (as in the 6to4
case), but tunnelling is lame (it is a hassle to set up, is not very
reliable, and more subtly, Windows may be stupid and end up trying to run
their local v4 traffic over the tunnel, interferring with ones' ability to
access stuff on their LAN, and also making internet access slow, requiring
one to fiddle with their network settings, ...).
an idle thought is that a hybrid strategy could be used, where there are
"tunnel routers", which sit around and keep track of where networks are in
v4 space (similar to a broker), but traffic may be routed indirectly (if
possible, this may depend some on the specific NAT routers).
for example, a local host (behind NAT), connects to a tunnel router, which
opens up a UDP port with a global v4 address, which reaches the "router"
(and it keeps track of this).
sending traffic to this network may hit this, and the traffic may be bounced
to the outgoing IP:port pair. however, maybe this could be passed along (in
the reverse direction), such that a little closer to the sender (for later
packets), it could try sending the packet directly to the public IP:port,
and see if the NAT router accepts it (AKA: packets from a source different
than the initial remote host), and if not staying with plain tunnelling.
then again, little is to say that this would work much better in practice
than plain old tunnelling...
had I been designing it clean (and there were no NAT, and I had foresight),
it would likely have taken a very different form:
I would essentially split up the host and network address, and slide them to
opposite ends (similar to the MAC-48 -> EUI-64 mapping).
for example:
192.168.0.0.0.0.0.1
so, for example:
network:
192.168.0.0
host:
0.0.0.1
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 (although, parts of the network would
be initially unreachable).
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, ...
(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.
> but, alas, the past is gone, and the world as it is, is waiting for
> eventual
> adoption, hopefully to eventually slay the NAT demon...
<--
I wonder if anyone would be interested in trying a new protocol stack
that is not IPv4 and not IPv6? I have been tinkering with protocol
design off and on over the years. I was thinking of starting a little
mini-network sometime in 2010 among people with interested in network
protocol design.
-->
dunno...
I guess the biggie issue is if it can be made to work much better in the
present landscape...
NAT makes a big mess which is not easily addressed.
> even then, it is likely that IPv4 will not completely die in the present
> state of things, but rather that a lot of stuff may end up "virtualizing"
> IPv4 (once the migration gets under way), such that legacy remains (as in,
> a
> world with a very NAT'ed and gradually decomposing IPv4 internet, and with
> local "bubbles" of IPv4 being routed over v6).
<--
-->
yeah...
> so, as I see it, the likely main problem with v6 was that people fell too
> far into the temptation of radical redesign, and so made the cost of
> migration overly high. as I have observed, radical redesign is rarely
> something which turns out ideally in practice.
<--
I think radical design and changeover might be, counterintuitively,
the least painful method. I am hoping to jump on the "clean slate"
bandwagon with a new miniature protocol stack if I ever get time to
finish it. A lot are trying to make new clean-slate models, btw:
http://en.wikipedia.org/wiki/Future_Internet
-Le Chaud Lapin-
-->
the problem is that of adoption...
if the design is too new, then it is unlikely it will be able to effectively
displace the original, especially if incentive is lacking.
IPv6 was essentially an incompatible new technology lacking the required
incentive, hence the current mess...
ELF did not (entirely) replace COFF;
JBC did not replace x86;
IA-64 did not replace x86;
...
however, OTOH:
x86-64 replaced x86;
UTF-8 (mostly) replaced ASCII;
Windows replaced DOS;
...
the big difference:
the successful technologies just happened to be backwards compatible;
...
Rick Jones
> 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?)
> 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?
> (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.
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...
BGB / cr88192
"Rick Jones" <rick....@hp.com> wrote in message
news:he23tm$u58$1...@usenet01.boi.hp.com...
> BGB / cr88192 <cr8...@hotmail.com> 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...
karthikbalaguru
> On Sun, 15 Nov 2009 08:40:41 -0800 (PST), karthikbalaguru
>
> >Though IPv4 clock is ticking fast, Internet is predominantly
> >based on IPv4 with few IPv6 implementations.
>
> Is the IPv4 clock indeed ticking fast? I've been hearing that we're
> close to exhaustion for quite a few years now, but I've suspected that
> the slow migration to IPv6 is an indicator that we're finding better
> ways to allocate IPv4 address, in effect slowing the ticking clock
> considerably. Thoughts?
Interesting links -
http://www.potaroo.net/tools/ipv4/index.html
The above link seems to tell as to when the continued availability
of the unallocated address pool may be exhausted. It has been
referenced in the section of 'IPv4 Address Space Countdown'
in http://www.ipv6forum.com/ through http://penrose.uk6x.com/ .
Karthik Balaguru
karthikbalaguru
wrote:
> On Nov 15, 10:08 pm, Char Jackson <n...@none.invalid> wrote:
>
> > On Sun, 15 Nov 2009 08:40:41 -0800 (PST), karthikbalaguru
>
> > <karthikbalagur...@gmail.com> wrote:
> > >Though IPv4 clock is ticking fast, Internet is predominantly
> > >based on IPv4 with few IPv6 implementations.
>
> > Is the IPv4 clock indeed ticking fast? I've been hearing that we're
> > close to exhaustion for quite a few years now, but I've suspected that
> > the slow migration to IPv6 is an indicator that we're finding better
> > ways to allocate IPv4 address, in effect slowing the ticking clock
> > considerably. Thoughts?
>
>
> The above link seems to tell as to when the continued availability
> of the unallocated address pool may be exhausted. It has been
> referenced in the section of 'IPv4 Address Space Countdown'
> inhttp://www.ipv6forum.com/throughhttp://penrose.uk6x.com/.
>
Karthik Balaguru