Subject: (ngtrans) SIIT -05 forwarding for Experimental RFC

From: Bob Fink <[email-masked]>
Date: Thu, 28 Jan 1999 18:08:26 -0800

NGtrans folk:

Erik Nordmark has submitted SIIT version -05 based on comments during the
Experimental RFC "last call". 

	<draft-ietf-ngtrans-siit-05.txt>

The diff of -04 and -05 is below (thanks Erik).  As this is to be submitted
to Harald/IESG for Experimental RFC processing, please make any comments by
February 11, after which it will be considered as forwarded (pending
comments of course).

Thanks,

Bob

===
>Date: Thu, 28 Jan 1999 09:21:34 -0800 (PST) 
>From: Erik Nordmark <[email-masked]> 
>Subject: Re: (ngtrans) comments on SIIT 04 
>To: Bob Fink <[email-masked]> 
>Cc: "Harald Alvestrand (outlook)" <[email-masked]>, 
>        Erik Nordmark <[email-masked]>, 
>        Bert Wijnen <[email-masked]>, Tony Hain <[email-masked]> 
>
>I just submitted -05 with updated references and some editorial fixes.
>(When the draft introduced ipv4-translatable addresses a while back to
>avoid using ipv4-compataible address the introductory material didn't
>get fixed.)
>
>
>I've attached the diff for the nroff source so that you can guage what
>you want to do with the draft.
>
>
>   Erik
>
>
>
>------- header-trans.nr -------
>*** /tmp/dV2aaTj        Thu Jan 28 09:15:51 1999
>--- header-trans.nr     Thu Jan 28 09:11:53 1999
>***************
>*** 10,20 ****
>  .nr FF 3
>  .nr PI 3n
>  .in 3n
>! .ds LF draft-ietf-ngtrans-siit-04.txt
>  .ds RF [Page %]
>  .ds CF
>  .ds CH Stateless IP/ICMP Translator (SIIT)
>! .ds RH December 1998
>  .ds LH INTERNET-DRAFT
>  .ad l
>  .hy 0
>--- 10,20 ----
>  .nr FF 3
>  .nr PI 3n
>  .in 3n
>! .ds LF draft-ietf-ngtrans-siit-05.txt
>  .ds RF [Page %]
>  .ds CF
>  .ds CH Stateless IP/ICMP Translator (SIIT)
>! .ds RH January 1999
>  .ds LH INTERNET-DRAFT
>  .ad l
>  .hy 0
>***************
>*** 33,39 ****
>  ..
>  .nf
>  .tl 'INTERNET-DRAFT''Erik Nordmark, Sun Microsystems'
>! .tl 'December 14, 1998'
>  .fi
>  .sp 2
>  .fi
>--- 33,39 ----
>  ..
>  .nf
>  .tl 'INTERNET-DRAFT''Erik Nordmark, Sun Microsystems'
>! .tl 'January 28, 1999'
>  .fi
>  .sp 2
>  .fi
>***************
>*** 40,46 ****
>  .ce 2
>  Stateless IP/ICMP Translator (SIIT)
>  .sp 1
>! <draft-ietf-ngtrans-siit-04.txt>
>  .sp 2
>  .ne 4
>  .ti -3
>--- 40,46 ----
>  .ce 2
>  Stateless IP/ICMP Translator (SIIT)
>  .sp 1
>! <draft-ietf-ngtrans-siit-05.txt>
>  .sp 2
>  .ne 4
>  .ti -3
>***************
>*** 63,69 ****
>  
>  Distribution of this memo is unlimited.
>  
>! This Internet Draft expires June 14, 1999.
>  .sp 3
>  .ti -3
>  Abstract
>--- 63,69 ----
>  
>  Distribution of this memo is unlimited.
>  
>! This Internet Draft expires July 28, 1999.
>  .sp 3
>  .ti -3
>  Abstract
>***************
>*** 135,142 ****
>  protocol specific and it is also less robust since a the ALG box is
>  likely to be a single point of failure for a connection using that box.
>  
>! If there IPv4 routing is supported inside the cloud and the implementations
>! support both IPv6 and IPv4 it might suffice to
>  have a mechanism for allocating temporary IPv4 and use IPv4 end to end
>  when communicating with IPv4-only nodes.  However, it would seem that
>  such a solution would require the pool of temporary IPv4 addresses
>--- 135,142 ----
>  protocol specific and it is also less robust since a the ALG box is
>  likely to be a single point of failure for a connection using that box.
>  
>! Otherwise, if there IPv4 routing is supported inside the cloud and the
>! implementations support both IPv6 and IPv4 it might suffice to
>  have a mechanism for allocating temporary IPv4 and use IPv4 end to end
>  when communicating with IPv4-only nodes.  However, it would seem that
>  such a solution would require the pool of temporary IPv4 addresses
>***************
>*** 148,158 ****
>  This document specifies a
>  mechanism by which IPv6-only nodes can interoperate with IPv4-only nodes
>  by having the IPv6-only nodes somehow acquire a temporary IPv4 address.
>! That IPv4 address will be used as an IPv4-compatible IPv6 address 
>  and the packets will travel through a stateless IP/ICMP translator
>  that will translate the packet headers between IPv4 and IPv6 and translate
>  the addresses in those headers between IPv4 addresses on one side
>! and IPv4-compatible or IPv4-mapped IPv6 addresses on the other side.
>  
>  This specification does not cover how an IPv6 node can acquire a
>  temporary IPv4 address and how such a temporary address be registered in
>--- 148,158 ----
>  This document specifies a
>  mechanism by which IPv6-only nodes can interoperate with IPv4-only nodes
>  by having the IPv6-only nodes somehow acquire a temporary IPv4 address.
>! That IPv4 address will be used as an IPv4-translated IPv6 address 
>  and the packets will travel through a stateless IP/ICMP translator
>  that will translate the packet headers between IPv4 and IPv6 and translate
>  the addresses in those headers between IPv4 addresses on one side
>! and IPv4-translated or IPv4-mapped IPv6 addresses on the other side.
>  
>  This specification does not cover how an IPv6 node can acquire a
>  temporary IPv4 address and how such a temporary address be registered in
>***************
>*** 159,165 ****
>  the DNS.  The DHCP protocol, perhaps with some extensions, could probably
>  be used to acquire temporary addresses with short leases but that is
>  outside the scope of this document.  The mechanism for routing this
>! temporary IPv4 address (or the IPv4-compatible IPv6 address) in the site
>  is currently not specified in this document.
>  
>  The figures below show how the Stateless IP/ICMP Translator (SIIT)
>--- 159,165 ----
>  the DNS.  The DHCP protocol, perhaps with some extensions, could probably
>  be used to acquire temporary addresses with short leases but that is
>  outside the scope of this document.  The mechanism for routing this
>! IPv4-translated IPv6 address in the site 
>  is currently not specified in this document.
>  
>  The figures below show how the Stateless IP/ICMP Translator (SIIT)
>***************
>*** 233,242 ****
>  function as the nodes listed in the source route are traversed and the
>  IPv6 routing header does not include the record route aspect.  Also,
>  the usefulness of source routing when going through a header translator
>! might be limited since all the routers would need to have an IPv4
>! address (or an IPv4-compatible IPv6 address) 
>! since the IPv4-only node will send a source option containing only
>! IPv4 addresses.
>  
>  At first sight it might appear that the IPsec functionality [IPv6-SA,
>  IPv6-ESP, IPv6-AH] can not be carried across the translator.  However,
>--- 233,241 ----
>  function as the nodes listed in the source route are traversed and the
>  IPv6 routing header does not include the record route aspect.  Also,
>  the usefulness of source routing when going through a header translator
>! might be limited since all the IPv6-only routers would need to have
>! an IPv4-translated IPv6 address since the IPv4-only node will send a
>! source route option containing only IPv4 addresses.
>  
>  At first sight it might appear that the IPsec functionality [IPv6-SA,
>  IPv6-ESP, IPv6-AH] can not be carried across the translator.  However,
>***************
>*** 282,294 ****
>  In order to take advantage of translators such a node should instead
>  send an IPv6 packet where the destination address is the IPv4-mapped
>  address and the source address is the nodes temporarily assigned
>! IPv4-compatible address.  If the node does not have a temporarily
>! assigned IPv4-compatible address it should acquire one using mechanisms
>  that are not discussed in this document.
>  
>! Note that the above also applies to a dual implementation node
>! which is not configured with
>! any IPv4 address.
>  
>  There are no extra changes needed to applications to operate
>  through a translator.  The applications that have been modified to work
>--- 281,292 ----
>  In order to take advantage of translators such a node should instead
>  send an IPv6 packet where the destination address is the IPv4-mapped
>  address and the source address is the nodes temporarily assigned
>! IPv4-translated address.  If the node does not have a temporarily
>! assigned IPv4-translated address it should acquire one using mechanisms
>  that are not discussed in this document.
>  
>! Note that the above also applies to a dual IPv4/IPv6 implementation node
>! which is not configured with any IPv4 address.
>  
>  There are no extra changes needed to applications to operate
>  through a translator.  The applications that have been modified to work
>***************
>*** 355,362 ****
>  Addresses\fR
>  
>  In addition to the forms of addresses defined in [ADDR-ARCH] this document
>! also introduces the new form of IPv4-translated address to avoid using
>! IPv4-compatible addresses outside the intended use of automatic tunneling.
>  Thus the address forms are:
>  .in +16
>  .sp
>--- 353,361 ----
>  Addresses\fR
>  
>  In addition to the forms of addresses defined in [ADDR-ARCH] this document
>! also introduces the new form of IPv4-translated address.
>! This is needed to avoid using IPv4-compatible addresses outside the
>! intended use of automatic tunneling.
>  Thus the address forms are:
>  .in +16
>  .sp
>***************
>*** 933,945 ****
>  If the IPv6 source address is an IPv4-translated or an IPv4-mapped address
>  then the low-order 32 bits of the IPv6 source address is copied to
>  the IPv4 source address.
>! Otherwise, the source address is set to 127.0.0.1.
>  .sp
>  .ti -8
>  Destination Address:
>  .br
>! IPv6 packets that are translated have a destination address that is
>! either an IPv4-translated or an IPv4-mapped address.
>  Thus the low-order 32 bits of the IPv6 destination address is copied to
>  the IPv4 source address.
>  .in -16
>--- 932,945 ----
>  If the IPv6 source address is an IPv4-translated or an IPv4-mapped address
>  then the low-order 32 bits of the IPv6 source address is copied to
>  the IPv4 source address.
>! Otherwise, the source address is set to 127.0.0.1.  The use of 127.0.0.1
>! is to avoid completely dropping e.g. ICMPv6 error messages sent by
>! IPv6-only routers.
>  .sp
>  .ti -8
>  Destination Address:
>  .br
>! IPv6 packets that are translated have an IPv4-mapped destination address.
>  Thus the low-order 32 bits of the IPv6 destination address is copied to
>  the IPv4 source address.
>  .in -16
>***************
>*** 1158,1164 ****
>  .sp
>  .ti -8
>  [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol,
>! Version 6 (IPv6) Specification", RFC 1883, January 1996.
>  .sp
>  .ti -8
>  [IPv4] J. Postel, "Internet Protocol", RFC 791, September 1981.
>--- 1158,1164 ----
>  .sp
>  .ti -8
>  [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol,
>! Version 6 (IPv6) Specification", RFC 2460, December 1998.
>  .sp
>  .ti -8
>  [IPv4] J. Postel, "Internet Protocol", RFC 791, September 1981.
>***************
>*** 1165,1171 ****
>  .sp
>  .ti -8
>  [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6
>! Addressing Architecture", RFC 1884, January 1996.
>  .sp
>  .ti -8
>  [TRANS-MECH] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6
>--- 1165,1171 ----
>  .sp
>  .ti -8
>  [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6
>! Addressing Architecture", RFC 2373, July 1998.
>  .sp
>  .ti -8
>  [TRANS-MECH] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6
>***************
>*** 1173,1190 ****
>  .sp
>  .ti -8
>  [DISCOVERY] T. Narten, E. Nordmark, and W. Simpson, "Neighbor
>! Discovery for IP Version 6 (IPv6)", RFC 1970, August 1996.
>  .sp
>  .ti -8
>  [IPv6-SA] R. Atkinson.  "Security Architecture for the Internet
>! Protocol".  RFC 1825, August 1995.
>  .sp
>  .ti -8
>! [IPv6-AUTH] R. Atkinson.  "IP Authentication Header", RFC 1826, August 1995.
>  .sp
>  .ti -8
>  [IPv6-ESP] R. Atkinson.  "IP Encapsulating Security Payload (ESP)",
>! RFC 1827, August 1995.
>  .sp
>  .ti -8
>  [ICMPv4] J. Postel, "Internet Control Message Protocol", RFC 792,
>--- 1173,1190 ----
>  .sp
>  .ti -8
>  [DISCOVERY] T. Narten, E. Nordmark, and W. Simpson, "Neighbor
>! Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
>  .sp
>  .ti -8
>  [IPv6-SA] R. Atkinson.  "Security Architecture for the Internet
>! Protocol".  RFC 2401, November 1998.
>  .sp
>  .ti -8
>! [IPv6-AUTH] R. Atkinson.  "IP Authentication Header", RFC 2402, November 
>1998.
>  .sp
>  .ti -8
>  [IPv6-ESP] R. Atkinson.  "IP Encapsulating Security Payload (ESP)",
>! RFC 2406, November 1998.
>  .sp
>  .ti -8
>  [ICMPv4] J. Postel, "Internet Control Message Protocol", RFC 792,
>***************
>*** 1192,1199 ****
>  .sp
>  .ti -8
>  [ICMPv6] A. Conta, S. Deering, "Internet Control Message Protocol (ICMPv6)  
>! for the Internet Protocol Version 6 (IPv6)", RFC 1885,
>! January 1996. 
>  .sp
>  .ti -8
>  [IGMP] S. Deering, "Host extensions for IP multicasting", RFC 1112,
>--- 1192,1199 ----
>  .sp
>  .ti -8
>  [ICMPv6] A. Conta, S. Deering, "Internet Control Message Protocol (ICMPv6)  
>! for the Internet Protocol Version 6 (IPv6)", RFC 2463,
>! December 1998. 
>  .sp
>  .ti -8
>  [IGMP] S. Deering, "Host extensions for IP multicasting", RFC 1112,
>***************
>*** 1209,1215 ****
>  .ti -8
>  [DIFFSERV] K. Nichols, S. Blake, F. Baker, and D. L. Black, 
>  "Definition of the Differentiated Services Field (DS Field) 
>! in the IPv4 and IPv6 Headers", Internet Draft, October 1998.
>  .sp
>  .ti -8
>  [MLD] S. Deering, W. Fenner, and B. Haberman,
>--- 1209,1215 ----
>  .ti -8
>  [DIFFSERV] K. Nichols, S. Blake, F. Baker, and D. L. Black, 
>  "Definition of the Differentiated Services Field (DS Field) 
>! in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
>  .sp
>  .ti -8
>  [MLD] S. Deering, W. Fenner, and B. Haberman, 
-end