File: rfc1454.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 (843 lines) | stat: -rw-r--r-- 35,064 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
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843






Network Working Group                                          T. Dixon
Request for Comments: 1454                                         RARE
                                                               May 1993


             Comparison of Proposals for Next Version of IP

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 is a slightly edited reprint of RARE Technical Report
   (RTC(93)004).

   The following is a brief summary of the characteristics of the three
   main proposals for replacing the current Internet Protocol. It is not
   intended to be exhaustive or definitive (a brief bibliography at the
   end points to sources of more information), but to serve as input to
   the European discussions on these proposals, to be co-ordinated by
   RARE and RIPE. It should be recognised that the proposals are
   themselves "moving targets", and in so far as this paper is accurate
   at all, it reflects the position at the 25th IETF meeting in
   Washington, DC. Comments from Ross Callon and Paul Tsuchiya on the
   original draft have been incorporated.  Note that for a time the term
   "IPv7" was use to mean the eventual next version of IP, but that the
   same term was closely associated with a particilar proposal, so the
   term "IPng" is now used to identify the eventual next generation of
   IP.

   The paper begins with a "generic" discussion of the mechanisms for
   solving problems and achieving particular goals, before discussing
   the proposals invidually.

1. WHY IS THE CURRENT IP INADEQUATE?

   The problem has been investigated and formulated by the ROAD group,
   but briefly reduces to the following:

      - Exhaustion of IP Class B Address Space.

      - Exhaustion of IP Address Space in General.

      - Non-hierarchical nature of address allocation leading to flat
        routing space.



Dixon                                                           [Page 1]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


   Although the IESG requirements for a new Internet Protocol go further
   than simply routing and addressing issues,  it is these issues that
   make extension of the current protocol an impractical option.
   Consequently, most of the discussion and development of the various
   proposed protocols has concentrated on these specific problems.

   Near term remedies for these problems include the CIDR proposals
   (which permit the aggregation of Class C networks for routing
   purposes) and assignment policies which will allocate Class C network
   numbers in a fashion which CIDR can take advantage of. Routing
   protocols supporting CIDR are OSPF and BGP4. None of these are pre-
   requisites for the new IP (IPng), but are necessary to prolong the
   life of the current Internet long enough to work on longer-term
   solutions. Ross Callon points out that there are other options for
   prolonging the life of IP and that some ideas have been distributed
   on the TUBA list.

   Longer term proposals are being sought which ultimately allow for
   further growth of the Internet. The timescale for considering these
   proposals is as follows:

      - Dec 15 Issue selection criteria as RFC.

      - Feb 12 Two interoperable implementations available.

      - Feb 26 Second draft of proposal documents available.

   The (ambitious) target is for a decision to be made at the 26th IETF
   (Columbus, Ohio in March 1993) on which proposals to pursue.

   The current likely candidates for selection are:

      - PIP ('P' Internet Protocol - an entirely new protocol).

      - TUBA (TCP/UDP with Big Addresses - uses ISO CLNP).

      - SIP (Simple IP - IP with larger addresses and fewer options).

   There is a further proposal from Robert Ullman of which I don't claim
   to have much knowledge. Associated with each of the candidates are
   transition plans, but these are largely independent of the protocol
   itself and contain elements which could be adopted separately, even
   with IP v4, to further extend the life of current implementations and
   systems.







Dixon                                                           [Page 2]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


2. WHAT THE PROPOSALS HAVE IN COMMON

2.1 Larger Addresses

   All the proposals (of course) make provision for larger address
   fields which not only increase the number of addressable systems, but
   also permit the hierarchical allocation of addresses to facilitate
   route aggregation.

