File: rfc2956.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 (899 lines) | stat: -rw-r--r-- 36,830 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
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899






Network Working Group                                            M. Kaat
Request for Comments: 2956                   SURFnet ExpertiseCentrum bv
Category: Informational                                     October 2000


              Overview of 1999 IAB Network Layer Workshop

Status of this Memo

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

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document is an overview of a workshop held by the Internet
   Architecture Board (IAB) on the Internet Network Layer architecture
   hosted by SURFnet in Utrecht, the Netherlands on 7-9 July 1999.  The
   goal of the workshop was to understand the state of the network layer
   and its impact on continued growth and usage of the Internet.
   Different technical scenarios for the (foreseeable) future and the
   impact of external influences were studied.  This report lists the
   conclusions and recommendations to the Internet Engineering Task
   Force (IETF) community.

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . .  2
   2. Conclusions and Observations . . . . . . . . . . . . . . .  3
    2.1  Transparency. . . . . . . . . . . . . . . . . . . . . .  3
    2.2  NAT, Application Level Gateways & Firewalls . . . . . .  4
    2.3  Identification and Addressing . . . . . . . . . . . . .  4
    2.4  Observations on Address Space . . . . . . . . . . . . .  5
    2.5  Routing Issues. . . . . . . . . . . . . . . . . . . . .  5
    2.6  Observations on Mobility. . . . . . . . . . . . . . . .  6
    2.7  DNS Issues. . . . . . . . . . . . . . . . . . . . . . .  7
    2.8  NAT and RSIP. . . . . . . . . . . . . . . . . . . . . .  7
    2.9  NAT, RSIP and IPv6. . . . . . . . . . . . . . . . . . .  8
    2.10 Observations on IPv6. . . . . . . . . . . . . . . . . .  9
   3. Recommendations. . . . . . . . . . . . . . . . . . . . . . 10
    3.1 Recommendations on Namespace . . . . . . . . . . . . . . 10
    3.2 Recommendations on RSIP. . . . . . . . . . . . . . . . . 10
    3.3 Recommendations on IPv6. . . . . . . . . . . . . . . . . 10
    3.4 Recommendations on IPsec . . . . . . . . . . . . . . . . 11



Kaat                         Informational                      [Page 1]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


    3.5 Recommendations on DNS . . . . . . . . . . . . . . . . . 11
    3.6 Recommendations on Routing . . . . . . . . . . . . . . . 12
    3.7 Recommendations on Application Layer and APIs. . . . . . 12
   4. Security Considerations. . . . . . . . . . . . . . . . . . 12
   References. . . . . . . . . . . . . . . . . . . . . . . . . . 13
   Appendix A. Participants. . . . . . . . . . . . . . . . . . . 15
   Author's Address. . . . . . . . . . . . . . . . . . . . . . . 15
   Full Copyright Statement  . . . . . . . . . . . . . . . . . . 16

1. Introduction

   From July 7 to July 9, 1999 the Internet Architecture Board (IAB)
   held a workshop on the architecture of the Internet Network Layer.
   The Network Layer is usually referred to as the IP layer.  The goal
   of the workshop was to discuss the current state of the Network Layer
   and the impact various currently deployed or future mechanisms and
   technologies might have on the continued growth and usage of the
   Internet.

   The most important issues to be discussed were:

   o  Status of IPv6 deployment and transition issues
   o  Alternative technical strategies in case IPv6 is not adopted
   o  Globally unique addresses and 32 bit address depletion
   o  Global connectivity and reachability
   o  Fragmentation of the Internet
   o  End to end transparency and the progressive loss thereof
   o  End to end security
   o  Complications of address sharing mechanisms (NAT, RSIP)
   o  Separation of identification and location in addressing
   o  Architecture and scaling of the current routing system

   The participants looked into several technical scenarios and
   discussed the feasibility and probability of the deployment of each
   scenario.  Among the scenarios were for example full migration to
   IPv6, IPv6 deployment only in certain segments of the network, no
   significant deployment of IPv6 and increased segmentation of the IPv4
   address space due to the use of NAT devices.

   Based on the discussion of these scenarios several trends and
   external influences were identified which could have a large impact
   on the status of the network layer, such as the deployment of
   wireless network technologies, mobile networked devices and special
   purpose IP devices.







