Internet Draft Submission
Tony Hain
tonyhain@microsoft.com
Mon, 4 Nov 1996 14:56:56 -0800
Quaizar,
While I will be glad to make time for discussing this on the agenda in
San Jose, I would like to warn you now that I think you are headed off
course with this paper. It appears you are retracing some old ground and
are trying to minimize the work to implement the software rather than
the work to implement the network. A few specific issues:
I don't see any place in draft-ietf-ipngwg-ipv6-tunnel-04.txt that talks
about V6 over V4 tunnels. What it is defining are encapsulations over V6
tunnels. In fact you should be looking at RFC1701 for use of V4 as a
tunnel media.
Trying to prohibit a V4 compatible address from communicating with a V6
only address increases the complexity since the node with the V4
compatible address will have to have another V6 only address to talk to
the desired destination.
I don't see the distinction between your Class 1 & 2 end systems in
terms of address usage. Any isolated node will need a V4 address to get
across that media. If it does not build an RFC1701 tunnel to its next
hop it will need a V4 compatible V6 address, otherwise any V6 address
should work.
Also, use of automatic tunnels does not imply that the entire Internet
has to use V4 compatible addresses. Only the systems which wish to
communicate with each other directly need this. What the automatic
tunneling systems need is a configured default V6 router which will get
them to non-V4 addressable destinations.
Finally, manually configured tunnels will be an administrative reality
for network management and diagnostics. Trying to push automatic
tunneling into these environments will only delay the roll out of V6.
Tony
PS: I guess I have been disconnected from the NGTRANS mailer since I
moved to Microsoft. I just assumed the list had gone dormant. If there
are issues in the deployment that are restricting progress we should
make sure they are talked about in San Jose.
>----------
>From: qv@iol.unh.edu[SMTP:qv@iol.unh.edu]
>Sent: Monday, November 04, 1996 12:57 PM
>To: internet-drafts@ietf.org
>Cc: Tony Hain; gilligan@free-gate.com; dan@lkg.dec.com; qv@sun4.iol.unh.edu
>Subject: Internet Draft Submission
>
>Dear Editor,
> We wish to submit an internet draft to the ngtrans working
>group. Please forward all the correspondance to my e-mail address as
>my co-author would be temporarily off the net.
>
>Thanks,
>Quaizar
>
>Quaizar Vohra
>Inter-Operatibility Lab. (IOL), Univ. of New Hampshire
>E-mail : qv@sun4.iol.unh.edu
>Phone : (603)-862-0090
>
>----------------------------------------------------------------
>IPng Transition Dan Harrington
>Internet Draft Digital Equipment Corp.
> Quaizar Vohra
> University of New Hampshire
> November 1996
>
> Limiting the role of IPv4-compatible Addresses in IPv6
>
> draft-harrington-ngtrans-v4comp-00.txt
>
>Abstract
>
> This draft presents a proposal to limit IPv4-compatible IPv6
> addresses to tunnelling interfaces in the transition from IPv4 to
> IPv6. The reasons and context for restricting the usage in this
> manner will be presented.
>
>Status of This Memo
>
> This document is a submission to the NGtrans Working Group of the
> Internet Engineering Task Force (IETF). Comments should be
> submitted to the ngtrans@sunroof.end.sun.com mailing list. The
> authors invite discussion and feedback on this topic.
>
> 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).
>
> Distribution of this document is unlimited.
>
>
>Table Of Contents
>
> 1. Introduction 3
> 2. Architectural and Philosophical Issues 3
> 3. Isolated Hosts 4
> 3.1. Class 1 Isolated Nodes 4
> 3.2. Class 2 Isolated Nodes 4
> 4. Other Issues 5
> 4.1. Host Issues 5
>
>Expires May 1997 [Page 1]
>
>Internet Draft IPv4-compatible Addresses November 1996
>
> 4.2. Router Issues 5
> 5. Acknowledgements 6
> 6. References 6
> 7. Author's Addresses 6
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Expires May 1997 [Page 2]
>
>Internet Draft IPv4-compatible Addresses November 1996
>
>1. Introduction
>
> IPv4-compatible addresses are designed to ease the transition of
> IPv4 to IPv6, by utilizing the readily available IPv4 address space
> and protocols to provide IPv6 connectivity. They currently serve
> two roles, both related to tunnelling:
>
> - To allow isolated IPv6 nodes to come up on the Internet
> and communicate with other IPv6 nodes via automatic tunneling,
> which requires a minimal amount of configuration.
>
> - Identifying an IPv6 router's next-hop interface address over
> a manually configured tunnel.
>
> These tasks both require implementations to treat an IPv4 tunnel as
> a pseudo-NBMA link, where ::/96 is treated as an on-link IPv6 prefix
> for the tunnel interface. In this model, all IPv4-compatible
> addresses are on-link to the tunnel interface and the IPv4 Internet
> forms one large link layer, in which address resolution is a trivial
> function. Manually configured tunnels are used with static routes to
> IPv6 prefixes, where the next-hop is an IPv4-compatible address on
> the link. While this link type does not use the standard link-local
> prefix of FE80:: or Neighbor Discovery protocols, it does have its
> own characteristics and rules [V6TUNNELS]. Conceptually, then, it
> can be seen that IPv6 packets using IPv4-compatible addresses could
> be treated as using a special type of link-local address, and the
> Hop Limit could be set to a value of 1 with no dire consequences.
>
> The current Transition Mechanisms specification [RFC1933], however,
> also include a provision to allow an IPv4-compatible address to be
> assigned to an interface for native IPv6 communications, with all
> the requirements of Neighbor Discovery. It is this usage which we
> wish to prohibit, for the sake of reduced complexity and increased
> interoperability.
>
>2. Architectural and Philosophical Issues
>
> Although IPv4 and IPv6 represent different network protocols, IPv4
> addresses can be represented as IPv6 addresses. However, they still
> define an IPv4 endpoint, that is, an interface on a link connected
> to an IPv4 network, using IPv4 protocols. Using them in multiple
> fashions, for both IPv4 and IPv6 packets on a given interface as
> well as for tunnelling, can and will lead to interoperability
> problems, as has been reported on the NGTRANS mailing list [NGLIST].
> This dual usage also leads to unnecessary implementation complexity;
> for example, the source address selection algorithm should not
> permit the use of an IPv4-compatible address (as source or
> destination) with a global IPv6 address (as destination or source).
>
> As mentioned above, the encapsulation of IPv6 packets in IPv4
> packets essentially uses the IPv4 network as a specialized media
> type. The "Generic Packet Tunneling in IPv6" [V6TUNNELS]
> specification gives the mechanism by which one protocol may be run
> over another. In keeping with the general IP philosophy of an
>
>
>Expires May 1997 [Page 3]
>
>Internet Draft IPv4-compatible Addresses November 1996
>
> address being associated with a particular interface [RFC1122], it
> should be held that a tunnel interface is not merely an abstraction,
> but a "real" interface to a specific media type, with its own rules
> and behaviours.
>
> Finally, restricting the usage of IPv4-compatible addresses will
> simplify the definition, implementation, and usage of this address
> form, and smooth the IPv4 to IPv6 transition. Simple, clear
> definitions are easy to explain; special cases and asterisks are
> not. If IPv6 is to be widely accepted and deployed, the training
> and educational aspects of the architecture must not be ignored.
>
>3. Isolated Hosts
>
> Two interpretations of the term "Isolated Host" have been proposed
> in the course of discussing IPv4-compatible address usage. Both are
> presented below, and hopefully these definitions can be clarified,
> and consensus reached, through further discussion.
>
>3.1. Class 1 Isolated Nodes
>
> The first interpretation of an isolated host is a host which does
> not have an on-link IPv6 router, and which thus must encapsulate all
> packets to off-link destinations. But this node is connected to an
> IPv6-capable Internet Service Provider (ISP) and thus has a provider
> based IPv6 address [RFC1897][V6PROVIDER], which we will refer to as
> PBA. This PBA is assigned to the tunnel interface and is used as
> source address in outgoing packets. The node has a manually
> configured tunnel to an ISP router. This PBA is based upon the ISP's
> prefix and the IPV4 address of the IPv4 interface through which the
> encapsulated packets get forwarded to the ISP. Note that the
> IPv4-compatible might be usable as the link-local address in a
> routing protocol, but this is yet to be determined.
>
> So this isolated node has global IPv6 connectivity via the ISP. This
> isolated node has a default IPv6 route (::/0) with the ISP router as
> next-hop, which may be identifed by an IPv4-compatible address.
> Examples of this class of isolated node can be found on the current
> 6-bone. [6BONE]
>
>3.2. Class 2 Isolated Nodes
>
> The second form of isolated nodes are those nodes which are not
> connected to an IPv6-capable ISP, i.e. they don't have a PBA. All
> they have is an IPv4-compatible address and they communicate with
> other IPv6 nodes which have IPv4-compatible addresses using
> end-to-end automatic tunneling. This requires that the destination
> node also has an IPv4-compatible address, and implies that the
> packet will make a single hop (i.e. the IPv6 packet will not be
> forwarded).
>
> In the evolution of the 6bone, the second class of host is not
> represented. It remains to be seen how common this type of host
> will be as IPv6 is deployed commercially. For these nodes to
>
>
>Expires May 1997 [Page 4]
>
>Internet Draft IPv4-compatible Addresses November 1996
>
> communicate with other IPv6 nodes on the Internet, the remote IPv6
> system must have automatic tunneling enabled on every IPv6 node on
> the Internet. At some point in transition, when the IPv4 address
> space is exhausted, new IPv6 nodes will not be able to get
> IPv4-compatible addresses to do automatic tunneling. These nodes
> will only have PBAs and would not be able to communicate with class
> 2 isolated nodes. So while this class of system represents a simple
> configuration, it can be seen that from the beginning these nodes
> may only be able to communicate with a subset of the IPv6 network,
> and the percentage of unreachable hosts will likely increase over
> time. Also, the extensive use of IPv4-compatible addresses for
> communications between IPv6 systems will exercise the IPv4 routing
> infrastructure, without promoting the use of IPv6 hierarchical
> routing, thereby taxing an overburdened service without any gain in
> operational experience in the new technology.
>
>4. Other Issues
>
> One important issue is whether IPv4-compatible addresses should be
> assigned to all physical interfaces having IPv4 addresses. We
> believe that this is not a good idea as it creates several problems
> without being a solution for any existing problem. There are other
> issues to consider as well.
>
> Another disadvantage is that IPv4-compatible addresses will have to
> be treated specially in name services like DNS and DHCP, with
> duplication of data and potential operational confusion resulting.
>
>4.1. Host Issues
>
> Hosts may have to deal with multiple mechanisms for obtaining
> addresses, and support dual address lifetime (or lease) constructs.
> While DHCP is commonly used to obtain IPv4 addresses, DHCPv6 does
> not support the assignment of IPv4-compatible addresses, and thus
> the server will not recognize such addresses as belonging to any
> given client. [DHCPv6]
>
> Also, assigning an IPv4-compatible address to the interface on which
> IPv4 is running may not be generally possible. For example, an IPv4
> host using SLIP could support an IPv6 implementation using
> tunnelling, but not a native interface. There may be other examples
> of media types which support one protocol but not the other.
>
>4.2. Router Issues
>
> In addition to the issues presented above, which focus largely on
> the impact to IPv6 hosts, there are various concerns related to dual
> IPv6/IPv4 routers. In the current RFC 1933 model, dual protocol
> routers at the borders of IPv6 islands may be called upon to perform
> routing of packets using IPv4-compatible source and destination
> addresses. There are several reasons why this is not a good idea:
>
> - While encapsulation of IPv6 packets in IPv4 tunnels will be a
> necessary function of dual IPv4/IPv6 routers, it would be best
>
>
>Expires May 1997 [Page 5]
>
>Internet Draft IPv4-compatible Addresses November 1996
>
> to reduce the need for this function by having the originating
> host use automatic tunnelling.
>
> - The routers may have greater memory requirements than otherwise.
> See the draft "IPv6 Routing Table Issues" [RJA] for details.
>
>5. Acknowledgements
>
> The authors wish to thank Pedro Roque, Jim Bound, Ran Atkinson, Bill
> Lenharth and Matt Thomas for their input and consideration, as well
> as the growing community of IPv6 developers.
>
>6. References
>
> [RFC1933] R. Gilligan, E. Nordmark, "Transition Mechanisms for
> IPv6 Hosts and Routers", RFC 1933, April 1996.
>
> [V6TUNNELS] A. Conta, S. Deering, "Generic Packet Tunneling in IPv6",
> <draft-ietf-ipngwg-ipv6-tunnel-04.txt>, Work in Progress,
> October 1996.
>
> [RFC1122] R. Braden, "Requirements for Internet Hosts - Communication
> Layers", RFC 1122, October 1989.
>
> [NGLIST] Interoperability problem described on ngtrans mailing
> list, Wednesday March 13, 1996.
>
> [RFC1897] R. Hinden, "IPv6 Testing Address Allocation", RFC 1897,
> January 1996.
>
> [V6PROVIDER] Y. Rekhter et al, "An IPv6 Provider-Based Unicast Address
> Format", <draft-ietf-ipngwg-unicast-addr-fmt-04.txt>,
> Work in Progress, March 1996.
>
> [6BONE] http://www-cnr.lbl.gov/6bone
>
> [DHCPv6] J. Bound, C. Perkins, "Dynamic Host Configuration Protocol
> for IPv6 (DHCPv6)", <draft-ietf-dhc-dhcpv6-07.txt>,
> Work in Progress, August 1996.
>
> [RJA] R. Atkinson, "IPv6 Routing Table Size Issues",
> <draft-ietf-ipngwg-ipv6-routing-00.txt>, Work in
> Progress, October 1996.
>
>7. Author's Addresses
>
>
> Dan Harrington
> P.O. Box 81W
> W. Townsend, MA
>
> Quaizar Vohra
> Interoperability Lab
> 7 Leavitt Lane
>
>
>Expires May 1997 [Page 6]
>
>Internet Draft IPv4-compatible Addresses November 1996
>
> University of New Hampshire
> Durham, NH 03824
> qv@iol.unh.edu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Expires May 1997 [Page 7]
>