Internet DRAFT - draft-ietf-ipae-transition

draft-ietf-ipae-transition



Internet Engineering Task Force                         Robert E. Gilligan
INTERNET-DRAFT                                          Erik Nordmark
                                                        Bob Hinden
                                                        Sun Microsystems, Inc.
                                                        November 10, 1993


        IPAE: The SIPP Interoperability and Transition Mechanism



Abstract

The Internet is experiencing growing pains.  The phenomenal success of
TCP/IP -- the exponential growth in the size of the global IP-connected
Internet and the ever increasing number of systems deployed on isolated
networks running the Internet protocols -- is likely to bring about two
serious problems in the near future.  First, since the IP routing system
has little hierarchical structure it may not scale much above its
current size.  Secondly, since the 32-bit IP address space is assigned
in an inefficient manner, it may be exhausted within a few years.  These
problems have given rise to a number of proposals for revising the
Internet Protocol.  SIPP -- the Simple Internet Protocol Plus -- is one
proposal for a next generation Internet Protocol.

If SIPP, or any next generation IP, is to be successful, it must provide
an easy mechanism by which hosts and routers implementing the new
protocol can continue to interoperate with systems using the existing IP
version.  Also, there must be mechanism to transition the Internet to
the new protocol without disrupting operation of the Internet.  This
specification details both with the mechanisms by which SIPP systems
interoperate with those using the current version of IP, and the plan
for transitioning the IP-connected Internet to SIPP.  While specifically
cast in terms of SIPP, the IPAE techniques could be applied to the other
network layer protocol transitions as well.


Status of this Memo

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.
This Internet Draft expires on May 10, 1994.  Internet Drafts may be
updated, replaced, or obsoleted by other documents at any time. It is
not appropriate to use Internet Drafts as reference material or to
cite them other than as a "working draft" or "work in progress."



draft-ietf-sipp-ipae-transition-00.txt                          [Page 1]

INTERNET-DRAFT             IPAE Specification              November 1993



Please check the I-D abstract listing contained in each Internet Draft
directory to learn the current status of this or any other Internet
Draft.

Distribution of this memo is unlimited.


Acknowledgements

This document is the result of the efforts of three IETF working
groups -- the IPAE working group, the SIP working group, and the SIPP
working group -- over a period of more than a year.  The groups met a
number of times over this period and exchanged a great amount of
electronic mail.  A number of individuals made significant
contributions.  Bob Hinden devised the original IPAE encapsulation
scheme.  Dave Crocker brought the idea of global addresses to IPAE.
Steve Deering brought the idea of a simple new version IP.  And Paul
Francis contributed the advanced routing ideas of PIP.

The working groups have included contributions from: Craig Partridge
of BBN, Tom Kessler, Geoff Mulligan, Erik Nordmark, and Bob Gilligan
of Sun Microsystems, Greg Chesson, Ronald Jacoby, and and Rob Warnock
of Silicon Graphics, Hon Wah Chin and Dave Newman of Protocol Engines,
Ross Callon of Wellfleet, Mike Reilly of TGV, Virgil Champlin of
Digital Equipment, Michael Conn of MCI, John Moy of Proteon, John
Veizades of FTP software, Jeffrey Burgan of NASA, R. Govindan of
Bellcore, and Vince Fuller of BARRNET.

Thanks to all who provided feedback to the first revision of this
document, including Jim Bound, Jon Crowcroft, and (your name goes
here, after you send in your insightful comments and suggestions).



















draft-ietf-sipp-ipae-transition-00.txt                          [Page 2]

INTERNET-DRAFT             IPAE Specification              November 1993


        Status of this Memo
        Acknowledgements
        1. Introduction
                1.1. Organization
        2. Problem Statement
        3. The IPAE Solution
                3.1. IPAE Addressing
                3.2. IPAE Tunneling: SIPP within IPv4
                3.3. IPAE Host Operation
                3.4. IPAE Header Translation
        4. IPAE Routers
                4.1. Multiple Routing Domains
                4.2. Tunneling SIPP in IPv4
                4.3. Encapsulating SIPP in IPv4
                4.4. Decapsulating IPAE Packets
                4.5. Tracking the Tunnel State
                4.6. Generating ICMP Error Packets
        5. IPAE Translators
                5.1. Translating IPv4 to SIPP
                5.2. Mapping Table
                5.3. Translating SIPP to IPv4
                5.4. SIPP and IPv4 Routing Configuration
                5.5. Translation of Fragments
                5.6. Knowing when to Translate
        6. IPAE Hosts
                6.1. What Packet Format to Send
                6.2. Transport Pseudo-header Checksum
                6.3. TCP and UDP Connection Identification
                6.4. ICMP Error Messages
                        6.4.1. Sending ICMP Error Messages
                        6.4.2. Receiving ICMP Error Messages
                6.5. Transport API changes
                6.6. IP Addresses Embedded In Application Protocols
                        6.6.1. FTP
                        6.6.2. Mail (RFC 822)
                        6.6.3. Domain Name System (DNS)
                        6.6.4. SMI, MIB-II, Forwarding Table MIB
                        6.6.5. RARP, BOOTP, DHCP, Bootparams
                        6.6.6. BSD Talk Protocol
        Appendix 1. Definitions
        Appendix 2. The IPv4 to SIP Transition
        Appendix 3. Examples
                A3.1. IPAE Encapsulation
        Appendix 4. Design Decisions
                A4.1. The C-bit
                A4.2. Global vs. Local Scope for C-bit
        Appendix 5. Open Issues
                A5.1. How is the DF Bit Handled?



draft-ietf-sipp-ipae-transition-00.txt                          [Page 3]

INTERNET-DRAFT             IPAE Specification              November 1993


                A5.2. Should we Map IPv4 TOS bits into a Flow ID?
                A5.3. How Should we Set the ID field?
                A5.4. ICMP Error Message Handling?
                A5.5 IPv4 Path MTU Discovery when Encapsulating
        Security Considerations
        References
        Author's Address












































draft-ietf-sipp-ipae-transition-00.txt                          [Page 4]

INTERNET-DRAFT             IPAE Specification              November 1993


1. Introduction

IPAE is designed to serve two purposes.  First, it is the set of
mechanisms by which SIPP systems interoperate with systems that only
understand the current (version 4) version of IP.  Secondly, it is the
means by which the operational Internet can transition to SIPP.  The
transition mechanisms build on the interoperability features.

All SIPP hosts that support IPAE are able to interoperate with IPv4
hosts anywhere in the Internet.  This feature minimizes the impact of
transition to SIPP on the users, since they may upgrade their hosts SIPP
at their own pace.

IPAE provides a similar "incremental upgrade" feature for routers.  SIPP
traffic can be encapsulated within IPv4 packets and then routed by IPv4
routers.  This leverages the existing IPv4 routing infrastructure.  It
allows sites and the Internet backbone service providers to upgrade
their routers to SIPP in an incremental fashion.  The IPv4 routers do
not need to be converted to SIPP at the same time.  The Internet can
gain some of the benefits of SIPP after only a small number of the IPv4
routers are converted to SIPP.

IPAE also defines a mechanism by which IPv4 traffic may be carried by
the SIPP routing infrastructure, once it is constructed.  This provides
complete global connectivity for IPv4 hosts up to the time when IPv4
addresses are no longer unique (i.e. when all of the IPv4 addresses are
assigned.  After the time when IPv4 addresses run out, there is no
practical way to provide global IPv4 connectivity, although it may be
possible to continue selective connectivity for some IPv4 destinations.)
With this feature, IPAE provides service for those IPv4 hosts that can
not be upgraded to SIPP, or whose users' simply choose not to upgrade.
What's more, the IPv4 traffic being carried by the SIPP routing
infrastructure receives the same benefits of route scaling as the SIPP
traffic.

IPAE is a collection of protocols, mechanisms, and operational
procedures that are built upon SIPP.  IPAE can be viewed as an add-on to
SIPP.  It is being cast as a mechanism separate from SIPP with an eye
toward the time -- probably in the far distant future -- when the
Internet may no longer require interoperability between SIPP and IPv4
hosts and routers.  At that time, the IPAE mechanisms can be retired,
and the IPAE software can be de-commissioned.

Another reason for separating the "IPv4 compatibility" features from the
core SIPP is that SIPP may be used in in environments in which there are
no IPv4 systems.  There may be a desire in the short term for
"SIPP-only" hosts or routers in isolated settings.  In order to
differentiate those SIPP-speaking systems that interoperate with IPv4



draft-ietf-sipp-ipae-transition-00.txt                          [Page 5]

INTERNET-DRAFT             IPAE Specification              November 1993


systems from those that do not, we offer the following definitions: A
"SIPP-only" host or router conforms to the SIPP specifications, but not
the IPAE specification.  An IPAE host or router conforms to both the
SIPP specifications and the IPAE specification.  Both IPAE and SIPP-only
systems can be referred to as "SIPP systems" since they both support
SIPP.

It is expected that for the foreseeable future, all of the SIPP systems
deployed on the Internet will need to interoperate with IPv4 systems.
Thus it is likely that most or all of the SIPP hosts or routers will
also be IPAE systems.

This paper assumes familiarity with SIPP.  We recommend that readers
read the SIPP specification before reading this paper.

Finally, a word on the term "IPAE."  IPAE was originally used as the
acronym for one of the IP next generation proposals.  The IPAE working
group merged with the SIP working group, but the new group maintained
the IPv4 interoperability techniques developed in the former group.
After that, the SIP working group merged with the PIP working group to
form the SIPP group, again keeping the IPAE techniques.  Today, IPAE is
no longer an acronym; it is simply a convenient term for the
interoperability and transition mechanisms originally developed in the
IPAE working group.


1.1. Organization

The remainder of this paper is organized as follows:

  -     Chapter 2 details the scaling problems that SIPP and IPAE were
        designed to overcome.

  -     Chapter 3 gives an overview of IPAE.

  -     Chapters 4, 5, and 6 give detailed specifications and
        requirements for the components of the IPAE network.

  -     The five appendices, A1 through A5, provide additional
        details and background information.

The reader can gain an understanding of IPAE by reading chapters 2 and
3.  Implementors should read chapters 4, 5, and 6 as well as the
appendices.







draft-ietf-sipp-ipae-transition-00.txt                          [Page 6]

INTERNET-DRAFT             IPAE Specification              November 1993


2. Problem Statement

Due to the widespread adoption the TCP/IP technology the Internet is
experiencing explosive growth, usually described as doubling every 12
months.  There is no indication that this growth will reduce and
development of IP use into mass markets will create an even steeper
growth curve.  The result is a crisis in IP router table storage and use
and in near-term exhaustion of available IP network numbers.

IP routers which record routes to all networks in the Internet must
maintain an entry for each such network, since the IP network address
space is flat.  That is, neighboring networks do not necessarily have
any similarity in the IP network portion of their address.  A new
address structure is required, so as to allow route-aggregation in table
entries to neighboring networks.  Even Classless Inter-Domain Routing
[CIDR], which is reducing the size of the routing tables in the short
term, can not be guaranteed to solve this problem for an extended period
of time due to sites changing providers and policy constraints in the
backbone networks.

While the 32-bits of the IP address space theoretically can reference
about 4 billion nodes, the bits have been partitioned to facilitate
assignment and aggregation into networks.  This reduces the realistic
maximum number of networks and hosts.  While estimates vary
considerably, it is possible that IP network number exhaustion will
occur within the next few years.  For example, IP could begin to make
penetrations in mass markets.  Since the damage caused by being unable
to assign new IP network numbers is so great, it is prudent to pursue an
urgent path to increasing the number of networks.

SIPP and IPAE provide a solution to these problems.  IPAE as the
transition mechanism for SIPP was designed around a number of objectives
to make the transition from IPv4 to SIPP as smooth as possible.  These
objectives are:


   -    The transition to SIPP should cause as little impact as possible
        on the end users of hosts.

   -    The transition to SIPP should leverage as much of the users' and
        administrators' intangible investment in IPv4 operations,
        training, terminology as possible.  We should recognize that
        users, administrators, and network operators have extensively
        invested in "understanding" IPv4.  That investment should not be
        lost.

   -    The transition should be "asynchronous".  Users and network
        operators should be able to transition at their own pace.  Users



draft-ietf-sipp-ipae-transition-00.txt                          [Page 7]

