- ipv6-wg - mailman.ripe.net

(IPng 6014) Protocol Action: IP Version 6 Addressing Architecture to Proposed Standard (fwd)
by Thomas Trede 09 Jul '98

09 Jul '98

FYI. Regards, Thomas ---------- Forwarded message ---------- Date: Wed, 08 Jul 1998 17:30:48 -0400 From: The IESG <iesg-secretary(a)ietf.org> To: IETF-Announce:;;;;@ns.cnri.reston.va.us;@Eng.Sun.COM;;; Cc: RFC Editor <rfc-editor(a)isi.edu>, Internet Architecture Board <iab(a)isi.edu>, ipng(a)sunroof.Eng.Sun.COM Subject: (IPng 6014) Protocol Action: IP Version 6 Addressing Architecture to Proposed Standard The IESG has approved the following o IP Version 6 Addressing Architecture <draft-ietf-ipngwg-addr-arch-v2-07.txt> for publication as a Proposed Standard. Note: This document is a replacement for RFC1884, which will be reclassified as Historic. o An IPv6 Aggregatable Global Unicast Address Format <draft-ietf-ipngwg-unicast-aggr-05.txt> for publication as a Proposed Standard. Note: This document is a replacement for RFC2073, which will be reclassified as Historic. These documents are the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary The document "IP Version 6 Addressing Architecture" specification defines the addressing architecture of the IP Version 6 protocol. This document includes the IPv6 addressing model, text representations of IPv6 addresses (which are 128 bits in length) , definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document is intended to replace RFC 1884 which will become historic. The document "An IPv6 Aggregatable Global Unicast Address Format" defines an IPv6 aggregatable global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol and the IPv6 Addressing Architecture (mentioned above) and is designed to facilitate scalable Internet routing. This documented is intended to replaces RFC 2073, "An IPv6 Provider-Based Unicast Address Format" which will become historic. This document is viewed as an improvement over RFC 2073; major changes include removal of the registry bits because they are not needed for route aggregation, support of EUI-64 based interface identifiers, support of provider and exchange based aggregation, separation of public and site topology, and new aggregation based terminology. Working Group Summary These two documents have been the topic of much discussion and consideration, both within the working group and among the IANA and registries. Specifically, the Aggregatable Global Unicast Address Format document has been the subject of detailed discussions for well over a year in an attempt to come up with an address format which has the support of many in the Internet community, including the ISPs. In addition, the policies for how TLAs (the top-level prefixes) are assigned to ISPs have been moved to a separate document in order to clearly separate the technical issues from the operational aspects of how the IANA and the registries manage address space. Protocol Quality This document has been reviewed by Jeffrey Burgan and Thomas Narten of the IESG. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo(a)sunroof.eng.sun.com --------------------------------------------------------------------

1 0

(IPng 6010) I-D ACTION:draft-degermark-ipv6-hc-06.txt (fwd)
by Thomas Trede 08 Jul '98

08 Jul '98

FYI. Regards, Thomas ---------- Forwarded message ---------- Date: Wed, 08 Jul 1998 08:44:26 -0400 From: Internet-Drafts(a)ietf.org To: IETF-Announce:;;;;@ns.cnri.reston.va.us;@Eng.Sun.COM;;; Cc: ipng(a)sunroof.Eng.Sun.COM Subject: (IPng 6010) I-D ACTION:draft-degermark-ipv6-hc-06.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Header Compression Author(s) : M. Degermark, B. Nordgren S. Pink Filename : draft-degermark-ipv6-hc-06.txt Pages : 46 Date : 07-Jul-98 This document describes how to compress multiple IP headers and TCP and UDP headers per-hop over point-to-point links. The methods can be applied to of IPv6 base and extension headers, IPv4 headers, TCP and UDP headers, and encapsulated IPv6 and IPv4 headers. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-degermark-ipv6-hc-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-degermark-ipv6-hc-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-degermark-ipv6-hc-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

1 0

(IPng 6007) I-D ACTION:draft-blanchet-ipaddressalloc-00.txt (fwd)
by Thomas Trede 08 Jul '98

08 Jul '98