Kaat                         Informational                      [Page 2]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


   The following technical issues were identified to be important goals:

   o  Deployment of end to end security
   o  Deployment of end to end transport
   o  Global connectivity and reachability should be maintained
   o  It should be easy to deploy new applications
   o  It should be easy to connect new hosts and networks to the
      Internet ("plug and ping")

   By the notion "deployment of end to end transport" it is meant that
   it is a goal to be able to deploy new applications that span from any
   host to any other host without intermediaries, and this requires
   transport protocols with similar span (see also [1]).

   This document summarizes the conclusions and recommendations made by
   the workshop.  It should be noted that not all participants agreed
   with all of the statements, and it was not clear whether anyone
   agreed with all of them.  The recommendations made however are based
   on strong consensus among the participants.

2. Conclusions and Observations

   The participants came to a number of conclusions and observations on
   several of the issues mentioned in section 1.  In the following
   sections 2.1-2.10 these conclusions will be described.

2.1 Transparency

   In the discussions transparency was referred to as the original
   Internet concept of a single universal logical addressing scheme and
   the mechanisms by which packets may flow from source to destination
   essentially unaltered [1].  This traditional end to end transparency
   has been lost in the current Internet, specifically the assumption
   that IPv4 addresses are globally unique or invariant is no longer
   true.

   There are multiple causes for the loss of transparency, for example
   the deployment of network address translation devices, the use of
   private addresses, firewalls and application level gateways, proxies
   and caches.  These mechanisms increase fragmentation of the network
   layer, which causes problems for many applications on the Internet.
   It adds up to complexity in applications design and inhibits the
   deployment of new applications.  In particular, it has a severe
   effect on the deployment of end to end IP security.







Kaat                         Informational                      [Page 3]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


   Another consequence of fragmentation is the deployment of "split DNS"
   or "two faced DNS", which means that the correspondence between a
   given FQDN and an IPv4 address is no longer universal and stable over
   long periods (see section 2.7).

   End to end transparency will probably not be restored due to the fact
   that some of the mechanisms have an intrinsic value (e.g. firewalls,
   caches and proxies) and the loss of transparency may be considered by
   some as a security feature.  It was however concluded that end to end
   transparency is desirable and an important issue to pursue.
   Transparency is further explored in [1].

2.2 NAT, Application Level Gateways & Firewalls

   The previous section indicated that the deployment of NAT (Network
   Address Translation), Application Level Gateways and firewalls causes
   loss of network transparency.  Each of them is incompatible with
   certain applications because they interfere with the assumption of
   end to end transparency.  NAT especially complicates setting up
   servers, peer to peer communications and "always-on" hosts as the
   endpoint identifiers, i.e. IP addresses, used to set up connections
   are globally ambiguous and not stable (see [2]).

   NAT, application level gateways and firewalls however are being
   increasingly widely deployed as there are also advantages to each,
   either real or perceived.  Increased deployment causes a further
   decline of network transparency and this inhibits the deployment of
   new applications.  Many new applications will require specialized
   Application Level Gateways (ALGs) to be added to NAT devices, before
   those applications will work correctly when running through a NAT
   device.  However, some applications cannot operate effectively with
   NAT even with an ALG.

2.3 Identification and Addressing

   In the original IPv4 network architecture hosts are globally,
   permanently and uniquely identified by an IPv4 address.  Such an IP
   address is used for identification of the node as well as for
   locating the node on the network.  IPv4 in fact mingles the semantics
   of node identity with the mechanism used to deliver packets to the
   node.  The deployment of mechanisms that separate the network into
   multiple address spaces breaks the assumption that a host can be
   uniquely identified by a single IP address.  Besides that, hosts may
   wish to move to a different location in the network but keep their
   identity the same.  The lack of differentiation between the identity
   and the location of a host leads to a number of problems in the
   current architecture.