INTERNET-DRAFT             IPAE Specification              November 1993


        should be able to upgrade hosts and routers incrementally.

   -    Sites which deploy IPAE should accumulate the benefits and
        features of SIPP and IPAE as they deploy.  For example a new
        IPAE host should be able to use the SIPP auto-configuration
        mechanisms immediately.  The benefits should not be accrued only
        after everyone else has deployed IPAE.

   -    The larger addresses of SIPP should be used to solve the
        IPv4 route scaling problem early on in the transition.

   -    It must provide complete, global interoperability between SIPP
        and IPv4 hosts for as long as IPv4 can provide global
        interconnectivity.

   -    It should provide global connectivity for IPv4 traffic for as
        long as possible.  (Note that is only possible to maintain
        global IPv4 connectivity only so long as IPv4 addresses are
        unique.  After "the day IPv4 address run out", it will no longer
        be possible to have direct global IPv4 connectivity.)

   -    It should leverage the existing IPv4 routing infrastructure
        wherever possible.




























draft-ietf-sipp-ipae-transition-00.txt                          [Page 8]

INTERNET-DRAFT             IPAE Specification              November 1993


3. The IPAE Solution

The design of IPAE centers on four core elements:

  -     A 64-bit SIPP addressing plan that is compatible with the
        current 32-bit IPv4 addressing plan.

  -     A mechanism for encapsulating SIPP traffic within IPv4 packets
        for routing over parts of the Internet that have only IPv4
        routers.

  -     Algorithms in IPAE hosts to know when they are communicating
        with IPv4 hosts and format packets that are compatible.

  -     Use of "translation agents" to maintain global IPv4
        connectivity.

Each of these elements is described in more detail below.


3.1. IPAE Addressing

We have defined a 64-bit SIPP addressing structure that is compatible
with the existing 32-bit IPv4 addressing structure.  IPv4 compatible
SIPP addresses -- which we call "IPAE Addresses" -- have the following
features:

  1)    They have an IPv4 address embedded within them as the low-order
        32 bits.

  2)    The state of the high-order bit -- which is termed the "C-bit"
        -- encodes whether the entity the address identifies is capable
        of processing the SIPP packet format.  If the high-order bit of
        an IPAE address is 0, the system that it represents is SIPP
        capable.  If the high-order bit is 1, the system may not be SIPP
        capable.

  3)    The remaining 31 bits are used to uniquely identify and address
        a new element of the Internet topology called an ``IPAE site.''

As part of the introduction of IPAE, the Internet will be sub-divided
into a number of logical regions called ``IPAE sites.''  This is done
without changing any physical elements of the Internet; it is only a
logical organization of the existing topology.

The only requirement for an IPAE site is that IPv4 traffic must be
routed completely within the boundaries of each site.  That is, all of
the routers within a site must continue to support IPv4 and must be



draft-ietf-sipp-ipae-transition-00.txt                          [Page 9]

INTERNET-DRAFT             IPAE Specification              November 1993


capable of routing to all IPv4 destinations within the site. (Routers
within a site MAY also support SIPP, in which case they are IPAE
routers; but they MUST support IPv4.  Also, the routers may be able to
route IPv4 traffic directly to destinations outside of the site, but
this is not required in order to qualify as an IPAE site.)

Each IPAE site is assigned a unique 31-bit ``site prefix,'' which is
used in the high-order bits of the IPAE addresses of all hosts and
routers within that site.  A hierarchal structure may be defined for
site prefixes, but details of their structure is outside the scope of
this paper.

Thus 64-bit IPAE addresses have the following structure:

         6                   3 3                 0
         3                   2 1                 0
        +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+-+
        |C|   Site Prefix     |    IPv4 Address   |
        +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+-+

An IPAE address has three components:

        C-bit           Encodes whether the entity addressed supports
                        SIPP or not.

        Site Prefix     Uniquely identifies the site that the
                        addressed entity is located in.

        IPv4 Address    Uniquely identifies the addressed entity.

64-bit IPAE addresses can be assigned to both IPAE and IPv4 hosts and
routers.  While an IPv4 host or router only ``knows'' its IPv4 address
(the low-order 32-bits of its IPAE address), it may have an IPAE address
assignment, which may be listed in the DNS.

Once an IPAE site has been defined and assigned a site prefix, all
existing IPv4 hosts and routers located within that site can be given
IPAE address assignments.  This assignment is straightforward, since the
IPv4 hosts' and routers' addresses are derived from their previously
assigned IPv4 addresses.  Specifically, IPAE addresses for IPv4 hosts
and routers can be assigned as follows:

        C-bit = 1.

        Site Prefix = prefix assigned to this site.

        IPv4 Address = IPv4 address assigned to this host or router.




draft-ietf-sipp-ipae-transition-00.txt                         [Page 10]

INTERNET-DRAFT             IPAE Specification              November 1993


When a new IPv4 host or router is introduced into a site, it is first
assigned an IPv4 address that is consistent with the IPv4 addressing plan
employed within the site.  Then, an IPAE address is assigned to the host
in the same manner as pre-existing IPv4 hosts.

When an IPAE host is introduced into a site, it is also first assigned
an IPv4 address that is consistent with the IPv4 addressing plan
employed within the site.  It is then assigned an IPAE address as
follows:

        C-bit = 0.

        Site Prefix = prefix assigned to this site.

        IPv4 Address = IPv4 address assigned to this host.

When an IPv4 host within a site is upgraded to support SIPP (i.e. it
becomes an IPAE host), the C-bit in the host's IPAE address is changed
from 1 to 0.

As long as IPv4 addresses remain unique in the Internet (that is, until
the time when IPv4 addresses "run out"), the IPv4 address portion of
IPAE addresses will be sufficient to uniquely identify a host or router.


3.2. IPAE Tunneling: SIPP within IPv4

IPAE hosts and routers use the IPAE tunneling technique to carry SIPP
packets over regions of the Internet that route only IPv4 packets.  In
IPAE tunneling, the end-to-end SIPP datagram is encapsulated within an
IPv4 datagram.  An IPAE tunnel may extend through only part of the
end-to-end path (e.g. between two IPAE routers), or may be used for the
entire path between two IPAE hosts (e.g.  when the only routers along
the path are IPv4).  On its journey from source host to destination
host, a SIPP datagram may be routed through one IPAE tunnel, many IPAE
tunnels, or none at all.

We use the term "IPAE packet format" to describe a SIPP datagram
encapsulated within an IPv4 header.  The IPAE packet format is shown
below, along with the IPv4 and SIPP packet formats for comparison:











draft-ietf-sipp-ipae-transition-00.txt                         [Page 11]

INTERNET-DRAFT             IPAE Specification              November 1993


        +------------+          +------------+          +------------+
        |    IPv4    |          |    IPv4    |          |    SIPP    |
        |   Header   |          |   Header   |          |   Header   |
        +------------+          +------------+          +------------+
        |  Transport |          |    SIPP    |          |  Transport |
        |   Layer    |          |   Header   |          |    Layer   |
        |   Header   |          +------------+          |   Header   |
        +------------+          |  Transport |          +------------+
        |            |          |   Layer    |          |            |
        ~    Data    ~          |   Header   |          ~    Data    ~
        |            |          +------------+          |            |
        +------------+          |            |          +------------+
                                ~    Data    ~
                                |            |
                                +------------+

         IPv4 Packet             IPAE Packet             SIPP Packet
           Format                  Format                  Format

In the IPAE packet format, the IPv4 source and destination addresses
identify the "endpoints of the tunnel."  The SIPP source and destination
addresses identify the end hosts -- the sender and recipient of the
datagram.

The IPv4 routers on the "interior" of a tunnel route the packet based on
its IPv4 header.  The IPAE router at the end of a tunnel decapsulates
the packet and routes it based on the SIPP header.

When an IPAE host or router composes a packet in the IPAE format, it
sets the IPv4 Time To Live (TTL) field to be the same as the SIPP Hop
Limit.  When an IPAE router receives a packet in the IPAE format, it
copies the IPv4 TTL into the SIPP hop limit field and subtracts one.
Thus IPv4 "hops" are counted in the SIPP hop limit.

It is possible that one of the IPv4 routers along the tunnel interior
might encounter an error while processing an IPAE packet, causing it to
return an IPv4 ICMP error message to the source endpoint of the tunnel.
The three types of ICMP errors that can occur in this circumstance are:

  -     Packet too big.
  -     Time Exceeded.
  -     Destination Unreachable.

Unfortunately, the ICMP spec only requires IPv4 routers to return 8
bytes (64 bits) of the packet beyond the IPv4 header. This is not enough
to include the SIPP source address, so it is not generally possible for
an IPAE router to immediately reflect a SIPP ICMP message back to the
source host when it receives an IPv4 ICMP message from the interior of a



draft-ietf-sipp-ipae-transition-00.txt                         [Page 12]

INTERNET-DRAFT             IPAE Specification              November 1993


tunnel.

However, by carefully maintaining "soft state" about its tunnels, an
IPAE router can return accurate SIPP ICMP messages in most cases.  An
IPAE router should maintain at least the following soft state
information about each tunnel:

  -     MTU of the tunnel.
  -     TTL (path length) of the tunnel
  -     Reachability of the end of the tunnel.

An IPAE router uses the IPv4 ICMP messages it receives from the interior
of a tunnel to update the soft state information for that tunnel.  When
subsequent SIPP packets that would transit the tunnel arrive, the router
checks the soft state for the tunnel.  If the packet would violate the
state of the tunnel (e.g. packet would be larger than the tunnel MTU;
the SIPP hop limit is less than the tunnel TTL) the router sends a SIPP
ICMP error message back to the source, but also forwards the packet into
the tunnel.

Using this technique, the SIPP ICMP error messages sent by IPAE routers
may not alway match up one-to-one with errors encountered by IPv4
routers, but they will accurately reflect the state of the network.


3.3. IPAE host operation.

The requirements on IPAE hosts can be expressed as three simple rules:

   1)   IPAE hosts accept packets in the IPv4 format.

   2)   IPAE hosts transmit packets in the IPv4 format when sending to
        IPv4 hosts within the same site.

   3)   IPAE hosts use the IPv4 transport connection-identification and
        pseudo-header checksum algorithms when communicating with IPv4
        hosts.

IPAE hosts need to be able to communicate with IPv4 hosts within their
"site" without the help of any other agents.  This is important so that
the first IPAE systems deployed at a site will immediately interoperate
with the deployed IPv4 hosts and routers without the need to first
deploy IPAE routers or translation agents.

The three rules above will guarantee that IPAE hosts always send IPv4
format packets to IPv4 hosts within their sites and that the IPv4
packets that the IPv4 hosts send back will be handled properly.  IPAE
hosts can use the C-bit of the destination address, along with knowledge



draft-ietf-sipp-ipae-transition-00.txt                         [Page 13]

INTERNET-DRAFT             IPAE Specification              November 1993


of the site prefix of the outgoing interface, to determine whether a
destination address is located within the same site, and whether it is
an IPv4 host or not.

IPAE hosts can use the IPv4 packet format when sending to IPv4 hosts in
the local site because IPv4 is always routed within a site.  But since
IPv4 traffic may not be routed globally, IPAE hosts must use the SIPP
packet format when sending to IPv4 hosts in remote sites.  The IPAE
translator (described in the next section) in the remote site will take
care of translating the packet into IPv4 format before it is delivered
to the destination IPv4 host.  Thus packets for all hosts in remote
sites can be sent in the SIPP format.

When sending to IPv4 hosts, IPAE hosts must calculate the
transport-layer pseudo-header checksum in such a way that it will be
accepted by the IPv4 host.  Similarly, when receiving packets from IPv4
hosts, the IPAE host must calculate the checksum in a way that a
correctly generated packet will be accepted.  This means that only the
low-order 32 bits of the SIPP address are used in the pseudo-header
calculation when communicating with IPv4 hosts.

Also, the connection identification logic in the transport layer of the
IPAE host must associate packets received from IPv4 hosts with the
correct connection state.  This means that IPAE hosts only use the
low-order 32 bits of the SIPP addresses in the connection identification
algorithm when communicating with IPv4 hosts.


3.4. IPAE Header Translation

IPAE translation agents, also called "IPAE translators", provide global
IPv4 connectivity once IPv4 is no longer routed globally.  They do this
by translating the Internet headers of all intra-site IPv4 traffic.