FYI. Regards, Thomas ---------- Forwarded message ---------- Date: Tue, 07 Jul 1998 12:27:39 -0400 From: Marc Blanchet <Marc.Blanchet(a)viagenie.qc.ca> To: ipng(a)sunroof.Eng.Sun.COM, 6bone(a)ISI.EDU, ngtrans(a)sunroof.Eng.Sun.COM Subject: (IPng 6007) I-D ACTION:draft-blanchet-ipaddressalloc-00.txt Hi, a first cut of a draft on an allocation scheme. Comments appreciated. Regards, Marc. ---------------------------------------------------------------------------- ------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A flexible allocation scheme for IP addresses (IPv4 and IPv6) Author(s) : M. Blanchet Filename : draft-blanchet-ipaddressalloc-00.txt Pages : 5 Date : 06-Jul-98 This draft presents an IP address allocation scheme that enables the IP allocator (the organisation that allocates addresses) to postpone the final decision of prefix length by keeping space between allocated bits of the different parts of the IP address. This enables the allocator to change the different part lengths of the prefix (TLA, subTLA, SLA, ...) even after allocated spaces. This scheme is applicable to both IPv4 and IPv6 but is envisionned mainly for IPv6 where the address space is larger and more flexible. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-blanchet-ipaddressalloc-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-blanchet-ipaddressalloc-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-blanchet-ipaddressalloc-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19980706163222.I-D(a)ietf.org> ENCODING mime FILE /internet-drafts/draft-blanchet-ipaddressalloc-00.txt <ftp://ftp.ietf.org/internet-drafts/draft-blanchet-ipaddressalloc-00.txt> ----------------------------------------------------------- Marc Blanchet | Marc.Blanchet(a)viagenie.qc.ca Viag�nie inc. | http://www.viagenie.qc.ca 3107 des h�tels | t�l.: 418-656-9254 Ste-Foy, Qu�bec | fax.: 418-656-0183 Canada, G1W 4W5 | radio: VA2-JAZ ------------------------------------------------------------ pgp :57 86 A6 83 D3 A8 58 32 F7 0A BB BD 5F B2 4B A7 ------------------------------------------------------------ Auteur du livre TCP/IP Simplifi�, �ditions Logiques, 1997 ------------------------------------------------------------ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo(a)sunroof.eng.sun.com --------------------------------------------------------------------

1 0

(IPng 5969) I-D ACTION:draft-ietf-ipngwg-unicast-aggr-05.txt (fwd)
by Thomas Trede 02 Jul '98

02 Jul '98

FYI. Regards, Thomas ---------- Forwarded message ---------- Date: Thu, 02 Jul 1998 11:12:17 -0400 From: Internet-Drafts(a)ietf.org To: IETF-Announce:;;;;@ns.cnri.reston.va.us;@Eng.Sun.COM;;; Cc: ipng(a)sunroof.Eng.Sun.COM Subject: (IPng 5969) I-D ACTION:draft-ietf-ipngwg-unicast-aggr-05.txt Note: This revision reflects comments received during the last call period. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : An IPv6 Aggregatable Global Unicast Address Format Author(s) : B. Hinden, M. O''Dell, S. Deering Filename : draft-ietf-ipngwg-unicast-aggr-05.txt Pages : 11 Date : 01-Jul-98 This document defines an IPv6 aggregatable global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol [IPV6] and the 'IPv6 Addressing Architecture' [ARCH]. It is designed to facilitate scalable Internet routing. This documented replaces RFC 2073, 'An IPv6 Provider-Based Unicast Address Format'. RFC 2073 will become historic. The Aggregatable Global Unicast Address Format is an improvement over RFC 2073 in a number of areas. The major changes include removal of the registry bits because they are not needed for route aggregation, support of EUI-64 based interface identifiers, support of provider and exchange based aggregation, separation of public and site topology, and new aggregation based terminology. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-unicast-aggr-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-unicast-aggr-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-unicast-aggr-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

1 0

(IPng 5964) Request - has anyone read (and can I get comments on) the draft that I posted ~6 months back on address allocation for IPv6? (fwd)
by Thomas Trede 02 Jul '98

02 Jul '98

