File: rfc1362.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (731 lines) | stat: -rw-r--r-- 30,219 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731






Network Working Group                                           M. Allen
Request for Comments: 1362                                  Novell, Inc.
                                                          September 1992


               Novell IPX Over Various WAN Media (IPXWAN)

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Abstract

   This document describes how Novell IPX operates over various WAN
   media.  Specifically, it describes the common "IPX WAN" protocol
   Novell uses to exchange necessary router to router information prior
   to exchanging standard IPX routing information and traffic over WAN
   datalinks.

Table of Contents

   1.  Introduction .................................................  1
   1.1. Operation Over PPP ..........................................  2
   1.2. Operation Over X.25 Switched Virtual Circuits ...............  2
   1.3. Operation Over X.25 Permanent Virtual Circuits ..............  2
   1.4. Operation Over Frame Relay ..................................  3
   1.5. Operation Over Other WAN Media ..............................  3
   2.  Glossary Of Terms ............................................  3
   3.  IPX WAN Protocol Description .................................  4
   4.  Information Exchange Packet Formats ..........................  5
   4.1. Timer Request Packet ........................................  6
   4.2. Timer Response Packet .......................................  8
   4.3. Information Request Packet .................................. 10
   4.4. Information Response Packet ................................. 12
   5.  References ................................................... 12
   6.  Security Considerations ...................................... 13
   7.  Author's Address.............................................. 13

1. Introduction

   This document describes how Novell IPX operates over various WAN
   media. It is strongly motivated by a desire for IPX to treat ALL wide
   area links in the same manner. Sections 3 and 4 describe this common
   "IPX WAN" protocol.





Allen                                                           [Page 1]

RFC 1362                         IPXWAN                   September 1992


   IPX WAN protocol operation begins immediately after link
   establishment. While IPX is a connectionless datagram protocol, WANs
   are often connection-oriented.  Different WANs have different methods
   of link establishment. The subsections of section 1 of this document
   describe what link establishment means to IPX for different media.
   They also describe other WAN-media-dependent aspects of IPX
   operation, such as protocol identification, frame encapsulation, and
   link tear down.

1.1 Operation Over PPP

   IPX uses PPP [1] when operating over point-to-point synchronous and
   asynchronous networks.

   With PPP, link establishment means the IPX NCP [4] reaches the Open
   state. NetWare IPX will reject all NCP options, and uses normal frame
   encapsulation as defined by PPP. The IPXWAN protocol MUST NOT occur
   until the IPX NCP reaches the Open state.

   PPP allows either side of a connection to stop forwarding IPX if one
   end sends an IPXCP or an LCP Terminate-Request. When a router detects
   this, it will immediately reflect the lost connectivity in its
   routing information database instead of naturally aging it out.

1.2 Operation over X.25 Switched Virtual Circuits

   With X.25, link establishment means successfully opening an X.25
   virtual circuit.  As specified in RFC-1356, "Multiprotocol
   Interconnect on X.25 and ISDN in the Packet Mode" [2], the protocol
   identifier 0x800000008137 is used in the X.25 Call User Data field of
   the Call Request frame, and indicates that the virtual circuit will
   be devoted to IPX.

   Furthermore, each IPX packet is encapsulated directly in X.25 data
   frame sequences without additional framing.

   Either side of the virtual circuit may close it, thereby tearing down
   the IPX link. When a router detects this, it will immediately reflect
   the lost connectivity in its routing information database instead of
   naturally aging it out.

1.3 Operation over X.25 Permanent Virtual Circuits

   The nature of X.25 PVC's is that no call request is made.  When the
   router is informed that X.25 Layer 2 is up, the router should assume
   that link establishment is complete.





Allen                                                           [Page 2]

RFC 1362                         IPXWAN                   September 1992


   Each IPX packet is encapsulated in an X.25 data frame sequence
   without additional framing. Novell IPX assumes a particular X.25
   permanent circuit is devoted to the use of IPX.

   If a router receives a layer 2 error condition (e.g., X.25 Restart),
   it should reflect lost connectivity for the permanent circuits in its
   routing information database and re-perform the necessary steps to
   obtain a full IPX connection.