Each site is equipped with at least one IPAE translator whose job it is
to:

  1)    Translate the IPv4 headers of all IPv4 traffic that is generated
        within the site, and is addressed to destinations in remote
        sites, into SIPP headers.  The resulting SIPP packets are then
        forwarded into the SIPP routing system, where they are routed
        based on their full 64-bit SIPP destination addresses.

  2)    Translate the SIPP headers of all SIPP traffic that is sent from
        remote sites, and is addressed to IPv4 destinations in the local
        site, into IPv4 headers.  The resulting IPv4 packets are then
        forwarded into the IPv4 routing system within the site for
        delivery to the destination IPv4 host.



draft-ietf-sipp-ipae-transition-00.txt                         [Page 14]

INTERNET-DRAFT             IPAE Specification              November 1993


The IPAE translators operate only on the Internet headers of packets.
They never look beyond the SIPP or IPv4 headers into the transport layer
headers or application data.  The interoperation of IPAE and IPv4
systems using application layer protocols that carry IPv4 addresses is
addressed in section 6.6.

In order to perform task (1) above, the IPAE translator must map the
destination IPv4 address of the packet into a 64-bit SIPP address.  This
is done with the help of a mapping table.  The mapping table maps IPv4
destination addresses into 32-bit prefixes.  The prefix is prepended to
the 32-bit IPv4 destination address to compose a complete 64-bit SIPP
which is stored in the SIPP header.

In order to efficiently encode mapping information, the entries in the
table are keyed by a 32-bit mask and 32-bit IP address.  The mask +
address are associated with a 32-bit SIPP address prefix.  For example,
this entry:

        mask            address         SIPP address prefix
        ----            -------         --------------------
        255.255.0.0     129.144.0.0     1404:1:0.0.0.0

states that all destination addresses with the high order 16 bits equal
to "129.144" should be given the prefix 1404:1.



























draft-ietf-sipp-ipae-transition-00.txt                         [Page 15]

INTERNET-DRAFT             IPAE Specification              November 1993


4. IPAE routers

We call a router that understands both the IPv4 and SIPP packet
formats, and participates in both the IPv4 and SIPP routing protocols
an IPAE router.

 Each site must have at least one IPAE router that
participates in both the IPv4 routing system within the site, and the
global SIPP routing system.

In addition to participating in multiple routing domains the IPAE router
has to be able to tunnel SIPP datagrams by encapsulating them in Ipv4
packets.

Finally, IPAE routers have to generate ICMP errors containing an
"offending packet" that the recipient of the ICMP error can understand.

4.1 Multiple routing domains

In addition to participating the SIPP routing system, an IPAE router has
to be capable of participating in multiple IPv4 routing domains. This is
required since each interface potentially belongs in a separate routing domain,
and after IPv4 addresses "run out" the IPv4 addresses will only be unique
within each routing domain/site. This implies that the router has to maintain
logically separate IPv4 routing tables for each domain/site and be able
to send return packets back to the correct site. This can be implemented by
tagging each incoming IPv4 packet with the address prefix (with the C-bit set)
of the interface in arrived on.


4.2 Tunneling SIPP in IPv4

IPAE routers, as well as IPAE hosts, tunnel SIPP datagrams by encapsulating
the in IPv4 packets. The tunneling mechanism consists of:

   -    The entry router of the tunnel (the encapsulating router) creating
        an encapsulating IPv4 header.

   -    The exit router of the tunnel (the decapsulating router)
        removing the IPv4 header and updating the SIPP header.

   -    The encapsulating router maintaining soft state for each tunnel
        in order to generate SIPP ICMP errors.

There are two sets of tunnels used in IPAE:

   -    configured tunnels between IPAE routers.




draft-ietf-sipp-ipae-transition-00.txt                         [Page 16]

INTERNET-DRAFT             IPAE Specification              November 1993


   -    implicit tunnels i.e. where the IPv4 addresses of the tunnel
        endpoint is the 32 low-order bits of the SIPP destination
        address.

The configured tunnels could be set up either manually or by a routing
protocol. The implicit tunnels are always present. A host with an
address prefix of A has implicit tunnels to all SIPP addresses that share
the A prefix. An IPAE router with an interface to a site with address prefix A
also has implicit tunnels to all SIPP address with the A prefix.

Thus there will potentially exist a very large number of implicit tunnels
in IPAE hosts and IPAE routers. Therefore the state associated with the
tunnels should be kept cache so that it can be discarded when no longer
used and later recreated.


4.3 Encapsulating SIPP in IPv4

The encapsulating header should have the Don't Fragment bit set in order
for the tunnel entry point to discover the tunnel mtu. The SIPP hop limit
field is copied into the IPv4 TTL field.

Either the SIPP hop limit must be decremented by one before the
packet is encapsulated, or the IPv4 TTL must be decremented by one after
the encapsulation (as part of the normal forwarding mechanism).

SIPP routers, in general, do not fragment SIPP datagrams that exceed
the MTU even if the datagram contains a fragmentation header. Thus, in
particular, there is no need for an encapsulating router to perform any
fragmentation.

                                        +-------------+
                                        |    IPv4     |
                                        |   Header    |
        +-------------+                 +-------------+
        |    SIPP     |                 |    SIPP     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |  Transport  |                 |  Transport  |
        |   Layer     |      ===>       |   Layer     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |             |                 |             |
        ~    Data     ~                 ~    Data     ~
        |             |                 |             |
        +-------------+                 +-------------+

                    SIPP Encapsulation in IPv4



draft-ietf-sipp-ipae-transition-00.txt                         [Page 17]

INTERNET-DRAFT             IPAE Specification              November 1993


When encapsulating a SIPP datagram in an IPv4 datagram, the IPv4 header fields
are set as follows:

        Version:

                4

        IP Header Length in 32-bit words:

                5 (There are no IPv4 options in the encapsulating header.)

        Type of Service:

                0

        Total Length:

                Payload length from SIPP header plus length of SIPP and
                IPv4 headers (i.e. a constant 44 bytes)

        Identification:

                Generated uniquely as for any IPv4 packet transmitted
                by the host function in the system.

        Flags:

                Set the Don't fragment flag.


        Fragment offset:

                0.

        Time to Live:

                Copied from the SIPP hop limit field.

        Protocol:

                41 (Assigned payload type number for SIPP)

        Header Checksum:

                Calculate the header checksum.

        Source Address:




draft-ietf-sipp-ipae-transition-00.txt                         [Page 18]

INTERNET-DRAFT             IPAE Specification              November 1993


                IPv4 address of outgoing interface.

        Destination Address:

                IPv4 address of remote end of tunnel.

Any SIPP options are preserved in the packet (after the SIPP header).


4.4 Decapsulating IPAE packets

When a host or a router receives an IPv4 datagram destined to one of
its IPv4 address with the protocol field set to 41 it must decapsulate the
packet.

When decapsulating such IPAE packets the SIPP hop limit is set to the
IPv4 TTL. The SIPP hop limit must be decremented by one after the
packet has been decapsulated (as part of the normal SIPP forwarding
mechanism.)

        +-------------+
        |    IPv4     |
        |   Header    |
        +-------------+                 +-------------+
        |    SIPP     |                 |    SIPP     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |  Transport  |                 |  Transport  |
        |   Layer     |      ===>       |   Layer     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |             |                 |             |
        ~    Data     ~                 ~    Data     ~
        |             |                 |             |
        +-------------+                 +-------------+

                    Decapsulating SIPP from IPv4

When decapsulating the IPAE packet only one field in the SIPP header is
modified:

        Hop Limit:
                TTL value copied from the encapsulating IPv4 header.

Then the encapsulating IPv4 header is dropped.






draft-ietf-sipp-ipae-transition-00.txt                         [Page 19]

INTERNET-DRAFT             IPAE Specification              November 1993


4.5 Tracking the tunnel state

Tunnels are "traceroute visible" i.e. a traceroute program running on
a SIPP or IPv4 host will report all the routers internal to the tunnel.
This is accomplished by copying the TTL from the SIPP header into
the encapsulating IPv4 header plus maintaining soft state about the tunnel
in the encapsulating router.

The soft state for the tunnel is based the ICMP errors that are received
from IPv4 routers interior to the tunnel. This tunnel state is associated
with the IPv4 address of the endpoint of the tunnel and consists of:

  -     Tunnel MTU.

  -     Path length of the tunnel (number of hops).

  -     For each TTL 't' between 1 and the path length of the tunnel,
        the IPv4 address of the router that was last known to be 't'
        hops into the tunnel.

  -     Reachability of the end of the tunnel.

  -     The IPv4 address of the router reporting unreachability.


The tunnel state does not have to be allocated until
an ICMP error is received; in the absence of tunnel state the tunnel
MTU is assumed to be the MTU of the outgoing interface, the path length
one hop and the endpoint being reachable.

When a datagram is encapsulated the router consults the tunnel state
to check if the packet is likely to generate an ICMP error from
a router interior to the tunnel. In such a case (e.g. packet size
greater than the tunnel MTU) the router generates the appropriate
ICMP error and also forwards the packet into the tunnel. Any ICMP error
caused by the forwarded packet will refresh the tunnel state.

When the encapsulator receives an ICMP errors destined to one of its IPv4
addresses where the "offending packet" is IPv4 with the IP protocol field being
41, it updates the tunnel state associated with the IPv4 destination
in the "offending packet". The update depends on the type of ICMP error:

   -    Host or network unreachable: Mark the tunnel endpoint as
        unreachable and record the source of the ICMP error as the
        source of unreachability.

   -    Time exceeded in transit: The TTL "consumed" before reaching the
        router that send the time exceeded message is extracted from the



draft-ietf-sipp-ipae-transition-00.txt                         [Page 20]

INTERNET-DRAFT             IPAE Specification              November 1993


        SIPP hop limit field in the "offending packet" (the SIPP hop
        limit field is in the first 8 bytes of the SIPP header thus it
        will be returned in the ICMP packet). Compute the updated tunnel
        path length as the maximum of the currently recorded path length
        and the extracted SIPP hop limit. Record the source of the ICMP
        error as the router at 'SIPP hop limit' hops into the tunnel.

   -    "Packet too big": If the ICMP packet contains the MTU (see RFC
        1191) update the tunnel MTU to be that value. If the ICMP packet
        does not contain the MTU use the IPv4 Total length field in the
        "offending packet" and the recommended plateaus in RFC 1191 to
        compute the new MTU for the tunnel.  Note that this can either
        increment or decrement the recorded tunnel mtu.

   -    For all other ICMP errors log a network management event.


When the encapsulator forwards a packet into the tunnel it performs
the following checks against the tunnel state:

   -    If the tunnel endpoint is unreachable it generates a SIPP ICMP
        network unreachable with the source address being the recorded
        router that reported the unreachability. The address is extended
        to 64 bits by using the 32 bit prefix of the tunnel's outgoing
        interface with the C-bit set.

   -    If the hop limit is less than the recorded tunnel ttl it
        generates a SIPP ICMP time exceeded in transit with the source
        address being the recorded router address that is 'hop limit'
        hops into the tunnel.  If there is no router address recorded
        for the specified hop limit, the router generates an ICMP time
        exceeded with a source address of 127.0.0.1. The recorded
        addresses are expanded to 64 bits just like for network
        unreachables.

   -    If the MTU exceeds the recorded tunnel mtu it generates a SIPP
        ICMP "packet too big" with itself as the source and setting the
        returned MTU to the recorded tunnel mtu minus the size of the
        IPv4 header (20 bytes).  (The 20 byte adjustment is needed since
        the packets will "expand" by 20 bytes when being encapsulated.)


In all of the above cases the datagram is also forwarded into the tunnel.

The mechanism described so far does not detect when an error
condition in the tunnel is lifted (e.g. the tunnel endpoint becomes
reachable or when the tunnel path length decreases). The simple
solution to detecting such "improvements" is to periodically



draft-ietf-sipp-ipae-transition-00.txt                         [Page 21]

INTERNET-DRAFT             IPAE Specification              November 1993


discard the recorded tunnel state. More elaborate schemes can be
envisioned, such as counting the number of 1) datagrams that should
have generated a certain ICMP error and 2) the actual number of such
ICMP errors received, and discarding the state when the ratio between
them exceeds some value.


4.6 Generating ICMP error packets

IPAE routers, as well as IPAE hosts, have to generate ICMP error packets
that the receiving host or router can decode. The possible formats for
the "offending packet" in the ICMP errors are:

   -    A SIPP header followed by the transport header (with possibly
        SIPP option headers between the SIPP header and the transport
        header)

   -    An IPv4 header followed by the transport header.

