The Mythical IPv8 (Was: Re: Fw: (ngtrans) AAAA Record Transition Strategy)
Eric Germann ekgermann at cctec.com
Thu Sep 3 16:30:35 CEST 1998
Of course, the Phlegm-bot has to bring up his chemically induced non-existant IPv8. Prepare yourselves for extraterrestrial stargates and routers between constellations soon. For the record, "since some of you people are not technical", Flemings version of IPv8 does not exist. And be wary of him keeping you informed. Check the NANOG archives for another groups take on his ideas. Eric At 08:56 AM 9/3/98 -0500, Jim Fleming wrote: >In my opinion, people following the IFWP and White Paper >discussions should make sure that they also closely follow >the IPv6 evolution. The following note from Jim Bound of >DEC is a very important message. Since some of you >people are not technical, I would like to point out that IPv8 >is not impacted by the situation below. IPv8 uses the IPv4 >DNS, as-is, without requiring revolutionary change. IPv8 >is able to use IPv6 for basic transport features. Those have >nothing to do with the serious IPv6 DNS issues discussed >below. We are tracking the IPv6 evolution (or revolution). >I will try to continue to keep people informed when major >points are raised by people working on IPv6. Besides the >points below, Jim Bound made some other excellent >points at the IETF meeting last week in Chicago. It was >sort of a shame that they have been lost in some of the >noise about the new IANA Inc. bylaws. One of Jim's points >was about the IETF now having the talent needed to work >effectively in certain areas. As more people from the IFWP >process make their way to the IETF, they might be able >to supply some of the needed talent. The expanding Internet >will require a diverse collection of people to make it go. >It may be somewhat of a challenge to convince groups >like the IETF that they need to be more diverse. Hopefully, >gotchas like those described below will help make them >realize that they do not have all of the answers. No one >has all of the answers. We have to all work together to >put the pieces of the puzzle together one piece at a time. > > >Jim Fleming >Unir Corporation - http://www.unir.com > > >-----Original Message----- >From: bound at zk3.dec.com <bound at zk3.dec.com> >To: ngtrans at sunroof.Eng.Sun.COM <ngtrans at sunroof.Eng.Sun.COM> >Date: Wednesday, September 02, 1998 3:31 PM >Subject: (ngtrans) AAAA Record Transition Strategy > > >>Folks, >> >>I spoke with the chairs of ngtrans, ipng, and Thomas Narten IESG AD. >> >>It appears the isssue of moving from the existing AAAA record to the new >>AAAA record (e.g. dname, bit-boundaries, edns) will not get done until >after >>IPv6 has been deployed and in many cases shipped by vendors. >> >>Hence, we need a plan. After talking to Paul Vixie and a few others >>here is a suggestion. >> >>Assumptions: >> a) New AAAA record support should be in the ISC BIND releases >> around the summer of 1999 and edns. >> b) The integrating drafts for this New AAAA record should be PS >> in the IETF and have DNSIND consensus too by summer of 1999. >> >>A plan: >> >> a) Deploy IPv6 in the market using the existing AAAA records, >> and keep them on the 6bone nodes. >> b) Vendors make sure your stub resolvers can accomodate the >> i) query for dame records and the reverse. >> ii) keep it transparent to the dns apis upon return of >> hostent like structure. >> c) We should not add an AAAA-Type New or OLD flag to the IPv6 >> API (basic or advanced) as we don't want to expose this >> to the ISV community building IPv6 apps. >> d) Use the eventual edns dns metaquery to be done in BIND too >> with the new AAAA records to request AAAA records for >> the new type - Note this implies we have a new type rec >> for the new AAAA record. >> e) Tell users to use the existing AAAA records and when the >> new AAAA record is ready then they can also distribute their >> name space as approiate to with the updates to AAAA and to >> DNS in general (e.g. edns, TSIG, DNSSEC). >> f) Vendors this will affect how dynamic updates to dns works >> at the server and I am hoping not at the client (this is >> a question for Matt). But we need to think about this. >> Esp if you have this done which most of us do. >> >>Other ideas or enhancments or replacements, we need to discuss... >> >>/jim >> >> >> >> > ========================================================================== Eric Germann CCTec ekgermann at cctec.com Van Wert, OH 45891 http://www.cctec.com Ph: 419 968 2640 Fax: 419 968 2641 Network Design, Connectivity & System Integration Services A Microsoft Solution Provider -------- Logged at Fri Sep 4 10:17:46 MET DST 1998 ---------
[ tld-wg Archives ]