[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fw: http://rfc3314.x42.com/
- To: <v6ops@ops.ietf.org>
- Subject: Fw: http://rfc3314.x42.com/
- From: "Jim Fleming" <JimFleming@ameritech.net>
- Date: Tue, 1 Oct 2002 09:17:49 -0500
- Delivery-date: Tue, 01 Oct 2002 07:19:02 -0700
- Envelope-to: v6ops-data@psg.com
----- Original Message -----
From: "Jim Fleming" <JimFleming@ameritech.net>
To: <mrw@windriver.com>; <jonne.soininen@nokia.com>; <Markku.Savela@vtt.fi>; <niallm@enigma.ie>; "Christian Huitema"
<huitema@windows.microsoft.com>; "Bob Hinden" <hinden@iprg.nokia.com>; <francis@tahoenetworks.com>;
<Karim.El-Malki@era.ericsson.se>; <deering@cisco.com>
Sent: Tuesday, October 01, 2002 9:07 AM
Subject: http://rfc3314.x42.com/
> http://rfc3314.x42.com/
> This document was written by the IPv6 3GPP design team:
>
> Steve Deering, Cisco Systems
> EMail: deering@cisco.com
>
> Karim El-Malki, Ericsson Radio Systems
> EMail: Karim.El-Malki@era.ericsson.se
>
> Paul Francis, Tahoe Networks
> EMail: francis@tahoenetworks.com
>
> Bob Hinden, Nokia
> EMail: hinden@iprg.nokia.com
>
> Christian Huitema, Microsoft
> EMail: huitema@windows.microsoft.com
>
> Niall Richard Murphy, Hutchison 3G
> EMail: niallm@enigma.ie
>
> Markku Savela, Technical Research Centre of Finland
> Email: Markku.Savela@vtt.fi
>
> Jonne Soininen, Nokia
> EMail: Jonne.Soininen@nokia.com
>
> Margaret Wasserman, Wind River
> EMail: mrw@windriver.com
> =============================================
>
> Your approach does not appear to represent the consensus of the marketplace.
> It appears that you took a protocol, based on a 128-bit address field, and then
> tried to develop an architecture to match the protocol. Most people would start
> with an architecture, and then decide what components are needed, what are
> available, and what need to be built, and then build those. While doing that, a
> careful eye would be kept on making sure that ALL people/users/devices
> currently connected to the global Internet remain connected, and evolve. That
> prevents massive fragmentation of the network, stranding users and services.
> Why would users want such a thing ? Evolution, not revolution has always been
> the way the computer field has evolved. Stability and security of people's and
> ISP's investments have to be considered. The world will route around you,
> not in a revolutionary way, but, via evolution. There are plenty of addresses and
> plenty of people writing software to make it all work. Face to face meetings and
> documents do not move anything forward, in the real society. Face to face is
> where people have fun. Somehow, you seem to have it backwards in the I* society.
>
>
> 128-bit DNS AAAA Record Flag Day Formats
> 2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
> [YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
> 1-bit to set the Reserved/Spare ("SNOOPY") bit in Fragment Offset [S]
> 1-bit to set the Don't Fragment (DF) bit [D]
> 2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL]
> 1-bit for Options Control [O]
> 7-bits to set the Identification Field(dst) [FFFFFFF]
> 4-bits to set the TOS(dst) Field [TTTT]
> Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000
> FFF.FFFF.TTTT = GGG.SSSS.SSSS
> http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
>
>
> Jim Fleming
> 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer...
> http://www.ietf.com
> http://www.iana.org/assignments/ipv4-address-space
> http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
> http://www.netfilter.org/
> 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://ipv8.myip.us
> http://ipv8.dyn.ee
> http://ipv8.community.net.au
> http://ipv8.ods.org
>