The first format is used when the C-bit is not set in the source address
in the offending packet. The second format is used when the C-bit is set
in the source address.

When the IPAE router or host receives a SIPP datagram and it has to generate
an ICMP error in the second format it creates, for the sole purpose of the
ICMP error, an IPv4 header derived from the SIPP header including any SIPP
option headers.

        +-------------+                 +-------------+
        |    SIPP     |                 |    IPv4     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |  Transport  |                 |  Transport  |
        |   Layer     |      ===>       |   Layer     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |             |                 |             |
        ~    Data     ~                 ~    Data     ~
        |             |                 |             |
        +-------------+                 +-------------+

                  ICMP "offending packet" conversion

When generating the IPv4 header from the SIPP header, the IPv4 header fields
are set as follows:

        Version:




draft-ietf-sipp-ipae-transition-00.txt                         [Page 22]

INTERNET-DRAFT             IPAE Specification              November 1993


                4

        IP Header Length in 32-bit words:

                5

        Type of Service:

                0

        Total Length:

                Payload length from SIPP header minus length of any SIPP
                optional headers plus length of the IPv4 header.

        Identification:

                If SIPP fragmentation option is present, copy low-order
                16 bits from ID field.  Otherwise set to zero.

        Flags:

                If SIPP fragmentation option is not present, set the
                Don't fragment flag.

        Fragment offset:

                0. (Only the first fragment will generate ICMP errors.)

        Time to Live:

                Copy from the SIPP hop limit field.

        Protocol:

                Payload type value copied from SIPP header or, if known
                SIPP options are present, from last SIPP option header.

        Header Checksum:

                Calculate the header checksum.

        Source Address:

                Copy the low-order 32-bits of the SIPP source address.

        Destination Address:




draft-ietf-sipp-ipae-transition-00.txt                         [Page 23]

INTERNET-DRAFT             IPAE Specification              November 1993


                Copy the low-order 32 bits of the SIPP destination
                address.

The IPv4 header is immediately followed by the transport header i.e. any
SIPP option headers are ignored.














































draft-ietf-sipp-ipae-transition-00.txt                         [Page 24]

INTERNET-DRAFT             IPAE Specification              November 1993


5. IPAE Translators.

IPAE translators perform the task of translating intra-site IPv4
traffic between the IPv4 and SIPP packet formats so that it can be
carried over the SIPP backbone.  IPv4 traffic originating within the
site is translated into the SIPP format and then forwarded into the
SIPP backbone.  SIPP traffic to IPv4 destinations within the site is
translated into the IPv4 format, and then forwarded into the IPv4
routing system within the site.

Each site must have at least one IPAE translator.  Additional IPAE
translators can be deployed within a site to provide fault tolerance
and robustness.

IPAE translators only operate on the SIPP and IPv4 headers of packets.
They never look beyond the Internet headers into the transport layer
headers or application data.

The function of the IPAE translator does not have to reside in a
dedicated machine.  It may be co-resident in a machine that also has
another function, such as the IPAE border router.

This work of the IPAE translator consists of five separate tasks:

  -     Translating IPv4 packets into SIPP format.

  -     Maintaining a table to map IPv4 addresses into SIPP address
        prefixes.

  -     Translating SIPP packets into IPv4 format.

  -     Participating in IPv4 routing within the site, and global SIPP
        routing.

  -     Knowing when to translate IPv4 into SIPP and SIPP into IPv4.

The rest of this section details each of these tasks.

5.1 Translating IPv4 to SIPP

When an IPAE translator receives an IPv4 datagram addressed to a
destination in a remote site, it translates the IPv4 header of that
packet into a SIPP header, and then forwards the packet based on the
SIPP destination address.  The original IPv4 header on the packet is
removed and replaced by a SIPP header; The transport layer header and
data portion of the packet are left unchanged.





draft-ietf-sipp-ipae-transition-00.txt                         [Page 25]

INTERNET-DRAFT             IPAE Specification              November 1993


        +-------------+                 +-------------+
        |    IPv4     |                 |    SIPP     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |  Transport  |                 |  Transport  |
        |   Layer     |      ===>       |   Layer     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |             |                 |             |
        ~    Data     ~                 ~    Data     ~
        |             |                 |             |
        +-------------+                 +-------------+

                    IPv4 to SIPP Header Translation

After the IPv4 header has been translated into a SIPP header, the packet
may be further encapsulated within an IPv4 header if the next hop is via
an IPv4 router.

When translating from the IPv4 format into SIPP, the SIPP 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.

        High-order 32 bits of Source Address:
                C-bit:  1
                Site Prefix: Prefix of the local site.

        Low-order 32 bits of Source Address:
                Source address copied from IPv4 header.

        High-order 32 bits of Destination SIPP address:
                Mapping table entry for IPv4 destination address.




draft-ietf-sipp-ipae-transition-00.txt                         [Page 26]

INTERNET-DRAFT             IPAE Specification              November 1993


        Low-order 32 bits of Destination SIPP address:
                Destination address copied from IPv4 header.

If IPv4 options are present in the IPv4 packet, they are dealt with as
follows:

        No Operation (Type = 1)

                This option is used only for padding.  It is ignored.


        Security (Type = 130)

                The RFC 791 security option is obsolete.  It is ignored.

        Strict Source and Record Route (Type = 137)

                Since SIPP does not support the Strict Source route
                model, this option can not be translated into SIPP.
                If this option is present, the packet must be dropped,
                and an IPv4 ICMP destination unreachable message back
                to the source.

        Loose Source and Record Route (Type = 131)

                The IPv4 LSRR option can be translated into the SIPP
                Route option.  The payload type in the SIPP header is
                set to the number assigned to the SIPP route option.
                The fields of the SIPP route option are set as follows:

                Payload Type:
                        Protocol field copied from IPv4 header.

                Number of addresses, n:
                        Number of IPv4 addresses in the IPv4 LSRR option.

                Next Address, i:
                        The number of the IPv4 address pointed to by the
                        pointer field LSRR option.  For example, if the
                        pointer field points to the first IPv4 address
                        in the LSRR option, then the Next Address field
                        is set to 1.  If the pointer field points past
                        the end of the route data, then the Next Address
                        field is set to the same value as the Number of
                        Addresses field.

                For each of address 1 through j in the LSRR route data,
                set the value of the corresponding SIPP address in the



draft-ietf-sipp-ipae-transition-00.txt                         [Page 27]

INTERNET-DRAFT             IPAE Specification              November 1993


                SIPP Route Options as follows:

                High-order 32 bits of SIPP address [j]:
                        Mapping table entry for LSRR option address [j]

                Low-order 32 bits of SIPP address [j]:
                        LSRR option address [j]

        Record Route (Type = 7)

                Since SIPP does not provide a record route option, this
                option is ignored.

        Stream Identifier (Type = 136)

                This Stream Identifier option is obsolete.  It is
                ignored

        Internet Timestamp (Type = 68)

                Since SIPP does not provide a timestamp option, this
                option is ignored.

        All other IPv4 options

                If any other IPv4 options are present, they are ignored.

By "ignored", we mean that the option is not processed, and no further
action is taken on it.  The translated SIPP packet is forwarded and no
ICMP error message is sent back to the source host.

If the IPv4 packet is a fragment (i.e. if either the More Fragments bit
is set, or the fragment-offset field of the packet is non-zero), then a
SIPP fragmentation option is added to the packet.  The payload type in
the SIPP header should be set to the number assigned to the
fragmentation option.  The fields of the SIPP fragmentation option
should then be set as follows:

        Payload Type:

                Protocol field copied from IPv4 header.

        More bit:

                More fragments bit copied from IPv4 header.

        Fragment offset:




draft-ietf-sipp-ipae-transition-00.txt                         [Page 28]

INTERNET-DRAFT             IPAE Specification              November 1993


                Fragment Offset value copied from IPv4 header.

        High-order 16 bits of the Identification field:

                0 (all zero bits)

        Low-order 16 bits of the Identification field:

                Value of the identification field copied from IPv4
                header.


5.2 Mapping Table

IPAE Translators must implement a mapping table to map IPv4 addresses
into 32-bit SIPP address prefixes.  The mapping table is used in the
process of translating IPv4 packets into SIPP headers.  The destination
address in the IPv4 packet is looked up in the mapping table.  If a
matching entry is found, the 32-bit prefix in that entry is prepended to
the 32-bit IPv4 address to form a complete 64-bit SIPP address for the
destination.  This address is then used as the destination address of
the SIPP header that is formed.

The 64-bit SIPP address that is formed for the destination is also an
IPAE address.  Thus the 32-bit prefix in the mapping table covers the
C-bit and the Site Prefix fields of the IPAE address:

         6                   3 3                 0
         3                   2 1                 0
        +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+-+
        |C|   Site Prefix     |    IPv4 Address   |
        +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+-+

        ^                     ^                   ^
        |  32-bit prefix from |  IPv4 address     |
        |   the mapping table | from the original |
        |                     |  IPv4 packet      |

In order to aggregate a large number of address mappings into a single
entry, the "key" in each mapping table entry should consist of a 32-bit
IPv4 address and a 32-bit mask.  The "value" information in the mapping
table is the 32-bit SIPP address prefix.  A destination IPv4 address
"matches" a mapping table entry if the destination address, logically
and-ed with the key mask, equals the key address.  More than one entry
may match.  The lookup process uses a "longest match" algorithm to
locate the best matching entry in the mapping table.  If more than one
matching entry exist in them mapping table, the entry with the longest
mask is the one that is used.



draft-ietf-sipp-ipae-transition-00.txt                         [Page 29]

INTERNET-DRAFT             IPAE Specification              November 1993


Here is an example of a mapping table entry:

        Key mask        Key address  ==>  SIPP address prefix
        --------        -----------       -------------------
        255.255.0.0     129.144.0.0  ==>  9404:3

It is important that the C-bit field of the prefixes in the mapping
table entries be set correctly.  The mapping table must be configured so
that the IPAE addresses composed for IPv4 destinations always have the
C-bit set to 1.  This will cause an IPAE translator in the destination
site to translate the packet into the IPv4 form before it is transmitted
to the destination IPv4 host.

The C-bit of the prefixes for IPAE hosts is less critical because IPAE
hosts accept packets in either the SIPP, IPAE, or IPv4 packet format.
If the C-bit is set to 1, packets will be delivered in the IPv4 form; if
the C-bit is set to 0, packets will be delivered in SIPP form.  The
traffic will be sub-optimal if the C-bit is 1, since it will undergo an
unnecessary translation into the IPv4 form.  But in order to condense
the size of the mapping table, it may be desirable to have some entries
that produce addresses for IPAE hosts with the C-bit set to 1.

Once a prefix is assigned for a site, it likely will not need to be
changed often.  For that reason, the mapping table will be continually
growing, but the individual entries, once added to the table, will
change only rarely.  For that reason, we do not need a highly dynamic
mechanism to distribute the mapping table to the IPAE translators.

In the initial deployment of IPAE and SIPP, the mapping table for the
entire Internet will be maintained at a central site and distributed
to all of the IPAE translators on a regular basis via FTP.  The
mapping table will be kept in a file on the central site, and the IPAE
translators will "pull" the file with FTP.  Each IPAE translator can
set its own schedule to pull the mapping table.

The central server from which the mapping table is FTP'ed must be an
IPAE system.  It can not be an IPv4 system.  This is required so that
the FTP traffic between the IPAE translators and the central sites does
not depend on the correct operation of the IPAE translators
themselves.


5.3 Translating SIPP to IPv4

When an IPAE translator receives a SIPP datagram addressed to an IPv4
destination in the local site, it translates the SIPP header of that
packet into an IPv4 header, and then forwards the packet based on the
IPv4 destination address.  The original SIPP header on the packet is



draft-ietf-sipp-ipae-transition-00.txt                         [Page 30]

INTERNET-DRAFT             IPAE Specification              November 1993


removed and replaced by an IPv4 header; the transport header and data
portion of the packet are left unchanged.

        +-------------+                 +-------------+
        |    SIPP     |                 |    IPv4     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |  Transport  |                 |  Transport  |
        |   Layer     |      ===>       |   Layer     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |             |                 |             |
        ~    Data     ~                 ~    Data     ~
        |             |                 |             |
        +-------------+                 +-------------+

                    SIPP to IPv4 Header Translation