Kaat                         Informational                      [Page 4]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


   Several technologies at this moment use tunneling techniques to
   overcome the problem or cannot be deployed in the case of separate
   address spaces.  If a node could have some sort of a unique
   identifier or endpoint name this would help in solving a number of
   problems.

   It was concluded that it may be desirable on theoretical grounds to
   separate the node identity from the node locator.  This is especially
   true for IPsec, since IP addresses are used (in transport mode) as
   identifiers which are cryptographically protected and hence MUST
   remain unchanged during transport.  However, such a separation of
   identity and location will not be available as a near-term solution,
   and will probably require changes to transport level protocols.
   However, the current specification of IPsec does allow to use some
   other identifier than an IP address.

2.4 Observations on Address Space

   There is a significant risk that a single 32 bit global address space
   is insufficient for foreseeable needs or desires.  The participants'
   opinions about the time scale over which new IPv4 addresses will
   still be available for assignment ranged from 2 to 20 years.
   However, there is no doubt that at the present time, users cannot
   obtain as much IPv4 address space as they desire.  This is partly a
   result of the current stewardship policies of the Regional Internet
   Registries (RIRs).

   It was concluded that it ought to be possible for anybody to have
   global addresses when required or desired.  The absence of this
   inhibits the deployment of some types of applications.  It should
   however be noted that there will always be administrative boundaries,
   firewalls and intranets, because of the need for security and the
   implementation of policies.  NAT is seen as a significant
   complication on these boundaries.  It is often perceived as a
   security feature because people are confusing NATs with firewalls.

2.5 Routing Issues

   A number of concerns were raised regarding the scaling of the current
   routing system.  With current technology, the number of prefixes that
   can be used is limited by the time taken for the routing algorithm to
   converge, rather than by memory size, lookup time, or some other
   factor.  The limit is unknown, but there is some speculation, of
   extremely unclear validity, that it is on the order of a few hundred
   thousand prefixes.  Besides the computational load of calculating
   routing tables, the time it takes to distribute routing updates
   across the network, the robustness and security of the current
   routing system are also important issues.  The only known addressing



Kaat                         Informational                      [Page 5]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


   scheme which produces scalable routing mechanisms depends on
   topologically aggregated addresses, which requires that sites
   renumber when their position in the global topology changes.
   Renumbering remains operationally difficult and expensive ([3], [4]).
   It is not clear whether the deployment of IPv6 would solve the
   current routing problems, but it should do so if it makes renumbering
   easier.

   At least one backbone operator has concerns about the convergence
   time of internetwork-wide routing during a failover.  This operator
   believes that current convergence times are on the order of half a
   minute, and possibly getting worse.  Others in the routing community
   did not believe that the convergence times are a current issue. Some,
   who believe that real-time applications (e.g. telephony) require
   sub-second convergence, are concerned about the implications of
   convergence times of a half minute on such applications.

   Further research is needed on routing mechanisms that might help
   palliate the current entropy in the routing tables, and can help
   reduce the convergence time of routing computations.

   The workshop discussed global routing in a hypothetical scenario with
   no distinguished root global address space.  Nobody had an idea how
   to make such a system work.  There is currently no well-defined
   proposal for a new routing system that could solve such a problem.

   For IPv6 routing in particular, the GSE/8+8 proposal and IPNG WG
   analysis of this proposal ([5]) are still being examined by the IESG.
   There is no consensus in the workshop whether this proposal could be
   made deployable.

2.6 Observations on Mobility

   Mobility and roaming require a globally unique identifier. This does
   not have to be an IP address.  Mobile nodes must have a widely usable
   identifier for their location on the network, which is an issue if
   private IP addresses are used or the IP address is ambiguous (see
   also section 2.3).  Currently tunnels are used to route traffic to a
   mobile node.  Another option would be to maintain state information
   at intermediate points in the network if changes are made to the
   packets.  This however reduces the flexibility and it breaks the end
   to end model of the network.  Keeping state in the network is usually
   considered a bad thing.  Tunnels on the other hand reduce the MTU
   size.  Mobility was not discussed in detail as a separate IAB
   workshop is planned on this topic.






Kaat                         Informational                      [Page 6]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


