[Saad] Some initiating thoughts...

As an initial contribution to this discussion list, I'm
attaching a pre-draft that was prepared by IAB member Mark Handley as
a result of reviewing the material of the IAB's Open Architecture
meeting in Vienna.

As noted in the text -- this is a first draft of thinking.  While
the IAB hasn't yet decided if this should be pursued as an IAB
document, we thought it would be a useful discussion starting point
for this mailing list.

Leslie,
for the IAB.

--------

Internet Engineering Task Force                                      IAB
INTERNET-DRAFT                                         Mark Handley (ed)
draft-iab-addressing-2003815.txt                          15 August 2003
$Revision: 1.1 $                                  Expires: NOT PUBLISHED

                 Architectural Issues with IP Addressing

1.  Introduction

This document examines a range of architectural issues related to IP
addressing.  The motivation is that we perceive that a number of
significant requirements are not being met by the currently deployed
addressing architecture.  In this document we do not attempt to find
solutions to these problems; our goal is merely to collect the
requirements to permit a reasoned discussion of solutions to take place.
The initial content in this document was drawn from the proceedings of
an Open IAB Meeting, held at the 57th IETF in Vienna in July 2003.

2.  Background

IP addresses have served both as a means of uniquely identifying a
device interface that is attached to a network (an endpoint identifier),
and as a means of identifying where a device is located within the
network (a forwarding or routing identifier).

IPv4 has two address types:

o Unique addresses, which are normally global-use.

o Private addresses [1], which are for local-use internets.

Although it is not strictly required, the IPv4 address architecture
largely assmed a unique binding of a device interface to an IP address.
Essentially this means a device interface existed as a member of a
single addressing realm.  Private addresses were not originally intended
to be connected to the global Internet, but the use of Network Address
Translators has since become commonplace.  A NAT enables limited
communication between a host with a private address and hosts outside of
its local-use internet.  However NATs raise a large number of
architectural problems in the way they do this [2].

Handley                                             Section 2.  [Page 1]

INTERNET-DRAFT           Expires: NOT PUBLISHED              August 2003

In contrast, IPv6 defined three address types:

o Unique addresses, which are normally global-use.

o Site-Local addresses, which are for scoped local-use internets.

o Link-Local addresses, which are for very local use.

The IPv6 address architecture explicitly explored the potential of
explicitly 'scoped' address realms coexisting with a global realm.  Thus
a device interface may have a globally unique address, a site-local
address, and a link-local address simultaneously, and use them for
different communications.  At the time this model was devised, it was
not entirely clear how this would work in practice, what architectural
issues it addressed, and what new issues it raises.

As IPv6 has moved into deployment, it has become clear that the
complexity issues raised by the new addressing architecture, and in
particular by the use of site-local addresses, are not negligable.  Thus
it behooves us to re-examine the requirements for Internet addressing in
the light of more recent experience.

3.  IP Addressing Requirements

The Internet is a complex and heterogeneous network, and becoming more
heterogeneous as time goes on.  Different people and different
subsystems in the network have different requirements on the addressing
architecture; this is a classic example of a "tussle space" [3] between
conflicting demands.

3.1.  Addressing Requirements of Routing

The structure of the address space should minimize the number of routing
table entries.  This is an issue both due to the sheer size of the
forwarding table, and due to the rate of change of the forwarding table.
Ideally the addressing architecture should allow for significant
information hiding, such that the number of forwarding entries and
number of updates to the forwarding table both scale O(log(n)) or better
in number of connected subnets.

Routing convergence times are dependent on the underlying topology of
the network, on the routing protocols in use, and on the suitability of
the addressing architecture for information hiding.  Thus the structure
of the address space should be suitable for minimizing routing
convergence times.

Handley                                           Section 3.1.  [Page 2]

INTERNET-DRAFT           Expires: NOT PUBLISHED              August 2003

Forwarding performance cannot be neglected.  Any address structure must
permit efficient route lookup operations at backbone speeds.  Secondary
requirements here might also include multipath routing for load
balancing purposes, and QoS-based scheduling [4].

Site multihoming is becoming commonplace, and should be regarded as
being a nearly ubiquitous requirement in the future.  The address
architecture should provide support for multihoming, while
simultaneously satisfying the requirements above.

Mobility of both hosts and networks is likely to be a significant
requirement in the future.  While host mobility can be handled with
solutions such as Mobile IP, this still imposes requirements on the
address architecture related to moving between addressing realms.
Network mobility imposes stronger requirements on addressing
architecture, related to both disconnected operation and to the process
of reconnecting to a new network attachment point without disrupting
ongoing communications with the mobile network.  While we do not see too
many mobile networks in the current Internet, it is highly likely that
there they will be a significant presense in the future.

3.2.  Addressing Requirements of Enterprises

A key requrirement of enterprises with regard to addressing is
independence from their ISPs.  To ensure good service from their ISP
that matches their needs, an enterprise needs to be able to change ISP
relatively easily.  However, if an enterprise's internal network is
numbered out of their ISP's address space then they need to renumber
their internal network when changing ISP.  As site-renumbering is
considered painful and costly, this leads to provider lock-in which is
clearly undesirable from the enterprise's point of view.