When translating from the SIPP format into IPv4, the IPv4 header fields
are set as follows:

        Version:

                4

        IP Header Length in 32-bit words:

                5 plus length of IPv4 options, if added (see below)

        Type of Service:

                0

        Total Length:

                Payload length from SIPP header plus length of IPv4
                header and options, if added (see below).

        Identification:

                If SIPP fragmentation option is present, copy low-order
                16 bits from ID field.  Otherwise generate a unique
                value for every packet.

        Flags:

                If SIPP fragmentation option is present, set MF bit if
                More bit is set in option.  If the SIPP fragmentation



draft-ietf-sipp-ipae-transition-00.txt                         [Page 31]

INTERNET-DRAFT             IPAE Specification              November 1993


                option is not present, and the C-bit is set in the
                source address, then set the DF bit.

        Fragment offset:

                If SIPP fragmentation option is present, copy the
                fragment offset value from the option.

        Time to Live:

                Hop limit field copied from the SIPP header.

        Protocol:

                Payload type value copied from SIPP header or, if known
                SIPP options are present, from last SIPP option header.

        Header Checksum:

                Calculate the header checksum.

        Source Address:

                Copy the low-order 32-bits of the SIPP source address.

        Destination Address:

                Copy the low-order 32 bits of the SIPP destination
                address.

If any end-to-end SIPP options are present, they are handled as follows:

        Fragmentation option:

                Copy the values from the option into the IPv4 header as
                described above.

        Route option:

                The SIPP Route option can be translated into
                an IPv4 LSRR option.  The option values are set
                as follows:

                Length:

                        3 + 4 * (number of addresses)

                Pointer:



draft-ietf-sipp-ipae-transition-00.txt                         [Page 32]

INTERNET-DRAFT             IPAE Specification              November 1993


                        3 + 4 * (next address)

                Route data:

                        Low-order 32 bits of each address in the SIPP
                        Route option.

        All others:

                The above two options are the only SIPP options defined
                at the time this document was written.  Since SIPP
                encodes end-to-end options using payload type codes, the
                codes for new options will be indistinguishable from
                those of transport layer protocols.  Packets with
                unknown payload type codes should be translated and
                forwarded.  When new SIPP options are defined, the
                specification should detail how they should be handled
                by IPAE translators.

As of this writing, no hop-by-hop SIPP options are defined.  Thus none
of the hop-by-hop options can be translated into IPv4.  If the
hop-by-hop options payload type is given in the SIPP header, the IPAE
translator must parse the hop-by-hop options and abide by the "action
code" encoded into the low order 2 bits of the option type as specified
in the SIPP specification [SIPP].  These action codes are:

        00      Ignore the option; Continue processing the packet.

        01      Discard the packet.

        10      Discard the packet and send an ICMP parameter problem
                message back to the source.

        11      Discard packet and, only if the packet's destination
                address was not a multicast address, send an ICMP
                parameter problem message back to the source.


5.4 SIPP and IPv4 Routing Configuration

The IPAE translator must have some minimal involvement in both the
IPv4 routing system within the site, and the global SIPP routing system.
The SIPP and IPv4 routing systems must be configured to deliver those
packets that must be translated to the IPAE translator.  This means that
the IPv4 routing system within the site must deliver the IPv4 traffic
for all IPv4 destinations outside of the site to the IPAE translator.
And the SIPP routing system must deliver the SIPP traffic addressed to
the site's prefix with the C-bit set to 1 to the IPAE translator.  (SIPP



draft-ietf-sipp-ipae-transition-00.txt                         [Page 33]

INTERNET-DRAFT             IPAE Specification              November 1993


traffic for the site's prefix with the C-bit set to 0 is routed to the
individual SIPP hosts within the site.) In the intra-site IPv4 routing
system, there usually must be a default route pointing to the IPAE
translator.  In the SIPP routing system, there must be a route for the
site prefix with the C-bit set to 1 pointing to the IPAE translator.

The necessary IPv4 and SIPP routing can be accomplished by static
configuration in the IPv4 and SIPP routing systems, or by having the
IPAE translator actively participate in the IPv4 and SIPP routing
protocols.

If multiple IPAE translators are deployed in a site, the routing
configuration should be designed to split the traffic load among the
translators.


5.5 Translation of fragments

The rules for translating fragments, when to set the DF bit, and when to
include a fragmentation header are derived from the following
constraints:

   -    The translator will not receive ICMP "packet too big" messages
        since it is not the source address in the packet. The ICMP
        errors will be delivered to the source host. (This is unlike the
        encapsulation case, where the encapsulator receives all ICMP
        errors from routers interior to the tunnel.) Thus the
        translation rules have to make sure that the source host does
        not see any ICMP 'packet too big' that it would not have seen
        without any translators in the path.

   -    The minimum MTU that a link has to support is different for IPv4
        and SIPP: 68 and 576 bytes, respectively. Thus SIPP hosts can
        send 576 bytes without supporting path mtu discovery.

   -    SIPP routers never fragment packets (even when the fragmentation
        header is present). Thus the translation from IPv4 to SIPP, when
        the source does not support MTU discovery, has to make sure that
        the SIPP packet never needs to be fragmented.

The different fragmentation cases are presented in the two tables below.
The first table covers the cases where the source is an IPv4 system.  In
this case there can be either just a translation to SIPP (for a SIPP
destination) or first a translation to SIPP and then a translation to
IPv4 (for an IPv4 destination in a different site).

When the source is a SIPP system (the second table) the only possible
translation is to IPv4.



draft-ietf-sipp-ipae-transition-00.txt                         [Page 34]

INTERNET-DRAFT             IPAE Specification              November 1993




        IPv4                    SIPP                            IPv4

        DF not set      =>      fragment to 576         =>      copy ID field
                                include fragmentation hdr       DF not set

        DF set          =>      no fragmentation hdr    =>      DF set

              Fragmentation translation for IPv4 source


        SIPP                            IPv4

        Fragmentation hdr       =>      Copy ID field
                                        DF not set

        No fragmentation hdr    =>      Generate pseudo-unique ID
                                        DF not set

              Fragmentation translation for SIPP source


5.6 Knowing when to Translate.

The IPAE translator must translate IPv4 packets destined to hosts
outside of the site and SIPP packets destined to hosts within the site.
To do this, it must be able to differentiate those packets it must
translate from those that it simply processes in the normal manner (and
forwards, for example, if the machine is also a router).  The translator
may need some configuration information in order to make this
distinction.

This specification does not place any requirements on how the IPAE
translator decides which packets to translate.  However, the decision
can be made based on information the machine has available.

The IPAE translator can use the SIPP addresses of its own interfaces to
decide which SIPP packets to translate.  SIPP packets whose destination
address match the 31-bits site prefix of an interface, and with the
C-bit set to 1, should be translated.  All other SIPP packets should be
simply forwarded based on the SIPP destination address.

The IPAE translator can use the mapping table along with the addresses
of its own interface to decide which IPv4 packets to translate.  If a
matching entry is found in the mapping table for the destination address
of the IPv4 packet, and the prefix in that mapping table entry does not
match the site prefix of the address of any interface, then the packet



draft-ietf-sipp-ipae-transition-00.txt                         [Page 35]

INTERNET-DRAFT             IPAE Specification              November 1993


can be translate.  Otherwise, the packet should be forwarded based on
its IPv4 destination address.

















































draft-ietf-sipp-ipae-transition-00.txt                         [Page 36]

INTERNET-DRAFT             IPAE Specification              November 1993


6. IPAE Hosts

IPAE hosts need to implement a variety of algorithms in order to be
compatible with IPv4 hosts and routers, and also use the new facilities
of SIPP.  The modifications affect the internet and transport layers of
the protocol software, as well as the transport layer application
program interface (API), and the applications themselves.

IPAE hosts must meet a couple of general requirements.  They must be
able to transmit and receive packets in the SIPP and IPv4 packet
formats.  They must be able to perform IPAE tunneling (SIPP encapsulated
within IPv4).  And they must be able to route outbound datagrams to both
SIPP and IPv4 destination addresses.

6.1. What packet format to send.

The first decision a host must make is which form of packet to transmit:
IPv4 or SIPP.  When sending traffic to IPv4 hosts within its own site,
IPAE hosts always transmit in the IPv4 format.  Thus the host can make
its initial packet format decision based on the C-bit and high-order 32
bits of the destination SIPP address:

        if (C-bit of dest == 1) && (dest is in local site)
                send IPv4 packet
        else
                send SIPP packet

The destination host is in the same site if the site prefix field
(high-order 31 bits to the right of the C-bit) of the destination SIPP
address match the site prefix field of the address of the outgoing
interface.

If a host is sending an IPv4 format packet, the packet can simply be
routed using the IPv4 routing features of the host and transmitted.
When sending a SIPP format packet, the host must determine whether the
packet can be sent in the raw SIPP form, or whether it must be tunneled
(encapsulated within an IPv4 header).  How the host makes this decision
depends on how IPAE tunnels are configured on the host.

If the packet is to be tunneled, the SIPP datagram is encapsulated in an
IPv4 header, and the IPv4 destination address set to the endpoint of the
IPAE tunnel.  The datagram is then routed using the IPv4 routing
features of the host.  The destination addresses in the IPAE packet will
be:

        IPv4 dest addr:         IPv4 address of tunnel endpoint.
        SIPP dest addr:         SIPP addr of destination host.




draft-ietf-sipp-ipae-transition-00.txt                         [Page 37]

INTERNET-DRAFT             IPAE Specification              November 1993


If the packet is in the SIPP format and is not tunneled, it is routed
using the SIPP routing features of the host and transmitted.

6.2. Transport pseudo-header checksum.

TCP [RFC793] and UDP [RFC768] both define a checksum that covers the
data portion of the segment along with a 96-bit "pseudo header" that
includes the IPv4 source and destination addresses, protocol ID and
length fields from the IPv4 header.  Including this pseudo header in the
transport checksum protects the transport layer against misrouted
segments.

The pseudo header used in the transport checksum when TCP and UDP are
layered above IPv4 can be viewed logically as this:

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     IPv4 source address                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                   IPv4 destination address                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  zero         | protocol      |       length                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Including the addresses in the checksum is even more important when TCP
and UDP are layered above SIPP because the SIPP header is not
checksummed.

When communicating with other SIPP hosts, the TCP and UDP pseudo header
includes the complete 64-bit SIPP source and destination addresses.  But
since the IPAE mechanism allows IPv4 packets to be translated into SIPP
and vice-versa, the IPAE host must implement a compatible pseudo-header
checksum when the packets it receives originated from, or the packets it
is sending are destined to, an IPv4 host.  The pseudo header checksum
algorithm must cover only the low-order 32 bits of the SIPP addresses
when an IPAE host is communicating with an IPv4 host.  When
transmitting, the IPAE host can use the C-bit of the SIPP destination
address to determine whether the peer is an IPv4 host.  When receiving,
the C-bit of the SIPP source address can be used.

When communicating with an IPv4 host using the IPv4 packet format
directly (i.e., an IPv4 host in the same site), the 96 bit pseudo header
shown above is used.

When communicating in the IPAE or SIPP format with another SIPP host,
the following pseudo header is used when the host is:

1)  Transmitting and C-bit of SIPP Destination Address is 0, or




draft-ietf-sipp-ipae-transition-00.txt                         [Page 38]

INTERNET-DRAFT             IPAE Specification              November 1993


2)  Receiving and C-bit of SIPP Source Address is 0


        0               8               16              24
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     zero      |    protocol   |          Length               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                     SIPP Source Address                       +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                    SIPP Destination Address                   +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         SIPP peer pseudo header


When communicating in the IPAE or SIPP format with an IPv4 host the
following pseudo header is used when the host is:

1)  Transmitting and C-bit of SIPP Destination Address is 1, or

2)  Receiving and C-bit of SIPP Source Address is 1.


        0               8               16              24
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Zero      |    Protocol   |          Length               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             Zero                              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                32-LSB of SIPP Source Address                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             Zero                              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |               32-LSB of SIPP Destination Address              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  SIPP - IPv4 compatible pseudo-header


6.3. TCP and UDP connection identification.

TCP uses the concatenation of local and remote IP address with local and
remote port number to uniquely identify a connection.  TCP uses the term
"socket" to identify one endpoint of a connection.  The local socket is



draft-ietf-sipp-ipae-transition-00.txt                         [Page 39]

INTERNET-DRAFT             IPAE Specification              November 1993


identified by the local IP address and local port number, while the
remote socket is identified by the remote IP address and remote port
number.

In processing received segments and ICMP error messages, TCP must use
the destination IP address and port number -- and possibly the source IP
address and port number as well -- from the received segment to find the
matching socket or connection in its own connection table.  When
communicating with another SIPP host, TCP must use the full SIPP source
and destination addresses to identify connections and sockets.  But when
communicating with IPv4 hosts using the SIPP packet format, TCP must use
only the low order 32 bits of global source and destination to identify
the connection.  This is necessary since the 64 bit SIPP addresses may
not carried end-to-end; only the low-order 32 bits are end-to-end. Thus
the high-order bits can be different in received packets from what was
sent when the source or destination is in a multihomed site (a site that
has multiple prefixes) or when the mapping tables contain prefixes with
incorrect C bits.

This requires a change to TCP's connection block lookup algorithm for
received segments.

Assuming that TCP keeps a single table of connection blocks identifying
connections to both IPv4 hosts and SIPP hosts, the change can be
summarized like this:

1)  If the format of the received packet is IPv4, then:

        use the source and destination IP addresses in the received
        packet to compare with the low-order 32 bits of the SIPP source
        and destination address in TCP's connection block table,

2)  If the format of the received packet is SIPP, then:

    2a)  If the C-bit of the SIPP source address is 1, then:

        use the low-order 32 bits of the SIPP source and destination
        addresses in the packet to compare the low-order 32 bits of the
        SIPP source and destination address in the connection block
        table,

    2b)  If the C-bit of the SIPP source address is 0, then:

        use the full SIPP source and destination addresses in the packet
        to compare with the full SIPP source and destination addresses in
        the connection block table.

The host should implement this same algorithm in UDP if UDP supports the



draft-ietf-sipp-ipae-transition-00.txt                         [Page 40]

INTERNET-DRAFT             IPAE Specification              November 1993


notion of a connected endpoint.  In addition, any user-level UDP
applications that use IP addresses to match replies with requests should
implement a similar algorithm.


6.4. ICMP Error Messages.

6.4.1. Sending ICMP Error Messages.

All of the ICMP error messages include an "offending packet" in the data
part of the message.  The "offending packet" is the internet header plus
at least the first 8 bytes of the packet that caused the error being
reported.  The offending packet is used by the recipient of the ICMP
error message to locate the transport-layer endpoint that caused the
error.

When sending ICMP error messages, the IPAE host must take into account
the C-bit of the intended recipient, and make sure that the offending
packet is in a form (IPv4 or SIPP) that the recipient understands.  This
is not always straightforward.  If the C-bit of the recipient is 1, then
the offending packet must be in the IPv4 form.  But since IPAE
translators may translate packets sent from IPv4 hosts into SIPP form,
it is possible that the packet that caused the error might be in the
SIPP form, even though the source was an IPv4 only host.  (The IPAE host
knows this because the C-bit of the Source SIPP address is 1.)  When
this happens, the IPAE host must "generate" an IPv4 header for use in
the offending packet part of the ICMP error message.  The IPAE host can
use the information in the SIPP header of the packet that actually
caused the error to generate the IPv4 header.  Since the offending
packet is going to be used by the recipient to identify a connection,
the address fields must be correct.  The IPAE host can the IPv4 header
of the offending packet from the received SIPP packet in the same way
that an IPAE translator translates SIPP to IPv4:

        Version:

                4

        IP Header Length in 32 bit words:

                5

        Type of Service:

                0

        Total Length:




draft-ietf-sipp-ipae-transition-00.txt                         [Page 41]

INTERNET-DRAFT             IPAE Specification              November 1993


                Payload length from SIPP header + 20

        Identification:

                If SIPP fragmentation option is present, copy low-order
                16 bits from ID field.  Otherwise generate a unique
                value for every packet.

        Flags:

                If SIPP fragmentation option is present, set MF bit if
                More bit is set in option.  If the SIPP fragmentation
                option is not present, and the C-bit is set in the
                source address, then set the DF bit.

        Fragment offset:

                If SIPP fragmentation option is present, copy the
                fragment offset value from the option.

        Time to Live:

                Hop limit field copied from the SIPP header.

        Protocol:

                Payload type value copied from SIPP header or, if known
                SIPP options are present, from last SIPP option header.

        Header Checksum:

                Calculate the header checksum.

        Source Address:

                Copy the low-order 32-bits of the SIPP source address.

        Destination Address:

                Copy the low-order 32 bits of the SIPP destination
                address.

The resulting ICMP error message can be sent within an IPv4 header (if
the destination is within the same site), or within a SIPP header (if
the destination is located in another site).  Thus the following two
header configurations are possible:





draft-ietf-sipp-ipae-transition-00.txt                         [Page 42]

INTERNET-DRAFT             IPAE Specification              November 1993


        +------------+                  +------------+
        |   SIPP     |                  |   IPv4     |
        |   Header   |                  |  Header    |
        +------------+                  +------------+
        |   ICMP     |                  |   ICMP     |
        |   Header   |                  |   Header   |
        +------------+                  +------------+
        |"Generated" |                  |"Generated" |
        |   IPv4     |                  |   IPv4     |
        | Header of  |                  | Header of  |
        | offending  |                  | offending  |
        |  packet    |                  |  packet    |
        +------------+                  +------------+
        |  Transport |                  |  Transport |
        |  Header    |                  |  Header of |
        |  Offending |                  |  Offending |
        |   Packet   |                  |   Packet   |
        ~~~~~~~~~~~~~~                  ~~~~~~~~~~~~~~

Sending ICMP error messages to destinations whose addresses have their
C-bit set to 0 is simpler.  Both the header of the offending packet and
the header of the ICMP message are of the SIPP form:

        +------------+
        |   SIPP     |
        |   Header   |
        +------------+
        |   ICMP     |
        |   Header   |
        +------------+
        |   SIPP     |
        |   Header   |
        | (offending |
        |   packet)  |
        +------------+
        |  Transport |
        |  Header    |
        | (Offending |
        |   packet)  |
        ~~~~~~~~~~~~~~

6.4.2 Receiving ICMP Error Messages.

IPAE hosts must be prepared to receive ICMP error messages encapsulated
within either SIPP or IPv4 headers.  They must also be able to decode
the "offending packet" within the ICMP error message that is in either
the SIPP or IPv4 header format.  They must use the same connection
matching rules spelled out in section 6.3 to match the "offending



draft-ietf-sipp-ipae-transition-00.txt                         [Page 43]

INTERNET-DRAFT             IPAE Specification              November 1993


packet" in the received ICMP error message with an existing TCP
connection or UDP endpoint.

6.5. Transport API changes.

Most IPv4 systems that are modified to support SIPP will already have an
existing application program interface (API) through which applications
use TCP and UDP.  These APIs typically carry a 32 bit IPv4 address in
order to bind a TCP or UDP endpoint to a local address, to specify the
destination address of a UDP datagram being sent, or to specify the
destination address of a TCP connection being opened.  The 32 bit IPv4
address shows up in other parts of the API, such as the return value
from a hostname-to-IPv4 address lookup function.  Generally, these APIs
provide fixed-size fields to hold IPv4 addresses and TCP and UDP port
numbers.  For the most part, these APIs must modified be to carry 64-bit
addresses in order to support SIPP.

The IPAE mechanism does not impose any specific requirements on how the
the APIs in a IPAE system should be changed to support SIPP.  However,
we offer here some general considerations in designing these new APIs.

Some desirable features of a SIPP API are:

  1)    The new API should allow applications to pass in both 32-bit
        IPv4 addresses and 64-bit SIPP addresses.  Even new applications
        may encounter 32 bit IPv4 addresses.  The API should allow the
        program to pass these addresses in.

  2)    The new API should provide both source and binary compatibility
        with the existing IPv4 API.  Applications written to the old API
        should continue to operate when run in binary form, or when
        re-compiled on an IPAE system with the new API.

  3)    Un-modified applications should provide as much SIPP service as
        possible.

  4)    Applications that do not manipulate IP addresses (e.g. TCP
        servers) should run without any modifications.

Along with the API changes, application programs that manipulate IP
addresses must usually be modified.  Often these changes can be isolated
to the code that that parses SIPP addresses typed in by users, and the
code that deals with SIPP addresses returned by the name to address
translation functions (DNS lookups).


6.6. IP Addresses Embedded in Application Protocols




draft-ietf-sipp-ipae-transition-00.txt                         [Page 44]

INTERNET-DRAFT             IPAE Specification              November 1993


There are many application protocols layered above TCP and UDP.  Some of
them carry IPv4 addresses as part of their protocol.  We have examined
the most popular application layer protocols, considering for each how
IPAE hosts would interoperate with IPv4 hosts, and with each other,
using these protocols.  In this section, we specify how IPAE hosts
should use existing application protocols.

This section addresses only application layer protocols.  The internet
routing protocols, control protocols, transport protocols, or layering
(e.g. IP over appletalk) protocols which carry IPv4 addresses are
specific to IPv4 and would not require any change for IPAE.  SIPP
versions may be developed, but that will be addressed in other
documents.

The application protocols that we analyzed fell into four categories:

   1)   Application protocols that do not carry embedded IPv4 addresses.
        These protocols can be used immediately between IPAE and IPv4
        systems and between IPAE systems.  They require no change.

   2)   Application protocols that carry IPv4 addresses, but the
        protocol or its use of IPv4 addresses is obsolete.  These
        protocols do not need to be changed.  They can continue to be
        used between IPAE and IPv4 systems and between IPAE systems
        indefinitely.

   3)   Application protocols that carry IPv4 addresses, but that are
        used exclusively by IPv4 systems, or the IPv4 parts of IPAE
        systems.  These protocols also do not need to be changed,
        although new versions of them may be necessary in order to
        support the same function in SIPP and IPAE systems.

   4)   Application protocols that carry IPv4 addresses, but that are
        not IPv4 specific.  Only one protocol, FTP, fell into this
        category.  FTP provides its full functionallity when used
        between IPv4 and IPAE systems, and that provide a subset of that
        functionallity when used among IPAE systems.  It will have to be
        extended in order to provide its full functionallity among SIPP
        and IPAE systems.

Most of the application layer protocols that we examined fell into the
first category.  These protocols, which require no change at all to be
used between IPAE and IPv4 systems, are:

        Telnet (RFC 854, RFC 855)
        SMTP (RFC 821)
        TFTP (RFC 1350)
        BSD "rlogin" protocol (RFC 1282)



draft-ietf-sipp-ipae-transition-00.txt                         [Page 45]

INTERNET-DRAFT             IPAE Specification              November 1993


        BSD "rsh" protocol (note: passes port number, bug not IP addr)
        BSD "biff" protocol (in.comsat)
        BSD "lpr" protocol (RFC 1179)
        BSD "syslog" protocol
        ONC RPC protocol (RFC 1057)
        ONC original "portmap" protocol (documented in RFC 1057)
        ONC+ new "rpcbind" protocol (replaces portmap)
        Echo  - TCP and UDP (RFC 862)
        Discard - TCP and UDP (RFC 863)
        Chargen - TCP and UDP (RFC 864)
        Quote of the Day - TCP and UDP (RFC 865)
        Active users - TCP or UDP (RFC 866)
        Daytime - TCP or UDP (RFC 867)
        Time - TCP or UDP (RFC 868)
        Nicname/Whois (RFC 954)
        Finger (RFC 1288)
        DNS mail routing (RFC 974)
        SNMP (RFC 1157)
        POP3 (RFC 1225)
        Concise-MIB (RFC 1212)
        Content type mail header field (RFC 1049)
        MIME (RFC 1341)
        NNTP (RFC 977)
        BSD "rexec" protocol
        NTP (RFC 1119)
        NFS

A few protocols fell into the second category.  These protocols -- which
carry IPv4 addresses, but do not need to be changed because their use of
IPv4 is obsolete -- are:

        Mail (RFC 822)
        BSD "talk" protocol

More protocols fell into the third category.  They are used only by IPv4
systems, and may need to be revised in order to provide a similar
function between SIPP systems:

        SMI (RFC 1155)
        MIB-II (RFC 1213)
        IP Forwarding table MIB (RFC 1354)
        RARP (RFC 903)
        BOOTP (RFC 951, RFC 1084)
        DHCP (RFC 1531)
        PPP IP address negotiation options
        ONC "bootparams" RPC protocol
        DNS (RFC 1034, RFC 1035)




