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@kinet.com.cn> To: "Fred Baker" <fred@cisco.com> Cc: <ietf@ietf.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@cisco.com> > To: "Jason Gao" <jag@kinet.com.cn> > Cc: <ietf@ietf.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. > > > > >