Subject: e6

From: Dmitry Zaitsev <[email-masked]>
Date: Wed, 24 Jun 2009 03:52:52 -0700 (PDT)

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 26 Jun 2009 17:52:25 -0400

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<[email-masked]> wrote:
> _______________________________________________
> Ietf mailing list
> [email-masked]
> 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/

---

From: Fred Baker <[email-masked]>
Date: Fri, 26 Jun 2009 15:48:26 -0700

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
>
>