I sent the following to him privately. His question to me was whether
I would vote for it.
On Jun 26, 2009, at 9:39 AM, Fred Baker wrote:
I would vote for it as a research project; I would not vote for it
as something I would ask my company to build and sell. To begin
with, the IETF has no votes; we work by rough consensus. But beyond
that, the great mistake of X.25, ATM, and others was that they
assumed that a single MAC/PHY-level architecture would replace
everything else in the world, and that's simply not reality. To
quote an old joke, God was able to make the world in six days
because He had no installed base. Your proposal would in fact work,
for those networks that used it; the issue is that compounding the
ethernet and IP headers into one gives me a few more payload bytes
in the frame but doesn't solve any new problems; it's just cute.
At a nit level, in the absence of a MAC address, it's not clear how
one actually gets an IP address. We would have to define some things
like "the most significant 24 bits being all zero implies 'this
LAN'" to support things like that.
There are two more important aspects. One is that there is no
obvious way to add a new technology that is materially different,
like we did in deploying MPLS for ISPs that want circuit-switch
control of their datagram networks for business and operational
reasons. How, for example, do I run this on a zigbee (802.15.4g)
network? Yes, it could be adapted, but that means I am providing
gateways between link layer types, not simply forwarding a packet.
For the other, let me point you to an online description of a very
different kind of network. I don't hold it up as the one true
solution for the problem class; it does, however, have a different
set of requirements and a very different solution. Look through:
http://www.stitcs.com/CN/lonworks/LonTalk%20Protocol%20Seminar.pdf
On Jun 26, 2009, at 2:52 PM, Phillip Hallam-Baker wrote:
Why would this be any easier to deploy than IPv6?
The problem with IPv6 deployment is that it requires a change across
the infrastructure. Adding 1 byte is no easier than adding 12. This
proposal loses the ability to aggregate routes and is thus completely
impractical.
And in any case, EUI48 MAC addresses will run out at some point in the
not too distant future which is why modern protocols are using EUI64
addresses.
On Wed, Jun 24, 2009 at 6:52 AM, Dmitry Zaitsev<zsoftua@xxxxxxxxx>
wrote:
a compromise between IPv4 and IPv6:
draft-zaitsev-e6-network-00.txt
the gist : IP address is extended up to 6 octets and put directly
into MAC-address field of Ethernet frame
the zest : Ethernet LLC2 is used instead of TCP
the best : no address mapping, enlargement in 16K times, headers
cut off
DAZE
Sincerely yours,
Dmitry Zaitsev
http://www.geocities.com/zsoftua
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
--
--
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf