One document matched: draft-yliteo-mobileip-paid-00.txt
Internet Engineering Task Force Y. Li
INTERNET DRAFT Bay Networks, Inc.
W. T. Teo
National University
of Singapore
18 January 1998
IP Private Address Identification (PAID)
draft-yliteo-mobileip-paid-00.txt
Status of this Memo
This document is a submission to the Mobile-IP Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the mobile-ip@smallworks.com mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This memo proposes a scheme to conserve the IPv4 address space by
allowing to allocate private instead of public IP addresses for its
internet hosts. These internet hosts can achieve complete internet
connectivity between any domains with each private host globally
identified as a <public, private> address pair. To enable private
hosts to communicate using these address pairs efficiently, we
propose a PAID Encapsulation protocol. To acquire a <public, private>
address pair, we specify a variant registration method derived from
Mobile IP, using a PAID Registration Request and PAID Registration
Reply. This approach requires modifications to network sockets and
enhancements to the domain name system.
Li, Teo Expires 17 July 1998 [Page i]
Internet Draft IP Private Address Identification 18 January 1998
1. Introduction
Many enterprises are employing network applications based on the IP
platform due to the widespread availability of such software. With
the current exponential growth of Internet hosts, the IPv4 address
space is rapidly being depleted. Enterprises can however utilize
private (in contrast to public) IP addresses to run their network
applications. But private addresses due to their nature restrict the
network spans to within the enterprises themselves.
The inaccessibility of private networks with foreign domains is
because the destination IP address of a datagram generally determines
the routing path taken. As a private address is not globally unique,
traffic destined to a private node from beyond the private network
will be undeliverable.
To allow a private node access to a foreign host, the IP network
address translator (NAT [6]) provides a means to convert between
private addresses and public addresses. However, there are a number
of limitations to this approach: it requires a sparse end-to-end
traffic matrix; it increases the probability of mis-addressing; it
breaks certain applications; it hides the identity of communicating
hosts.
Morever, it is not possible for foreign hosts to access a private
host without the use of application gateways. These methods generally
requires tunneling, both the routing domains to be known beforehand,
the private IP addresses between the communicating domains to be
unique or static configurations at the application gateways to
deliver the traffic to the private host.
This document proposes that a private node register its own address
with a public node. This latter will receive traffic from a public
IP tunnel over the Internet on behalf of the private node and then
forward the traffic to the node. Therefore, this <public, private>
address pair is taken as the identification (PAID) of the private
node over the global Internet. The public node is called PAID agent.
To efficiently identify the PAID sources and PAID destination in
datagrams between private hosts, the document proposes a PAID
Encapsulation protocol. This encapsulation method also reduces the
overhead in multiple encapsulations.
To locate a PAID agent, we specify a PAID agent discovery protocol.
To acquire a <public, private> address pair, we derive a new variant
registration method from Mobile IP [1], using a PAID Registration
Request and PAID Registration Reply. With the registration, a private
node is able to automatically acquire a global identification.
Li, Teo Expires 17 July 1998 [Page 1]
Internet Draft IP Private Address Identification 18 January 1998
Private nodes that only require access to foreign servers but do not
provide service to foreign clients can continue to employ NAT [6] to
access domains that do not support PAID. Therefore, internet
connectivity of the private hosts can expand with PAID deployment
without sacrificing an organization's access to internet resources.
The primary advantage in the PAID approach is that all private hosts
in a domain can be accessed by public or private nodes in other
domains, and even hosts in different domains but with the same
private address can communicate with each other. Additionally, PAID
provides an easy migration path to enable internet connectivity for
private intranets or the formation of extranets, without the need to
renumber the network machines.
Many other benefits can be gained from using private addresses that
are not allocated by a central registration body. An organization has
more flexibilty during network deployment and expansion using the
large number of private addresses available.
The disadvantage with this approach is that, network applications
have to be modified, and the domain name system has to be enhanced.
2. Applicability
=============== WAN ============== Public Internet ======= WAN =======
. | . . . . . . . . . . .|. . . . . . . . . .| .
Public . | ..........|...................|..........
192.32.174.44 | :200.9.1.1| Public 200.9.2.1| . :
. . . . .+---------+ : +----+---+ +------+------+ :
.+-------| ISP Rtr |--+ : |Router A| | Router B | :
.| +-+-----+-+ | : +----+---+ +--+---+---+--+ :
.| | | | : | | | . | :
.| | | | : | | | . | :
............. ............... : ............. ............... :
: . : : : : : : : . : :
: Private : : Private : : : Private : : Private : :
: Network : : Network : : : Network : : Network : :
:192.168.0.0: : 10.0.0.0 : : :192.168.0.0: : 10.0.0.0 : :
:255.255.0.0: : 255.0.0.0 : : :255.255.0.0: : 255.0.0.0 : :
: : : : : : : : : :
: 256x256 : : 256x256x256 : : : 256x256 : : 256x256x256 : :
: addresses : : addresses : : : addresses : : addresses : :
:...........: :.............: : :...........: :.............: :
: :
: Enterprise Virtual Private Network :
: (VPN) :
:.......................................:
Figure 1 Private Nodes Communicate with Each Other Using PAID
Li, Teo Expires 17 July 1998 [Page 2]
Internet Draft IP Private Address Identification 18 January 1998
Private Address Identification (PAID) is intended to enable private
nodes to communicate globally. For example, a private host in an ISP
network is able to access a public or private HTTP server in an
enterprise network, and a public or private host outside an ISP
network can access a private HTTP server in the ISP network.
Figure 1 is a typical network deployment over the Internet.
For example, a private host 10.10.10.10 in the ISP network can talk
to a private host 10.20.20.20 in the enterprise VPN by using an ISP
address pair <192.32.174.44, 10.10.10.10> and an enterprise address
pair <200.9.2.1, 10.20.20.20>. To enable this functionality, these
two private hosts should use PAID encapsulation and decapsulation.
Also, the ISP router, router A and router B should support the PAID
encapsulation protocol. All other routers will remain with running
conventional routing protocols.
Li, Teo Expires 17 July 1998 [Page 3]
Internet Draft IP Private Address Identification 18 January 1998
2. Terminology and Definitions
2.1 Private Node
A node where all its interface addresses are private as specified in
RFC 1918 [9].
2.2 Public Node
A node which has at least one public interface address. The public
address is in contrast to the private address [9].
2.3 Identification of Private Address (PAID)
A private node, when attempting to enable global communication, can
register its own address with a public node. The <public, private>
address pair is called the identification of the private node, or
PAID for short, over the global Internet.
In Figure 1, <192.32.174.44, 10.10.10.10> is a PAID of the private
host 10.10.10.10 in the ISP network, and <200.9.2.1, 10.20.20.20> is
a PAID of the private host 10.20.20.20 in the enterprise VPN.
2.4 PAID Agent
A PAID agent is a node that provides private nodes with the public
portion of the identifications for the private nodes. It will tunnel
traffic between a private node in the same domain and a node in
another domain.
In Figure 1, the ISP router is a PAID agent for the private host
10.10.10.10 in the ISP network, and the router B is a PAID agent for
the private host 10.20.20.20 in the enterprise VPN.
From the standpoint of routing and security, the PAID agent should be
chosen from domain border routers or backbone routers.
2.5 PAID Agent Address
A PAID agent address is referred to as an interface address that is
public.
Li, Teo Expires 17 July 1998 [Page 4]
Internet Draft IP Private Address Identification 18 January 1998
3. PAID Encapsulation Protocol
Encapsulation is suggested as a means to alter the normal IP routing
for datagrams, by delivering them to an intermediate destination that
would otherwise not be selected by the (network part of the) IP
Destination Address field in the original IP header.
The process of encapsulation and decapsulation of a datagram is
frequently referred to as "tunneling" the datagram, and the
encapsulator and decapsulator are then considered to be the
"endpoints" of the tunnel; the encapsulator node is referred to as
the "entry point" of the tunnel, and the decapsulator node is
referred to as the "exit point" of the tunnel.
The Minimal Encapsulation for IP [3] is an encapsulation mechanism
that eliminates unnecessary duplication required by other
encapsulation mechanisms, such as IP Encapsulation within IP [2] and
Generic Routing Encapsulation [8]. However, the minimal encapsulation
does not really save any space for PAID. Also, with the existing
encapsulation mechanisms, it is difficult to identify the private
source, public source, private destination and public destination
from a received packet.
3.1 PAID Encapsulation
A PAID forwarding header is defined for datagrams to be originated.
PAID encapsulation must not be used when an original datagram is
already fragmented, since there is no room in the PAID forwarding
header to store fragmentation information. To encapsulate an IP
datagram using PAID encapsulation, the PAID forwarding header is
inserted into the datagram, as follows:
+---------------------------+ +---------------------------+
| | | |
| IP Header | | Modified IP Header |
| | | |
+---------------------------+ ====> +---------------------------+
| | | PAID Forwarding Header |
| | +---------------------------+
| IP Payload | | |
| | | |
| | | IP Payload |
+---------------------------+ | |
| |
+---------------------------+
Li, Teo Expires 17 July 1998 [Page 5]
Internet Draft IP Private Address Identification 18 January 1998
The IP header of the original datagram is modified, and the PAID
forwarding header is inserted into the datagram after the IP header,
followed by the unmodified IP payload of the original datagram (e.g.,
transport header and transport data). No additional IP header is
added to the datagram.
In encapsulating the datagram, the original IP header [5] is modified
as follows:
- The Protocol field in the IP header is replaced by protocol
number 56 for the PAID encapsulation protocol.
- The Destination Address field in the IP header is replaced by the
IP address of the exit point of the tunnel.
- If the encapsulator is not the original source of the datagram,
the Source Address field in the IP header is replaced by the IP
address of the encapsulator.
- The Total Length field in the IP header is incremented by the
size of the PAID forwarding header added to the datagram.
- The Header Checksum field in the IP header is recomputed [5] or
updated to account for the changes in the IP header described
here for encapsulation.
Note that like minimal encapsulation, the Time to Live (TTL) field
in the IP header is not modified during encapsulation; since this
encapsulation is performed at the datagram origination, the
encapsulator will not decrement the TTL.
3.2 Format of PAID Forwarding Header
The format of the PAID forwarding header is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol |D|S| Reserved | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (if present) Private Destination Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (if present) Private Source Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Li, Teo Expires 17 July 1998 [Page 6]
Internet Draft IP Private Address Identification 18 January 1998
Protocol
Copied from the Protocol field in the original IP header.
D bit
If set, the private destination PAID is present.
S bit
If set, the private source PAID is present.
Reserved
Sent as zero; ignored on reception.
Header Checksum
The 16-bit one's complement of the one's complement sum of all
16-bit words in the PAID forwarding header. For purposes of
computing the checksum, the value of the checksum field is 0.
The IP header and IP payload (after the PAID forwarding header)
are not included in this checksum computation.
Public Destination Address
The address of a public destination node, or the PAID agent
address of a private destination node. In the case of public
destination node, this is the original destination address.
Public source Address
The address of a public source node, or the PAID agent address
of a private source node. In the case of public source node,
this is the original source address.
Private Destination Address
If present, the address of a private destination node. In the
case of private destination node, this is the original
destination address.
Private Source Address
If present, the address of a private source node. In the case
of private source node, this is the original source address.
Li, Teo Expires 17 July 1998 [Page 7]
Internet Draft IP Private Address Identification 18 January 1998
3.3 PAID Decapsulation
A PAID agent should perform PAID decapsulation in the same way as in
IP encapsulation within IP [2]. The agent should perform PAID
encapsulation without changing the inner PAID forwarding header when
it forwards the decapsulated packet to the destination.
A private or public destination node should decapsulate a received
packet and save the source <public, private> address pair for
subsequent datagram origination.
3.4 ICMP Messages from within the Tunnel
ICMP messages are to be handled as specified in [2], including the
maintenance of tunnel "soft state".
Li, Teo Expires 17 July 1998 [Page 8]
Internet Draft IP Private Address Identification 18 January 1998
4. Datagram Routing with PAID Encapsulation
This section describes how the PAID encapsulation and decapsulation
are performed when no other encapsulation protocols are involved. In
this case, the following nodes should support the PAID encapsulation
protocol:
- private nodes who wish to enable global communication,
- all PAID agents, and
- public nodes who wish to communicate with a private node in
another routing domain.
4.1 An Example of Packet Processing
To better illustrate PAID, we take the same picture from NAT [1]:
\ | /
+---------------+
|Regional Router|
+---------------+
WAN | | WAN
| |
{s2=198.76.28.4,^ | | |{s2=198.76.28.4,
d2=198.76.28.7}| | | v d2=198.76.28.7}
{S=198.76.28.4,^ | | |{S=198.76.28.4,
D=198.76.29.7}| | | v D=198.76.29.7}
{s=10.33.96.5, ^ | | |{s=10.22.96.5,
d=10.81.13.22}| | | v d=10.81.13.22}
+-----------------+ +-----------------+
| PAID Agent | | PAID Agent |
+-----------------+ +-----------------+
| |
| LAN LAN |
------------- -------------
{s2=10.33.96.5, ^ | | |{s2=198.76.28.7,
d2=198.76.28.4}| | | v d2=10.81.13.22}
{S=198.76.28.4,^ | | |{S=198.76.28.4,
D=198.76.29.7}| | | v D=198.76.29.7}
{s=10.33.96.5, ^ | | |{s=10.22.96.5,
d=10.81.13.22}| +--+ +--+ v d=10.81.13.22}
|--| |--|
/____\ /____\
10.33.96.5 10.81.13.22
Figure 2 Datagram Encapsulation and Decapsulation under PAID
Li, Teo Expires 17 July 1998 [Page 9]
Internet Draft IP Private Address Identification 18 January 1998
4.2 Packets Originating from a Private Node To Another Domain
When receiving a packet from a private node, any intermediate
router should never change the PAID forwarding header.
4.2.1 Source Private Node
When a private node generates a packet, it should perform PAID
encapsulation for the packet. In the PAID forwarding header, private
source address field should be present (S bit set). The exit point of
the tunnel should be the PAID agent of the private source node.
4.2.2 Source PAID Agent
When the PAID agent for the source private node receives the packet,
it should replace the source and destination address in the outer IP
header, respectively with its own address and the public destination
address in the PAID forwarding header. This means the packet will be
tunneled to a public destination node or the PAID agent of a private
destination node.
4.2.3 Destination Node
When receiving the packet, the final destination node should save the
source <public, private> address pair for subsequent datagram
origination.
4.3 Packets from a Domain to Private Node in Another Domain
When receiving a packet destined to a private node, any
intermediate router should never change the PAID forwarding header.
4.3.1 Source Node
When a source node originates a packet to a private node in another
routing domain, if it does not have the destination node's PAID, it
may consult relevant DNS servers in the other domain to obtain the
PAID of the private destination node. The method of obtaining PAIDs
this way is beyond the scope of this document.
The source node should perform PAID encapsulation for the packet. In
the PAID forwarding header, private destination address field should
be present (D bit set). The exit point of the tunnel should be the
PAID agent of the source node if the source is a private node, or
otherwise the public destination address in the PAID forwarding
header.
Li, Teo Expires 17 July 1998 [Page 10]
Internet Draft IP Private Address Identification 18 January 1998
4.3.2 Destination PAID Agent
When the PAID agent of the destination private node receives the
packet, it should replace the source and destination address in the
outer IP header, respectively with its own address and the private
destination address in the PAID forwarding header. This means the
packet will be tunneled to the destination private node.
4.4 Packets within the Same Domain
When a packet is destined to a node in the same routing domain, PAID
encapsulation and decapsulation are not required.
4.5 Packets between Public-Public Pair
When a packet is originated from a public node and destined to
another public node, PAID encapsulation and decapsulation are not
required.
Li, Teo Expires 17 July 1998 [Page 11]
Internet Draft IP Private Address Identification 18 January 1998
5. NAT and PAID Compatability
NAT [6] provides a means for private hosts to access the global
Internet. It is dominant in the virtual private networks (VPNs).
PAID is a complement to the NAT. A PAID agent can employ either the
PAID encapsulation protocol or NAT to forward packets from a private
node to a public node, provided the private node tunnels the packets
to the PAID agent by the PAID encapsulation.
As the PAID approach may not be deployed quicky, the use of PAID as
a complement to the NAT will probably help in the transition.
5.1 Source Private Node
The source private node should specify the "forward" field in the
PAID Registration Request message (see section 7.1). If it requests
the PAID agent to employ the PAID encapsulation in forwarding
packets to the destination, the "forward" field should be 0. If it
requests to employ NAT in the forwarding, the field should be 1.
The private should use the PAID encapsulation protocol to tunnel
packets to the PAID agent as specified in section 4.2.1.
5.2 PAID agent
The PAID agent should indicate its support for NAT using N bit in the
PAID Agent Advertisement message (see section 6.2). Supporting PAID
is the minimum requirement.
When the PAID agent receives a PAID Registration Request, it should
verify if it supports the requested forwarding method. If it does not
support, it should deny the request and respond with a PAID
Registration Reply with code set to 72.
If it supports the requested forwarding method, whenever it receives
a packet from the private node, the PAID agent should employ the
relevant method, take the source and destination addresses from the
PAID header, and forward packets to the destination.
Li, Teo Expires 17 July 1998 [Page 12]
Internet Draft IP Private Address Identification 18 January 1998
6. PAID Agent Discovery Protocol
This section describes an optional means for a private node to
discover PAID agents available in the same domain.
A private node may multicast PAID Agent Solicitation messages to
learn the presence of any PAID agents. Each PAID agent, whenever
receiving a Solicitation message, must unicast a PAID Agent
Advertisement message back to the private node.
6.1 PAID Agent Solicitation
A private node may multicast a PAID Agent Solicitation message to
obtain one or more PAID agent addresses. This message should be sent
to the All-PAID-Agents multicast address.
UDP fields:
Source Port variable
Destination Port 434
The UDP header is followed by the fields shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |C|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Address (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 16
C If set, the private node requests that all PAID agents
receiving the message release the PAIDs associated with
the private node.
P If set, the private address is present.
Reserved 0
Private Address
This field, 4 bytes long, is present only if C bit is set.
Li, Teo Expires 17 July 1998 [Page 13]
Internet Draft IP Private Address Identification 18 January 1998
A private node may multicast PAID Agent Solicitation messages to
learn the presence of any PAID agents. It may retransmit the message
in a reasonable interval if it does not receive any PAID Agent
Advertisement message.
If a private node reboots and loses its PAIDs, it must set the 'C'
bit in the PAID Agent Solicitation message it sends when restarting.
By setting the 'C' bit in the solicitation, a private node requests
that all the PAID agents that receive the solicitation should clean
up their private PAIDs that match the private address.
6.2 PAID Agent Advertisement
A PAID agent may send a PAID Agent Advertisement message to inform a
prospective private node about the IP address of the PAID agent.
It may also multicast a PAID Advertisement message, at certain
interval, to all private nodes.
This message should be sent to a specific private address if it is
in response to a PAID Agent Solicitation message, or otherwise the
All-Private-Nodes multicast address.
UDP fields:
Source Port variable
Destination Port 434 if IP destination address is multicast,
or otherwise copied from the source port of
the corresponding PAID Solicitation.
The UDP header is followed by the fields shown below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |B|H|F|N| Reserved| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Li, Teo Expires 17 July 1998 [Page 14]
Internet Draft IP Private Address Identification 18 January 1998
Type 17
B Busy. The PAID agent will not accept request from
additional private nodes.
H Home PAID agent. This agent offers service as a home
PAID agent.
F Foreign PAID agent. This agent offers service as a
foreign PAID agent.
N NAT support. This agent support NAT. See 5.2.
Reserved 0
Lifetime The longest lifetime (measured in seconds) that this
agent is willing to accept in any PAID Request.
A value of 0xffff indicates infinity.
Agent Address
A public address of the PAID agent.
Li, Teo Expires 17 July 1998 [Page 15]
Internet Draft IP Private Address Identification 18 January 1998
7. PAID Registration Protocol
This section describes a means for a private node to register a PAID
with a PAID agent. It is a subset of the registration procedure
specified in the Mobile IP base protocol [1], where the private node
is taken as the mobile node, the PAID agent is taken as the foreign
agent, and no home agent is required.
A private node may intend to register a PAID with a PAID agent in
order to enable global communication. To register a PAID, the private
node should send a PAID Registration Request message to a PAID agent.
The PAID Agent should respond with a PAID Registration Reply message
where it indicates whether it agrees to bind the private node to
itself and to receive and forward traffic subsequently on behalf of
the private node.
The private node may keep retransmitting PAID Registration Request
messages to the PAID agent until it receives a reply or a maximum of
MAX_RETRANS Registration Request messages have been sent. In the
latter case, the private node may choose to seek a PAID from another
PAID agent.
A private node may have multiple PAIDs, each associated with a
different PAID agent. These PAIDs can be used for various sessions
of datagram origination. However, each private node can only receive
global datagrams at one PAID, which is the one it obtained in the
latest registration.
Below are the formats of the PAID Registration Request and Reply
messages. The use of these messages are similar to the Mobile IP base
protocol [1].
7.1 PAID Registration Request Message
A private node may send a PAID Registration Request message to
register a PAID with a PAID agent. This message should be sent to the
specific PAID agent, which may be learned from previous PAID
Advertisement messages.
UDP fields:
Source Port variable
Destination Port 434
The UDP header is followed by the fields shown below:
Li, Teo Expires 17 July 1998 [Page 16]
Internet Draft IP Private Address Identification 18 January 1998
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |D|Rsvd |Forward| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 18
D Domain name. If the 'D' bit is set, the private node
requests the PAID agent to update the DNS with the new
PAID.
Forward Forwarding method. See 5.1.
0: PAID Encapsulation
1: NAT
Reserved 0
Lifetime
The number of seconds remaining before the PAID is
considered expired. A value of zero indicates a
request for disassociation. A value of 0xffff indicates
infinity.
Agent Address
A public address of the PAID agent.
Private address
A private address of the originating node.
Identification
A 64-bit number, constructed by the private node, used
for matching PAID Registration Requests with PAID
Registration Replies, and for protecting against replay
attacks of these messages.
Li, Teo Expires 17 July 1998 [Page 17]
Internet Draft IP Private Address Identification 18 January 1998
7.2 PAID Registration Reply Message
A PAID agent returns a PAID Registration Reply message to a private
node which has sent a PAID Registration Request message. The Reply
message contains the necessary codes to inform the private node about
the status of its Request, along with the lifetime granted by the
PAID agent, which may be smaller than the original Request.
UDP fields:
Source Port variable
Destination Port copied from the source port of the
corresponding Reply message.
The UDP header is followed by the fields shown below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 19
Code A value indicating the result of the PAID Registration
Request. See below for a list of currently defined Code
values.
Lifetime
If the Code field indicates that the PAID Registration
request was accepted, the Lifetime field is set to the
number of seconds remaining before the registration is
considered expired. A value of zero indicates that the
private node has been disassociated. A value of 0xffff
indicates infinity. If the Code field indicates that the
request was denied, the contents of the Lifetime field
are unspecified and must be ignored on reception.
Li, Teo Expires 17 July 1998 [Page 18]
Internet Draft IP Private Address Identification 18 January 1998
Agent Address
A public address of the PAID agent.
Private address
A private address of the originating node.
Identification
A 64-bit number used for matching PAID Registration
Requests with PAID Registration Replies, and for
protecting against replay attacks of these messages. The
value is based on the Identification field from the PAID
Registration Request message from the private node, and
on the style of replay protection used in the security
context between the private node and its PAID agent
(defined by the PAID security association between them,
and SPI value in the PAID Authentication Extension).
The following values are defined for use within the Code field.
PAID request successful:
0 registration accepted
PAID request denied by the foreign agent:
64 reason unspecified
65 administratively prohibited
66 insufficient resources
67 private node failed authentication
68 requested Lifetime too long
69 poorly formed Request
70 invalid public address
71 registration Identification mismatch
72 forwarding method is not supported
Up-to-date values of the Code field are specified in the most recent
"Assigned Numbers" [4].
Li, Teo Expires 17 July 1998 [Page 19]
Internet Draft IP Private Address Identification 18 January 1998
7.3 PAID Authentication Extension
Exactly one PAID Authentication Extension must be present in all PAID
Requests and PAID Replies. The location of the extension marks the
end of the authenticated data. This extension should be appended to
both the PAID Request and Reply messages.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SPI ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... SPI (cont.) | Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 32
Length 4 plus the number of bytes in the Authenticator.
SPI Security Parameter Index (4 bytes). An opaque
identifier.
Authenticator (variable length)
Li, Teo Expires 17 July 1998 [Page 20]
Internet Draft IP Private Address Identification 18 January 1998
8. Various Aspects of PAID
8.1 Network Applications Consideration
To allow network applications (such as FTP) to control over the
encapsulation, some BSD APIs ought to be changed. This issue may be
discussed elsewhere.
8.2 Domain Name System Consideration
This issue may be discussed elsewhere.
9. Security
The security issue is beyond the scope of this document.
10. Acknowledgments
Many thanks to Dr. Y. C. Tay at the National University of Singapore
for supporting this joint work as well as for his valuable comments.
References
[1] C. Perkins, Editor. IP Mobility Support. RFC 2002, October
1996.
[2] C. Perkins. IP Encapsulation within IP. RFC 2003, May 1996.
[3] C. Perkins. Minimal Encapsulation within IP, RFC 2004, October
1996.
[4] J. K. Reynolds and J. Postel. Assigned Numbers. RFC 1700,
October 1994.
[5] J. Postel, Editor. "Internet Protocol", STD 5, RFC 791, September
1981.
[6] K. Egevang, and P. Francis. The IP Network Address Translator,
RFC 1631, May 1994.
[7] P. Calhoun and C. Perkins. Tunnel Establishment Protocol, Internet
Draft, November 1997.
[8] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing
Encapsulation (GRE). RFC 1701, October 1994.
[9] Y. Rekhter, and et al. Address Allocation for Private Internets,
RFC 1918, February 1996.
Li, Teo Expires 17 July 1998 [Page 21]
Internet Draft IP Private Address Identification 18 January 1998
Author's Address
Questions about this memo can also be directed to the author:
Y. Li
Bay Networks, Inc.
BL60-304
600 Technology Park Drive
Billerica, MA 01821
Phone: 1-978-916-1130
Fax: 1-978-670-8760
E-mail: yli@BayNetworks.COM
W. T. Teo
Department of ISCS
National University of Singapore
Lower Kent Ridge Crescent
SINGAPORE 119260
E-mail: teoweetu@iscs.nus.edu.sg
Li, Teo Expires 17 July 1998 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-23 22:31:42 |