November 1998 - ipv6-wg - mailman.ripe.net

Fw: (IPng 6786) Protocol Action: IPv6 over Non-Broadcast Multiple Access (NBMA) networks to Proposed Standard
by Thomas Trede 26 Nov '98

26 Nov '98

FYI. Regards, Thomas Trede -----Original Message----- From: The IESG (by way of Bob Hinden <hinden(a)iprg.nokia.com>) <iesg-secretary(a)ietf.org> To: ipng(a)sunroof.Eng.Sun.COM <ipng(a)sunroof.Eng.Sun.COM> Date: Mittwoch, 25. November 1998 17:39 Subject: (IPng 6786) Protocol Action: IPv6 over Non-Broadcast Multiple Access (NBMA) networks to Proposed Standard > > >The IESG has approved publication of the following Internet-Drafts as >Proposed Standards: > >o IPv6 over Non-Broadcast Multiple Access (NBMA) networks > <draft-ietf-ion-ipv6-02.txt> > >o IPv6 over ATM Networks > <draft-ietf-ion-ipv6-atm-03.txt> > >These documents are the product of the Internetworking Over NBMA >Working Group. The IESG contact persons are Jeffrey Burgan and Thomas >Narten. > > >Technical Summary > > The document "IPv6 over Non-Broadcast Multiple Access (NBMA) > networks" provides a framework for how to run IPv6 over NBMA > link types (e.g., ATM, Frame Relay, etc.). It provides a basis for > companion documents (e.g., "IPv6 over ATM Networks") to define > specific items that are by their nature link-layer specific. The > first document also defines how a client can use use Neighbor > Discovery to request NBMA shortcuts (i.e., to initiate NHRP > services). The MARS model is assumed, allowing Neighbor > Discovery to be used (Neighbor Discovery assumes multicast is > available on a specific link-layer.) The two documents together > define how to run IPv6 over ATM networks for both SVCs and PVCs. > >Working Group Summary > > There was consenus in the WG for this approach, and no issues were > raised during the Last Call. > >Protocol Quality > > This specification has been reviewed for the IESG by Thomas Narten > and Jeffrey Burgan. > > > >-------------------------------------------------------------------- >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

Fw: (IPng 6771) I-D ACTION:draft-ietf-ipngwg-esd-analysis-03.txt
by Thomas Trede 24 Nov '98

24 Nov '98

FYI. Regards, Thomas Trede -----Original Message----- From: Internet-Drafts(a)ietf.org <Internet-Drafts(a)ietf.org> To: "IETF-Announce:;;;;@ns.cnri.reston.va.us;"@Eng.Sun.COM;;; <"IETF-Announce:;;;;@ns.cnri.reston.va.us;"@Eng.Sun.COM;;;> Cc: ipng(a)sunroof.Eng.Sun.COM <ipng(a)sunroof.Eng.Sun.COM> Date: Dienstag, 24. November 1998 00:19 Subject: (IPng 6771) I-D ACTION:draft-ietf-ipngwg-esd-analysis-03.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 : Separating Identifiers and Locators > in Addresses: An Analysis of the GSE Proposal > for IPv6 > Author(s) : M. Crawford, A. Mankin, T. Narten, > J. Stewart, L. Zhang > Filename : draft-ietf-ipngwg-esd-analysis-03.txt > Pages : 50 > Date : 20-Nov-98 > > On February 27-28, 1997, the IPng Working Group held an interim > meeting in Palo Alto, California to consider adopting Mike O'Dell's > 'GSE - An Alternate Addressing Architecture for IPv6' proposal [GSE]. > In GSE, 16-byte IPv6 addresses are split into distinct portions for > global routing, local routing and end-point identification. GSE > includes the feature of configuring a node internal to a site with > only the local routing and end-point identification portions of the > address, thus hiding the full address from the node. When such a > node generates a packet, only the low-order bytes of the source > address are specified; the high-order bytes of the address are filled > in by a border router when the packet leaves the site. > > There is a long history of a vague assertion in certain circles that > IPv4 'got it wrong' by treating its addresses simultaneously as > locators and identifiers. Despite these claims, however, there was > never a complete proposal for a scaleable network protocol which > separated the functions. As a result, it wasn't possible to do a > serious analysis comparing and contrasting a 'separated' architecture > and an 'overloaded' architecture. The GSE proposal serves as a > vehicle for just such an analysis, and that is the purpose of this > paper. > > We conclude that an architecture that clearly separates locators and > identifiers in addresses introduces new issues and problems that do > not have an easy or clear solution. Indeed, the alleged > disadvantages of overloading addresses turn out to provide some > significant benefits over the non-overloaded approach. > >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-esd-analysis-03.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-esd-analysis-03.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nic.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-esd-analysis-03.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. > ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-esd-analysis-03.txt

1 0

Fw: (IPng 6765) I-D ACTION:draft-ietf-ipngwg-iana-tla-00.txt
by Thomas Trede 20 Nov '98

20 Nov '98

FYI. Regards, Thomas Trede -----Original Message----- From: Internet-Drafts(a)ietf.org <Internet-Drafts(a)ietf.org> To: "IETF-Announce:;;;;@ns.cnri.reston.va.us;"@Eng.Sun.COM;;; <"IETF-Announce:;;;;@ns.cnri.reston.va.us;"@Eng.Sun.COM;;;> Cc: ipng(a)sunroof.Eng.Sun.COM <ipng(a)sunroof.Eng.Sun.COM> Date: Donnerstag, 19. November 1998 17:23 Subject: (IPng 6765) I-D ACTION:draft-ietf-ipngwg-iana-tla-00.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 : Initial IPv6 Sub-TLA ID Assignments > Author(s) : B. Hinden, S. Deering, R. Fink, T. Hain > Filename : draft-ietf-ipngwg-iana-tla-00.txt > Pages : 5 > Date : 17-Nov-98 > > This document proposes initial assignments of IPv6 Sub-TLA > Aggregation Identifiers (Sub-TLA ID) to the Address Registries and > continued management of the IP6.INT domain. It is intended as input > to the IANA from the IETF IP Next Generation (IPNG) and Next > Generation Transition (NGTRANS) working groups as an aid in starting > the process of allocating IPv6 addresses. It is not intended for any > official IETF status. > >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-iana-tla-00.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-iana-tla-00.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nic.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-iana-tla-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. > ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-iana-tla-00.txt