2.7 DNS issues

   If IPv6 is widely deployed, the current line of thinking is that site
   renumbering will be significantly more frequent than today.  This
   will have an impact on DNS updates.  It is not clear what the scale
   of DNS updates might be, but in the most aggressive models it could
   be millions a day.  Deployment of the A6 record type which is defined
   to map a domain name to an IPv6 address, with the provision for
   indirection for leading prefix bits, could make this possible ([6]).

   Another issue is the security aspect of frequent updates, as they
   would have to been done dynamically.  Unless we have fully secured
   DNS, it could increase security risks.  Cached TTL values might
   introduce problems as the cached records of renumbered hosts will not
   be updated in time.  This will become especially a problem if rapid
   renumbering is needed.

   Another already mentioned issue is the deployment of split DNS (see
   section 2.1).  This concept is widely used in the Intranet model,
   where the DNS provides different information to inside and outside
   queries.  This does not necessarily depend on whether private
   addresses are used on the inside, as firewalls and policies may also
   make this desirable.  The use of split DNS seems inevitable as
   Intranets will remain widely deployed.  But operating a split DNS
   raises a lot of management and administrative issues.  As a work
   around, a DNS Application Level Gateway ([7]) (perhaps as an
   extension to a NAT device) may be deployed, which intercepts DNS
   messages and modifies the contents to provide the appropriate
   answers.  This has the disadvantage that it interferes with the use
   of DNSSEC ([8]).

   The deployment of split DNS, or more generally the existence of
   separate name spaces, makes the use of Fully Qualified Domain Names
   (FQDNs) as endpoint identifiers more complex.

2.8 NAT and RSIP

   Realm-Specific IP (RSIP), a mechanism for use with IPv4, is a work
   item of the IETF NAT WG.  It is intended as an alternative (or as a
   complement) to network address translation (NAT) for IPv4, but other
   uses are possible (for example, allowing end to end traffic across
   firewalls).  It is similar to NAT, in that it allows sharing a small
   number of external IPv4 addresses among a number of hosts in a local
   address domain (called a 'realm').  However, it differs from NAT in
   that the hosts know that different externally-visible IPv4 addresses
   are being used to refer to them outside their local realm, and they





Kaat                         Informational                      [Page 7]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


   know what their temporary external address is.  The addresses and
   other information are obtained from an RSIP server, and the packets
   are tunneled across the first routing realm ([9], [10]).

   The difference between NAT and RSIP - that an RSIP client is aware of
   the fact that it uses an IP address from another address space, while
   with NAT, neither endpoint is aware that the addresses in the packets
   are being translated - is significant.  Unlike NAT, RSIP has the
   potential to work with protocols that require IP addresses to remain
   unmodified between the source and destination.  For example, whereas
   NAT gateways preclude the use of IPsec across them, RSIP servers can
   allow it [11].

   The addition of RSIP to NATs may allow them to support some
   applications that cannot work with traditional NAT ([12]), but it
   does require that hosts be modified to act as RSIP clients.  It
   requires changes to the host's TCP/IP stack, any layer-three protocol
   that needs to be made RSIP-aware will have to be modified (e.g. ICMP)
   and certain applications may have to be changed.  The exact changes
   needed to host or application software are not quite well known at
   this moment and further research into RSIP is required.

   Both NAT and RSIP assume that the Internet retains a core of global
   address space with a coherent DNS.  There is no fully prepared model
   for NAT or RSIP without such a core; therefore NAT and RSIP face an
   uncertain future whenever the IPv4 address space is finally exhausted
   (see section 2.4).  Thus it is also a widely held view that in the
   longer term the complications caused by the lack of globally unique
   addresses, in both NAT and RSIP, might be a serious handicap ([1]).

   If optimistic assumptions are made about RSIP (it is still being
   defined and a number of features have not been implemented yet), the
   combination of NAT and RSIP seems to work in most cases.  Whether
   RSIP introduces specific new problems, as well as removing some of
   the NAT issues, remains to be determined.

   Both NAT and RSIP may have trouble with the future killer
   application, especially when this needs QoS features, security and/or
   multicast.  And if it needs peer to peer communication (i.e. there
   would be no clear distinction between a server and a client) or
   assumes "always-on" systems, this would probably be complex with both
   NAT and RSIP (see also section 2.2).

