rfc2491.txt

RFC 的详细文档！

   At this time no rules are specified for mapping outbound packets to
   VCs using anything more than the packet's destination address.

4.4.2. Sending Multicast Data.

   The IP level 'next hop' for each outbound multicast IPv6 packet is
   used to identify a pt-pt or pt-mpt VC on which to forward the packet.

      For NBMA networks where LLC/SNAP encapsulation is typically used
      (e.g. ATM or SMDS), multicast packets SHALL be encapsulated in the
      following manner:

         [0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6
         packet]
             (LLC)       (OUI)     (PID)    (mars encaps)

         The IPv6/NBMA driver's Cluster Member ID SHALL be copied into
         the 2 octet pkt$cmi field prior to transmission.

      For NBMA networks that do not use LLC/SNAP encapsulation, an
      alternative rule SHALL be specified in the NBMA-specific companion
      document. Some mechanism for carrying the IPv6/NBMA driver's
      Cluster Member ID SHALL be provided.

   If the packet's destination is one of the following multicast
   addresses, it SHALL be sent over the IPv6/NBMA driver's direct pt-pt
   VC to the MARS:

      - A Solicited-node address with link-local scope.
      - The All-nodes address with link-local scope.
      - The All-routers address with link-local scope.
      - A DHCP-v6 relay or server multicast address.




Armitage, et. al.           Standards Track                    [Page 18]

RFC 2491                IPv6 over NBMA networks             January 1999


   The MARS SHALL then redistribute the IPv6 packet as described in
   section 3.1.1.  (If the VC to the MARS has been idle timed out for
   some reason, it MUST be re-established before forwarding the packet
   to the MARS.)

   If packet's destination is any other address, then the usual MARS
   client mechanisms are used by the IPv6/NBMA driver to select and/or
   establish a pt-mpt VC on which the packet is to be sent.

   At this time no rules are specified for mapping outbound packets to
   VCs using anything more than the packet's destination address.

4.5. Receiving Data.

   Packets received using the encapsulation shown in section 4.4.1 SHALL
   be de-encapsulated and passed up to the IPv6 layer.  The IPv6 layer
   then determines how the incoming packet is to be handled.

   Packets received using the encapsulation specified in section 4.4.2
   SHALL have their pkt$cmi field compared to the local IPv6/NBMA
   driver's own CMI.  If the pkt$cmi in the header matches the local CMI
   the packet SHALL be silently dropped.  Otherwise, the packet SHALL be
   de-encapsulated and passed to the IPv6 layer.  The IPv6 layer then
   determines how the incoming packet is to be handled.

   For NBMA networks that do not use LLC/SNAP encapsulation, alternative
   rules SHALL be specified in the NBMA-specific companion document.

   The IPv6/NBMA driver SHALL NOT attempt to filter out multicast IPv6
   packets arriving with encapsulation defined for unicast packets, nor
   attempt to filter out unicast IPv6 packets arriving with
   encapsulation defined for multicast packets.

4.6. VC Setup and release for unicast data.

   Unicast VCs are maintained separately from multicast VCs.  The setup
   and maintenance of multicast VCs are handled by the MARS client in
   each IPv6/NBMA driver [5]. Only the setup and maintenance of pt-pt
   VCs for unicast IPv6 traffic will be described here.  Only best
   effort unicast VCs are considered.  The creation of VCs for other
   classes of service is outside the scope of this document.

   Before sending a packet to a new destination within the same LL a
   node will first perform a Neighbor Discovery on the intra-LL target.
   This is done to resolve the IPv6 destination address into a link-
   layer address which the sender can then use to send unicast packets.





Armitage, et. al.           Standards Track                    [Page 19]

