RFC 1219

On the assignment of subnet numbers

๐Ÿ“… published April 1991, from ietf

On the Assignment of Subnet Numbers ๐ŸŽ€

okay bestie, here's the title block tea โ˜•

  • Group: Network Working Group
  • RFC: 1219
  • Author: P. Tsuchiya, from Bellcore
  • Date: April 1991
  • Category: informational. It's info for the Internet community, not an Internet standard ๐Ÿ“š
  • Obsoletes / Updates: none listed in the header, so it isn't replacing or changing any RFC listed there โœจ

Status Of This Memo ๐ŸŒธ

okay so this memo suggests a new way to assign subnet numbers ๐Ÿฆ‹. using this technique inside a network is a totally local thing, and it wouldn't affect other networks. so using these procedures is entirely up to you (discretionary) ๐Ÿ’….

this memo provides information for the Internet community, and it doesn't specify an Internet standard ๐Ÿ“–. distribution of this memo is unlimited ๐ŸŒˆ.

Overview ๐Ÿ’…

so RFC-950 [2] explains how to subnet Internet addresses with a bit-mask ๐ŸŽ€. it lets the "ones" in the subnet mask be non-contiguous, but RFC-950 recommends two things: 1) that they be contiguous, and 2) that they occupy the most significant bits of the "host" part of the internet address ๐Ÿ’–.

here's the tea ๐Ÿซ–: RFC-950 didn't say whether different subnets of the same network may have different masks ๐Ÿ™ˆ. that gap was messy, because it led to routing protocols that don't support different masks, see e.g., RIP [6] ๐Ÿ’€. the Gateway Requirements RFC [7] settled it in favor of allowing different masks, so future routing protocols may be expected to support this feature, and OSPF [3] is an example ๐Ÿงš.

the network admin must of course figure out the mask for each subnet ๐Ÿ‘‘. that means estimating how many hosts each subnet will have, and it's basically impossible to predict how big a subnet will grow ๐Ÿ˜ญ. so you end up with inefficient choices: some subnets are underused, and others might need renumbering because they ran out of capacity ๐Ÿซ .

this memo specifies a procedure for assigning subnet numbers that gets rid of the need to estimate subnet size โœจ. basically, host bits (mask = 0) get assigned starting from the least significant bit and working toward the most, and subnet bits (mask = 1) get assigned starting from the most significant bit and working toward the least ๐Ÿฆ‹. as subnets grow, more host bits get assigned. as the number of subnets grows, more subnet bits get assigned ๐Ÿ’…. yes, this sometimes results in new subnet masks, but no host ever needs to change its address ๐Ÿซถ.

this technique isn't new ๐ŸŒˆ, but it's not widely known, and it's even less widely implemented ๐Ÿฅบ. with new routing protocols like OSPF, you can take full advantage of it โญ. so the whole point of this memo is to make the technique widely known and to specify it exactly ๐Ÿ’œ.

this memo doesn't require any changes to existing Internet standards ๐ŸŽ€. it does, however, require that the intra-domain routing protocol handle multiple different subnet masks ๐Ÿงš.

Acknowledgments ๐Ÿซถ

the author wants to thank Phil Karn, Charles Lynn, Jeff Mogul, and Charles Wolverton for their helpful suggestions ๐Ÿ’–. special thanks go to Joel Halpern for his painstaking debugging of the detailed specification and the examples ๐Ÿ‘‘.

1. Motivation ๐Ÿ’…

okay so the Subnetting standard, RFC-950, says the Host part of a formally 2-level Internet address can be split into two fields, Subnet and Host ๐Ÿฆ‹. that gives the address a third level of hierarchy, plus the firewalls and savings in routing overhead that come with it โœจ. but it also makes address allocation less efficient ๐Ÿ˜ฌ.

this inefficiency happens because the network admin usually overestimates the size (number of hosts) of any single subnetwork, so they don't have to re-address subnets later ๐Ÿ™ˆ. it may also occur if the routing protocol being used doesn't handle different length subnets. then the admin must therefore give every subnet as much space as the largest subnet gets ๐Ÿ’€. (this RFC doesn't help in that latter case, because the technique here requires different length subnets ๐Ÿ™….)

changing a network's subnet structure can be a massive administrative hassle ๐Ÿ˜ฉ. here's an example ๐Ÿ”. a network has three subnets, A, B, and C ๐Ÿงฉ. assume the lowest significant byte is the host part and the next byte is the subnet part (so the mask is 255.255.255.0) ๐Ÿ’–. assume further that A has subnet 1.0, B has subnet 2.0, and C has subnet 3.0 ๐ŸŽ€.

now assume B grows beyond its allocation of 254 hosts ๐Ÿ“ˆ. ideally we'd just change B's mask without changing any of the host addresses in B ๐Ÿฅน. but the subnets numerically above and below B are already taken by A and C ๐Ÿ˜ญ. (if 3.0 was not taken by C, B's mask could be changed from 255.0 (ff00) to 254.0 (fe00) ๐Ÿง . in that case, all of B's existing addresses would still match the new subnet ๐Ÿ’ซ. indeed, if non-contiguous masks were in use, it might be possible for B to find some other mask bit to change to 0 ๐Ÿค”. but non-contiguous masks aren't really in favor, since they impose limitations on certain forwarding table lookup algorithms ๐Ÿ™ƒ. RFC-950 discourages their use ๐Ÿšซ.)

so the network admin's choices are 1) form two subnets out of the existing one, or 2) renumber the subnet so it ends up with a smaller (fewer 1's) mask ๐Ÿง. choice 1 can be accomplished physically or logically ๐Ÿ› ๏ธ. forming two subnets physically means partitioning the subnet and inserting a gateway between the two partitions. for obvious reasons, that's not a desirable course of action ๐Ÿ™….

forming two subnets logically is done by simply assigning another subnet number (say 4.0) to the same subnet, and then assigning host addresses under the new subnet ๐Ÿฆ‹. the result is that hosts with different subnet numbers won't recognize that the others are on the same subnet, so they send packets to the default gateway instead of directly to the host ๐Ÿคท. honestly, this isn't such a bad solution ๐Ÿ’…. if the gateway is capable of recognizing multiple subnet numbers on the same subnet, it will simply send the host an ICMP Redirect [4], and subsequent packets will go directly to the host [1] (this may not work correctly on all hosts) โญ.

but if neither choice is acceptable or possible, the network admin must assign a new subnet number to B ๐Ÿ˜ค. that means renumbering the existing hosts, modifying the Domain Name System entries, and changing any other configuration files that have hardwired addresses for hosts in subnet B ๐Ÿฅฒ.

2. A More Flexible and Efficient Technique for Assigning Subnet Numbers ๐Ÿฆ‹

to explain the new technique, first we need to show what's wrong with how things are done now ๐Ÿง. currently, most subnets are assigned by splitting the host part of the address into two fields: the subnet field and the host field ๐Ÿฐ. mask bits are one for subnet field bits, and zero for host field bits 1๏ธโƒฃ. (in all of our addresses, the least significant bit (LSB) is on the right, and the most significant bit (MSB) is on the left ๐Ÿ‘ˆ.)

        MSB                                LSB
        --------------------------------------
       | subnet field    | host field         |
        --------------------------------------

the subnet field could be different lengths for different size subnets ๐Ÿ“. say a network had two large subnets and the rest small subnets (by large subnet we mean a large number of hosts) ๐Ÿ˜๐Ÿญ. then the network administrator might assign two types of addresses:

        --------------------------------------
       | subnet |               host          |  large subnets
        --------------------------------------

        --------------------------------------
       |         subnet             |  host   |  small subnets
        --------------------------------------

in this case, the full range of subnet numbers wouldn't be available to the small subnets ๐Ÿ˜ฌ. the bits in the small subnet that correspond to those in the large subnet couldn't have the same values as those in the large subnets ๐Ÿงฉ. for instance, say that the large subnets had 4-bit subnet numbers, and the small subnets had 8-bit subnet numbers ๐Ÿ”ข. if the large subnets had values 0001 and 0010, then subnet numbers in the range 00010000 to 00101111 couldn't be assigned to the small subnets, otherwise there will be addresses that would match both subnets ๐Ÿ™ˆ.

in any event, a network administrator will typically assign values to the two fields in numerical order ๐Ÿ”ข. for example, within a given subnet, hosts will be numbered 1, 2, 3, etc. within a given network, subnets will be numbered 1, 2, 3, etc. ๐Ÿงฎ. the result is that some number of bits on the right side of the subnet and host fields will be ones for some hosts and zeros for others, and some number of bits on the left side of the subnet and host fields will be zeros for all subnets and hosts ๐ŸŒˆ. the "all zeros" bits represent room for growth ๐ŸŒฑ, and the "ones and zeros" bits represent bits already consumed by growth ๐Ÿ‚.

        --------------------------------------
       | subnet field    | host field         |
       |-----+-----------+-------+------------|
       |     |           |       |            |
       | 0's | 1's & 0's |  0's  | 1's & 0's  |
          /\                /\
          ||                ||
        subnets can         hosts can grow here
        grow here

now let's assume the number of hosts in a certain subnet grows to the maximum allowed, but there's still room in the subnet field to assign more addresses ๐Ÿ“ˆ. then we have the following:

        --------------------------------------
       | subnet field    | host field         |
       |-----+-----------+--------------------|
       |     |           |                    |
       | 0's | 1's & 0's |     1's & 0's      |

while the host field can no longer grow, there's still room in the address for growth ๐Ÿฅบ. the problem is that, because of where the growth areas are situated, the remaining growth has effectively been reserved for subnets only ๐Ÿ™….

what should be done instead is assigning subnet numbers so that the ones start from the left of the subnet field and work right โœจ. in this case we get the following:

        --------------------------------------
       | subnet field    | host field         |
       |-----------+-------------+------------|
       |           |             |            |
       | 1's & 0's |    0's      | 1's & 0's  |
                         /\
                         ||
                    Both hosts and subnets can
                    grow here

now both hosts and subnets individually have considerably more growing space than before, although the combined growing space is the same ๐Ÿ’–. since one can rarely predict how many hosts might end up in a subnet, or how many subnets there might eventually be, this arrangement allows for the maximum flexibility in growth ๐Ÿฆ‹.

okay, the previous figure is kinda misleading ๐Ÿ™ˆ. the boundary between the host and subnet fields is shown in the middle of the growth area, but the boundary could exist anywhere within the growth area ๐Ÿง. note that it's the mask itself that determines where the boundary is. ones in the mask indicate subnet bits, and zeros indicate host bits ๐ŸŽ€. we'll show later that the boundary should actually lie somewhere in the middle ๐Ÿ’…. putting it there minimizes the number of times that the masks must be changed in hosts ๐Ÿ‘‘.

2.1. Specification of the New Technique ๐Ÿงš

Okay so now we get to the actual recipe ๐Ÿ’…โœจ We've done all the explaining, so it's finally time to spell out how subnet numbers get handed out. First, the definitions, bestie ๐Ÿซถ

  • Host-assigned Bits (h-bits): These are the bits, lined up contiguously from the right, where the host values inside a given subnet end up with both ones and zeros. Different subnets can have different h-bits ๐Ÿฆ‹
  • Subnet-assigned Bits (s-bits): These are the bits, contiguous from the left, which 1) are not h-bits, AND 2) are required to distinguish one subnet from another, AND 3) include all bits to the left of and including the right-most one. Notice that different subnets can have different s-bits ๐Ÿ’œ
  • Growth Bits (g-bits): These are the "all zeros" bits sitting in between the h-bits and s-bits ๐ŸŒธ
  • s-mask: For a given subnet, this is the mask where all s-bits are one, and all g-bits and h-bits are zero ๐ŸŽ€
  • g-mask: For a given subnet, this is the mask where all s-bits and g-bits are one, and all h-bits are zero ๐Ÿงš
  • Subnet Field: These are the one bits in the subnet mask (as defined in RFC-950). These bits are on the left. The subnet field MUST at least include all of the s-bits, and MAY additionally include some or all of the g-bits. bestie, this is the part where the boundaries get real โœจ
  • Host Field: These are the zero bits in the subnet mask. These bits are on the right. The host field MUST at least include all of the h-bits, and MAY additionally include some or all of the g-bits ๐Ÿ“

Mirror-image Counting: Normal counting, in binary, causes one bits to start at the right and work left, and that's how host values get assigned ๐Ÿซ  For subnet assignment, though, we want the one bits to start at the left and work right. This process is the mirror image of normal counting, where the MSB is swapped with the LSB, the second MSB is swapped with the second LSB, and so on. So, where normal counting is:

             0       (reserved to mean "this host")
            01
            10
           011
           100
           101
           :
           :
     11...1110
     11...1111       (reserved to mean "all hosts")

and so on, Mirror-image, or MI counting, is:

     0       (reserved to mean "this subnet")
     10
     01
     110
     001
     101
       :
       :
     011...11
     111...11        (reserved to mean "all subnets")

and so on. If the current MI counting value is, say, 001, the "next" MI value is 101, and the "previous" MI value is 11. Mirror-image counting is giving upside-down main character energy ๐Ÿ™ƒ๐Ÿฆ‹

Now we can specify the algorithm. We have the following functions: Initialize(), AddSubnet(), RemoveSubnet(subnet#), AddHost(subnet#), and RemoveHost(subnet#,host#) ๐Ÿ’–

Notice that the algorithm is described as though one state machine is executing it. In reality, there may be a root Address Authority (RootAA) that assigns subnet numbers (Initialize, AddSubnet, and RemoveSubnet), and subnet AA, that assign host numbers within a subnet (AddHost and RemoveHost). While in general the AAs can act independently, there are two cases where "coordination" is required between the rootAA and a subnetAA. These are the cases where either the rootAA or the subnetAA "grabs" the last growth bit (in the former case because another subnet has been added, and in the latter because another host has been added). Since it is impossible for the rootAA and a subnetAA to simultaneously grab the last growth bit, either one or the other MUST do it ๐Ÿ”ฅ

Finally, note that the following C language style notation is used:

     &               bit-wise AND function
     ==              is equal to
     !=              is not equal to
     x-mask(X)       the x-mask of X (where x is s or g)

Initialize(): Assign the first subnet value to be 0 (the value reserved to mean "this subnet"). This is not assigned to any real subnet ๐ŸŒˆ

AddSubnet():

  1. Find the lowest non-zero (in MI counting) non-assigned subnet number S such that (S & g-mask(Y)) != (Y & g-mask(Y)) for all existing subnet numbers Y, (Y != S).
  2. If all bits in S from the rightmost one bit left are ones, then label all bits to the left of and including one bit position to the right of the rightmost one bit in S to be s-bits. Else, label all bits to the left of and including the rightmost one bit in S to be s-bits. This prevents the "all ones" value (which is the "all subnets" broadcast address) from being assigned to a subnet. (Since no hosts have been added, the rightmost one bit is a subnet bit.) ๐Ÿ™ˆ
  3. Label all other bits in the address to be g-bits. (By address, we mean that part of the IP address not including the network number.)
  4. Set the subnet mask to include at least all s-bits, and optionally some g-bits. The subnet mask MUST be contiguous. (Section 2.2 discusses the pros and cons of choosing a mask.) ๐ŸŽ€
  5. For all existing subnet numbers Y (Y != S):
    1. If (S & s-mask(Y)) == (Y & s-mask(Y)), then:
      1. Change the leftmost g-bit of Y to an s-bit. If the rootAA and YAA (the address authority for Y) are separate AAs, then the YAA MUST be informed of the change of bit status. If this is the last g-bit, then this change MUST be coordinated with YAA.
      2. Expand the subnet mask for all hosts in Y if necessary (that is, if the subnet mask no longer includes all s-bits).

RemoveSubnet(S):

  1. Consider B to be the bit position of the rightmost s-bit in S.
  2. Remove S.
  3. For all existing subnet numbers Y:
    1. If the bit in position B is not an s-bit, or if the bit in bit position B is a one, or if the bit in bit position B is a zero and all bits to the left of bit position B are ones, then do nothing (skip steps 32 and 33).
    2. Change the s-bit in position B to a g-bit.
    3. If for any other existing subnet numbers X (X & s-mask(Y)) == (Y & s-mask(Y)), then change the g-bit in position B back into an s-bit for Y. Else, inform YAA that of the change of bit status. ๐Ÿฆ‹

AddHost(S):

  1. Create an address A consisting of subnet number S concatenated with zeros.
  2. Assign to A the same h-bits, g-bits, and s-bits as the other host addresses.
  3. Find the lowest non-zero (using normal counting) non-assigned host number H.
  4. If all bits from the leftmost one bit to bit position 0 are ones, then execute steps 5 and 6 using bit position B equals one bit position to the left of the leftmost one bit in H. Else, execute steps 5 and 6 with bit position B equals the leftmost one bit in H. This prevents the "all ones" value (which is the "all hosts" broadcast address) from being assigned to a host. ๐Ÿ’…
  5. If bit position B is an s-bit, then the host cannot be added. Skip the remaining steps.
  6. If bit position B is a g-bit:
    1. Change the g-bit to an h-bit for all hosts in S. Note that if this is the last g-bit, this change MUST be coordinated with the address authority assigning subnet numbers (see section 2.2).
    2. Modify the subnet mask in all hosts if necessary.
  7. Create a new address A consisting of S concatenated with H
  8. Assign A to the host.

RemoveHost(S,H):

  1. Remove H.
  2. If for all remaining host numbers in S, the value of the bit position of the leftmost h-bit is zero, and there is a zero in at least one of the bit positions to the right of the leftmost h-bit, then for all hosts change the leftmost h-bit into a g-bit. โœจ

It is worth noting here that this technique is a 2-level subset of the more general n-level kampai addressing [5]. The main difference here is that n-level kampai results in non-contiguous masks, while 2-level does not. In the description of kampai addressing in [5], g-bits are called a-bits, h-bits are called g-bits, and s-bits are called i-bits. kampai really said "what if we made the bits even more complicated" and we're here for it ๐Ÿงš๐Ÿ’œ

2.2. An Example ๐ŸŽ€

For this example, we assume a class C network, so we will only need to work with 8 bits. We start with 3 subnets, A, B, and C. Our nomenclature is h for h-bit and g for g-bit. Note that h-bits can be one or zero, but g-bits are all zero. The remaining bits are s-bits, but are shown as 1's and 0's according to the subnet number assignment. The space is just to make the addresses and masks easier to read. Finally, we number our bits 0 to 7 from right to left as shown below.

     Subnet  Address         Mask
     A       10gg ghhh       1111 0000
     B       01gg ghhh       1111 0000
     C       110g ghhh       1111 0000
         bit 7       bit 0

We see that each subnet has at most 6 hosts (because of the three h-bits). Notice that we have chosen the masks so that there is room for growth in both hosts and subnets without requiring a mask change. ๐ŸŒธ

However, we have generally allowed for more growth in subnets than in hosts because adding new subnets can cause mask changes in existing subnets, while adding new hosts in a subnet only causes that subnet's mask to change.

Further, if a subnet's mask must change, but not all hosts are reconfigured at the same time, then it is less damaging if the not yet reconfigured hosts have too large a mask (too many ones) than if they have too small a mask. This is because with too large a mask, a host may think that another host which is in fact on the subnet is on another subnet. In this case, the host will send packets to the gateway, and will be redirected to the host. the drama of the hosts not being on the same page ๐Ÿ˜ญ

However, with too small a mask, a host may think that another host which is in fact not on the subnet is on the subnet, and will ARP for that host but receive no reply. (Note that broadcasts may fail if all masks do not match.) ๐Ÿ’€

Finally, notice that subnet C requires three s-bits instead of just two. This is because with just two, the subnet address of C could be "11" (rather than "110"), which is a broadcast value. Step 2 of AddSubnet checks for this case. that's the whole reason the three bits exist, iykyk ๐Ÿ‘‘

Now, a fourth subnet, D, also with 6 hosts, is added. We get:

     Subnet  Addr            Mask
     A       10gg ghhh       1111 0000
     B       01gg ghhh       1111 0000
     C       110g ghhh       1111 0000
     D       001g ghhh       1111 0000

Notice that none of the original subnets required a change in any of their status bits. This is because, when D compared its subnet number with the others (step 5 of AddSubnet(), using the s-mask), they were all different. In other words, a router would be able to distinguish an address in D from addresses in A, B, and C. ๐Ÿฆ‹

Next, a fifth subnet, E, is added. We get:

     Subnet  Addr            Mask
     A       100g ghhh       1111 0000
     B       01gg ghhh       1111 0000
     C       110g ghhh       1111 0000
     D       001g ghhh       1111 0000
     E       101g ghhh       1111 0000

Notice that this time, A was forced to change its leftmost g-bit (bit 5) into an s-bit, because bit 5 is needed to distinguish subnet A from subnet E (step 511 of AddSubnet()). Changing bit 5 into an s-bit prevents hosts from being added to A to the point where bit 5 would be changed into a one (that is, step 5 of AddHost() would fail). subnet A really had to glow up for this one ๐ŸŒˆโœจ

Okay so peep this ๐Ÿ‘€ if A, B, and C had their masks set to 1100.0000 at the start, adding E would've flipped A's mask to 1110.0000 (that's Step 512 of AddSubnet() doing its thing) ๐ŸŽ€

Next, 8 hosts each get added to subnets A and C, so the right-most g-bit in each one turns into an h-bit ๐ŸŒธ

        Subnet  Addr            Mask
        A       100g hhhh       1111 0000
        B       01gg ghhh       1111 0000
        C       110g hhhh       1111 0000
        D       001g ghhh       1111 0000
        E       101g ghhh       1111 0000

Notice again that no masks changed ๐Ÿฆ‹ If the masks for A, B, and C had started at 1111 1000, they would've needed changing (step 62 of AddHost()) ๐Ÿ˜ญ

Next, enough hosts go into subnet B that all of its remaining g-bits become h-bits ๐Ÿ’œ

        Subnet  Addr            Mask
        A       100g hhhh       1111 0000
        B       01hh hhhh       1100 0000
        C       110g hhhh       1111 0000
        D       001g ghhh       1111 0000
        E       101g ghhh       1111 0000

Notice here that B's masks had to change so the new h-bits fit (step 62 of AddHost()) ๐Ÿ’… Also, if the person handing out host addresses for B (the B Address Authority, or BAA) is different from the person handing out network numbers (RootAA), then BAA has to coordinate changing its last g-bit into an h-bit with the RootAA ๐Ÿซถ That lets the RootAA properly assign more subnet numbers, like in the next step where we add subnet F:

        Subnet  Addr            Mask
        A       100g hhhh       1111 0000
        B       01hh hhhh       1100 0000
        C       110g hhhh       1111 0000
        D       001g ghhh       1111 0000
        E       101g ghhh       1111 0000
        F       1110 ghhh       1111 0000

Notice that F got subnet number 1110 instead of 011 (which is what comes after 101 in MI counting) ๐Ÿค” Why? Because 1) 011 isn't distinguishable from B's subnet address using B's mask, and 2) we can't bump B's mask to make it distinguishable, since B has already assigned hosts at bit position 5 ๐Ÿ™ˆ In other words, when the comparison of step 1 in AddSubnet() was tried on 011, the two values were equal, so the next number got tried. Honestly, no subnet numbers with 01 in bit positions 7 and 6 can be assigned (unless B loses hosts) ๐Ÿ’€

Next, subnet E gets removed:

        Subnet  Addr            Mask
        A       10gg hhhh       1111 0000
        B       01hh hhhh       1100 0000
        C       110g hhhh       1111 0000
        D       001g ghhh       1111 0000
        F       1110 ghhh       1111 0000

Notice that this made subnet A change an s-bit back into a g-bit ๐Ÿ”„ That's because the equality check in step 33 of RemoveSubnet() didn't hold for subnet A against the remaining subnets.


References ๐Ÿ“š

  • [1] Braden, R., "Requirements for Internet Hosts -- Communication Layers", RFC 1122, USC/Information Sciences Institute, October 1989.
  • [2] Mogul, J., and J. Postel, "Internet Standard Subnetting Procedure", RFC 950, USC/Information Sciences Institute, August 1985.
  • [3] Moy, J., "OSPF Specification", RFC 1131, Proteon, October 1989.
  • [4] Postel, J., "Internet Control Message Protocol", RFC 792, USC/Information Sciences Institute, September 1981.
  • [5] Tsuchiya, P., "Efficient and Flexible Hierarchical Address Assignment", TM-ARH-018495, Bellcore, February 1991.
  • [6] Hedrick, C., "Routing Information Protocol" RFC 1058, Rutgers University, June 1988.
  • [7] Braden, R., and J. Postel, "Requirements for Internet Gateways", RFC 1009, USC/Information Sciences Institute, June 1987.

Security Considerations ๐Ÿ”’

Security issues are not discussed in this memo. ๐Ÿ™ˆ Zero security talk in here, so keep that in mind as you read ๐Ÿ’œ


Author's Address ๐Ÿงš

   Paul F. Tsuchiya
   Bellcore
   435 South St.5 South St.
   MRE 2L-281
   Morristown, NJ 07960

   Phone: 201 829-4484

   EMail: tsuchiya@thumper.bellcore.com
๐Ÿ“ฆ where this page comes from