2.9 NAT, RSIP and IPv6

   Assuming IPv6 is going to be widely deployed, network address
   translation techniques could play an important role in the transition
   process from IPv4 to IPv6 ([13]).  The impact of adding RSIP support



Kaat                         Informational                      [Page 8]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


   to hosts is not quite clear at this moment, but it is less than
   adding IPv6 support since most applications probably don't need to be
   changed.  And RSIP needs no changes to the routing infrastructure,
   but techniques such as automatic tunneling ([14]) and 6to4 ([15])
   would also allow IPv6 traffic to be passed over the existing IPv4
   routing infrastructure.  While RSIP is principally a tool for
   extending the life of IPv4, it is not a roadblock for the transition
   to IPv6.  The development of RSIP is behind that of IPv6, and more
   study into RSIP is required to determine what the issues with RSIP
   might be.

2.10 Observations on IPv6

   An important issue in the workshop was whether the deployment of IPv6
   is feasible and probable.  It was concluded that the transition to
   IPv6 is plausible modulo certain issues.  For example applications
   need to be ported to IPv6, and production protocol stacks and
   production IPv6 routers should be released.  The core protocols are
   finished, but other standards need to be pushed forward (e.g. MIBs).
   A search through all RFCs for dependencies on IPv4 should be made, as
   was done for the Y2K problem, and if problems are found they must be
   resolved.  As there are serious costs in implementing IPv6 code, good
   business arguments are needed to promote IPv6.

   One important question was whether IPv6 could help solve the current
   problems in the routing system and make the Internet scale better.
   It was concluded that "automatic" renumbering is really important
   when prefixes are to be changed periodically to get the addressing
   topology and routing optimized.  This also means that any IP layer
   and configuration dependencies in protocols and applications will
   have to be removed ([3]).  One example that was mentioned is the use
   of IP addresses in the PKI (IKE).  There might also be security
   issues with "automatic" renumbering as DNS records have to be updated
   dynamically (see also section 2.7).

   Realistically, because of the dependencies mentioned, IPv6
   renumbering cannot be truly automatic or instantaneous, but it has
   the potential to be much simpler operationally than IPv4 renumbering,
   and this is critical to market and ISP acceptance of IPv6.

   Another issue is whether existing TCP connections (using the old
   address(es)) should be maintained across renumbering.  This would
   make things much more complex and it is foreseen that old and new
   addresses would normally overlap for a long time.

   There was no consensus on how often renumbering would take place or
   how automatic it can be in practice; there is not much experience
   with renumbering (maybe only for small sites).



Kaat                         Informational                      [Page 9]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


3. Recommendations

3.1 Recommendation on Namespace

   The workshop recommends the IAB to appoint a panel to make specific
   recommendations to the IETF about:

      i) whether we should encourage more parts of the stack to adopt a
         namespace for end to end interactions, so that a) NAT works
         'better', and b) we have a little more independence between the
         internetwork and transport and above layers;
     ii) if so, whether we should have a single system-wide namespace
         for this function, or whether it makes more sense to allow
         various subsystems to chose the namespace that makes sense for
         them;
    iii) and also, what namespace(s) [depending on the output of the
         point above] that ought to be.

3.2 Recommendations on RSIP

   RSIP is an interesting idea, but it needs further refinement and
   study.  It does not break the end to end network model in the same
   way as NAT, because an RSIP host has explicit knowledge of its
   temporary global address.  Therefore, RSIP could solve some of the
   issues with NAT.  However, it is premature to recommend it as a
   mainstream direction at this time.

   It is recommended that the IETF should actively work on RSIP, develop
   the details and study the issues.

3.3 Recommendations on IPv6

3.3.1
   The current model of TLA-based addressing and routing should be
   actively pursued.  However, straightforward site renumbering using
   TLA addresses is really needed, should be as nearly automatic as
   possible, and should be shown to be real and credible by the IPv6
   community.