1.4 Operation over Frame Relay

   Novell conforms to RFC-1294, "Multiprotocol Interconnect over Frame
   Relay" [3] for frame relay service and packet encapsulation.
   Currently, Novell has not stabilized the method for treating frame
   relay connections - whether they treat the connections as LANs or
   WANs.

1.5 Operation over other WAN media

   Additional WAN media will be added here as specifications are
   developed.

2. Glossary Of Terms

Primary Network Number:

      Every IPX WAN router has a "primary network number". This is an
      IPX network number unique to the entire internet.  This number
      will be a permanently assigned network number for the router.
      Those readers familiar with NetWare 3.x servers should realize
      that this is the "Internal" network number.

Router Name:

      Every IPX WAN router must have a "Router Name". This is a symbolic
      name given to the router. Its purpose is to allow routers to know
      who they are connected to after link establishment - particularly
      for network management purposes.  A symbolic name conveys more
      information to an operator than a set of numbers. The symbolic
      name should be between 1 and 47 characters in length containing
      the characters 'A' through 'Z', underscore (_), hyphen (-) and
      "at" sign (@). The string of characters should be followed by a
      null character (byte of zero) and padded to 48 characters using
      the null character.  Those readers familiar with NetWare 3.x
      servers should realize that the file server name is the Router
      Name.





Allen                                                           [Page 3]

RFC 1362                         IPXWAN                   September 1992


3. IPX WAN Protocol Description

   IPX WAN links have the concept of a LINK MASTER and a LINK SLAVE.
   This relationship is decided upon based on information contained
   within the first IPX packets transferred across the WAN link.

   After link establishment, both sides of the link send "Timer Request"
   packets and start a timer waiting for a "Timer Response". These
   "Timer Request" packets are sent every 20 seconds until a response is
   received or a time-out occurs trying to initialize a connection (the
   timer is restarted each time a new "Timer Request" is sent). The
   time-out should be configurable, and is normally about one minute.
   This is directly dependent on the call setup time for the connection.
   If a time-out occurs, the router issues a disconnect on the offending
   connection and optionally attempts to retry the connection.

   When a "Timer Request" is received, the router with the lowest
   primary network number MUST respond with a "Timer Response" packet -
   and become the "Slave" of the link. If the "Slave" determines that it
   cannot support any of the Routing Types included in the "Timer
   Request" packet, the "Slave" should issue a disconnect on the
   connection being established. The "Master" of the link (determined
   when a "Timer Response" packet is received) is responsible for
   defining the network number that is to be used as a common network
   number for the new WAN link, and for calculating the RIP transport
   time that will be advertized to other RIP routers for the new link.
   This is calculated by stopping the timer which was started when a
   "Timer Request" was initiated and applying the algorithm in section
   4.2.

   To allow this, both sides of the link MUST have an adequate pool of
   WAN network numbers (unique within the internetwork) available to be
   assigned to the link when the call is fully completed. The "Master"
   of the link MUST then select a network number and construct an
   "Information Request" packet containing the calculated link delay,
   the common network number, and its own router name. On receiving this
   packet, the "Slave" MUST turn the packet around, overwrite the router
   name and node identifier and send an "Information Response".

   After the "Master" has received the "Information Response" and the
   "Slave" has received the "Information Request", standard IPX RIP and
   SAP packets are transferred across the WAN link, as currently defined
   for LAN links. The "IPX Router Specification" [5] contains
   information describing the Novell RIP/SAP protocol for third party
   developers.

   Note that the "Information Request" and "Information Response"
   packets are specific to the "Routing Type"=0 information exchanges.



Allen                                                           [Page 4]

RFC 1362                         IPXWAN                   September 1992


   With this routing type, no retransmission is made of any of the
   Information packets. If a response has not been received within the
   predefined time-out period, a disconnect is issued on the link, and
   the link can optionally be attempted later.

   If a router detects an error for which no suitable protocol response
   exists (e.g., unable to allocate a network number), the link should
   be terminated according to the relevant media specification.

   Under certain circumstances, particularly on X.25 permanent circuits,
   it is only possible to detect the remote router went away when it
   comes back up again.  In this case, one side of the link receives a
   Timer Request packet when IPX is in a fully connected state.  The
   side receiving the Timer Request MUST realize that a problem
   occurred, and revert to the IPX link establishment phase.
   Furthermore, the routing information learned from this connection
   should be immediately discarded.