1 0

[Fwd: (ngtrans) I-D ACTION:draft-ietf-ngtrans-translator-00.txt]
by Thomas Trede 18 Nov '98

18 Nov '98

FYI. Regards, Thomas Trede

1 0

[Fwd: (ngtrans) I-D ACTION:draft-ietf-ngtrans-dual-stack-hosts-00.txt]
by Thomas Trede 18 Nov '98

18 Nov '98

FYI. Regards, Thomas Trede

1 0

(ngtrans) W.G. Last Call on "Network Address Translation - Protocol Translation (NAT-PT)" (fwd)
by Thomas Trede 13 Nov '98

13 Nov '98

FYI. Regards, Thomas Trede ---------- Forwarded message ---------- Date: Mon, 09 Nov 1998 16:06:21 -0800 From: Bob Fink <rlfink(a)lbl.gov> Reply-To: ngtrans(a)sunroof.Eng.Sun.COM To: ngtrans(a)sunroof.Eng.Sun.COM Cc: Tony Hain <tonyhain(a)microsoft.com>, Harald Tveit Alvestrand <Harald.Alvestrand(a)maxware.no> Subject: (ngtrans) W.G. Last Call on "Network Address Translation - Protocol Translation (NAT-PT)" This is an NGtrans working group last call for comments on advancing the following document as an Experimental Standard: Title : Network Address Translation - Protocol Translation (NAT-PT) Author(s) : G. Tsirtsis, P. Srishuresh Filename : draft-ietf-ngtrans-natpt-03.txt Pages : 21 Date : 9-Nov-98 Please send substantive comments to the ngtrans mailing list, and minor editorial comments to the authors. This last call period will end two week from today on November 23, 1998. Bob Fink/ Tony Hain ----------------------------cut here-------------------------------------- INTERNET-DRAFT George Tsirtsis NGTRANS WG BT Laboratories Expires April, 1999 Pyda Srishuresh Category: EXPERIMENTAL Lucent Technologies November 1998 Network Address Translation - Protocol Translation (NAT-PT) <draft-ietf-ngtrans-natpt-03.txt> Status of this Memo This document is an Internet-Draft. Internet-Drafts are working doc- uments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing 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 mate- rial or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Eu- rope), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document specifies a transition mechanism in addition to those already specified in [TRANS]. The new mechanism provides an end-to-end solution to allow IPv6-only hosts to communicate with IPv4-only hosts and vice versa using Network Address Translation and Protocol Translation. The scheme described does not require du- al-stack hosts; nor does it mandate any routing related changes on the hosts. The scheme is based on a combination of address transla- tion theme as described in [NAT] and V6/V4 protocol translation theme as described in [SIIT]. Acknowledgements The authors would like to thank Erik Nordmark whose Protocol Translation details in [SIIT] formed the bases of the corresponding section 5 in this document Special thanks to Pedro Marques for reviewing the draft. Finally, many thanks to Alan O'Neill and Martin Tatham since the initial Tsirtsis & Srisuresh [Page 1] ^L Internet Draft Network Address + Protocol Translator November 1998 idea described in this document was developed after discussions with them. Index 1. Introduction 2. Terminology 3. Network Address Translation operation 3.1 NAT-PT Outgoing Sessions (IPv6 to IPv4) 3.2 NAPT-PT Outgoing Sessions (IPv6 to IPv4) 4. IP v4 Address Assignment 4.1 V4 Address assignment for outgoing connections 4.2 V4 Address assignment for incoming connections 4.2.1 DNS Application Layer Gateway (ALG) support 5. Protocol Translation Details 5.1 Translating IPv4 headers to IPv6 headers 5.2 Translating ICMPv4 headers to ICMPv6 headers 5.3 Translating IPv6 headers to IPv4 headers 5.4 Translating ICMPv6 headers to ICMPv4 headers 5.5 TCP/UDP Checksum Update 5.6 FTP Control session payload 6. NAT-PT Limitations and Future Work 6.1 Topology limitations 6.2 Protocol Translation Limitations 6.3 Impact of Address Translation 6.4 Lack of end-to-end security 6.5 DNS Translation and DNSSEC 7. Applicability Statement 8. Security Considerations 9. References 1. Introduction IPv6 is the upcoming IP protocol that was designed in order to modernise IPv4, which was designed in the 1970s. IPv6 has a number of advantages over IPv4 including the fact that it provides a much larger address space than IPv4, which for many, is the number one reason to move to IPv6. A basic requirement, however, for a large Tsirtsis & Srisuresh [Page 2] ^L Internet Draft Network Address + Protocol Translator November 1998 number of people is to be able to communicate with IPv4 hosts during the transition period. Keeping in mind that the chances are that IPv4 and IPv6 will have to coexist for a very long time, interoperability becomes a very important issue. The SIIT proposal [SIIT] describes a protocol translation mechanism that allows communication between IPv6-only and IPv4-only machines. This proposal assumes that V6 hosts are somehow assigned a V4 address for communicating with V4 hosts. Further, it assumes that the V6 hosts would use a V6 address based on their V4 address (V4 mapped or V4 compatible) as their source V6 address and V4-mapped address of the target V4 machine as the destination V6 address. With these as- sumptions, SIIT purports to do protocol independent translation of V4/V6 datagrams, requiring no state details on the sessions. Unlike SIIT, NAT-PT provides a transparent end-to-end solution re- quiring no changes to end nodes. NAT-PT uses a pool of V4 addresses for assignment to V6 hosts on a dynamic basis as sessions are initi- ated across V4-V6 boundaries. These assigned addresses in turn are used to transparently replace the original addresses used by V6 end nodes and vice versa. This requires NAT-PT to track the sessions it supports and mandates that inbound and outbound datagrams pertaining to a session traverse through the same NAT-PT router. You will note that the topology restriction on NAT-PT are very similar to those de- scribed for V4 NATs in [NAT]. Protocol translation details specified in [SIIT] would be used to extend address translation with protocol syntax/semantics translation. 2. Terminology Session initiation packet This is the first packet of an IP session. Only the first packet of a TCP session can be identified in a de- terministic way, with the presence of SYN bit and absence of ACK bit in TCP header. There is no deterministic way to recognise the start of a UDP or any non-TCP session. [NAT]. Network Address Translation (NAT) NAT in this document is very similar, but not the same, with IPv4 NAT as described in [NAT]. IPv4 NAT trans- lates one IPv4 address into another IPv4 address . In this document, NAT refers to translation of an IPv4 address into an IPv6 address and vice versa. Protocol Translation (PT) PT in this document refers to translation of an IPv4 Tsirtsis & Srisuresh [Page 3] ^L Internet Draft Network Address + Protocol Translator November 1998 packet into a semantically equivalent IPv6 packet and vice versa. Application Layer Gateway (ALG) Application Level Gateway (ALG) is an application spe- cific agent that allows a V6 host to communicate with a V4 host and vice versa. Some applications carry network ad- dresses in payload. NAT-PT is application independent (with the notable exception of FTP) and does not snoop the payload to fix IP addresses in payload. ALG is an alterna- tive to NAT-PT for such applications. 3. Network Address Translation operation NAT-PT offers a straight forward end-to-end solution with trans- parent routing and address/protocol translation. Operation of NAT-PT is described in the following sub-sections. There are limitations to using the translation method. Is it mandatory that all requests and responses pertaining to a session be routed via the same NAT router. One way to ascertain this would be to have NAT based on a border router that is unique to a stub domain, where all IP packets are ei- ther originated from the domain or destined to the domain. There are other ways to ensure this with multiple NAT devices. For example, a private domain could have two distinct exit points to different providers and the session flow from the hosts in a private network could traverse through whichever NAT device has the best metric for an external host. NAT-PT is application independent. Applications such as "FTP" that include IP addresses in payload will need to be supported by appli- cation specific ALGs in conjunction with NAT-PT. This document de- scribes the functioning of FTP and DNS ALGs in conjunction with NAT- PT. Specifications of ALGs for other applications is outside the scope of this document. NAT-PT is also limited by the fact that it can translate only the shared semantics between the V4 and V6 protocols. Features specific only to V6 or features not supported in V6 will not be supported by NAT-PT. In the following paragraphs we describe the operation of NAT-PT and the way that connections can be initiated from both sides, when an IPv6 domain is connected to an IPv4 domain through a NAT-PT. 3.1 NAT-PT Outgoing Sessions (IPv6 to IPv4) Tsirtsis & Srisuresh [Page 4] ^L Internet Draft Network Address + Protocol Translator November 1998 ^ | [IPv6-B]-+ | +==============+ [IPv6-A]-+-[NAT-PT]---------| IPv4 network |--[IPv4-C] | +==============+ (pool of v4 addresses) Figure 1: IPv6 to IPv4 communication Host IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210 Host IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211 Host IPv4-C has an IPv4 address -> 132.146.243.30 NAT-PT has a pool of addresses including the IPv4 subnet 120.130.26/24 Say the IPv6 Host A wants to communicate with the IPv4 Host C. Host A creates a packet with: Source Address, SA=FEDC:BA98::7654:3210 and Destination Address, DA = prefix::132.146.243.30 NOTE: The prefix PREFIX::/96 is advertised in the stub domain by the NAT-PT and it points to it. The pre-configured prefix has to be routable only inside the stub domain representing the IPv4 world. The packet is routed to the NAT-PT gateway, where it has to be translated to IPv4. If the outgoing packet is not a session initialisation packet, the NAT-PT SHOULD already have stored some state about the related session, including assigned IPv4 address and cached parameters for the translation. If this state does not exist the packet SHOULD be silently discarded. If the packet is a session initialisation packet the NAT-PT locally allocates an address (e.g: 120.130.26.10) from its pool of addresses and the packet is translated to IPv4, while translation parameters are cached for the duration of the session and the IPv6 to IPv4 mapping is retained by NAT-PT. The resulting IPv4 packet has SA=120.130.26.10 and DA=132.146.243.30. The returning traffic will be recognised as belonging to the same session and the packet will use the cached information in order to be translated, while the addresses after the translation will be as follows. SA=PREFIX::132.146.243.30, DA=FEDC:BA98::7654:3210. Note that Tsirtsis & Srisuresh [Page 5] ^L Internet Draft Network Address + Protocol Translator November 1998 this packet can now be routed inside the IPv6-only network as nor- mal. 3.2 NAPT-PT Outgoing Sessions (IPv6 to IPv4) with a single V4 address NAPT-PT, which stands for "Network Address Port Translation + Pro- tocol Translation", would allow V6 hosts to communicate with the V4 world transparently using a single V4 address. The TCP/UDP ports of the V6 hosts are translated into TCP/UDP ports of the registered V4 address. The port translation and ICMP query iden- tifier translation works very similar to the way NAPT is described in [NAT]. NAPT-PT also solves a problem that is inherent with NAT-PT. That is, NAT-PT would fall flat when the pool of V4 addresses assigned for translation purposes is exhausted. Once the address pool is exhausted, newer V6 hosts cannot establish sessions with the out- side world anymore. NAPT-PT, on the other hand, will allow for a maximum of 63K TCP and 63K UDP sessions before falling flat with no TCP and UDP ports left to assign. In the example sited in figure 1, say, we have NAPT-PT on the bor- der router (instead of NAT-PT) and all V6 addresses are mapped in- to a single v4 address 120.130.26.10. Say the IPv6 Host A wanted to set up a TCP session with the IPv4 Host C. Host A creates a packet with: Source Address, SA=FEDC:BA98::7654:3210 , source TCP port = 3017 and Destination Address, DA = PREFIX::132.146.243.30, destination TCP port = 23. When the packet reaches the NAPT-PT box, NAPT-PT would assign one of the TCP ports from the assigned V4 address to translate the tu- ple of (source Address, Source TCP port) as follows. SA=120.130.26.10, source TCP port = 1025 and DA=132.146.243.30, destination TCP port = 23. The returning traffic from 132.146.243.30, TCP port 23 will be recognised as belonging to the same session and will be translated back to V6 as follows: SA = PREFIX::132.146.243.30, source TCP port = 23; DA = FEDC:BA98::7654:3210 , destination TCP port = 3017 Tsirtsis & Srisuresh [Page 6] ^L Internet Draft Network Address + Protocol Translator November 1998 As for inbound sessions, they are restricted to one server per service made possible by static TCP/UDP port mapping. For example, say the Host [IPv6-A] in figure 1 is the only HTTP server in the V6 domain. Host [IPv4-C] sends a packet: SA=132.146.243.30, source TCP port = 1025 and DA=120.130..26.10, destination TCP port = 80 (http port) NAPT-PT will translate this packet to: SA=PREFIX::132.146.243.30, source TCP port = 1025 DA=FEDC:BA98::7654:3210, destination TCP port = 80 (http port) In the above example, note that all sessions to NAPT registered address with service port of 80 will be redirected to the same host [IPv6-A]. 4. IPv4 Address Assignment IPv4 addresses are assigned by NAT-PT to a V6 host, when NAT-PT iden- tifies the start of session, inbound or outbound. Identification of session start on the inbound is done differently from that on the outbound. However, the same V4 address pool is used for assigning to V6 hosts, irrespective of whether a session is initiated outbound from a V6 host or initiated inbound from a V4 host. Policies determining what type of sessions are allowed and in which direction and from/to which hosts is out of the scope of this docu- ment. 4.1 V4 Address assignment for outgoing connections Outbound session start is based on identifying the first packet of a session. For ex: SYN, !ACK for TCP sessions. V6 hosts learn the address of V4 hosts from the DNS server in the V4 domain or the DNS server internal to the V6 network. We recom- mend that DNS servers internal to V6 maintain mapping of names to IP V6 addresses for internal hosts and possibly some external hosts. External DNS servers in the V4 domain maintain name map- ping for external hosts (i.e., V4 hosts) alone. In case of NAPT-PT, a TCP/UDP source port is assigned from the registered V4 address upon detection of each new outbound session. Tsirtsis & Srisuresh [Page 7] ^L Internet Draft Network Address + Protocol Translator November 1998 4.2 V4 Address assignment for incoming connections In order to initiate incoming sessions, a V4 host obtains the V4 address of the V6 host it is trying to connect to by making a DNS request. This request constitutes the start of a potential new session. ^ [DNS]--+ | [DNS]------[DNS]-------[DNS] [IPv6-B]-+ | | | +==============+ | [IPv6-A]-+----[NAT-PT]------| IPv4 network |--[IPv4-C] | +==============+ (pool of v4 addresses) Figure 2: IPv4 to IPv6 communication Host IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210 Host IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211 Host IPv4-C has an IPv4 address -> 132.146.243.30 NAT-PT has a pool of addresses including the IPv4 subnet 120.130.26/24 4.2.1 DNS Application Layer Gateway (ALG) support In figure 2 above, when Host C name resolver makes a name look up request for Host A, the lookup query is redirected to the DNS server on the V6 network. Considering that NAT-PT is resid- ing on the border router between V4 and V6 networks, this re- quest datagram would traverse through the NAT-PT router. The DNS ALG on NAT-PT would modify the DNS Queries going into V6 domain as follows: a) For Host Name to Host Address Query requests: Change the Query type from "A" to "AAAA". b) For Host address to Host name query requests: Replace the V4 address octets (in reverse order) pre- ceding the string "IN-ADDR.ARPA" with the corresponding V6 address (if there exists a map) octets in reverse or- der. In the opposite direction, when DNS response traverse from the DNS server on V6 network to V4 host, the DNS-ALG once again traps the DNS packet and would: Tsirtsis & Srisuresh [Page 8] ^L Internet Draft Network Address + Protocol Translator November 1998 a) Translate DNS responses for "AAAA" records into 'A' records, b) Replace the V6 address sent by the V6 DNS server with the V4 address internally assigned by the NAT-PT router. If a V4 address is not previously assigned to this V6 host, NAT-PT would assign it this time. The TTL values on all DNS re- source records (RRs) passing through NAT-PT would be set to 0. This technique is also useful for outgoing communication as well. We saw that a v6host that needs to communicate with a v4 hosts needs to use a specific prefix (PREFIX::) in front of the IPv4 address of the v4host. The above technique allows the use of this prefix without any configuration in the hosts. E.g.: In Figure 2, Host-A makes a name look-up on the Host-C. The DNS query goes to the v6 DNS server and from there to the v4 DNS server outside the v6 stub domain after it has been translated by the NAT-PT. The reply follows the same route but now the NAT-PT translates the reply adding the appropriate prefix. So, if the reply is: HostC A 132.146.243.30, it is translated to HostC AAAA PREFIX::132.146.243.30 Now Host A can use this address as any other IPv6 address and the v6 DNS server can even cache it as long as the prefix does not change. An additional problem is how the v6 DNS server in the v6 stub domain talks to the v4 domain outside the v6 stub domain. Re- member that there are no dual stack hosts here. The v4 DNS server needs to point to a v4 address, part of the v4 pool of addresses, available to the NAT-PT. The NAT-PT keeps a one-to- one mapping between this v4 address and the IPv6 address of the v6 DNS server. In the other direction, the v6 DNS server points to the IPv4 address of the v4 DNS servers with the prefix (PRE- FIX::) which indicates non IPv6 address. This mechanism can easily be extended to accommodate secondary DNS servers. Note that the scheme described above impacts DNSSEC and look at section 6.5 of this document for details. 5. Protocol Translation Details The IPv4 and ICMPv4 headers are similar to their V6 counterparts but a number of field are either missing, have different meaning or dif- Tsirtsis & Srisuresh [Page 9] ^L Internet Draft Network Address + Protocol Translator November 1998 ferent length. NAT-PT SHOULD translate all IP/ICMP headers from and to IPv6 in order to make end-to-end IPv6 to IPv4 communication possi- ble. Due to the address translation function and possible port mul- tiplexing, NAT-PT SHOULD also make the appropriate adjustments to the upper layer protocol (TCP/UDP) as well as to the FTP control ses- sion payload. In the following paragraphs we are borrowing the translation mecha- nism from the SIIT specification and we make the changes imposed by the address translation. 5.1 Translating IPv4 headers to IPv6 headers If the DF flag is not set and the IPv4 packet will result in an IPv6 packet larger than 1280 bytes the IPv4 packet SHOULD be frag- mented prior to translating it. Since IPv4 packets with DF not set will always result in a fragment header being added to the packet, the IPv4 packets should be fragmented so that their length, excluding the IPv4 header, is at most 1232 bytes (1280 minus 40 for the IPv6 header and 8 for the Fragment header). The resulting fragments are then translated independently using the logic described below. If the DF bit is set and the packet is not a fragment (i.e., the MF flag is not set and the Fragment Offset is zero) then there is no need to add a fragment header to the packet. The IPv6 header fields are set as follows: Version: 6 Flow ID: 0 (all zero bits) Payload Length: Total length value from IPv4 header, minus the size of the IPv4 header and IPv4 options, if present. Payload Type: Protocol field copied from IPv4 header Hop Limit: TTL value copied from IPv4 header, decremented by one. Source Address: The low-order 32 bits is the IPv4 source address. The high-order 96 bits is the designated prefix for all v4 Tsirtsis & Srisuresh [Page 10] ^L Internet Draft Network Address + Protocol Translator November 1998 communications and points to the NAT-PT gateway (PRE- FIX::/96) Destination Address: The NAT-PT retains a mapping between the IPv4 DA and the IPv6 address of the destination host. The IPv4 DA is replaced by the IPv6 address retained in that mapping. If IPv4 options are present in the IPv4 packet, they are ignored i.e., there is no attempt to translate them. If there is need to add a fragment header (the DF bit is not set or the packet is a fragment) the header fields are set as above with the following exceptions: IPv6 fields: Payload Length: Total length value from IPv4 header, plus 8 for the fragment header, minus the size of the IPv4 header and IPv4 options, if present. Payload Type: Fragment Header (44). Fragment header fields: Next Header: Protocol field copied from IPv4 header. Fragment Offset: Fragment Offset copied from the IPv4 header. M flag: More Fragments bit copied from the IPv4 header. Identification: The low-order 16 bits copied from the Identification field in the IPv4 header. The high-order 16 bits set to zero 5.2 Translating ICMPv4 headers to ICMPv6 headers All ICMP messages that are to be translated require that the ICMP checksum field be updated as part of the translation since ICMPv6, unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP. The NAT-PT retains a mapping between the IPv4 DA and the IPv6 ad- dress of the destination host. The checksum update needs to in- Tsirtsis & Srisuresh [Page 11] ^L Internet Draft Network Address + Protocol Translator November 1998 clude this IPv6 address in the calculation. In addition all ICMP packets needs to have the Type value trans- lated and for ICMP error messages the included IP header also needs translation. The actions needed to translate various ICMPv4 messages are: ICMPv4 query messages: Echo and Echo Reply (Type 8 and Type 0) Adjust the type to 128 and 129, respectively, and adjust the ICMP checksum both take the type change into account and to include the ICMPv6 pseudo-header. Information Request/Reply (Type 15 and Type 16) Obsoleted in ICMPv4. Silently drop. Timestamp and Timestamp Reply (Type 13 and Type 14) Obsoleted in ICMPv6. Silently drop. Address Mask Request/Reply (Type 17 and Type 18) Obsoleted in ICMPv6. Silently drop. ICMP Router Advertisement (Type 9) Single hop message. Silently drop. ICMP Router Solicitation (Type 10) Single hop message. Silently drop. Unknown ICMPv4 types Silently drop. IGMP messages: While there are ICMPv6 counterparts for the IGMP messages all the "normal" IGMP messages are single-hop messages and should be silently dropped by the translator. Other IGMP messages might be used by multicast routing protocols and, since it would be a configuration error to try to have router adjacen- cies across IPv4/IPv6 translators those packets should also be silently dropped. ICMPv4 error messages: Destination Unreachable (Type 3) For all that are not explicitly listed below set the Type to 1. Translate the code field as follows: Code 0, 1: Set Code to 0 (no route to destination). Tsirtsis & Srisuresh [Page 12] ^L Internet Draft Network Address + Protocol Translator November 1998 Code 2: Translate to an ICMPv6 Parameter Problem (Type 4, Code 1) and make the Pointer point to the IPv6 Payload Type field. Code 3: Set Code to 4 (port unreachable). Code 4: Translate to an ICMPv6 Packet Too Big message (Type 2) with code 0. The MTU field needs to be ad- justed for the difference between the IPv4 and IPv6 header sizes. Note that if the IPv4 router did not set the MTU field i.e. the router does not implement [PMTUv4], then the translator should use the plateau values specified in [PMTUv4] to determine a likely path MTU and include that path MTU in the ICMPv6 packet. (Use the greatest plateau value that is less than the re- turned Total Length field.) Code 5: Set Code to 2 (not a neighbor). Code 6,7: Set Code to 0 (no route to destination). Code 8: Set Code to 0 (no route to destination). Code 9, 10: Set Code to 1 (communication with destination administratively prohibited) Code 11, 12: Set Code to 0 (no route to destination). Redirect (Type 5) Single hop message. Silently drop. Source Quench (Type 4) Obsoleted in ICMPv6. Silently drop. Time Exceeded (Type 11) Set the Type field to 3. The Code field is unchanged. Parameter Problem (Type 12) Set the Type field to 4. The Pointer needs to be updated to point to the corresponding field in the translated include IP header. There are some differences between the IPv4 and the IPv6 ICMP er- ror message formats as detailed above. In addition, the ICMP er- ror messages contain the IP header for the packet in error which needs to be translated just like a normal IP header. The transla- tion will change the length of the datagram thus the Payload Tsirtsis & Srisuresh [Page 13] ^L Internet Draft Network Address + Protocol Translator November 1998 Length field in the outer IPv6 header will need to be updated. TCP/UDP/ICMP query headers within the ICMP error messages will need to be translated to account for checksum changes. In the case of NAPT-PT, even the TCP/UDP port numbers and ICMP Query ID will need to be translated. 5.3 Translating IPv6 headers to IPv4 headers If there is no IPv6 Fragment header the IPv4 header fields are set as follows: Version: 4 Internet Header Length: 5 (no IPv4 options) Type of Service: All zero. Total Length: Payload length value from IPv6 header, plus the size of the IPv4 header. Identification: All zero. Flags: The More Fragments flag is set to zero. The Don't Fragments flag is set to one. Fragment Offset: All zero. Time to Live: Hop Limit value copied from IPv6 header, decremented by one. Protocol: Payload Type field copied from IPv6 header. Header Checksum: Computed once the IPv4 header has been created. Source Address: The NAT-PT retains a mapping between the IPv6 SA and an Tsirtsis & Srisuresh [Page 14] ^L Internet Draft Network Address + Protocol Translator November 1998 IPv4 address from the pool of IPv4 addresses available. The IPv6 SA is replaced by the above IPv4 address. Destination Address: IPv6 packets that are translated have a destination address that includes an IPv4 address in the lower 32 bits of the address. Thus, the low-order 32 bits of the IPv6 destination address is copied to the IPv4 source address. If any of an IPv6 hop-by-hop options header, destination options header, or routing header are present in the IPv6 packet, they are ignored i.e., there is no attempt to translate them. However, the Total Length field and the Protocol field would have to be adjust- ed to "skip" these extension headers. If the IPv6 packet contains a Fragment header the header fields are set as above with the following exceptions: Total Length: Payload length value from IPv6 header, minus 8 for the Fragment header, plus the size of the IPv4 header. Identification: Copied from the low-order 16-bits in the Identification field in the Fragment header. Flags: The More Fragments flag is copied from the M flag in the Fragment header. The Don't Fragments flag is set to zero allowing this packet to be fragmented by IPv4 routers. Fragment Offset: Copied from the Fragment Offset field in the Fragment Header. Protocol: Next Header value copied from Fragment heade 5.4 Translating ICMPv6 headers to ICMPv4 headers All ICMP messages that are to be translated require that the ICMP checksum field be updated as part of the translation since ICMPv6, unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP. The NAT-PT retains a mapping between the IPv6 SA and an IPv4 ad- dress from the pool of IPv4 addresses. The checksum update needs Tsirtsis & Srisuresh [Page 15] ^L Internet Draft Network Address + Protocol Translator November 1998 to include this IPv4 address in the calculation. In addition all ICMP packets needs to have the Type value trans- lated and for ICMP error messages the included IP header also needs translation. The actions needed to translate various ICMPv6 messages are: ICMPv6 informational messages: Echo Request and Echo Reply (Type 128 and 129) Adjust the type to 0 and 8, respectively, and adjust the ICMP checksum both take the type change into ac- count and to exclude the ICMPv6 pseudo-header. Group Membership Query/Report/Reduction (Type 130, 131, 132) Single hop message. Silently drop. Neighbor Discover messages (Type 133 through 137) Single hop message. Silently drop. Unknown informational messages Silently drop. ICMPv6 error messages: Destination Unreachable (Type 1) Set the Type field to 3. Translate the code field as fol- lows: Code 0: Set Code to 1 (host unreachable). Code 1: Set Code to 10 (communication with destination host administratively prohibited). Code 2: Set Code to 5 (source route failed). Code 3: Set Code to 1 (host unreachable). Code 4: Set Code to 3 (port unreachable). Packet Too Big (Type 2) Translate to an ICMPv4 Destination Unreachable with code 4. The MTU field needs to be adjusted for the difference between the IPv4 and IPv6 header sizes taking into account whether or not the packet in error in- cludes a Fragment header. Time Exceeded (Type 3) Set the Type to 11. The Code field is unchanged. Parameter Problem (Type 4) If the Code is 1 translate this to an ICMPv4 protocol unreachable (Type 3, Code 2). Otherwise set the Type to 12 and the Code to zero. The Pointer needs to be up- Tsirtsis & Srisuresh [Page 16] ^L Internet Draft Network Address + Protocol Translator November 1998 dated to point to the corresponding field in the translated include IP header. Unknown error messages Silently drop. There are some differences between the IPv4 and the IPv6 ICMP er- ror message formats as detailed above. In addition, the ICMP er- ror messages contain the IP header for the packet in error which needs to be translated just like a normal IP header. The transla- tion will change the length of the datagram thus the Payload Length field in the outer IPv6 header might need to be updated. TCP/UDP/ICMP query headers within the ICMP error messages will need to be translated to account for checksum changes. In the case of NAPT-PT, even the TCP/UDP port numbers and ICMP Query ID will need to be translated. 5.5 TCP/UDP Checksum Update The NAT-PT retains a mapping between an IPv6 address and an IPv4 address from the pool of IPv4 addresses available. The above map- ping is used in the translation process of every packet that goes through the NAT-PT. TCP/UDP checksum SHOULD be recalculated according to the ad- dress change: Source Address for v6 to v4 translation; Destina- tion Address for v4 to v6 translation The incremental checksum adjustment algorithm may be borrowed from [NAT] draft. In the case of NAPT-PT, TCP/UDP checksum should be recalculated on the outbound to account for V6 source address and V6 TCP/UDP port changes. Likewise, TCP/UDP checksum on the inbound packets should be recalculated to account for destination v4 address and destination TCP/UDP port changes. 5.6 FTP Control session payload FTP control session carries in its payload the IP address and TCP port information pertaining to the data session it supports, an FTP ALG on NAT-PT is needed to provide support for the popular In- ternet application. The arguments to the File Transfer Protocol (FTP) PORT command and Tsirtsis & Srisuresh [Page 17] ^L Internet Draft Network Address + Protocol Translator November 1998 PASV response include an IP address (V4 or V6 address) and a TCP port in ASCII. If the IP address in PORT command or PASV response is a V6 address, then NAT-PT should substitute this with the NAT- PT assigned V4 address. In case of NAPT-PT, even the TCP port fol- lowing the IP address should be translated. The reverse (trans- lation from v4 address to V6 address) is true in the inbound packets. Note, all translations are ASCII encoded translations. As a re- sult, these translations may result in a change in the size of packet. If the new size is same as the previous, only the TCP checksum needs adjustment as a result of payload translation. If the new size is different from the previous, TCP sequence numbers should also be changed to reflect the change in length of FTP control session payload. The IP packet length field in V4 header or the IP payload length in V6 field should also be changed by the same delta change in payload size. A special table is used to correct the TCP sequence and acknowledge numbers in the TCP header for control packets in both directions. The table entries should have the source address, source data port, destination address and destination data port for V4 and V6 portions of the session, sequence number delta for outbound pack- ets and sequence number delta for inbound packets. The sequence number deltas are negative (i.e., payload size decreases) on the outbound and positive (i.e., payload increases) on the inbound. Sequence number for an outbound packet is increased by the out- bound sequence number delta and acknowledgement number for the same outbound packet is decreased by the inbound sequence number delta. Likewise, sequence number for an inbound packet is in- creased by the inbound sequence number delta and acknowledgement number for the same inbound packet is decreased by the outbound sequence number delta. 6. NAT-PT Limitations and Future Work 6.1 Topology limitations There are limitations to using the translation method. It is mandatory that all requests and responses pertaining to a session be routed via the same NAT router. One way to ascertain this would be to have NAT based on a border router that is unique to a stub domain, where all IP packets are either originated from the domain or destined to the domain. Tsirtsis & Srisuresh [Page 18] ^L Internet Draft Network Address + Protocol Translator November 1998 Note that the same limitation does not apply to IPv6 routing, since IPv4 routing cn be recognised from its form PREFIX::x.y.z.w (PREFIX::/96) and be treated differently. 6.2 Protocol Translation Limitations A number of IPv4 fields have changed meaning in IPv6 and transla- tion is not straightforward. For example the TOS field in IPv4 be- came meaningful mapping may be possible. As another example, the option headers semantics and syntax have changed significantly in IPv6, some meaningful translation may also be possible in the fu- ture using NAT-PT. 6.3 Impact of Address Translation Since NAT-PT performs address translation, applications that carry the IP address in the higher layers will not work. In this case Application Layer Gateways (ALG) need to be incorpo- rated to provide services to that kind of applications. 6.4 Lack of end-to-end security One of the most important limitations of the NAT-PT proposal is the fact that end-to-end network and transport layer security is not possible. Also application layer security may not be possible for applications that carry IP addresses to the application layer. This is an inherent limitation from the Network Address Translation function. 6.5 DNS Translation and DNSSEC The scheme described in section 4.2 involves translation of DNS messages. It is clear that this scheme can not be deployed in combination with secure DNS. I.e., an authoritative DNS name server in the V6 domain cannot sign replies to queries that originate from the V4 world. As a result, an V4 end-node that demands DNS replies to be signed will reject replies that have been tampered with by NAT-PT. The good news, however, is that only servers in V6 domain that need to be accessable from the V4 world pay the price for the above limitation, as V4 end-nodes may not access V6 servers due to DNS replies not being signed. Also note that zone transfers between DNS-SEC servers within the same V6 network are not impacted. Clearly, if DNS-SEC were to become the norm in both V4 and V6 Tsirtsis & Srisuresh [Page 19] ^L Internet Draft Network Address + Protocol Translator November 1998 DNS servers and end-host resolvers, the scheme suggested in this document will not work. 7. Applicability Statement NAT-PT can be a valuable transition tool at the border of a stub net- work that has been deployed as an IPv6 only network and it is con- nected to an Internet that is either V4-only or a combination of V4 and V6. NAT-PT by default provides one way connectivity between an IPv6 stub domain and the IPv4 world meaning that only sessions initialised by IPv6 nodes internal to the IPv6 stub domain can be translated, while sessions initiated by IPv4 nodes are droped. This makes NAT-PT a use- ful tool to IPv6 only stub networks that need to be able to maintain connectivity with the IPv4 world without the need to deploy servers visible to the IPv4 world. NAT-PT combined with a DNS ALG as described in 4.2.1 provides two way connectivity between the IPv6 stub domain and the IPv4 world allowing sessions to be initialised by IPv4 nodes outside the IPv6 stub do- main. This makes NAT-PT useful for IPv6 only stub networks that need to deploy servers visible to the IPv4 world. 8. Security Considerations Section 6.4 of this document describes the fact that end-to-end network and transport layer security is not possible when a session is intercepted by a NAT-PT. Also application layer security may not be possible for applications that carry IP addresses to the ap- plication layer. Section 6.5 of this document describes the fact that the DNS-ALG can not be deployed in combination with secure DNS. 9. REFERENCES [DNSSEC] D. Eastlake, C. Kaufman, "Domain Name System Security Exten- sions", RFC 2065, January 1997. [NAT] K. Egevang, P. Francis, The IP Network Address Translator (NAT), RFC 1631, May 1994 [PMTUv4] J. Mogul, S. Deering, "Path MTU Discovery", RFC 1191, November 1990 Tsirtsis & Srisuresh [Page 20] ^L Internet Draft Network Address + Protocol Translator November 1998 [SIIT] E. Nordmark, "Stateless IP/ICMP Translator (SIIT)", <draft-ietf-ngtrans-siit-02.txt>, Work in progress, November 1998 [TRANS] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers, RFC 1933, April 1996 AUTHORS George Tsirtsis Internet Transport Group B29 Room 129 BT Laboratoties IPSWICH IP5 3RE England Phone: +44 1473 640756 Fax: +44 1473 640709 e-mail: george(a)gideon.bt.co.uk Pyda Srisuresh Lucent Technologies 4464 Willow Road Pleasanton, CA 94588-8519 U.S.A. Voice: (925) 737-2153 Fax: (925) 737-2110 EMail: suresh(a)ra.lucent.com Tsirtsis & Srisuresh [Page 21] ^L Internet Draft Network Address + Protocol Translator November 1998