3.3.2
   Network address translation techniques, in addition to their
   immediate use in pure IPv4 environments, should also be viewed as
   part of the starting point for migration to IPv6.  Also RSIP, if
   successful, can be a starting point for IPv6 transition.







Kaat                         Informational                     [Page 10]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


   While the basic concepts of the IPv4 specific mechanisms NAT and RSIP
   are also being used in elements of the proposed migration path to
   IPv6 (in NAT-PT for NAT, and SIIT and AIIH for RSIP), NAT and RSIP
   for IPv4 are not directly part of a documented transition path to
   IPv6.

   The exact implications, for transition to IPv6, of having NAT and
   RSIP for IPv4 deployed, are not well understood.  Strategies for
   transition to IPv6, for use in IPv4 domains using NAT and RSIP for
   IPv4, should be worked out and documented by the IETF.

3.3.3
   The draft analysis of the 8+8/GSE proposal should be evaluated by the
   IESG and accepted or rejected, without disturbing ongoing IPv6
   deployment work.  The IESG should use broad expertise, including
   liaison with the endpoint namespace panel (see section 3.1) in their
   evaluation.

3.4 Recommendations on IPsec

   It is urgent that we implement and deploy IPsec using some other
   identifier than 32-bit IP addresses (see section 2.3).  The current
   IPsec specifications support the use of several different Identity
   types (e.g. Domain Name, User@Domain Name).  The IETF should promote
   implementation and deployment of non-address Identities with IPsec.
   We strongly urge the IETF to completely deprecate the use of the
   binary 32-bit IP addresses within IPsec, except in certain very
   limited circumstances, such as router to router tunnels; in
   particular any IP address dependencies should be eliminated from
   ISAKMP and IKE.

   Ubiquitous deployment of the Secure DNS Extensions ([8]) should be
   strongly encouraged to facilitate widespread deployment of IPsec
   (including IKE) without address-based Identity types.

3.5 Recommendations on DNS

   Operational stability of DNS is paramount, especially during a
   transition of the network layer, and both IPv6 and some network
   address translation techniques place a heavier burden on DNS.  It is
   therefore recommended to the IETF that, except for those changes that
   are already in progress and will support easier renumbering of
   networks and improved security, no fundamental changes or additions
   to the DNS be made for the foreseeable future.

   In order to encourage widespread deployment of IPsec, rapid
   deployment of DNSSEC is recommended to the operational community.




Kaat                         Informational                     [Page 11]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


3.6 Recommendations on Routing

   The only known addressing scheme which produces scalable routing
   mechanisms depends on topologically aggregated addresses, which
   requires that sites renumber when their position in the global
   topology changes.  Thus recommendation 3.3.1 is vital for routing
   IPv6.

   Although the same argument applies to IPv4, the installed base is
   simply too large and the PIER working group showed that little can be
   done to improve renumbering procedures for IPv4.  However, NAT and/or
   RSIP may help.

   In the absence of a new addressing model to replace topological
   aggregation, and of clear and substantial demand from the user
   community for a new routing architecture (i.e. path-selection
   mechanism) there is no reason to start work on standards for a "next
   generation" routing system in the IETF.  Therefore, we recommend that
   work should continue in the IRTF Routing Research Group.

3.7 Recommendations on Application layer and APIs

   Most current APIs such as sockets are an obstacle to migration to a
   new network layer of any kind, since they expose network layer
   internal details such as addresses.

   It is therefore recommended, as originally recommended in RFC 1900
   [3], that IETF protocols, and third-party applications, avoid any
   explicit awareness of IP addresses, when efficient operation of the
   protocol or application is feasible in the absence of such awareness.
   Some applications and services may continue to need to be aware of IP
   addresses.  Until we once again have a uniform address space for the
   Internet, such applications and services will necessarily have
   limited deployability, and/or require ALG support in NATs.

   Also we recommend an effort in the IETF to generalize APIs to offer
   abstraction from all network layer dependencies, perhaps as a side-
   effect of the namespace study of section 3.1.

4. Security Considerations

   The workshop did not address security as a separate topic, but the
   role of firewalls, and the desirability of end to end deployment of
   IPsec, were underlying assumptions.  Specific recommendations on
   security are covered in sections 3.4 and 3.5.