4. Information Exchange Packet Formats

   All IPX WAN information exchange packets conform to the standard
   Novell IPX packet format. The packets use the IPX defined packet type
   04 defining a Packet Exchange Packet. The socket number 0x9004 is a
   Novell reserved socket number for exclusive use with IPX WAN
   information exchange. IPX defines that a network number of 0 is
   interpreted as being a local network of unknown number that requires
   no routing. This feature is of use to us in transferring these
   packets before the common network number is exchanged. Some routers
   need to know a "Node Number" (or MAC address) for each node on a
   link. Node numbers will be formed from the "WNode ID" field.  The
   node number will be the 4 bytes of WNode ID followed by 2 bytes of
   zero.

   Router Type number assignment. Other vendors IPX routing protocols
   can make use of the IPXWAN protocol definition by obtaining Router
   Types from Novell. This document will then include the new Router
   Types (with the references to vendor protocol description documents).

   WOption Number assignment. These numbers only need to be assigned
   from Novell for the "Timer Request" and "Timer Response" packets.
   Other packet types (e.g., the "Information Request" packets, are
   dependent on the "Router Type" negotiated and can contain any (vendor
   defined) packet type other than 0 or 1. WOption numbers in these
   packets are then defined by the vendor defining the Routing Type. The
   same packet format should still be maintained.






Allen                                                           [Page 5]

RFC 1362                         IPXWAN                   September 1992


4.1 Timer Request Packet

   +---------------------------------------------------------------+
   | Checksum         | FF FF             | Always FFFF            |
   | Packet Length    | 02 40             | Max IPX size (576 bytes|
   |                  |                   | Hi Lo order)           |
   | Trans Control    | 00                | Hops traversed         |
   | Packet Type      | 04                | Packet Exchange Packet |
   | Dest Net #       | 00 00 00 00       | Local Network          |
   | Dest Node #      | FF FF FF FF FF FF | Broadcast              |
   | Dest Socket #    | 90 04             | Reserved WAN socket    |
   | Source Net #     | 00 00 00 00       | Local Network          |
   | Source Node #    | 00 00 00 00 00 00 | Set to zero            |
   | Source Socket #  | 90 04             | Reserved WAN socket    |
   |------------------+-------------------+------------------------|
   | WIdentifier      | 57 41 53 4D       | Confidence identifier  |
   | WPacket Type     | 00                | Timer Request          |
   | WNode ID         | xx xx xx xx       | Primary Net # of       |
   |                  |                   | sending router         |
   |                  |                   | (Hi Lo order)          |
   | WSequence #      | xx                | Sequence start at 0    |
   | WNum Options     | 02                | 2 Options follow       |
   | WOption Number   | 00                | Define Routing Type    |
   | WAccept Option   | 01                | 0=No,1=Yes,3=Not Applic|
   | WOption Data Len | 00 01             | Option length (Hi Lo)  |
   | WOption Data     | 00                | IPX RIP/SAP Routing    |
   | WOption Number   | FF                | Pad option             |
   | WAccept Option   | 01                | 0=No,1=Yes,3=Not Applic|
   | WOption Data Len | 02 0E             | Pad data length (Hi Lo)|
   | WOption Data     | 00->FF's          | Repeated sequence of 00|
   |                  |                   | through FF's.          |
   +---------------------------------------------------------------+

   Note:
        Timer Request packets will always be 576 bytes. However,
        there should be no assumption made about the number of
        options specified in this packet.

   After link establishment, Timer Request packets are sent by both
   sides of the link. Each end starts their sequence number at zero.
   Subsequent retries (every 20 seconds) will increment the value of
   this sequence number.  Only a Timer Response packet with a sequence
   number matching the last sent sequence number will be acted upon.

   When receiving this packet, the WNode ID should be compared to the
   receiver's Primary Network #. If the WNode ID is larger than the
   receiver's Primary Network #, a Timer Response packet should be sent,
   and the receiver should become the link "Slave".



Allen                                                           [Page 6]

RFC 1362                         IPXWAN                   September 1992


   Packets received on the reserved socket number not having the
   WIdentifier set to the hexadecimal values noted above should be
   discarded.

Routing Type Option:

   A routing type of zero (0) is the minimum interoperability
   requirement (as defined by this document). A router ready to send a
   Timer Response (and receiving a routing type of zero) MUST respond
   with a routing type of zero. A router ready to send a Timer Response
   (and receiving routing types not matching a supported value) SHOULD
   respond with a Routing Type of zero indicating support for the
   minimum common protocol.

   Note that multiple Routing Type Options can be included in the Timer
   Request packet if the router supports multiple routing methods for
   IPX. The included Router Types MUST include and support this type
   zero option.

Accept Option (for Routing Type and PAD options):

   This field MUST be set to YES if the option is supported, and NO if
   an option is not supported. A Timer Response MUST respond with ONLY
   one Router Type set to YES.

PAD Option:

   This option will normally be the last entry in the packet.  Its sole
   purpose is to fill the IPX packet to be 576 bytes.  The pad option
   data will contain a repeating sequence of zero's through 0xFF's. This
   should stop compression modems from collapsing the packet and
   destroying the link delay calculation.

   Currently Assigned WOption Numbers (Timer Request Packet):
       Routing Type Option = 0x00;     Option Length = 0001
           Current option data values:
               0       Novell RIP/SAP routing with network
                       number assigned to the link.

       PAD Type Option     = 0xFF;     Option Length = Variable

       Compression Option  = 0x80;     Option Length = Variable
                         (length dependent on compression type)
           Current option data values:
               Byte 1  Compression type
                   0 = Telebit compression (length=3) [6]
                   Telebit Byte 2 - Compression options
                   Telebit Byte 3 - Number compression slots



Allen                                                           [Page 7]

RFC 1362                         IPXWAN                   September 1992


4.2. Timer Response Packet

   +---------------------------------------------------------------+
   | Checksum         | FF FF             | Always FFFF            |
   | Packet Length    | 02 40             | Max IPX size (576 bytes|
   |                  |                   | Hi Lo order)           |
   | Trans Control    | 00                | Hops traversed         |
   | Packet Type      | 04                | Packet Exchange Packet |
   | Dest Net #       | 00 00 00 00       | Local Network          |
   | Dest Node #      | FF FF FF FF FF FF | Broadcast              |
   | Dest Socket #    | 90 04             | Reserved WAN socket    |
   | Source Net #     | 00 00 00 00       | Local Network          |
   | Source Node #    | 00 00 00 00 00 00 | Set to zero            |
   | Source Socket #  | 90 04             | Reserved WAN socket    |
   |------------------+-------------------+------------------------|
   | WIdentifier      | 57 41 53 4D       | Confidence identifier  |
   | WPacket Type     | 01                | Timer Response         |
   | WNode ID         | xx xx xx xx       | Primary Net # of       |
   |                  |                   | sending router         |
   |                  |                   | (Hi Lo order)          |
   | WSequence #      | xx                | Same as Timer Request  |
   |                  |                   | received               |
   | WNum Options     | 02                | 2 Options follow       |
   | WOption Number   | 00                | Define Routing Type    |
   | WAccept Option   | 01                | 0=No,1=Yes,3=Not Applic|
   | WOption Data Len | 00 01             | Option length (Hi Lo)  |
   | WOption Data     | 00                | IPX RIP/SAP Routing    |
   |                  |                   | (Minimum interoperating|
   |                  |                   | requirement). Others   |
   |                  |                   | may be defined by at a |
   |                  |                   | later date by Novell   |
   | WOption Number   | FF                | Pad option             |
   | WAccept Option   | 01                | 0=No,1=Yes,3=Not Applic|
   | WOption Data Len | 02 0E             | Pad data length (Hi Lo)|
   | WOption Data     | 00->FF's          | Repeated sequence of 00|
   |                  |                   | through FF's to stop   |
   |                  |                   | compression modems     |
   |                  |                   | doing any compression  |
   |                  |                   | for link delay calc.   |
   +---------------------------------------------------------------+

   The responses contained within this packet are as described in
   section 4.1. Any unknown options or not supported options from the
   Timer Request should have the WAccept Option set to NO.

   If the Timer Request packet contained more than one Router Type
   option and the "Slave" supports all the options, the "Slave" should
   set the WAccept Option to NO on all Router Types except the Routing



Allen                                                           [Page 8]

RFC 1362                         IPXWAN                   September 1992


   Type which is to be adopted. The "Master" of the link will then adopt
   the routing option specified with the YES setting and complete
   further information exchanges according to that routing standard.

   This packet should contain the same sequence number as the received
   Timer Request. This packet should ONLY be sent by the router
   determining themselves to be the "Slave" of the link.

   Currently Assigned WOption Numbers (Timer Response Packet):
       Routing Type Option = 0x00;     Option Length = 0001
           Current option data values:
              0       Novell RIP/SAP routing with network
                      number assigned to the link.

       PAD Type Option     = 0xFF;     Option Length = Variable

       Compression Option  = 0x80;     Option Length = Variable
                         (length dependant on compression type)
           Current option data values:
               Byte 1  Compression type
                   0 = Telebit compression (length=3) [6]
                   Telebit Byte 2 - Compression options
                   Telebit Byte 3 - Number compression slots




























Allen                                                           [Page 9]

RFC 1362                         IPXWAN                   September 1992


4.3. RIP/SAP Information Request Packet (Router Type=0 Only)

   +---------------------------------------------------------------+
   | Checksum         | FF FF             | Always FFFF            |
   | Packet Length    | 00 63             | Size of header+data    |
   |                  |                   | (Hi Lo order)          |
   | Trans Control    | 00                | Hops traversed         |
   | Packet Type      | 04                | Packet Exchange Packet |
   | Dest Net #       | 00 00 00 00       | Local Network          |
   | Dest Node #      | FF FF FF FF FF FF | Broadcast              |
   | Dest Socket #    | 90 04             | Reserved WAN socket    |
   | Source Net #     | 00 00 00 00       | Local Network          |
   | Source Node #    | 00 00 00 00 00 00 | Set to zero            |
   | Source Socket #  | 90 04             | Reserved WAN socket    |
   |------------------+-------------------+------------------------|
   | WIdentifier      | 57 41 53 4D       | Confidence identifier  |
   | WPacket Type     | 02                | Information Request    |
   | WNode ID         | xx xx xx xx       | Primary Net # of       |
   |                  |                   | sending router         |
   |                  |                   | (Hi Lo order)          |
   | WSequence #      | 00                | Sequence start at 0    |
   | WNum Options     | 01                | 1 Option to follow     |
   | WOption Number   | 01                | Define IPX RIP/SAP     |
   |                  |                   | info exchange          |
   | WAccept Option   | 01                | 0=No,1=Yes,3=Not Applic|
   | WOption Data Len | 00 36             | Option length (Hi Lo)  |
   | WOption Data     |                   |                        |
   |  Link Delay      | xx xx             | Hi Lo link delay in    |
   |                  |                   | milli seconds (see     |
   |                  |                   | below for calculation) |
   |  Common Net #    | xx xx xx xx       | Hi Lo Common Network # |
   |  Router Name     | xx (x 48 decimal) | Router name - as defned|
   |                  |                   | in section 2.          |
   +---------------------------------------------------------------+

















Allen                                                          [Page 10]

RFC 1362                         IPXWAN                   September 1992


Calculation of link delay is performed as follows:

   // Start_time is a time stamp when Timer Request sent out
   // End_time is a time stamp when a Timer Response is
   // received.
   link_delay = end_time - start_time; // 1/18th second
   // We are on a slow net, so add some biasing to help stop
   // multiple workstation sessions timing out on the link
   if (link_delay < 1)
   {
       link_delay = 1;
   }/*IF*/
   link_delay *= 6;   // Add the biasing
   link_delay *= 55;  // Convert link delay to milliseconds

   The "Link Delay" is used as the network transport time when
   advertized in the IPX RIP packet tuple for the network entry "Common
   Net #". For a consistent network, a common link delay is required at
   both ends of the link and is calculated by the link "Master".

   The Common Net # is supplied by the link "Master". This number must
   be unique in the connected internetwork. Each WAN call requires a
   separate number.

   Currently only a single option is defined for the "Information
   Request" packet for Routing Type=0.

























Allen                                                          [Page 11]

RFC 1362                         IPXWAN                   September 1992


4.4. RIP/SAP Information Response Packet (Router Type=0 Only)

   +---------------------------------------------------------------+
   | Checksum         | FF FF             | Always FFFF            |
   | Packet Length    | 00 63             | Size of header+data    |
   |                  |                   | (Hi Lo Order)          |
   | Trans Control    | 00                | Hops traversed         |
   | Packet Type      | 04                | Packet Exchange Packet |
   | Dest Net #       | 00 00 00 00       | Local Network          |
   | Dest Node #      | FF FF FF FF FF FF | Broadcast              |
   | Dest Socket #    | 90 04             | Reserved WAN socket    |
   | Source Net #     | 00 00 00 00       | Local Network          |
   | Source Node #    | 00 00 00 00 00 00 | Set to zero            |
   | Source Socket #  | 90 04             | Reserved WAN socket    |
   |------------------+-------------------+------------------------|
   | WIdentifier      | 57 41 53 4D       | Confidence identifier  |
   | WPacket Type     | 03                | Information Response   |
   | WNode ID         | xx xx xx xx       | Primary Net # of       |
   |                  |                   | sending router         |
   |                  |                   | (Hi Lo order)          |
   | WSequence #      | 00                | Sequence start at 0    |
   | WNum Options     | 01                | 1 Option to follow     |
   | WOption Number   | 01                | Define IPX RIP/SAP     |
   |                  |                   | info exchange          |
   | WAccept Option   | 01                | 0=No,1=Yes,3=Not Applic|
   | WOption Data Len | 00 36             | Option length (Hi Lo)  |
   | WOption Data     |                   |                        |
   |  Link Delay      | xx xx             | Hi Lo link delay (as   |
   |                  |                   | received in Info Requ) |
   |  Common Net #    | xx xx xx xx       | Hi Lo Common Network # |
   |                  |                   | (as received in Info   |
   |                  |                   | request)               |
   |  Router Name     | xx (x 48 decimal) | Router name - as defned|
   |                  |                   | in section 2.          |
   +---------------------------------------------------------------+

   The responses contained within this packet are as described in
   section 4.3.

5. References

   [1] Simpson, W., "The Point-to-Point Protocol (PPP) for the
       Transmission of Multi-protocol Datagrams over Point-to-Point
       Links", RFC 1331, May 1992.

   [2] Malis, A., Robinson, D., and R. Ullman, "Multiprotocol
       Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356,
       August 1992.



Allen                                                          [Page 12]

RFC 1362                         IPXWAN                   September 1992


   [3] Bradley, T., Brown, C., and A. Malis, "Multiprotocol Interconnect
       over Frame Relay", RFC 1294, January 1992.

   [4] Simpson, W., "The PPP Internetwork Packet Exchange Control
       Protocol (IPXCP) Compromise Version", Work in Progress.

   [5] Novell IPX Router Specification. Novell Part Number 107-000029-
       001. (Note:  Currently, this document is only available as part
       of a Novell developers program as part of an SDK. Novell Labs,
       Provo (UT) should be able to provide more information on this
       document.)

   [6] Lewis, M., Telebit Corp. "IPX Header Compression based on Van
       Jacobson Header Compression for TCP/IP", Work in Progress,
       contact: (mlewis@telebit.com).

6. Security Considerations

       Security issues are not discussed in this memo.

7. Author's Address

       Michael Allen
       Novell, Inc.
       2180 Fortune Drive
       San Jose, CA 95131

       EMail: MALLEN@NOVELL.COM

       Chair's Address:

       The working group can be contacted via the current chair:

       Brian Lloyd
       Lloyd & Associates
       3420 Sudbury Road
       Cameron Park, California 95682

       EMail: brian@ray.lloyd.com

       Phone: (916) 676-1147










Allen                                                          [Page 13]