FYI. Regards, Thomas ---------- Forwarded message ---------- Date: Wed, 1 Jul 1998 21:32:10 -0500 From: Karl Denninger <karl(a)mcs.net> To: ipng(a)sunroof.Eng.Sun.COM Subject: (IPng 5964) Request - has anyone read (and can I get comments on) the draft that I posted ~6 months back on address allocation for IPv6? The subject says it all. For those who might not still have it, here is the document: INTERNET DRAFT K. Denninger Expires 10 May 1998 10 November 1997 IPV6 NUMBER ASSIGNMENT PROTOCOL Rev 0.1 draft-denninger-ipv6number-00.txt Status ====== This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract ======== This memorandum shall be entitled "IPV6 NUMBER ASSIGNMENT PROTOCOL", and describes a proposed policy, procedure and control structure for the allocation of IPV6 Internet addresses. This memorandum discusses the issues surrounding IPV6 numbering on a hierarchial structure and overview. It also presents, where possible and relevant, justification for the positions expressed in this paper. Distribution is unlimited and comments are invited. Revisions ========= As a draft, this document may be revised at any time. The revision number of the document in question is displayed at the top of the masthead, and should be referred to when commenting on the proposal contained in this draft. Operating Assumptions ===================== This draft is written under the following assumptions: 1) The IPv6 number space, as a 128-bit entity, is virtually unlimited in scope. 2) It is required that we utilize the IPv6 space in a hierarchial manner since full destination-level routing of a 128-bit space would require 2^128 lookup table entries - prohibitive for any device now existant or envisioned to be available in the forseeable future. 3) The size of the address space at 128 bits requires reasonable assumptions to be made about end node addresses and devices, but does not functionally limit the number of known networks, nor should the protocol for assignment of numbers artifically impose constraints on the number of possible autonomous systems. 4) An Autonomous System, or "AS" in today's terminology, is one routing entity with a consolidated policy and procedure for exchanging traffic with others. 5) Historically multiple AS numbers have been assigned to single entities. It is desirable to reduce or eliminate this practice such that a given AS uniquely identifies an organization for administrative purposes, but the functionality of multiple geographic regions which function independantly cannot be lost. 6) It is desirable to permit every man, woman, child, toaster, automobile or other vehicle and light switch if desired to have its own unique end-point identifier on the global Internet. 7) It is desired that backward-compatibility with IPv4 assignments be maintained to the greatest possible degree such that gateways to allow IPv4 and IPv6 to co-exist during a transition period, expected to last several years, are possible to construct in an efficient and functional manner. Since these gateways are required to operate at wire speeds, which today may reach or exceed 155mbps (and in the future will run at higher data rates) the simplicity of the mapping function is a paramount design consideration. 8) A function to provide unique IPv4-compatible endpoint identifiers is desired by the community during the transition period, and for user-friendly end-point identifiers on a permanent basis (including after IPv4 is considered deprecated). 9) Since 128 bits of address constitutes more space than we can envision needing for the forseeable (and even beyond) future, we will make certain assumptions about potential future uses which aren't realistic or even possible at the present time given the state of science in the late 1990s. Items Not Addressed =================== The following item is intentionally omitted from discussion in this draft: "Command and control structures" necessary to implement assumption #8. This draft does not attempt to set political agendas or create policy bodies. Definitions =========== Autonomous System (AS): An Autonomous System, for the purposes of this draft, is a network which is (1) connected to more than one other network, (2) assigns addresses to end users or other providers of network services, and (3) announces its network presence to more than one other network over the connections defined in (1). End Customer: An End Customer (EC) is any entity which (1) does not fit the definition of an AS above, and which (2) consumes or uses IPv6 addresses. Allocation Framework ==================== IPv6 numbers are 128-bit integers. To maintain a hierarchial structure over assignment, we must break down these numbers into fields which are either assigned by a numbering authority under delegation or which are controlled by the autonomous system and assigned ultimately to customers. To meet to goals and assumptions in the above section, this draft attempts to detail "automatic" fields which are assigned by virtue of either location or an entities status as an autonomous system. To break down the allocation of IPv6 numbers, we therefore define the following field names, uses, and bit placements, counting from the LEFT of the address field. Note that the first 64 bits of the address are defined as *assigned* and the second 64 bits are defined as *provider dependant*, giving each AS 2^64 addresses to assign to customers. Bits Len Name Use ===================================================================== 0 - 7 8 GALAXY Reserved for when subspace and/or other worlds (ie: the moon) become viable destinations. As the scope of our transmission and reception capability increases, we can increase the "reach" of a given value in this field. For the purposes of the Earth-based communication we use today, this value shall be zero (0). 8 - 17 10 COUNTRY Represents the country code of the designee. This permits 1024 countries to be represented on each planet (well above what we have today on Earth). Numbering for these to be taken from ISO in order of "creation" of the country in question. Country codes represent geographies; if a country renames itself or changes government system this does not change its designated code. A country which splits into two or more independant nations "creates" new country codes for the new, independant entities (with the original fragment, as close as can be determined, being left in existance). Absent cataclysmic events (ie: a country disappearing into the sea) country codes are never destroyed. 18 - 43 26 RESVC Reserved for future use. 44 - 47 4 REGION Reserved for use by an AS in specifying regional routing policy *within* a country. 48 - 63 16 ASN Provider's AS Number. Note that we currently have 2194 ASNs in the GLOBAL routing system. As such, this should be more than sufficient space. If it is not, then we can encroach on or redefine the RESVC and REGION fields as needed. --------------- End ASSIGNED addresses 64 - 95 32 RESVA Reserved for future use by the provider when IPv4 compatibility no longer is necessary, OR for use at their discretion in the current instance (ie: "overloading" if an address needs to be mapped which already exists in the IPv4 space). 96 - 127 IPV4 Existing IPv4 address space compatibility zone. Authorities Designating Fields ============================== GALAXY Assigned by whatever intergalactic or interplanetary authority might come to exist in the future. Currently zero (Earth) and not modifyable since no such authority currently exists. COUNTRY Tracks ISO country code designation system automatically. Existing and new country codes are assigned by an automated mapping process which does not require decisions by any standards body. REGION For organizations which have multiple autonomous routing zones within a country, they can use this field (16 possible values) to designate multiple routing policy domains within a country. Note that under NO circumstance should this field be used as a substitute for country designations. ASN AS Numbers are assigned by existing delegation processes, with one exception - only one ASN may be assigned to a given organization. In the event that multiple ASNs are required for a given organization the organization should use the multiple REGION designations where appropriate. RESVA & IPV4 Assignable by the ASN holder as they deem fit. Route Exchange ============== Routers which are attempting to set up peering sessions for the exchange of routes must agree on the position and size of the following fields: GALAXY COUNTRY RESVC REGION ASN An attaching router MUST obtain the other end's designations for these parameters. A router may (1) configure itself to match the existing mesh's idea of these fields, (2) refuse to establish a peering session if it has hard-coded values which disagree, or (3) CHANGE its field designations PROVIDED that no data existant in the current tables conflicts with the newly-desired defaults. Routers may specify some connections as MASTER and some as SLAVE; MASTER peering connections must choose actions (1) and (2) as the only possible outcome of configuration exchange, while SLAVE connections may take step (3) if it is possible. This permits a dynamically-configured Internet where the sizes and positions of fields may be changed by mutual agreement. Characteristics Of This Delegation Method ========================================= This delegation scheme has the following important characteristics which will make hierarchial routing more efficient in the Internet of tomorrow under the IPv6 addressing scheme: 1) Easy routing. End-node ASNs which wish to make full routing decisions within a region of a country will only need to care about the "ASN" field. They can safely ignore the REGION and COUNTRY designations. Any national ASN can choose to ignore the REGION designation (potentially at its peril). This gives a current route table size for FULL route exchange of just over 2,000 entries. Regional ASNs compute and carry a table of "best" COUNTRY and GALAXY exit points and forward traffic to those as appropriate. Note that recomputation of GALAXY and COUNTRY exits may be deemed a very low priority task at the discretion of the ASN. This design gives low-end providers in a given region a maximum route table size of 65,536 entries, and a current route table size of just over 2,000. 2) Multinational ASNs must use the COUNTRY, REGION and ASN fields to make routing decisions. Multinational ASNs which wish to use only one ASN per country do not need multiple REGION codes. Those which do wish to sub-divide countries may use a REGION code within those countries, but not elsewhere. 3) Growth of the Internet in a given country does not impact the route table size for non-multinational providers outside of that country. Multinational providers see impact no worse than they have to cope with today under IPv4 addressing. 4) All "address assignment" policies which could be used to restrain trade disappear; each provider has a 64-bit address space to themselves, which is more than enough to accomodate every possible device attached to that provider. (64 bits of address give you 18,446,744,073,709,551,616 possible addresses). We can therefore address every man, woman, child, dog, cat, and light switch under this scheme and never even come close to running out. 5) IPV4 mapping at the low order end gives us very easy NAT capability between IPV6 and IPV4. Specifically, if two ASNs cooperate through either themselves or a third party, they can set policies on the allocation of the IPV4 field which will insure uniqueness (similar to what IANA does now) - allowing full end-user IPV4 portability. Transport to the full IPV6 layer for backbone routing is now an index function in most of today's CPUs - a one-clock-cycle operation. This byte-alignment is important to maintain high performance in the gateway function, as these devices will have to run at wire speeds. Author's Address ================ Karl Denninger Email: <karl(a)MCS.Net> Voice: [+1 312 803-MCS1] Fax: [+1 312 248-9865] draft-denninger-ipv6number-00.txt Expires 10 May 1998 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo(a)sunroof.eng.sun.com --------------------------------------------------------------------