Kaat                         Informational                     [Page 12]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


References

   [1]   Carpenter, B., "Internet Transparency", RFC 2775, February
         2000.

   [2]   Hain, T., "Architectural Implications of NAT", Work in
         Progress.

   [3]   Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
         1900, February 1996.

   [4]   Ferguson, P and H. Berkowitz, "Network Renumbering Overview:
         Why would I want it and what is it anyway?", RFC 2071, January
         1997.

   [5]   M. Crawford, A. Mankin, T. Narten, J.W. Stewart, III, L. Zhang,
         "Separating Identifiers and Locators in Addresses: An Analysis
         of the GSE Proposal for IPv6", Work in Progress.

   [6]   Crawford, M., and C. Huitema, "DNS Extensions to Support IPv6
         Address Aggregation and Renumbering", RFC 2874, July 2000.

   [7]   Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan,
         "DNS extensions to Network Address Translators (DNS_ALG)", RFC
         2694, September 1999.

   [8]   Eastlake, D., "Domain Name System Security Extensions", RFC
         2535, March 1999.

   [9]   M. Borella, D. Grabelsky, J. Lo, K. Tuniguchi "Realm Specific
         IP: Protocol Specification", Work in Progress.

   [10]  M. Borella, J. Lo, D. Grabelsky, G. Montenegro "Realm Specific
         IP: Framework", Work in Progress.

   [11]  G. Montenegro, M. Borella, "RSIP Support for End-to-end IPsec",
         Work in Progress.

   [12]  M. Holdrege, P. Srisuresh, "Protocol Complications with the IP
         Network Address Translator", Work in Progress.

   [13]  Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
         Protocol Translation (NAT-PT)", RFC 2766, February 2000.








Kaat                         Informational                     [Page 13]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


   [14]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
         Hosts and Routers", RFC 2893, August 2000.

   [15]  B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4
         Clouds", Work in Progress.














































Kaat                         Informational                     [Page 14]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


Appendix A. Participants

   Harald Alvestrand           harald@alvestrand.no
   Ran Atkinson                rja@corp.home.net
   Rob Austein                 sra@hactrn.net
   Steve Bellovin              smb@research.att.com
   Randy Bush                  randy@psg.com
   Brian E Carpenter           brian@hursley.ibm.com
   Vint Cerf                   vcerf@MCI.NET
   Noel Chiappa                jnc@lcs.mit.edu
   Matt Crawford               crawdad@fnal.gov
   Robert Elz                  kre@munnari.OZ.AU
   Tony Hain                   tonyhain@microsoft.com
   Matt Holdrege               matt@ipverse.com
   Erik Huizer                 huizer@cs.utwente.nl
   Geoff Huston                gih@telstra.net
   Van Jacobson                van@cisco.com
   Marijke Kaat                Marijke.Kaat@surfnet.nl
   Daniel Karrenberg           Daniel.Karrenberg@ripe.net
   John Klensin                klensin@jck.com
   Peter Lothberg              roll@Stupi.SE
   Olivier H. Martin           Olivier.Martin@cern.ch
   Gabriel Montenegro          gab@sun.com
   Keith Moore                 moore@cs.utk.edu
   Robert (Bob) Moskowitz      rgm@htt-consult.com
   Philip J. Nesser II         pjnesser@nesser.com
   Kathleen Nichols            kmn@cisco.com
   Erik Nordmark               nordmark@eng.sun.com
   Dave Oran                   oran@cisco.com
   Yakov Rekhter               yakov@cisco.com
   Bill Sommerfeld             sommerfeld@alum.mit.edu
   Bert Wijnen                 wijnen@vnet.ibm.com
   Lixia Zhang                 lixia@cs.ucla.edu

Author's Address

   Marijke Kaat
   SURFnet ExpertiseCentrum bv
   P.O. Box 19115
   3501 DC  Utrecht
   The Netherlands

   Phone: +31 30 230 5305
   Fax: +31 30 230 5329
   EMail: Marijke.Kaat@surfnet.nl






Kaat                         Informational                     [Page 15]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Kaat                         Informational                     [Page 16]