2.2 Philosophy

   The proposals also originate from a "routing implementation" view of
   the world - that is to say they focus on the internals of routing
   within the network and do not primarily look at the network service
   seen by the end-user, or by applications. This is perhaps inevitable,
   especially given the tight time constraints for producing
   interoperable implementations. However, the (few) representatives of
   real users at the 25th IETF, the people whose support is ultimately
   necessary to deploy new host implementations, were distinctly
   unhappy.

   There is an inbuilt assumption in the proposals that IPng is
   intended to be a universal protocol: that is, that the same network-
   layer protocol will be used between hosts on the same LAN, between
   hosts and routers, between routers in the same domain, and between
   routers in different domains. There are some advantages in defining
   separate "access" and "long-haul" protocols, and this is not
   precluded by the requirements. However, despite the few opportunities
   for major change of this sort within the Internet, the need for speed
   of development and low risk have led to the proposals being
   incremental, rather than radical, changes to well-proven existing
   technology.

   There is a further unstated assumption that the architecture is
   targeted at the singly-connected host. It is currently difficult to
   design IPv4 networks which permit hosts with more than one interface
   to benefit from increased bandwidth and reliability compared with
   singly-connected hosts (a consequence of the address belonging to the
   interface and not the host). It would be preferable if topological
   constraints such as these were documented. It has been asserted that
   this is not necessarily a constraint of either the PIP or TUBA
   proposals, but I believe it is an issue that has not emerged so far
   amongst the comparative criteria.








Dixon                                                           [Page 3]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


2.3 Source Routing

   The existing IPv4 has provision for source-specified routes, though
   this is little used [would someone like to contradict me here?],
   partly because it requires knowledge of the internal structure of the
   network down to the router level. Source routes are usually required
   by users when there are policy requirements which make it preferable
   or imperative that traffic between a source and destination should
   pass through particular administrative domains. Source routes can
   also be used by routers within administrative domains to route via
   particular logical topologies. Source-specified routing requires a
   number of distinct components:

      a.  The specification by the source of the policy by which the
          route should be selected.

      b.  The selection of a route appropriate to the policy.

      c.  Marking traffic with the identified route.

      d.  Routing marked traffic accordingly.

   These steps are not wholly independent. The way in which routes are
   identified in step (c) may constrain the kinds of route which can be
   selected in previous steps. The destination, inevitably, participates
   in the specification of source routes either by advertising the
   policies it is prepared to accept or, conceivably, by a negotiation
   process.

   All of the proposals mark source routes by adding a chain of (perhaps
   partially-specified) intermediate addresses to each packet. None
   specifies the process by which a host might acquire the information
   needed to  specify these intermediate addresses [not entirely
   unreasonably at this stage, but further information is expected]. The
   negative consequences of these decisions are:

      - Packet headers can become quite long, depending on the number of
        intermediate addresses that must be specified (although there are
        mechanisms which are currently specified or which can be imagined
        to specify only the significant portions of intermediate addresses).

      - The source route may have to be re-specified periodically if
        particular intermediate addresses are no longer reachable.

   The positive consequences are:

      - Inter-domain routers do not have to understand policies, they
        simply have to mechanically follow the source route.



Dixon                                                           [Page 4]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


      - Routers do not have to store context identifying routes, since
        the information is specified in each packet header.

      - Route servers can be located anywhere in the network, provided
        the hosts know how to find them.

2.4 Encapsulation

   Encapsulation is the ability to enclose a network-layer packet within
   another one so that the actual packet can be directed via a path it
   would not otherwise take to a router that can remove the outermost
   packet and direct the resultant packet to its destination.
   Encapsulation requires:

      a.  An indication in the packet that it contains another packet.

      b.  A function in routers which, on receiving such a packet,
          removes the encapsulation and re-enters the forwarding process.

   All the proposals support encapsulation. Note that it is possible to
   achieve the effect of source routing by suitable encapsulation by the
   source.

2.5 Multicast

   The specification of addresses to permit multicast with various
   scopes can be accomodated by all the proposals. Internet-wide
   multicast is, of course, for further study!

2.6 Fragmentation

   All the proposals support the fragmentation of packets by
   intermediate routers, though there has been some recent discussion of
   removing this mechanism from some of the proposals and requiring the
   use of an MTU-discovery process to avoid the need for fragmentation.
   Such a decision would effectively preclude the use of transport
   protocols which use message-count sequence numbering (such as OSI
   Transport) over the network, as only protocols with byte-count
   acknowledgement (such as TCP) can deal with MTU reductions during the
   lifetime of a connection. OSI Transport may not be particularly
   relevant to the IP community (though it may be of relevance to
   commercial suppliers providing multiprotocol services), however the
   consequences for the types of services which may be supported over
   IPng should be noted.







Dixon                                                           [Page 5]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