draft-ietf-sipp-ipae-transition-00.txt                         [Page 46]

INTERNET-DRAFT             IPAE Specification              November 1993


The one protocol in the fourth category, which will need to be extended
in order to provide full functionallity to SIPP systems, is:

        FTP (RFC 959)

We did not have enough information to evaluate two application
protocols:

        Kerberos        (Where are the complete protocol spec?)
        Telnet options  (Is there a complete list of all options?)

The remainder of this section discusses how IPAE systems should use the
IPv4 address carrying application protocols.

6.6.1. FTP

IPv4 addresses are encoded in FTP in two places:

  -     the arguments to the PORT command.
  -     the reply to the PASV command.

Both the argument to the PORT command and the reply to the PASV command
contain a 32-bit IPv4 address and a 16-bit TCP port number.

These commands are used for two specific purposes:

  1)    In a 2-party FTP transaction, the client uses the PORT command
        to specify a TCP port number on the client's machine other
        than the default (port 20) for the server to connect back to
        the client on.

  2)    In a 3-party FTP transaction involving one client FTP and two
        server FTPs.  The client gives the PASV command command to FTP
        server 1 and records the address reply.  Then it sends the
        PORT command command to FTP server 2, giving the address
        returned by server 1.  Then it sends the STOR or RETR command
        to server 2 to transfer file(s) directly between server 1 and
        server 2.

IPAE hosts must implement the algorithm below, which provides complete
interoperability for 2-party FTP transactions between IPv4 hosts and all
other IPAE hosts.  It also provides interoperability for 3-party FTP
transactions with other IPv4 and IPAE hosts within the same IPAE site.
This algorithm does not allow 3-party FTP transactions among hosts in
different IPAE sites.  Such a feature could be provided by modifying the
FTP protocol, but such a change is outside the scope of this document.

In a 2-party FTP, the client may generate PORT commands of the form:



draft-ietf-sipp-ipae-transition-00.txt                         [Page 47]

INTERNET-DRAFT             IPAE Specification              November 1993


        PORT a1,a2,a3,a4,p1,p2

The semantics of this are that the bytes a1, a2, a3 and a4 are the
low-order 32 bits of the 64 bit SIPP address that the server should
connect to.  The high-order 32-bits of the SIPP address that the server
should connect to are communicated implicitly: they are the high-order
32 bits of the client's SIPP address used in the FTP control connection.
Thus the FTP client can communicate any SIPP address in the PORT command
so long as the high-order 32 bits of that address are the same as the
client-side address of the control connection.  The client may
communicate the SIPP address of any of its SIPP interfaces so long as
all of those addresses share the same high-order 32 bits as the control
connection.  If a host is multi-homed in multiple SIPP sites (i.e. it
has multiple SIPP interfaces with different high-order 32 bits), it can
not communicate the addresses of those interfaces connected to different
sites.

The FTP server, when it receives a PORT command composes the 64 bit SIPP
address to connect back to by concatenating the 32 high-order bits of
the client's address of the control connection with the low-order 32
address bits passed in the PORT command.

An FTP server generates a replies to the PASV command with the form:

        227 Entering Passive Mode. a1,a2,a3,a4,p1,p2

The bytes a1, a2, a3, and a4 are the low-order 32 bits of the 64 bit
SIPP address that the client can connect to the server on.  The
high-order 32 bits of the connect address are communicated implicitly:
they are the high-order 32 bits of the SIPP address of the server side
of the control connection.  The server may return any 64 bit SIPP
address in its PASV reply that shares the same high-order 32 bits as the
server side of the control connection.  Thus, for example, it can return
the address of any other interface on the server that is in the same
SIPP site, but may not return the address of interfaces that are in
other SIPP sites.

A client FTP may initiate a 3-party FTP *only* if the SIPP addresses of
all three participants -- the FTP client, server 1 and server 2 -- share
the same high-order 32 bits.

6.6.2. Mail (RFC 822)

The only place where IPv4 addresses appear in the RFC 822 mail header
format is in the "domain literal" address construct.  It is possible to
specify a domain address as a dotted-decimal address.  For example, one
could specify:




draft-ietf-sipp-ipae-transition-00.txt                         [Page 48]

INTERNET-DRAFT             IPAE Specification              November 1993


        Gilligan@[192.9.9.1]

This construct is specified in section 6.2.3 of RFC 822.

The spec includes the following warning:

        Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.  It
               is  permitted  only  as  a means of bypassing temporary
               system limitations, such as name tables which  are  not
               complete.

In IPAE, we continue the campaign to "discourage" the domain-literal
address construct by not modifying its syntax to support 64 bit SIPP
addresses.  IPAE hosts may continue to use the domain-literal address
format as specified in RFC 822.  However, this format specifies only a
32 bit IPv4 address and not a SIPP address.  IPAE hosts that parse a
domain-literal address treat the resulting 32-bit IPv4 address the same
as if they had parsed a domain name that translated (via a DNS lookup
that returned an "A" record) to a 32-bit IPv4 address.

Thus domain literal addresses will still be useful globally so long as
IPv4 addresses are globally unique.  After IPv4 addresses are no longer
globally unique, the domain literal form can still be used within a SIPP
site.

6.6.3. Domain Name System (DNS)

There are two places within the DNS where IPv4 addresses are encoded:

  -     The "A" record format.
  -     The structure of the "in-addr.arpa" tree.

A new address record is being defined to hold 64-bit SIPP addresses.
This new record is specified in another document [SIPPDNS].  There is no
need to change the existing "A" record format or the "in-addr.arpa"
tree.  They can continue to be used by IPv4 systems for as long as
necessary.  IPAE hosts can use the A records and "in-addr.arpa" in
addition to the new 64-bit SIPP address records and reverse lookup tree.

6.6.4. SMI, MIB-II, Forwarding Table MIB

The SMI RFC defines a data type for the 32-bit IPv4 address.  This type
is named "IpAddress". The MIB-II and some other MIBs use this data
structure.  These definitions can remain unchanged and can continue to
be used by IPv4 hosts and routers.  Management stations running on IPAE
hosts can continue to use these definitions when managing IPv4 hosts and
routers.  IPAE hosts and routers may choose to continue to support the
IPv4-based MIBs in order to provide meaningful information to the



draft-ietf-sipp-ipae-transition-00.txt                         [Page 49]

INTERNET-DRAFT             IPAE Specification              November 1993


installed base of management stations.

For SIPP and IPAE systems, a new data type for the 64-bit SIPP address
will need to be defined.  All of the MIBs that include IP address data
types (at least MIB-II and the Forwarding table MIB) will need to be
revised for SIPP and IPAE systems.  In addition, a MIB will need to be
defined for the mapping table stored on IPAE translators.

6.6.5. RARP, BOOTP, DHCP, Bootparams

RARP, BOOTP, DHCP, and Bootparams are all used to support booting.
RARP, BOOTP, and DHCP all provide a mechanism for a host to acquires its
own IPv4 address.  These protocols can continue to be used without
change by IPv4 systems.

These protocols can be used without change to provide limited service to
IPAE systems.  The Bootparams protocol carries 32-bit IPv4 addresses in
two places: The "whoami" RPC returns the 32-bit IPv4 address of a
default router, and the "getfile" RPC returns the 32-bit IPv4 address of
a file server.  IPAE systems can use the whoami call to learn their
default IPv4 router address.  IPAE systems should use the SIPP router
discovery mechanism to learn the addresses of SIPP routers.  IPAE hosts
can continue to use the getfile call to communicate with IPv4 or IPAE
file servers within the local site.

In order to provide their full functionallity to SIPP and IPAE systems,
these three protocols will have to either be revised to return 64-bit
SIPP addresses, or incorporated into a new host configuration scheme.
SIPP host configuration is being addressed in another spec [SIPPDISC].
The ONC RPC system includes a versioning mechanism that should allow us
to revise the bootparams protocol in a compatible way.

6.6.6. BSD talk protocol.

This protocol is obsolete.  We make no attempt to convert it to SIPP.
















draft-ietf-sipp-ipae-transition-00.txt                         [Page 50]

INTERNET-DRAFT             IPAE Specification              November 1993


Appendix 1. Definitions

IPv4:

        The Internet Protocol, version 4.  This is the version of the
        Internet Protocol specified in RFC 791.

SIPP:

        The Simple Internet Protocol Plus.  This is the working name
        for the next generation Internet Protocol being designed by
        the IETF SIPP working group.  If SIPP is accepted as the next
        generation IP, it will likely be re-named simply IP.

IPAE:

        The set of protocols and operational techniques that provide
        interoperability between IPv4 and SIPP systems, and transition
        the Internet from IPv4 to SIPP.  The acronym "IPAE" no longer
        stands for anything.

IPAE Address:

        A 64-bit SIPP address that is structured so as to be
        compatible with IPv4.  The format of an IPAE address is:

                 6                   3 3                 0
                 3                   2 1                 0
                +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+-+
                |C|   Site Prefix     |    IPv4 Address   |
                +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+-+

        An IPAE address has three components:

                C-bit           Encodes whether the entity addressed
                                supports SIPP or not.

                Site Prefix     Uniquely identifies the IPAE site that
                                the addressed entity is located in.

                IPv4 Address    Uniquely identifies the addressed entity.

IPAE Host:

        A host adhering to both the SIPP specifications and the IPAE
        specifications.  An IPAE host is capable of sending and
        receiving packets in any of the three packet formats - IPv4,
        SIPP, and IPAE.



draft-ietf-sipp-ipae-transition-00.txt                         [Page 51]

INTERNET-DRAFT             IPAE Specification              November 1993



IPAE Packet Format:

        SIPP encapsulated within IPv4.

IPAE Router:

        A router capable of sending, receiving, and processing the
        three packet formats -- IPv4, SIPP and IPAE.  An IPAE router
        also participates in both IPv4 and SIPP routing protocols.

IPAE Site:

        A region of the Internet that contains IPv4 hosts and routes
        IPv4 packets.  An IPAE site typically has at least one IPAE
        router providing SIPP connectivity to the global Internet.

IPAE Translator - or - IPAE Translation Agent:

        An IPAE router that performs the following additional
        functions to support intra-site IPv4-to-IPv4 and IPv4-to-SIPP
        traffic:

           -    Mapping the source and destination addresses of
                locally generated IPv4 traffic into SIPP addresses
                through the use of a mapping table.

           -    Translating headers of locally generated IPv4 traffic
                from IPv4 format to SIPP format.

           -    Translating headers of remotely-generated SIPP traffic
                from SIPP format to IPv4 format.

        IPAE translators must participate in IPv4 and SIPP routing
        to the extent that they receive:

           -    All IPv4 traffic generated within the site destined to
                IPv4 hosts outside the site.  This is usually
                accomplished by pointing an IPv4 default route at the
                IPAE translator.

           -    All SIPP traffic generated external to the site with
                destination SIPP address of the site with the C-bit
                set.

SIPP-only Host:

        A host that sends and receives *only* the SIPP format.



draft-ietf-sipp-ipae-transition-00.txt                         [Page 52]

INTERNET-DRAFT             IPAE Specification              November 1993


        SIPP-only hosts can not send or receive IPv4 or IPAE format
        packets.

SIPP-only Router:

        A router that sends and receives *only* the SIPP format.
        SIPP-only routers can not send or receive IPv4 or IPAE format
        packets.

SIPP-only Site:

        A region of the Internet that consists of only SIPP or IPAE
        hosts and SIPP routers.  No IPv4 or IPAE traffic will be seen
        in a SIPP-only site.

IPv4-only Host:

        A host that sends and receives only IPv4 format packets.

IPv4-only Router:

        A router that sends and receives only IPv4 format packets.





























draft-ietf-sipp-ipae-transition-00.txt                         [Page 53]

INTERNET-DRAFT             IPAE Specification              November 1993


Appendix 2. The IPv4 to SIPP Transition