Additional enterprise requirements include the ability to multi-home
important hosts, server virtualization, and server load balancing.  All
of these may impact addressing architectures in different ways.

Security is clearly a major concern for enterprises, and an important
requirement is to be able to perform some degree of traffic isolation at
security domain boundaries.  While this is really the task of a
firewall, there is a widespread view that the use of RFC 1918 private
IPv4 addresses when combined with a SOCKS firewall or a NAT is an
effective mechanism for enhancing traffic isolation.  We note that the
use of private addresses with a NAT instead of a correctly configured
firewall has significant shortcomings from a security point of view, but
it does have the advantage of being very simple to set up.

Handley                                           Section 3.2.  [Page 3]

INTERNET-DRAFT           Expires: NOT PUBLISHED              August 2003

Irrespective of the technology used to accomplish it, the specific
security requirement that enterprises have on addressing is that it
should be easy to set up a well-known and well-understood filter at
security boundaries that reduces the exposure profile from individual
configuration errors.

Some enterprises have addressing requirements caused by the need to set
up inter-enterprise Virtual Private Networks (VPNs).  Also, at some
point in their existence most enterprises undergo some form of merger or
acquisition, and discover that they need to merge internal networks.  In
both these circumstances there is a requirement to avoid the need to
renumber or to suffer from ambiguous addressing resulting from the
merger of two private address spaces.

3.3.  Addressing Requirements of Consumers

As networking equipment becomes ubiquitous, an increasing fraction of
networks will be owned and operated by people with minimal technical
skills.  The primary requirement that these users have is that
addressing is autoconfiguring (or at the very least, trivial to
configure).  The user must not have to explicitly register their network
addresses.  Their network must function when first set up while being
dsiconnected from the global Internet, and must permit later and
intermittent commectivity without disrupting local communications.
Consumer appliances must be able to ship with appropriate defaults so
that they work "out of the box".  At the same time, their default
exposure to attack and denial-of-service needs to be minimalized.

A key requirement on addressing is that much of this consumer equipment
(printers, light switches, etc) needs to be able to communicate locally
without being directly exposed to the global Internet.  At the same time
the same network infrastructure will be used by devices that do need
global Internet access.

3.4.  Addressing Requirements of Transport Protocols, Middleware and
Applications

Transport protocols including TCP and security associations may use the
endpoint's IP address as an endpoint identifier.  In the case of TCP,
the binding is a loose one - so long as the IP address in incoming
packets doesn't change during the connection lifetime, then TCP is
happy.  Other protocols may have more stringent requirements requiring
both endpoints to have the same understanding of each other's addresses.

Other protocols including SCTP may be address-agile.  The transport
association may be with multiple addresses rather than a single one,

Handley                                           Section 3.4.  [Page 4]

INTERNET-DRAFT           Expires: NOT PUBLISHED              August 2003

permitting failover.  Alternatively this may be done at the middleware
or application layers.

If each endpoint has multiple addresses, the transport, middleware or
application layer has the complex problem of choosing the correct pair
of addresses to enable communication.  There are two conflicting goals
here:

o To guarantee reachability between the endpoints.

o To ensure that the traffic stays within the tightest possible
   administrative and security boundaries.

Non-globally unique addresses present a particular problem.  Essentially
this is a routing problem, but one that must be solved above the network
layer.

Some applications have a requirement to support third-party references
to addresses across both space and time.  The simplest example is ftp,
which uses the control channel to communicate the IP addresses to use
for the data channel.  However, while third-party ftp is rare, the
problem is a more significant one for signalling protocols such as SIP
[5] and RTSP [6]. Such protocols by their nature set up a signalling
channel first, then initiate additional data channels.  The need to do
user-location with SIP or server load-balancing with RTSP means that it
is commonplace for the initial control channel to be set up between
different hosts than the final data channels, and so there is an
inherent need to signal the identities of the end-systems that should
comprise the data channel.  While it may be safer to pass domain names
instead of IP addresses in such cases, this may not always be possible.

Finally, most applications would really prefer to never see addresses at
all.  They should not need to care whether a communiation is between
IPv4 addresses, IPv6 addresses, or a mixture of the two.

Notes

Intermittently committed nets (ships, planes).

4.  References

[1] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear,
      "Address Allocation for Private Internets", RFC 1918, February
      1996.

Handley                                             Section 4.  [Page 5]

INTERNET-DRAFT           Expires: NOT PUBLISHED              August 2003

[2] B. Carpenter, "Internet Transparency", RFC 2775, February 2000.

[3] David D. Clark, John Wroclawski, Karen R. Sollins, Robert Braden,
      "Tussle in Cyberspace: Defining Tomorrow's Internet", Proc. ACM
      SIGCOMM 2002.

[4] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the
      Differentiated Services Field (DS Field) in the IPv4 and IPv6
      Headers", RFC 2474, December 1998.

[5]

[6]

Handley                                             Section 4.  [Page 6]

_______________________________________________
Saad mailing list
Saad@ietf.org
https://www1.ietf.org/mailman/listinfo/saad