1 0

(IPng 6724) I-D ACTION:draft-ietf-ipngwg-router-renum-06.txt (fwd)
by Thomas Trede 13 Nov '98

13 Nov '98

FYI. Regards, Thomas Trede ---------- Forwarded message ---------- Date: Wed, 11 Nov 1998 09:49:19 -0500 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 6724) I-D ACTION:draft-ietf-ipngwg-router-renum-06.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 : Router Renumbering for IPv6 Author(s) : M. Crawford Filename : draft-ietf-ipngwg-router-renum-06.txt Pages : 23 Date : 10-Nov-98 IPv6 Neighbor Discovery and Address Autoconfiguration conveniently make initial assignments of address prefixes to hosts. Aside from the problem of connection survival across a renumbering event, these two mechanisms also simplify the reconfiguration of hosts when the set of valid prefixes changes. This document defines a mechanism called Router Renumbering ('RR') which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used by and advertised by IPv6 routers throughout a site. 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-router-renum-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-router-renum-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.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-router-renum-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

(ngtrans) I-D ACTION:draft-ietf-ngtrans-siit-03.txt (fwd)
by Thomas Trede 13 Nov '98

13 Nov '98

FYI. Regards, Thomas Trede ---------- Forwarded message ---------- Date: Wed, 11 Nov 1998 09:54:35 -0500 From: Internet-Drafts(a)ietf.org Reply-To: ngtrans(a)sunroof.Eng.Sun.COM To: IETF-Announce:;;;;@ns.cnri.reston.va.us;@Eng.Sun.COM;;; Cc: ngtrans(a)sunroof.Eng.Sun.COM Subject: (ngtrans) I-D ACTION:draft-ietf-ngtrans-siit-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Generation Transition Working Group of the IETF. Title : Stateless IP/ICMP Translator (SIIT) Author(s) : E. Nordmark Filename : draft-ietf-ngtrans-siit-03.txt Pages : 23 Date : 10-Nov-98 This document specifies a transition mechanism in addition to those already specified in RFC 1933. The new mechanism can be used as part of a solution that allows IPv6 hosts that do not have a permanently assigned IPv4 address to communication with IPv4-only hosts. 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-ngtrans-siit-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ngtrans-siit-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.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-ngtrans-siit-03.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