The Internet's transition to SIPP takes place in a number of
sequential steps:

  1)    The first IPAE systems are deployed on the Internet.  IPAE
        site boundaries are defined, and the first IPAE site prefixes
        are assigned.  64-bit SIPP address records are added to the
        DNS for each new SIPP system as well as IPv4 systems.

  2)    Backbone SIPP routing topology is designed.  Sites begin to
        deploy IPAE routers.  Backbone SIPP routing runs in parallel
        with IPv4 routing.

  3)    Sites begin to deploy IPAE translators.  Site-internal default
        routes are configured to point to the IPAE translators.  SIPP
        C-bit routes are propagated.  After a IPAE translator has been
        deployed at a site, 64-bit SIPP address records (with C-bit
        on) are added to the DNS for each IPv4 host within that site.

  4)    Deployment of IPAE routers and IPAE translators at every site
        connected to the backbone is complete.

  5)    Backbone IPv4 routing is turned off.  All inter-site
        IPv4-to-IPv4 and IPv4-to-SIPP traffic uses IPAE translators.

  6)    Internet runs out of IPv4 network numbers. IPAE translators
        are de-commissioned.  Inter-site IPv4-to-IPv4 and IPv4-to-SIPP
        traffic is no longer possible.  Intra-site IPv4-to-IPv4 and
        IPv4-to-SIPP traffic can continue indefinitely.





















draft-ietf-sipp-ipae-transition-00.txt                         [Page 54]

INTERNET-DRAFT             IPAE Specification              November 1993


Time            What is Happening
----            -----------------
        |
Today --+
        |       - IPv4 is routed globally.
        |       - All hosts speak IPv4.
        |
 T1  ---+       - First IPAE hosts deployed
        |       - IPAE hosts use IPAE tunneling across the IPv4
        |         infrastructure to reach other IPAE hosts.
        |       - IPAE hosts use IPv4 packet format to communicate with
        |         IPv4 hosts
        |
 T2  ---+       - SIPP routing is started.
        |       - IPAE hosts route intra-site SIPP traffic via IPAE routers.
        |       - IPAE hosts continue to use IPv4 packet format to communicate
        |         IPv4 hosts.
        |
 T3  ---+       - Installation of IPAE translators begins.
        |       - IPAE hosts send SIPP packets to IPv4 hosts in other sites
        |         where translators have been installed.
        |       - IPv4 traffic generated in sites with IPAE translators
        |         and destined for sites with translators is translated.
        |
 T4  ---+       - IPAE routers and translators have been installed in
        |         every site.
        |       - All inter-site IPv4-to-IPv4 and IPv4-to-SIPP traffic
        |         should be using IPAE translators and are carried via
        |         the backbone SIPP routing system.  Only mis-configured
        |         routers use IPv4 backbone routing.
        |
 T5  ---+       - Backbone IPv4 routing is cut.
        |       - Users should not notice any change.
        |       - Mis-configurations are detected and repaired.
        |
        |
 T6  ---+       - IPv4 address "run-out" day.
        |       - Since IPv4 addresses are no longer unique, global
        |         IPv4 connectivity is discontinued.  IPAE translators
        |         are de-commissioned.
        |       - IPv4 hosts continue to have complete connectivity within
        |         their site.
        |       - IPv4 hosts continue to have complete interoperability
        |         with IPAE hosts within their site.
        |       - Remaining IPv4 hosts and routers may be converted to
        |         SIPP at the convenience of their owners, but
        |         conversion is not required.
        |       - Note: introduction of new SIPP services may require



draft-ietf-sipp-ipae-transition-00.txt                         [Page 55]

INTERNET-DRAFT             IPAE Specification              November 1993


        |         conversion of some routers to SIPP.

The transition starts by dividing the existing Internet into a
collection of IPAE sites.  This doesn't involve any physical
re-configuration or re-numbering of the Internet.  We simply take the
existing Internet topology and identify individual regions.  Generally
speaking, a "site" will be a single administrative entity, such as a
University campus or a corporation.

Each site is assigned a unique 32-bit SIPP prefix which comprises a
1-bit C-bit and a 32-bit IPAE site prefix.  These prefixes are selected
based on a global 64-bit SIPP addressing plan to be drawn up.  A 64-bit
SIPP address for each host and router is formed by concatenating the
site's 32-bit prefix with the host or router's previously assigned
32-bit IPv4 address.  The C-bit field of the addresses of all
SIPP-capable hosts and routers is set to 0.  For those hosts and routers
that speak only IPv4, the C-bit is set to 1.

All hosts and routers in the Internet keep their existing IPv4 address
assignments. No IPv4 re-numbering is required.  The Internet continues
to use the CIDR-based IPv4 address allocation scheme.  New IPv4 hosts
and routers can continue to be added during the SIPP transition.

Next, the Internet backbone is converted to route SIPP traffic.  This
can be done by converting all of the routers from the sites into the
backbone and the sites to route SIPP.

Next, an IPAE translator is installed in each site.  The IPAE
translator can be co-resident with the IPAE router.






















draft-ietf-sipp-ipae-transition-00.txt                         [Page 56]

INTERNET-DRAFT             IPAE Specification              November 1993


Appendix 3.  Examples

A3.1.  IPAE Encapsulation

Consider the following topology, which includes two IPAE hosts, two
IPAE routers, and two IPv4 routers:

---+----------------------------------+--- (Subnet A)
   |                                  |
(1404:1:192.9.5.2)                (192.9.5.1)
  IPAE Host H1                     IPv4 Router R1
                                  (192.9.6.1)
                                      |
                     -----+-----------+------- (Subnet B)
                          |
                   (1404:1:192.9.6.17)
                       IPAE Router R2
                   (1404:8:192.9.88.13)
                          |
  -------+----------------+------  (Subnet C)
         |
    (1404:8:192.9.88.3)
      IPAE Router R3
    (1404:8:192.9.89.3)
         |
      ---+-------+----- (Subnet D)
                 |
            (192.9.89.77)
              IPv4 Router R4
            (192.9.123.68
                 |
              ---+-----------------------------+-------- (Subnet E)
                                               |
                                          (1404:8:192.8.123.244)
                                            IPAE Host H2

A UDP datagram is sent from IPAE host A to IPAE host B.  The packet
transits two IPAE tunnels.  One tunnel runs from the source host, H1,
to the IPAE router, R2.  The router R3 sends the packet to router R3
in the raw SIPP packet format.  The packet then rides the second tunnel
from IPAE router R3 to the destination host, H2.

The packet transmitted on Subnet A and Subnet B looks like this:

        IPv4 src = 192.9.5.2
        IPvr dst = 192.9.6.17
        SIPP src = 1404:1:192.9.5.2
        SIPP dst = 1404:8:192.9.123.244



draft-ietf-sipp-ipae-transition-00.txt                         [Page 57]

INTERNET-DRAFT             IPAE Specification              November 1993


The packet as transmitted on Subnet C looks like this:

        SIPP src = 1404:1:192.9.5.2
        SIPP dst = 1404:8:192.9.123.244

The packet as transmitted on Subnet D and Subnet E looks like this:

        IPv4 src = 192.9.89.3
        IPvr dst = 192.9.123.244
        SIPP src = 1404:1:192.9.5.2
        SIPP dst = 1404:8:192.9.123.244








































draft-ietf-sipp-ipae-transition-00.txt                         [Page 58]

INTERNET-DRAFT             IPAE Specification              November 1993


Appendix 4.  Design Decisions

This section explains the reasoning behind some of the decisions made in
the design of IPAE.

A4.1.  The C-bit.

Question: The C-bit wasts a full bit in the address space, effectively
halving its size.  Why not just define a single prefix for IPv4 hosts (A
C-prefix instead of a C-bit)?

Answer: The C-bit as it is defined allows IPv4 traffic to have the same
benefits of scaling that SIPP traffic enjoys.  Since intra-site IPv4
traffic is translated early on into SIPP form by the IPAE translators,
it is routed over the backbone by its 64 bit SIPP destination address,
not its 32-bit IPv4 address.  The 64-bit SIPP addresses that the IPAE
translators convert the IPv4 addresses into have the same hierarchical
structure as SIPP hosts.

We viewed the near-term benefits of route scaling for IPv4 traffic as
outweighing the cost of the C-bit in terms of address space.

A4.2.  Global vs. Local scope for C-bit.

Question: Why wasn't the C-bit defined with local scope?  That way it
could C-bits could be recycled after a site was completely converted
to SIPP.

Answer: That was one of our early designs. However, we quickly found
that there the C-bit could be used in a number of different places.
To limit the C-bit to local scope, we would have to change each of
those places where we use the C-bit.



















draft-ietf-sipp-ipae-transition-00.txt                         [Page 59]

INTERNET-DRAFT             IPAE Specification              November 1993


Appendix 5.  Open Issues

In this section, we discuss those issues that are not yet decided.

A5.1. How is the DF bit handled?

How should the IPAE translators handle IPv4 packets that arrive with
the DF bit set?


A5.2. Should we map IPv4 TOS bits into a flow ID?

When translating IPv4 to SIPP, should the IPAE translators map the
8-bit IPv4 TOS field into the SIPP flow ID?


A5.3.  How should we set the ID field?

The IPv4 header has an ID field that is used by the receiving host
when re-assembling fragments.  In order to ensure proper reassembly,
the IPv4 ID field must be unique per IP source and destination
address.  When a SIPP packet is translated into an IPv4 packet for
delivery to an IPv4 host, the IPv4 ID field must be generated by the
IPAE translator.  The translator can generate an ID field that is
unique relative to itself.  However, it is possible that datagrams
from one source host to one destination source might be translated by
more than one IPAE translator.  If more than one translator translates
packets from this host pair, fragments of different IPv4 packets might
end up with the same ID field.

There are a  number of potential solutions to this problem:

  1)    Allow only one IPAE translator per site.

  2)    Have the IPAE translators choose random ID values
        for each packet.

  3)    Have the IPAE translators choose per-destination unique
        values that start with a random seed.

A5.4.  ICMP error message handling?

How should an IPAE translator deal with IPv4 ICMP error messages
returned for "last hop" packets translated from SIP to IPv4 and then
sent by an IPAE translator?  How should they deal with SIPP ICMP error
messages returned for packets translated from IPv4 to SIP by the IPAE
translator?




draft-ietf-sipp-ipae-transition-00.txt                         [Page 60]

INTERNET-DRAFT             IPAE Specification              November 1993


One solution is to have the IPAE translators translate both the IPv4
or SIPP headers of the ICMP message, as well as the IPv4 or SIPP
headers of the "offending packet" that is within the ICMP error
message.  This would be possible to implement, but would be complex.
It would be nice if we could find a simpler solution.

A5.5 IPv4 path mtu discovery when encapsulating.

Section 4.3 states that the Don't fragment bit should always be set in the
IPv4 header when encapsulating SIPP (in order for the encapsulator to track
the tunnel mtu so that it can generate SIPP ICMP errors back to the source).

Should we allow simple IPAE hosts to send IPAE packets without performing IPV4
path MTU discovery?

A5.6 Determining "improvements" in tunnel state

Can the mechanism to discard stale tunnel state in an encapsulating
host or router be a simple periodic discarding of the timer state or
should we use more sophisticated algorithms?

A more elaborate scheme would be to count the number of 1) datagrams
that should have generated a certain ICMP error and 2) the actual
number of such ICMP errors received, and discarding the state when the
ratio between them exceeds some value.


























draft-ietf-sipp-ipae-transition-00.txt                         [Page 61]

INTERNET-DRAFT             IPAE Specification              November 1993


Security Considerations

Security issues are not discussed in this document.


References

[CIDR]          Classless Inter-Domain Routing (CIDR): an Address
                Assignment and Aggregation Strategy. Fuller, V.; Li,
                T.; Yu, J.; Varadhan, K.; September 1993.  RFC 1519

[SIPP]          Simple Internet Protocol Plus Specification.  To be
                published.

[IP]            Internet Protocol. Postel, J.B.  September 1981.  RFC
                791.

[RFC793]        Transmission Control Protocol. Postel, J.B. September
                1981. RFC 793.

[RFC768]        User Datagram Protocol. Postel, J.B. August 1980.
                RFC-768.

[SIPPDNS]       SIP addresses in the domain name service
                specifications, Internet Draft, 06/11/1993,
                <draft-ietf-sip-dnss-00.txt>

[SIPPCONF]      SIP System Discovery, Internet Draft, 06/09/1993,
                <draft-ietf-sip-discovery-02.txt>



Authors' Address

        Robert E. Gilligan
        Sun Microsystems, Inc.
        2550 Garcia Avenue
        Mailstop UMTV05-44
        Mountain View, California 94043-1100

        415-336-1012

        bob.gilligan@eng.sun.com








draft-ietf-sip-ipae-transition-00.txt                          [Page 62]