1 0

(IPng 5961) I-D ACTION:draft-ietf-ipngwg-addr-arch-v2-07.txt (fwd)
by Thomas Trede 02 Jul '98

02 Jul '98

FYI. Regards, Thomas ---------- Forwarded message ---------- Date: Wed, 01 Jul 1998 10:28:58 -0400 From: Internet-Drafts(a)ietf.org To: IETF-Announce:;;;;@ns.cnri.reston.va.us;@Eng.Sun.COM;;; Cc: ipng(a)sunroof.Eng.Sun.COM Subject: (IPng 5961) I-D ACTION:draft-ietf-ipngwg-addr-arch-v2-07.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 Addressing Architecture Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v2-07.txt Pages : 25 Date : 30-Jun-98 This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-addr-arch-v2-07.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v2-07.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v2-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

1 0

(no subject)
by Sam J. H. Hamilton 22 Jun '98

22 Jun '98

1 0

(ngtrans) scheduling for August IETF (fwd)
by Thomas Trede 17 Jun '98

17 Jun '98

FYI. Regards, Thomas Trede ---------- Forwarded message ---------- Date: Wed, 17 Jun 1998 12:38:08 -0700 From: Bob Fink <rlfink(a)lbl.gov> Reply-To: ngtrans(a)sunroof.Eng.Sun.COM To: 6bone(a)isi.edu, ngtrans(a)sunroof.Eng.Sun.COM Cc: Tony Hain <tonyhain(a)microsoft.com>, Bob Gilligan <gilligan(a)freegate.net>, ops-chairs(a)ops.ietf.org Subject: (ngtrans) scheduling for August IETF 6bone/ngtrans folk, I will need to schedule the ngtrans meeting soon for the August IETF, so am soliciting input. I'm inclined to ask for the usual two one-hour slots on Tuesday afternoon. Currently we have the following on the table: "IPv6 Transitions Mechanisms" draft for advancement to replace RFC 1933 "6bone Routing Practices" draft for advancement to Info RFC 6bone operational issues BGP4+ routing reports other stuff?? When/if do we change from a 'test' AUP to a production 'AUP' Status of IPv6 address registry issues with RIPE/ARIN/APNIC Please let me know what else may be appropriate. Thanks, Bob

