rfc2956.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 900 行 · 第 1/3 页

   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.