(ngtrans) W.G. Last Call on 6Bone Routing Practice" (fwd)
by Thomas Trede 13 Nov '98

13 Nov '98

FYI. Regards, Thomas Trede ---------- Forwarded message ---------- Date: Mon, 09 Nov 1998 17:35:59 -0800 From: Bob Fink <rlfink(a)lbl.gov> Reply-To: ngtrans(a)sunroof.Eng.Sun.COM To: ngtrans(a)sunroof.Eng.Sun.COM Cc: Tony Hain <tonyhain(a)microsoft.com>, Harald Tveit Alvestrand <Harald.Alvestrand(a)maxware.no> Subject: (ngtrans) W.G. Last Call on 6Bone Routing Practice" This is an NGtrans working group last call for comments on advancing the following document as an Informational RFC: Title : 6Bone Routing Practice Author(s) : B. Buclin, A. Durand Filename : draft-ietf-ngtrans-6bone-routing-01.txt Pages : 8 Date : 20-May-98 Please send substantive comments to the ngtrans mailing list, and minor editorial comments to the authors. This last call period will end two week from today on November 23, 1998. Bob Fink/ Tony Hain http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-6bone-routing-01.txt

1 0

(IPng 6743) I-D ACTION:draft-ietf-ipngwg-bsd-api-new-04.txt (fwd)
by Thomas Trede 13 Nov '98

13 Nov '98

FYI. Regards, Thomas Trede ---------- Forwarded message ---------- Date: Fri, 13 Nov 1998 10:45:03 -0500 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 6743) I-D ACTION:draft-ietf-ipngwg-bsd-api-new-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 : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens Filename : draft-ietf-ipngwg-bsd-api-new-04.txt Pages : 33 Date : 12-Nov-98 The de facto standard application program interface (API) for TCP/IP applications is the 'sockets' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. 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-bsd-api-new-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-bsd-api-new-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.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-bsd-api-new-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