1 0

Try It Before You Join.....
by giftnkind＠latinmail.com 17 Jun '98

17 Jun '98

Have your downline built BEFORE you spend any money!!! There are a number of important factors that increased the chances of any networker becoming successful. Initiallly the most important of these is the momentum and excitement of actively sponsoring new members. How would you like to know that you have an existing downline and team in place to continue to help you develop a network BEFORE you ever sign up or spend a penny? With the Post Launch 1 you can!!!! A Post Launch is similar to a pre-launch with two main differences. A Post Launch places a large group of excited individuals into an ESTABLISHED marketing program instead of a marketing plan that may only be testing the waters(80% of new MLMs go defunct in the first year of business.) Secondly, our program uses a new and unique TEAM concept to help you build a network. There is absolutely no risk to get involved and no cost to join Post Launch 1. For more information, please call 415-221-2804 and leave your email address. what it's all about. Sincerely, Ben T. Tsuchimoto YOU HAVE NOTHING TO LOSE AND POTENTIALLY A LOT TO GAIN!!! >>> If you wish to be removed from our mailing list, kindly <<< >>> reply with the word "Remove" in the Subject line. <<< >>>Thank you for your time <<<

1 0

(IPng 5882) I-D ACTION:draft-ietf-ipngwg-tla-assignment-04.txt (fwd)
by Thomas Trede 16 Jun '98

16 Jun '98

FYI. Regards, Thomas Trede ---------- Forwarded message ---------- Date: Mon, 15 Jun 1998 10:16:10 -0400 From: Internet-Drafts(a)ietf.org To: IETF-Announce:;;;;@CNRI.Reston.VA.US;@Eng.Sun.COM;;; Cc: ipng(a)sunroof.Eng.Sun.COM Subject: (IPng 5882) I-D ACTION:draft-ietf-ipngwg-tla-assignment-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Proposed TLA and NLA Assignment Rules Author(s) : B. Hinden Filename : draft-ietf-ipngwg-tla-assignment-04.txt Pages : 10 Date : 12-Jun-98 This document proposes rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID) as defined in [AGGR]. These proposed rules apply to registries allocating TLA ID's and to organizations receiving TLA ID's. This proposal is intended as input from the IPng working group to the IANA and Registries. It is not intended for any official IETF status. Its content represents the result of extensive discussion between the IPng working group, IANA, and Registries. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-tla-assignment-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-tla-assignment-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-tla-assignment-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

1 0