RFC 2491                IPv6 over NBMA networks             January 1999


   Appendix A.1.1 contains non-normative, descriptive text covering the
   Neighbor Solicitation/Advertisement exchange and eventual
   establishment of a new SVC.

   A Redirect message (either a redirect to a node on the same LL, or a
   shortcut redirect to a node outside the LL) results in the sending
   (redirected) node creating a new pt-pt VC to a new receiving node.
   the Redirect message SHALL contain the link layer (NBMA) address of
   the new receiving IPv6/NBMA interface.  The redirected node does not
   concern itself where the new receiving node is located on the NBMA
   network.  The redirected node will set up a pt-pt VC to the new node
   if one does not previously exist.  The redirected node will then use
   the new VC to send data rather than whatever VC it had previously
   been using.

   Redirects are unidirectional.  Even after the source has reacted to a
   redirect, the destination will continue to send IPv6 packets back to
   the redirected node on the old path.  This happens because the
   destination node has no way of determining the IPv6 address of the
   other end of a new VC in the absence of Neighbor Discovery. Thus,
   redirects will not result in both ends of a connection using the new
   VC. IPv6 redirects are not intended to provide symmetrical
   redirection.  If the non-redirected node eventually receives a
   redirect it MAY discover the existing VC to the target node and use
   that rather than creating a new VC.

   It is desirable that VCs are released when no longer needed.

      An IPv6/NBMA driver SHALL release any VC that has been idle for 20
      minutes.

   This time limit MAY be reduced through configuration or as specified
   in companion documents for specific NBMA networks.

   If a Neighbor or Destination cache entry is purged then any VCs
   associated with the purged entry SHOULD be released.

   If the state of an entry in the Neighbor cache is set to STALE, then
   any VCs associated with the stale entry SHOULD be released.

4.7 NBMA SVC Signaling Support and MTU issues.

   Mechanisms for signaling the establishment and teardown of pt-pt and
   pt-mpt SVCs for different NBMA networks SHALL be specified in
   companion documents.






Armitage, et. al.           Standards Track                    [Page 20]

RFC 2491                IPv6 over NBMA networks             January 1999


   Since any given IPv6/NBMA driver will not know if the remote end of a
   VC is in the same LL, drivers SHALL implement NBMA-specific
   mechanisms to negotiate acceptable MTUs at the VC level. These
   mechanisms SHALL be specified in companion documents.

   However, IPv6/NBMA drivers can assume that they will always be
   talking to another driver attached to the same type of NBMA network.
   (For example, an IPv6/NBMA driver does not need to consider the
   possibility of establishing a shortcut VC directly to an IPv6/FR
   driver.)

5. Interface Tokens, Link Layer Address Options, Link-Local Addresses

5.1 Interface Tokens

   Each IPv6 interface must have an interface token from which to form
   IPv6 autoconfigured addresses. This interface token must be unique
   within a Logical Link to prevent the creation of duplicate addresses
   when stateless address configuration is used.

   In cases where two nodes on the same LL produce the same interface
   token then one interface MUST choose another host-token.  All
   implementations MUST support manual configuration of interface tokens
   to allow operators to manually change a interface token on a per-LL
   basis.  Operators may choose to manually set interface tokens for
   reasons other than eliminating duplicate addresses.

   All interface tokens MUST be 64 bits in length and formatted as
   described in the following sections.  The hosts tokens will be based
   on the format of an EUI-64 identifier [10]. Refer to [19 - Appendix
   A] for a description of creating IPv6 EUI-64 based interface
   identifiers.

5.1.1 Single Logical Links on a Single NBMA Interface

   Physical NBMA interfaces will generally have some local identifier
   that may be used to generate a unique IPv6/NBMA interface token. The
   exact mechanism for generating interface tokens SHALL be specified in
   companion documents specific to each NBMA network.

5.1.2 Multiple Logical Links on a Single NBMA Interface

   Physical NBMA interfaces MAY be used to provide multiple logical NBMA
   interfaces. Since each logical NBMA interface MAY support an
   independent IPv6 interface, two separate scenarios are possible:

      - A single host with separate IPv6/NBMA interfaces onto a number
        of independent Logical Links.



Armitage, et. al.           Standards Track                    [Page 21]