2.7 The End of Lifetime as We Know It

   The old IPv4 "Time to Live" field has been recast in every case as a
   simple hop count, largely on grounds of implementation convenience.
   Although the old TTL was largely implemented in this fashion anyway,
   it did serve an architectural purpose in putting an upper bound on
   the lifetime of a packet in the network. If this field is recast as a
   hop-count, there must be some other specification of the maximum
   lifetime of a packet in the network so that a source host can ensure
   that network-layer fragment ids and transport-layer sequence numbers
   are never in danger of re-use whilst there is a danger of confusion.
   There are, in fact, three separate issues here:

      1. Terminating routing loops (solved by hop count).

      2. Bounding lifetime of network-layer packets (a necessity,
         unspecified so far) to support assumptions by the transport
         layer.

      3. Permitting the source to place further restrictions on packet
         lifetime (for example so that "old" real-time traffic can be
         discarded in favour of new traffic in the case of congestion
         (an optional feature, unspecified so far).

3. WHAT THE PROPOSALS ONLY HINT AT

3.1 Resource Reservation

   Increasingly, applications require a certain bandwidth or transit
   delay if they are to be at all useful (for example, real-time video
   and audio transport). Such applications need procedures to indicate
   their requirements to the network and to have the required resources
   reserved.  This process is in some ways analogous to the selection of
   a source route:

      a.  The specification by the source of its requirements.

      b.  The confirmation that the requirements can be met.

      c.  Marking traffic with the requirement.

      d.  Routing marked traffic accordingly.

   Traffic which is routed according to the same set of resource
   requirements is sometimes called a "flow". The identification of
   flows requires a setup process, and it is tempting to suppose that
   the same process might also be used to set up source routes, however,
   there are a number of differences:



Dixon                                                           [Page 6]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


      - All the routers on a path must participate in resource
        reservation and agree to it.

      - Consequently, it is relatively straightforward to maintain
        context in each router and the identification for flows can be
        short.

      - The network can choose to reroute on failure.

   By various means, each proposal could carry flow-identification,
   though this is very much "for future study" at present. No setup
   mechansisms are defined. The process for actually reserving the
   resources is a higher-order problem. The interaction between source-
   routing and resource reservation needs further investigation:
   although the two are distinct and have different implementation
   constraints, the consequence of having two different mechanisms could
   be that it becomes difficult to select routes which meet both policy
   and performance goals.

3.2 Address-Assignment Policies

   In IPv4, addresses were bound to systems on a long-term basis and in
   many cases could be used interchangeably with DNS names. It is
   tacitly accepted that the association of an address with a particular
   system may be more volatile in IPng. Indeed, one of the proposals,
   PIP, makes a distinction between the identification of a system (a
   fixed quantity) and its address, and permits the binding to be
   altered on the fly. None of the proposals defines bounds for the
   lifetime of addresses, and the manner in which addresses are assigned
   is not necessarily bound to a particular proposal. For example,
   within the larger address space to be provided by IPng, there is a
   choice to be made of assigning the "higher order" part of the
   hierarchical address in a geographically-related fashion or by
   reference to service provider. Geographically-based addresses can be
   constant and easy to assign, but represent a renewed danger of
   degeneration to "flat" addresses within the region of assignment,
   unless certain topological restrictions are assumed.  Provider-based
   address assignment results in a change of address (if providers are
   changed) or multiple addresses (if multiple providers are used).
   Mobile hosts (depending on the underlying technology) can present
   problems in both geographic and provider-based schemes.

   Without firm proposals for address-assignment schemes and the
   consequences for likely address lifetimes, it is impossible to assume
   that the existing DNS model by which name-to-address bindings can be
   discovered remains valid.





Dixon                                                           [Page 7]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


   Note that there is an interaction between the mechanism for
   assignment of addresses and way in which automatic configuration may
   be deployed.

3.3 Automatic Configuration

   Amongst the biggest (user) bugbears of current IP services is the
   administrative effort of maintaining basic configuration information,
   such as assigning names and addresses to hosts, ensuring these are
   refelected in the DNS, and keeping this information correct. Part of
   this results from poor implementation (or the blind belief that vi
   and awk are network management tools). However, a lot of the problems
   could be alleviated by making this process more automatic. Some of
   the possibilities (some mutually-exlusive) are:

      - Assigning host addresses from some (relative) invariant, such
        as a LAN address.

      - Defining a protocol for dynamic assignment of addresses within a
        subnetwork.

      - Defining "generic addresses" by which hosts can without
        preconfiguration reach necessary local servers (DNS, route
        servers, etc.).

      - Have hosts determine their name by DNS lookup.

      - Have hosts update their name/address bindings when their
        configuration changes.

   Whilst a number of the proposals make mention of some of these
   possibilities, the choice of appropriate solutions depends to some
   extent on address-assignment policies. Also, dynamic configuration
   results in some difficult philosopical and practical issues (what
   exactly is the role of an address?, In what sense is a host "the same
   host" when its address changes?, How do you handle dynamic changes to
   DNS mappings and how do you authenticate them?).

   The groups involved in the proposals would, I think, see most of
   these questions outside their scope. It would seem to be a failure in
   the process of defining and selecting candidates for IPng that
   "systemness" issues like these will probably not be much discussed.
   This is recognised by the participants, and it is likely that, even
   when a decision is made, some of these ideas will be revisited by a
   wider audience.

   It is, however, unlikely that IP will make an impact on proprietary
   networking systems for the non-technical environment (e.g., Netware,



Dixon                                                           [Page 8]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


   Appletalk), without automatic configuration being taken seriously
   either in the architecture, or by suppliers. I believe that there are
   ideas on people's heads of how to address these issues - they simply
   have not made it onto paper yet.

3.4 Application Interface/Application Protocol Changes

   A number of common application protocols (FTP, RPC, etc.) have been
   identified which specifically transfer 32-bit IPv4 addresses, and
   there are doubtless others, both standard and proprietary. There are
   also many applications which treat IPv4 addresses as simple 32-bit
   integers. Even applications which use BSD sockets and try to handle
   addresses opaquely will not understand how to parse or print longer
   addresses (even if the socket structure is big enough to accommodate
   them).

   Each proposal, therefore, needs to specify mechanisms to permit
   existing applications and interfaces to operate in the new
   environment whilst conversion takes place. It would be useful also,
   to have (one) specification of a reference programming interface for
   (TCP and) IPng (which would also operate on IPv4), to allow
   developers to begin changing applications now. All the proposals
   specify transition mechansisms from which existing application-
   compatibility can be inferred. There is no sign yet of a new
   interface specification independent of chosen protocol.

3.5 DNS Changes

   It is obvious that there has to be a name to address mapping service
   which supports the new, longer, addresses. All the proposals assume
   that this service will be provided by DNS, with some suitably-defined
   new resource record. There is some discussion ongoing about the
   appropriateness of returning this information along with "A" record
   information in response to certain enquiries, and which information
   should be requested first. There is a potential tradeoff between the
   number of queries needed to establish the correct address to use and
   the potential for breaking existing implementations by returning
   information that they do not expect.

   There has been heat, but not light, generated by discussion of  the
   use of DNS for auto-configuration and the scaling (or otherwise) of
   reverse translations for certain addressing schemes.









Dixon                                                           [Page 9]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


4. WHAT THE PROPOSALS DON'T REALLY MENTION

4.1 Congestion Avoidance

   IPv4 offers "Source Quench" control messages which may be used by
   routers to indicate to a source that it is congested and has or may
   shortly drop packets. TUBA/PIP have a "congestion encountered" bit
   which provides similar information to the destination. None of these
   specifications offers detailed instructions on how to use these
   facilities. However, there has been a substantial body of analysis
   over recent years that suggests that such facilities can be used (by
   providing information to the transport protocol) not only to signal
   congestion, but also to minimise delay through the network layer.
   Each proposal can offer some form of congestion  signalling, but none
   specifies a mechanism for its use (or an analysis of whether the
   mechanism is in fact useful).

   As a user of a network service which currently has a discard rate of
   around 30% and a round-trip-time of up to 2 seconds for a distance of
   only 500 miles I would be most interested in some proposals for a
   more graceful degradation of the network service under excess load.

4.2 Mobile Hosts

   A characteristic of mobile hosts is that they (relatively) rapidly
   move their physical location and point of attachment to the network
   topology.  This obviously has signficance for addressing (whether
   geographical or topological) and routing. There seems to be an
   understanding of the problem, but so far no detailed specification of
   a solution.

4.3 Accounting

   The IESG selection criteria require only that proposals do not have
   the effect of preventing the collection of information that may be of
   interest for audit or billing purposes. Consequently, none of the
   proposals  consider potential accounting mechanisms.

4.4 Security

   "Network Layer Security Issues are For Further Study". Or secret.

   However, it would be useful to have it demonstrated that each
   candidate could be extended to provide a level of security, for
   example against address-spoofing. This will be particularly
   important if resource-allocation features will permit certain hosts
   to claim large chunks of available bandwidth for specialised
   applications.



Dixon                                                          [Page 10]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


   Note that providing some level of security implies manual
   configuration of security information within the network and must be
   considered in relationship to auto-configuration goals.

5. WHAT MAKES THE PROPOSALS DIFFERENT?

   Each proposal is about as different to the others as it is to IPv4 -
   that is the differences are small in principle, but may have
   significant effects (extending the size of addresses is only a small
   difference in principle!). The main distinct characteristics are:

   PIP:

      PIP has an innovative header format that facilitates hierarchical,
      policy and virtual-circuit routing. It also has "opaque" fields in
      the header whose semantics can be defined differently in different
      administrative domains and whose use and translation can be
      negotiated across domain boundaries. No control protocol is yet
      specified.

   SIP:

      SIP offers a "minimalist" approach - removing all little-used
      fields from the IPv4 header and extending the size of addresses to
      (only) 64 bits. The control protocol is based on modifications to
      ICMP. This proposal has the advantages of processing efficiency
      and familiarity.

   TUBA:

      TUBA is based on CLNP (ISO 8473) and the ES-IS (ISO 9542) control
      protocol. TUBA provides for the operation of TCP transport and UDP
      over a CLNP network. The main arguments in favour of TUBA are that
      routers already exist which can handle the network-layer protocol,
      that the extensible addresses offer a wide margin of "future-
      proofing" and that there is an opportunity for convergence of
      standards and products.

5.1 PIP

   PIP packet headers contain a set of instructions to the router's
   forwarding processor to perform certain actions on the packet. In
   traditional protocols, the contents of certain fields imply certain
   actions; PIP gives the source the flexibility to write small
   "programs" which direct the routing of packets through the network.

   PIP addresses have an effectively unlimited length: each level in the
   topological hierarchy of the network contributes part of the address



Dixon                                                          [Page 11]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


   and addresses change as the network topology changes. In a completely
   hierarchical network topology, the amount of routing information
   required at each level could be very small. However, in practice,
   levels of hierarchy will be determined more by commercial and
   practical factors than by the constraints of any particular routing
   protocol. A greater advantage is that higher-order parts of the
   address may be omitted in local exchanges and that lower-order parts
   may be omitted in source routes, reducing the amount of topological
   information that host systems are required to know.

   There is an assumption that PIP addresses are liable to change, so a
   further quantity, the PIP ID, is assigned to systems for the purposes
   of identification. It isn't clear that this quantity has any purpose
   which could not equally be served by a DNS name [it is more compact,
   but equally it does not need to be carried in every packet and
   requires an additional lookup]. However, the problem does arise of
   how two potentially-communicating host systems find the correct
   addresses to use.

   The most complex part of PIP is that the meaning of some of the
   header fields is determined by mutual agreement within a particular
   domain. The semantics of specific processing facilities (for example,
   queuing priority) are registered globally, but the actual use and
   encoding of requests for these facilities in the packet header can be
   different in different domains. Border routers between two domains
   which use different encodings must map  from one encoding to another.
   Since routers may not only be adjacent physically to other domains,
   but also via "tunnels", the number of different encoding rules a
   router may need to understand is potentially quite large. Although
   there is a saving in header space by using such a scheme as opposed
   to the more familiar "options", the cost in the complexity of
   negotiating the use and encoding of these facilities, together with
   re-coding the packets at each domain border, is a subject of some
   concern. Although it may be possible for hosts to "precompile" the
   encoding rules for their local domain, there are many potential
   implementaion difficulties.

   Although PIP offers the most flexibility of the three proposals, more
   work needs to be done on "likely use" scenarios which make the
   potential advantages and disadvantages more concrete.

5.2 SIP

   SIP is simply IP with larger addresses and fewer options. Its main
   advantage is that it is even simpler that IPv4 to process. Its main
   disadvantages are:





Dixon                                                          [Page 12]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


      - It is far from clear that, if 32 bits of address are
        insufficient, 64 will be enough for the forseeable future;

      - although there are a few "reserved" bits in the header, the
        extension of SIP to support new features is not obvious.

   There's really very little else to say!

5.3 TUBA

   The characteristics of ISO CLNS are reasonably well known: the
   protocol bears a strong cultural resemblance to IPv4, though with
   20-byte network-layer addressing. Apart from a spurious "Not Invented
   Here" prejudice, the main argument againt TUBA is that it is rather
   too like IPv4, offering nothing other than larger, more flexible,
   addresses.  There is proof-by-example that routers are capable of
   handling the (very) long addresses efficiently, rather less that the
   longer headers do not adversely impact network bandwidth.

   There are a number of objections to the proposed control protocol
   (ISO 9542):


      - My early experience is that the process by which routers
        discover hosts is inefficient and resource consuming for
        routers - and requires quite fine timer resolution on hosts -
        if large LANs are to be accomodated reasonably. Proponents of
        TUBA suggest that recent experience suggests that ARP is no
        better, but I think this issue needs examination.

      - The "redirect" mechanism is based on (effectively) LAN
        addresses and not network addresses, meaning that local routers
        can only "hand-off" complex routing decisions to other routers
        on the same LAN.  Equally, redirection schemes (such as that of
        IPv4) which redirect to network addresses can result in
        unnecessary extra hops.  Analysis of which solution is better
        is rather dependent on the scenarios which are constructed.

   To be fair, however, the part of the protocol which provides for
   router-discovery provides a mechanism, absent from other proposals,
   by which hosts can locate nearby gateways and potentially
   automatically configure their addresses.

6. Transition Plans

   It should be obvious that a transition which permits "old" hosts to
   talk to "new" hosts requires:




Dixon                                                          [Page 13]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


   Either:

      (a) That IPng hosts can also use IPv4 or
      (b) There is translation by an intermediate system

   and either:

      (c) The infrastructure between systems is capable of carrying both
          IPng and IPv4 or (d) Tunneling or translation is used to carry
          one protocol within another in parts of the network

   The transition plans espoused by the various proposals are simply
   different combinations of the above. Experience would tend to show
   that all these things will in fact happen, regardless of which
   protocol is chosen.

   One problem of the tunneling/translation process is that there is
   additional information (the extra address parts) which must be
   carried across IPv4 tunnels in the network. This can either be
   carried by adding an extra "header" to the data before encapsulation
   in the IPv4 packet, or by encoding the information as new IPv4 option
   types. In the former case, it may be difficult to map error messages
   correctly, since the original packet is truncated before return; in
   the latter case there is a danger of the packet being discarded (IPv4
   options are not self-describing and new ones may not pass through
   IPv4 routers). There is thus the possibility of having to introduce a
   "new" version of IPv4 in order to support IPng tunneling.

   The alternative (in which IPng hosts have two stacks and the
   infrastructure may or may not support IPng or IPv4) of course
   requires a mechanism for resolving which protocols to try.

7. Random Comments

   This is the first fundamental change in the Internet protocols that
   has occurred since the Internet was manageable as an entity and its
   development was tied to US government contracts. It was perhaps
   inevitable that the IETF/IESG/IAB structure would not have evolved to
   manage a change of this magnitude and it is to be hoped that the new
   structures that are proposed will be more successful in promoting a
   (useful) consensus. It is interesting to see that many of the
   perceived problems of the OSI process (slow progress, factional
   infighting over trivia, convergence on the lowest-common denominator
   solution, lack of consideration for the end-user) are in danger of
   attaching themselves to IPng and it will be interesting to see to
   what extent these difficulties are an inevitable consequence of wide
   representation and participation in network design.




Dixon                                                          [Page 14]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


   It could be regarded either as a sign of success or failure of the
   competitive process for the selection of IPng that the three main
   proposals  have few really significant differences. In this respect,
   the result of the selection process is not of particular
   significance, but the process itself is perhaps necessary to repair
   the social and technical cohesion of the Internet Engineering
   process.

8. Further Information

   The main discussion lists for the proposals listed are:

        TUBA:           tuba@lanl.gov
        PIP:            pip@thumper.bellcore.com
        SIP:            sip@caldera.usc.edu
        General:        big-internet@munnari.oz.au

        (Requests to: <list name>-request@<host>)

   Internet-Drafts and RFCs for the various proposals can be found in
   the usual places.

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   Tim Dixon
   RARE Secretariat
   Singel 466-468
   NL-1017AW Amsterdam
   (Netherlands)

   Phone: +31 20 639 1131 or + 44 91 232 0936
   EMail: dixon@rare.nl or Tim.Dixon@newcastle.ac.uk















Dixon                                                          [Page 15]