Attempts to redefine the IPv4 Header to block clear paths to using all 160 bits
in the IPv4 Header
for extended addressing and routing have been political in nature, not
technical. With 128-bit DNS,
more bits in the 160 bit IPv4 Header are available for setting and for extended
addressing and
routing. Because of the dominance of UDP and TCP in the next layer, the 16-bit
Port number also
becomes part of the available extended addressing, or sub-addressing. The
current "public IPv4"
non-QoS transport is defined at the edges by operators willing to provide
clear-channel 160-bit clean
transport from one side to the other, with the awful overhead of checksum
changing and the less
than optimum routing paths. Native IPv4++, using all of the extended
addressing, can evolve and
grow around the edges of that legacy core. Native IPv4++ will of course benefit
from higher-speed
(more optimal) direct routing, and can use the legacy core as a last resort to
getting packets from
one place to another. Keep in mind that equipment vendors claim that 80% of all
IPv4 equipment
never connects directly to that legacy core. When one looks at the ethically
bankrupt people who
operate that legacy core, one wonders why anyone would want to touch it with a
10 ft. cable.
....route around it.....
Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...
http://ipv8.dyndns.tv
http://ipv8.yi.org
http://ipv8.dyns.cx
http://ipv8.no-ip.com
http://ipv8.no-ip.org
http://ipv8.no-ip.biz
http://ipv8.no-ip.info
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
----- Original Message -----
From: "Jason Gao" <jag(_at_)kinet(_dot_)com(_dot_)cn>
To: "Fred Baker" <fred(_at_)cisco(_dot_)com>
Cc: <ietf(_at_)ietf(_dot_)org>
Sent: Thursday, September 05, 2002 8:00 PM
Subject: Re: Fuzzy-layering and its suggestion
Well, I should have cited another instance. What the TCP checksum protects
includes the pseudu-header which contains the source
and the destination IP address. Transport address in TCP (and SCTP) contains IP
address. Clearly the IP address is not stored in the
transport layer header. IMHO it is not an instance of clear layering.
Implementations that let TCP and IP 'share' the ECN bits, in another word,
practice in fuzzy-layering way, avoid the
standardization process of the API (actually there seems no standard, or de
facto standard API that the IP layer provides to the
transport layer.), benefit from lower overhead accross layer interface calls.
Though 'fuzzy-layering' is really not a requirement,
concerns on performance and efficiency often make it the preferred practice
principle.
----- Original Message -----
From: "Fred Baker" <fred(_at_)cisco(_dot_)com>
To: "Jason Gao" <jag(_at_)kinet(_dot_)com(_dot_)cn>
Cc: <ietf(_at_)ietf(_dot_)org>
Sent: Friday, September 06, 2002 4:58 AM
Subject: Re: Fuzzy-layering and its suggestion
At 09:11 PM 9/5/2002 +0800, Jason Gao wrote:
--- TCP with ECN extension
has already been a practice of fuzzy-layering.
TCP in the end system and IP in the intermediate systems share the two ECN
bits in the IP header.
that is incorrect. First off, IP also is found in the end system, and uses
the ECN bits.
More important, though, is that TCP uses an IP service, through an
IP-provided API. The TCPs negotiate whether they are willing to run ECN,
and if they agree, they (on transmission) use the API feature that says
"please tell my peer if this datagram experiences congestion", and (on
reception) use the API feature that says whether or not congestion was
experienced somewhere in the network. All other communication regarding ECN
is via the transport header. SCTP also has a defined facility for the
transport exchange relevant to ECN.
If your implementation delivers the IP header to or from TCP or SCTP, then
the implementation of the API in question is the passage of that header. I
know of a number of implementations that do that; it certainly is a
convenient approach. However, I don't see any requirement that the API take
that form, and I know some very common implementations that don't.
I don't see any significant difference between using a service of this
type, and using a service that says "please send this message as urgent
data" to TCP, or "please send this message with this DSCP" to IP, or
"please send this message without permitting fragmentation" to IP. It's
just a service accessed through the API.