hassler@wrtfac.UUCP (Barry D. Hassler) (12/27/87)
Has there been any standardization on the translation of Class B or C IP addresses to X.25 addresses? I am aware of the translation standard for Class A addresses, but have not seen any for B or C. Thanks, Barry D. Hassler hassler%wrtfac@lognet2.arpa System Software Analyst Control Data Corporation
malis@CC5.BBN.COM (Andy Malis) (01/20/88)
The following message didn't seem to make it out of my host when
I sent it the first time. Since this is a topic that comes up
from time to time, I thought I would resend it.
Andy
------- Forwarded Message
To: "Barry D. Hassler" <wrtfac!hassler@LOGNET2.ARPA>
cc: malis,tcp-ip@sri-nic.arpa
Subject: Re: IP class B and C to X.25 address translation
In-reply-to: Your message of Sun, 27 Dec 00 19:87:13 +0000.
<7137.8712280332@wrtfac.cdc.com>
Date: Mon, 28 Dec 87 11:44:33 -0500
From: Andy Malis <malis@cc5.bbn.com>
Barry asked the following:
Has there been any standardization on the translation of
Class B or C IP addresses to X.25 addresses? I am aware
of the translation standard for Class A addresses, but
have not seen any for B or C.
Barry,
There is an informal standardization for Class B: the first two
octets of the IP address are the network number, the third octet
is treated identically to the second octet of Class A addresses,
and the fourth octet is treated identically to the fourth octet
of Class A addresses. The third octet of Class A addresses is
dropped completely in Class B addresses.
There is absolutely no standardization for Class C, because there
are so few local network address bits to play with. The host
network software support person for Class C nets must provide his
or her own mapping between the Class C addresses and X.25
addresses for that net. For example, the five most significant
bits of the fourth octet of the Class C address could be the host
number, and the three least significant bits the PSN number. It
is a compromise between the number of PSNs on the network and the
maximum number of hosts on a PSN.
Regards,
Andy
------- End of Forwarded MessageMRC@PANDA.PANDA.COM (Mark Crispin) (01/20/88)
Andy -
For the record, PANDA and BBN TOPS-20's implement class C
PSN addresses as being in old ARPANET 8-bit format; that is, the
low order 6 bits is the PSN number and the high order 2 bits is
the host number. This is relatively simple to change, though,
and to my knowledge no TOPS-20 system is on a class C PSN network.
All TOPS-20's use 1822 instead of X.25 when talking to PSN's.
-- Mark --
-------hassler@nap1.arpa (Barry D. Hassler) (01/26/88)
Its been some time since I sent out my original message concern-
ing the subject, and I have received a few responses to my ques-
tion, but noone answered the question I asked (maybe I asked it
poorly).
My original question concerned the translation from IP addresses
to X.25 addresses for X.25 links, such as those on MILNET (each
answer I received told me about subnetting, which I do under-
stand). The X.25 standard used by DDN contains an appendix out-
lining the address translation, but it only works properly for
Class A addresses. The algorithm itself can be found in
NETINFO:X25.DOC.1 on sri-nic.arpa.
The algorithm used is as follows (copied out of X25.DOC, appendix
A):
------------------------------------------------------
A-8
A-5 Derivation of DDN X.25 Addresses
All DDN hosts are assigned addresses by the Administration.
The address of a DDN host may be obtained from the Network
Information Center (NIC), represented as an ASCII text string in
what is called "host table format". This section describes the
process by which DDN X.25 addresses in the format described in
Section 2.1.1 may be derived from addresses in NIC host table
format.
A NIC host table address consists of the ASCII text string
representations of four decimal numbers separated by periods,
corresponding to the four octets of a thirty-two bit Internet
address. The four decimal numbers are referred to in this
section as "n", "h", "l", and "i." Thus, a host table address
may be represented as "n.h.l.i" Each of these four numbers will
have either one, two, or three decimal digits and will never have
a value greater than 255. For example, in the host table address
"10.2.0.124", n=10, h=2, l=0, and i=124. To convert a host table
address to a DDN X.25 address:
1. If h < 64, the host table address corresponds to
the DDN X.25 physical address
ZZZZ F IIIHHZZ (SS)
where:
ZZZZ = 0000
as required in Section 2.1.1.1.1;
F = 0 because the address is a physical
address;
III is a three decimal digit
representation of "i", right-adjusted
and padded with leading zeros if
required;
HH is a two decimal digit representation
of "h", right-adjusted and padded
with leading zeros if required;,
ZZ = 00
and
(SS) is optional, as described in Section
2.1.1.1.4.
A-9
In the example given above, the host table address
10.2.0.124 corresponds to the DDN X.25 physical
address 000001240200.
2. If h > 64 or h = 64, the host table address
corresponds to the DDN X.25 logical address
ZZZZ F RRRRRZZ (SS)
where:
ZZZZ = 0000
as required in Section 2.1.1.1.1;
F = 1 because the address is a logical
address;
RRRRR is a five decimal digit
representation of the result "r" of
the calculation
r = h * 256 + i
(note that the decimal representation
of "r" will always require five
digits);
ZZ = 00
and
(SS) is optional, as described in Section
2.1.1.1.4.
Thus, the host table address 10.83.0.207
corresponds to the DDN X.25 logical address
000012145500.
In both cases, the "n" and "l" fields of the host table
address are not used.
-------------------------------------------------------------
Note that while this algorithm can be used on class B and C ad-
dresses, it maps out to duplicate X.25 addresses for certain
Class B and C addresses, since it only takes into account the
second and fourth octets of the address.
Are there any other standards being used for this translation
that will provide a one-to-one mapping of both class B and C ad-
dresses to X.25 addresses? I am running a quickly growing net-
work of hosts, and have receiveed several requests already for
X.25 connections to our gateway. I am very concered about the
address translations for our class B network addresses (subnetted
of course). I use portions of the third octet (depending upon the
size of the subnet, and whether or not it needs to be subnetted
further) for the subnetwork number and find that that octet does
not enter in the X.25 address at all. Therefore, If I would have
two X.25 hosts behind my gateway with addresses 129.48.1.1 and
129.48.32.1, they would both have the same X.25 address:
000011228900.
-BDHpogran@ccq.bbn.COM (Ken Pogran) (01/27/88)
Barry,
How about the mapping that Andy Malis suggested in his message of
19 January?
There is an informal standardization for Class B: the first two
octets of the IP address are the network number, the third octet
is treated identically to the second octet of Class A addresses,
and the fourth octet is treated identically to the fourth octet
of Class A addresses. The third octet of Class A addresses is
dropped completely in Class B addresses.
There is absolutely no standardization for Class C, because there
are so few local network address bits to play with. The host
network software support person for Class C nets must provide his
or her own mapping between the Class C addresses and X.25
addresses for that net. For example, the five most significant
bits of the fourth octet of the Class C address could be the host
number, and the three least significant bits the PSN number. It
is a compromise between the number of PSNs on the network and the
maximum number of hosts on a PSN.
We've just put in a small "campus-area" Class B network of C/30
PSNs using this mapping.
If my memory serves me correctly (and it turns out that I'm the
author of the text in the DDN X.25 spec that you quoted -- though
not the originator of the algorithm), an earlier draft of the DDN
X.25 spec contained both Class A and Class B mappings. In review,
it was pointed out to us that since this was a _DDN_ X.25 spec,
and DDN was a Class A network, there was no need for a Class B
mapping in the DDN-specific document. In retrospect, it would
have been a good idea to put out the Class B mapping as an RFC at
the same time the DDN spec was published!
I think it's now time to put out that RFC ...
Ken Pogranmalis@CC5.BBN.COM (Andy Malis) (01/28/88)
Barry, To reiterate my earlier message on the subject: for Class B, use the same algorithm, but replace the Class A second octet with the Class B third octet; in other words, treat the Class B number's octets as n1.n2.h.i and use the Class A algorithm. There is no standard for Class C - you have to roll your own algorithm by dividing up the last octet into h and i bits. It's your choice as to which bits are h and which are i. Once you've done that, again follow the Class A algorithm. Regards, Andy