RFC 2491                IPv6 over NBMA networks             January 1999


      - A set of 2 or more 'virtual hosts' (vhosts) sharing a common
        NBMA driver. Each vhost is free to establish IPv6/NBMA
        interfaces associated with different or common LLs. However,
        vhosts are bound by the same requirement as normal hosts - no
        two interfaces to the same LL can share the same interface
        token.

   In the first scenario, since each IPv6/NBMA interface is associated
   with a different LL, each interface's external identity can be
   differentiated by the LL's routing prefix.  Thus, the host can re-use
   a single unique interface token across all its IPv6/NBMA interfaces.
   (Internally the host will tag received packets in some locally
   specific manner to identify what IPv6/NBMA interface they arrived on.
   However, this is an issue generic to IPv6, and does not required
   clarification in this document.)

   The second scenario is more complex, but likely to be rarer.

   When supporting multiple logical NBMA interfaces over a single
   physical NBMA interface, independent and unique identifiers SHALL be
   generated for each virtual NBMA interface to enable the construction
   of unique IPv6/NBMA interface tokens.  The exact mechanism for
   generating interface tokens SHALL be specified in companion documents
   specific to each NBMA network.

5.2 Link Layer Address Options

   Neighbor Discovery defines two option fields for carrying link-layer
   specific source and target addresses.

   Between IPv6/NBMA interfaces, the format for these two options is
   adapted from the MARS [5] and NHRP [8] specs. It SHALL be:

          [Type][Length][NTL][STL][..NBMA Number..][..NBMA
          Subaddress..]
          |   Fixed    ||            Link layer address
          |

   [Type] is a one octet field.

          1 for Source link-layer address.
          2 for Target link-layer address.

   [Length] is a one octet field.

   The total length of the option in multiples of 8 octets. Zeroed bytes
   are added to the end of the option to ensure its length is a multiple
   of 8 octets.



Armitage, et. al.           Standards Track                    [Page 22]

RFC 2491                IPv6 over NBMA networks             January 1999


   [NTL] is a one octet 'Number Type & Length' field.

   [STL] is a one octet 'SubAddress Type & Length' field.

   [NBMA Number] is a variable length field. It is always present. This
   contains the primary NBMA address.

   [NBMA Subaddress] is a variable length field. It may or may not be
   present. This contains any NBMA subaddress that may be required.

   If the [NBMA Subaddress] is not present, the option ends after the
   [NBMA Number] ( and any additional padding for 8 byte alignment).

   The contents and interpretation of the [NTL], [STL], [NBMA Number],
   and [NBMA Subaddress] fields are specific to each NBMA network, and
   SHALL be specified in companion documents.

5.3 Link-Local Addresses

   The IPv6 link-local address is formed by appending the interface
   token, as defined above, to the prefix FE80::/64.

          10 bits            54 bits                  64 bits
      +----------+-----------------------+----------------------------+
      |1111111010|         (zeros)       |      Interface Token       |
      +----------+-----------------------+----------------------------+

6. Conclusion and Open Issues

   This document describes a general architecture for IPv6 over NBMA
   networks. It forms the basis for subsidiary companion documents that
   provide details for various specific NBMA technologies (such as ATM
   or Frame Relay). The IPv6 over NBMA architecture allows conventional
   host-side operation of the IPv6 Neighbor Discovery protocol, while
   also supporting the establishment of 'shortcut' NBMA forwarding paths
   (when dynamically signaled NBMA links are available).

   The IPv6 "Link" is generalized to "Logical Link" in an analagous
   manner to the IPv4 "Logical IP Subnet".  The MARS protocol is
   augmented and used to provide relatively efficient intra Logical Link
   multicasting of IPv6 packets, and distribution of Discovery messages.
   Shortcut NBMA level paths are supported either through router based
   flow detection, or host originated explicit requests.  Neighbor
   Discovery is used without modification for all intra-LL control
   (including the initiation of NBMA shortcut discovery).  Router to
   router NHRP is used to obtain the IPv6/NBMA address mappings for
   shortcut targets outside a source's Logical Link.




Armitage, et. al.           Standards Track                    [Page 23]

RFC 2491                IPv6 over NBMA networks             January 1999


7. Security Considerations