Internet Engineering Task Force                           P. Christian,
INTERNET-DRAFT                                      Christian Tena LTD,
Category: Informational                                  September 2002
Expires: March 2003



                       IS-IS Automatic Encapsulation
                    <draft-ietf-isis-auto-encap-02.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   The IETF is advised of potential intellectual property rights in
   regard to some or all of the specification contained in this
   document. For more information consult the online list for notices
   and/or updates.

   Internet Drafts are working documents of the Internet Engineering
   Task Force (IETF), its Areas, and its Working Groups.  Note that
   other groups may also distribute working documents as Internet
   Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   "working draft" or "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This memo provides information for the Internet community. This memo
   does not specify an Internet standard of any kind.

   Distribution of this draft is unlimited.














Christian                 Expires March 2003                          1

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

Abstract

   RFC 1195 [1] documents a dual routing protocol that can be used to
   route both CLNP and IPv4, that is Integrated IS-IS.   Integrated IS-
   IS can now also be used to route IPv6 [12].

   RFC 1195 [1] places certain topological restrictions on networks
   that are routed using Integrated IS-IS, specifically that every
   Intermediate System in a level-1 area must be able to forward all
   network layer protocols that are present in that area, and that
   every level-2 Intermediate System must be able to forward all
   network layer protocols present in the routing domain.

   The mechanism described in this document enables an Intermediate
   System or a group of Intermediate Systems that do not support a
   particular network layer protocol to be used in a level-1 area or
   level-2 subdomain where that network layer protocol is present.

   Specifically the mechanism provides automatic encapsulation and
   unencapsulation so that a packet or PDU may pass through an
   Intermediate System that would not normally be able to forward that
   type of packet.


1.History

   The automatic encapsulation mechanism was originally presented to
   Study Group 15 of the ITU-T as part of a push by the ITU-T to
   migrate SONET / SDH DCN networks from CLNP to IP.  The scheme was
   presented as an "autotunnelling scheme" that used the existing IS-IS
   routing protocol that was present in all standards compliant SONET
   or SDH multiplexers, so that IP traffic could be passed through
   existing CLNP capable multiplexers without needing to upgrade them.

   In May 2002 the ITU-T Draft Recommendation G.7712 version 1.1 and
   1.2 were liaised to the IETF IS-IS Working Group.  The liaison
   statement and these version of G.7712 may be viewed from

      ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport
      /COMMUNICATIONS/isis/index.html

   The automatic encapsulation mechanism was then documented as an
   IETF document in draft-ietf-isis-proprietary-tlv-00.txt.  This
   document included a modified PseudoNode election process that
   was intended to improve interoperability and ease topologic
   restrictions compared with G.7712.

   The modification turned out to be impossible to implement, as it
   would have required an automatically encapsulating IS to create
   two or more pseudonodes in certain circumstances (one for each
   supported network-layer protocol).  Multiple pseudonodes would have
   required multiple IDs in LAN Hello PDUs, which is not possible.

Christian                 Expires March 2003                          2

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

   draft-ietf-isis-proprietary-tlv-01.txt therefore reverted the
   pseudonode election process back to that used in G.7712.

   This version converges further towards G.7712 as it only documents
   GRE encapsulation.  G.7712 requires SONET / SDH multiplexers to
   support GRE for encapsulation of CLNP, IPv4 or IPv6 PDUs.  This
   modification is designed to improve interoperability between
   vendors.

   Shortest paths are calculated by ISs in the domain without
   considering whether a complete path for any particular network-layer
   protocol exists or not, nor whether encapsulation and
   unencapsulation is available or not.  Thus if some automatically
   encapsulating ISs support only GRE encapsulation, whilst others
   support only some other encapsulation, then dynamic tunnels cannot
   be built between the two.  The result is paths that cannot forward
   traffic which causes blackholes, or very complex topological
   restrictions to avoid them.

   Given that GRE is the only standardised encapsulation mechanism that
   supports CLNP (see RFC 2784[4] and RC 3147[5]) it makes sense to use
   it here.  As a result implementations that conform to this draft are
   guaranteed to interwork with others (by virtue of a common
   encapsulation) and with ITU-T G.7712 implementations (by virture of
   using GRE).

2.Introduction

   RFC 1195 [1] documents a dual routing protocol that can be used to
   route both CLNP and IPv4, that is Integrated IS-IS. Integrated IS-IS
   can now also be used to route IPv6 [12].

   RFC 1195 [1] also foresaw the possibility of an automatic
   encapsulation feature.  Automatic encapsulation is stated as for
   "for further study" in section 3.8.  The automatic encapsulation
   scheme detailed here may be considered a continuation of section 3.8
   of RFC 1195 [1].

   Integrated IS-IS ISs (Intermediate Systems) can calculate routes to
   CLNS, IPv4 and IPv6 destinations using a single SPF calculation.
   This is achieved by treating OSI End System, IPv4 and IPv6 addresses
   in a similar way, but it does rely on an assumption which forces
   topological restrictions onto the network.

   Integrated IS-IS views a level-1 area or level-2 subdomain as a
   collection of connected ISs, without considering which ISs can
   actually forward which network-layer protocols. It simply assumes
   that all ISs that it can see, can forward all packet types. For
   Integrated IS-IS to be able to pick different routes for different
   network-layer protocols would imply a separate SPF calculation for
   each network layer protocol.  It would then arguably no longer be an
   integrated routing protocol.

Christian                 Expires March 2003                          3

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

   Specifically page 26 of RFC 1195 [1] states:-

     "The Dijkstra computation does not take into consideration whether
     a router is IP-only, OSI-only, or dual. The topological
     restrictions specified in section 1.4 ensure that IP packets will
     only be sent via IP-capable routers, and OSI packets will only be
     sent via OSI-capable routers."

   It is important that all ISs in a network calculate routes in such
   a way that they all arrive at the same shortest path.  If some ISs
   calculate a different shortest path to others then routing loops
   and blackholes can occur.  Therefore in a multiprotocol environment
   having ISs that consider forwarding capabilities when calculating
   the shortest path, mixed with ISs that do not could result in
   routing loops and packet loss.

   Consequently, RFC 1195 states that if both IPv4 and CLNP are to be
   forwarded anywhere in a level-1 area or level-2 subdomain, then, all
   of the ISs in that level-1 area or level-2 subdomain must be capable
   of forwarding both IPv4 and CLNP. The same logic applies if it is
   required to have both IPv4 and IPv6 present in a level-1 area or
   level-2 subdomain.

   This topological rule can already be broken with extreme care. If it
   can be guaranteed that a certain part of an IS-IS network will never
   receive a certain type of packet, then that network layer protocol
   need not be supported.

   However, failure to observe these topological restrictions can
   result in blackholes forming, and packet loss. Consider the
   following (illegal) example:-

                     +--------+  +-------+  +--------+
        IPv6 host#1--+  IS A  +--+ IS B  +--+  IS C  +--IPv6 host#2
                     |  v4/v6 |  | v4 IS |  |  v4/v6 |
                     +--------+  +-------+  +--------+

   IS A will find the shortest path to IPv6 host#2 as being through IS
   B. If host#1 then sends an IPv6 packet to the host#2, then the dual
   IS will forward it to the IS B, which will not be able to forward
   the packet.  IS B will discard the packet instead, resulting in
   packet loss and a blackhole.

   This document describes a mechanism that can be used to overcome
   this topological restriction. The mechanism detects that a packet is
   about to be send to an IS that does not support that network-layer
   protocol, and automatically encapsulates the packet into a form that
   then can be forwarded. Essentially the mechanism can take an
   existing IS, or collection of ISs, that support forwarding of IPv4
   for example, and, by automatic encapsulation of IPv6 inside IPv4,
   can enable IPv6 traffic to also cross these IPv4 ISs, making that
   part of the network behave as if it is dual.

Christian                 Expires March 2003                          4

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

3.The automatic encapsulation mechanism.

3.1. Introduction.

   Consider the following example:-

                     +--------+  +-------+  +--------+
          IPv4 host--+  IS A  |  | IS B  |  |  IS C  +--IPv4 host
                     |  v4/v6 +--+ v4 IS +--+  v4/v6 |
          IPv6 host--+        |  |       |  |        +--IPv6 host
                     +--------+  +-------+  +--------+


   Forwarding of IPv4 traffic from one host to the other is not a
   problem in this network. However IPv6 traffic cannot be forwarded by
   IS B without being encapsulated inside an IPv4 packet.

   IS A and IS C actually have most of the information that they need
   in order to automatically perform this encapsulation.

   1. IS A can detect that IS B cannot forward an IPv6 packet, because
      RFC 1195 [1] already requires IS B to include a "protocols
      supported" TLV in Hello packets. Absence of the TLV indicates
      that an IS that can forward only CLNP.

   2. IS A receives LSPs (Link State PDUs) from IS C.  This is because
      IS-IS LSPs are neither IPv4 nor IPv6 packets.  IS-IS is a
      network-layer protocol in its own right, and is used in common
      by all ISs whether they forward CLNP, IPv4 or IPv6 packets.

   By adding an extra TLV to the LSPs that IS C transmits, containing
   the encapsulation/unencapsulation capability of C, this information
   will be flooded throughout the level-1 area or level-2 subdomain.
   IS A is now able to encapsulate IPv6 traffic inside IPv4 packets,
   and send them to IS C, on the understanding that IS C will
   unencapsulate the IPv6 traffic and forward it onwards.

3.2. Encapsulation Capability Field.

   Any IS that supports automatic encapsulation/unencapsulation MUST
   include an "Encapsulation Capability" TLV in LSPs that have LSP
   number 0.  This TLV MUST be included in both level-1 LSPs and level-
   2 LSPs.

   The structure of the TLV is as follows:-

        Code:   16 (decimal)
        Length: The length of the value
        Value:  The value shall contain Sub-TLVs of the form:-
                        Sub-TLV Type
                        Sub-TLV Length: The length of the sub-TLV value
                        Sub-TLV Value:  Variable number of bytes

Christian                 Expires March 2003                          5

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

   Sub-TLVs with sub-TLV type equal to 1 MUST contain three byte
   encapsulation modes with the following structure:-

        Sub-TLV type:   1
        Sub-TLV length: Three times the number of encapsulation modes
        Sub-TLV value:  Encapsulation-mode#1
                        Inner-Protocol#1
                        Outer-Protocol#1
                        Encapsulation-mode#2
                        Inner-Protocol#2
                        Outer-Protocol#2
                        .
                        .
                        Encapsulation-mode#n
                        Inner-Protocol#n
                        Outer-Protocol#n

               Encapsulation-mode SHALL be 47 (decimal) to describe a
               GRE encapsulation as defined in RFCs 1701[2], 1702[3],
               2784[4] and 3147[5].

               Inner-Protocol SHALL be the NLPID of a packet that the
               IS is capable of sending or receiving in an encapsulated
               form.

               Outer-Protocol SHALL be the NLPID of a packet that the
               IS is capable of using to transport the Inner-Protocol
               in encapsulated form.

               NLPIDs SHALL be those as specified in ISO/TR 9577[8].

   47 is chosen simply as it is the IP protocol number for GRE
   encapsulation.

   Note that ITU-T G.7712 [10] mandates that GRE shall be used for all
   combinations of CLNS, IPv4 and IPv6 over CLNS, IPv4 or IPv6.
   Therefore if interoperability is required with SONET / SDH DCC
   channels then GRE will have to be supported.  RFC 3147 [5] also
   describes IP encapsulation over CLNS using GRE.

   Future capabilities, such as non-NLPID definitions, may be provided
   using the same TLV number by using an alternative sub-TLV number.











Christian                 Expires March 2003                          6

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

   By way of an example, a dual IPv4/IPv6 IS that supports automatic
   encapsulation of IPv6 over IPv4, and automatic encapsulation of IPv4
   over IPv6, using GRE would therefore transmit the TLV with the
   following contents:-

        Dec  (Hex)
        16   (0x10):   The TLV number
        8    (0x08):   The length of the value
        1    (0x01):   Sub-TLV type 1
        6    (0x06):   Length of the value of the sub-TLV
        47   (0x2F):   Indicating that the next two bytes are a GRE mode
        204  (0xCC):   Inner-protocol of IPv4
        142  (0x8E):   Outer-protocol of IPv6
        47   (0x2F):   Indicating that the next two bytes are a GRE mode
        142  (0x8E):   Inner protocol of IPv6
        204  (0xCC):   Outer protocol of IPv4

   An IS that includes an encapsulation mode in its "encapsulation
   capability" TLV MUST be capable of both transmitting and receiving
   that encapsulation mode, as specified in sections 3.3 and 3.4.

3.3. Transmission of automatically encapsulated packets

   Shortest paths SHALL be calculated in the normal way, as per RFC
   1195 [1].

   Before forwarding a packet to a next hop, an IS MUST check that the
   next hop can forward that type of packet.  The IS MUST check this by
   referring to the "protocol supported" TLV in IS-IS Hello PDUs.
   Absence of a "Protocols Supported" TLV in Hello PDUs indicates that
   the next hop can forward only CLNP packets.

   If an IS finds that the next hop does support the type of packet
   that it is attempting to forward, then it MUST simply forward the
   packet to that adjacency as normal, without encapsulating it.

   If an IS finds that the next hop does not support the type of packet
   that it is attempting to forward, then it MUST search along the
   shortest path from itself to the destination, and MUST inspect the
   "encapsulation capability" TLV of LSP 0 of each IS until it finds an
   IS that it is able to send the packet to in an encapsulated form.












Christian                 Expires March 2003                          7

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

   The IS MUST search within each "encapsulation capability" TLV until
   it finds an encapsulation mode that meets the following three
   conditions:-

   1.The encapsulation-mode MUST be one that this IS supports.
   2.The inner-protocol MUST be equal to the NLPID of the packet that
     this IS is attempting to forward.
   3.The outer-protocol MUST be equal to one of the NLPIDs that the
     next hop lists in the "protocols supported" TLV of IS-IS Hello
     PDUs, or equal to the NLPID for CLNS/CLNP if no "protocols
     supported" TLV is present in IS-IS Hello PDUs from the next hop.

   When inspecting an "encapsulation capability" TLV, then, an IS MUST
   ignore any encapsulation modes that it does not understand, but
   instead jump forward to inspect the next encapsulation mode, until
   it finds a suitable mode or until it reaches the end of the TLV.

   When inspecting an "encapsulation capability" TLV, then, an IS MUST
   ignore any sub-TLVs that it does not understand, but instead jump
   forward to inspect the next sub-TLV, until it finds a suitable mode
   or until it reaches the end of the TLV.

   The IS MUST encapsulate the packet inside another and send it to the
   first IS along the shortest path to the destination that meets the
   criteria, using the encapsulation mode that resulted in it meeting
   the above criteria.  See 2.3.1. for an explanation.

   It is suggested that this search is pre-calculated and performed for
   every destination that cannot be forwarded natively every time the
   SPF (Dijkstra) algorithm is run, and that the results are included
   in each forwarding table, with a marker indicating that for that
   particular destination that the packet should be encapsulated using
   a certain encapsulation mode (if more than one is supported) and
   with a certain destination address, which will be a destination
   address expressed in the format used by the outer-protocol that is
   going to be used.  For this a modified SPF algorithm is provided in
   Annex A.

   The destination address of the resultant encapsulation packet MUST
   be equal to the identity of the IS that sent the TLV that was the
   first along the shortest path that met the above criteria.

   The source address of the resultant encapsulation packet MUST be
   equal to the identity of the IS that is performing the
   encapsulation.

   If the outer protocol is IPv4 then the "Don't Fragment" bit MUST NOT
   be set.  If the outer protocol is CLNP then the "Segmentation
   Permitted" flag MUST be set.  This will protect against packet loss
   due to the new packet being longer than the MTU size of the link
   over which it is to be transmitted, and will prevent unwanted
   interactions with path MTU discovery [11].

Christian                 Expires March 2003                          8

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

3.3.1. Reasoning for sending to first capable IS

   Section 3.3 indicates that a packet that cannot be forwarded
   natively should be encapsulated and sent to the first IS along the
   shortest path that advertises itself as being capable of
   unencapsulating it.  In fact, the packet could be encapsulated and
   sent to any IS along the shortest path that advertises itself as
   being capable of unencapsulating it, and the packet would arrive at
   its destination.

   The most reasonable choices would appear to be either the first, or
   the last IS unencapsulation capable IS, each choice has advantages
   and disadvantages.

   Choosing the first may result in a packet being encapsulated and
   unencapsulated several times on its way to its destination, as it
   crosses multiple "subnetworks" that do not support forwarding of
   that type of packet. When the packet is being forwarded by a part of
   the network that can forward it natively, it is in its original
   form.

   Choosing the last may result in encapsulation within encapsulation
   within encapsulation, as for example an IPv6 packet will become an
   IPv4 packet and remain so till the last IS that can unencapsulate.
   This IPv4 packet may in turn need to traverse an IPv6-only
   "subnetwork" and be encapsulated again.  If the last IS capable of
   unencapsulation advertises itself as being capable of IPv6/IPv4 and
   IPv4/IPv6, then it will loaded with unencapsulating all of the
   layers of encapsulation in one go.

   Although the argument is probably a religious one, unencapsulating a
   packet as soon as possible, and avoiding encapsulation within
   encapsulation (and the long packets that may result) would appear to
   be the lesser of the two evils.  The load of fragmentation and
   reassembly must also be considered if multiple layers of
   encapsulation results in an MTU size being blown.  Also it is
   probably better for a packet to exist in the network in its native
   form whenever possible, making the network easier to debug, and
   reducing the impact of encapsulation to the smallest part of the
   network possible.

   However, any IS MUST be able to unencapsulate any packet that
   arrives at it with its destination address, and with an
   encapsulation mode that it advertised in its "encapsulation
   capability" TLV.  This opens the possibility for more intelligent
   algorithms to be developed that choose an IS capable of
   unencapsulating, other than the first.






Christian                 Expires March 2003                          9

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

3.4. Receipt of automatically encapsulated packets

   An IS that supports automatic encapsulation / unencapsulation MUST
   inspect any received packet that has a destination address equal to
   itself to see if it is an encapsulation of a type that it
   transmitted in its "encapsulation capability" TLV.

   If the IS finds that such a received packet is an encapsulation
   packet then it SHOULD discard the inner packet if it is of a type
   that it did not list as an "inner-protocol" in an encapsulation mode
   in its "encapsulation capability" TLV.

   Upon discarding such a packet it is suggested that the IS reports or
   logs an error report.

   An IS that also supports manually configured tunnels will need to
   check that a packet has not arrived over a manual tunnel in the
   normal way before discarding it.

   Otherwise the received packet MUST be unencapsulated and re-
   received. Note that encapsulation within encapsulation is a
   possibility, particularly for ISs that support three or more network
   layer protocols.


3.5. Interaction with Path MTU Discovery (PMTU), RFC 1191 [11].

   Although packets become encapsulated, no tunnel "interface" or
   circuit as such really exists.  Therefore there will be no MTU limit
   for the inner-protocol.  It is suggested that packets of any size
   are accepted, then encapsulated, and that the encapsulated outer-
   protocol packet is fragmented/segmented if necessary in order to be
   forwarded over the real interface.  For this reason in the new
   outer-protocol packet the Don't Fragment MUST NOT be set (for IPv4),
   or Segmentation Permitted flag MUST be set (for CLNP).

   One consequence of this is that a link, if packets traverse it in
   an encapsulated form, becomes invisible to Path MTU Discovery.

   However this is the safest option as it guarantees that packets will
   never be discarded due to MTU issues.  Because the inner-protocol is
   different to the outer-protocol, if the outer-protocol where to be
   discarded for any reason then the reason is not likely to be known
   to the originator of the inner-protocol packet.  Path MTU discovery
   does rely on knowing the reason for discard of packets, and so the
   safest option is to make the outer-protocol and encapsulation
   process invisible to it.






Christian                 Expires March 2003                         10

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

   An additional option is to reject packets for encapsulation that are
   bigger than a certain size, and to report back to the originator a
   suitable error message.  If this approach is chosen then the packet
   MUST be rejected before encapsulation, and a suitable error message
   MUST be returned to the originator using the correct mechanism for
   that network layer protocol.  Such a process would be prior to and
   independent of automatic encapsulation, and does not alter the
   requirement that the outer-protocol packets are never discarded, but
   fragmented/segmented instead.

4.Allowable and non-allowable topologies

   This mechanism effectively enables an IS or group of ISs to act as
   if they support one or more network layer protocols that they
   actually do not.  Automatic encapsulation is the process that
   enables this to be possible, but care must be taken to ensure that
   incompatible packets are not leaked into such a "subnetwork" without
   going through an automatic encapsulation capable IS.

   Thus, at the all of the boundaries to the "subnetwork", there MUST
   be installed an IS that supports automatic encapsulation. At points
   where the inner "subnetwork" meet the outer general network without
   an automatic encapsulation IS between the two, any adjacency MUST be
   disabled.

   In order to partially automate this the ITU-T mandated in G.7712[10]
   that any Integrated IS-IS capable SDH NE must not consider itself a
   neighbour to any other IS unless the other IS supports at least one
   network layer protocol in common with it.  This effectively makes it
   impossible to accidentally have an adjacency between an OSI-only and
   an IP-only SDH NE, or between an IPv4-only and an IPv6-only SDH NE.

   This cannot be retrospectively applied to RFC 1195[1] compliant ISs,
   however it is recommended that all Integrated IS-IS ISs include this
   safeguard whenever possible.  In the absence of this behaviour it is
   the responsibility of the network manager to manually insure that no
   such adjacencies are formed.  Certain Integrated IS-IS
   implementations also check for correct subnetting of a neighbour
   before accepting an adjacency; usefully this should also prevent an
   IPv4-only IS from forming an adjacency with an OSI-only or an
   IPv6-only IS.












Christian                 Expires March 2003                         11

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

   In general the existing RFC 1195[1] topological restrictions still
   apply inside a "subnetwork" that is bounded by automatically
   encapsulating ISs, and outside of the automatically encapsulating
   ISs too. For example:-

   1. Within a "subnetwork" that can forward only IPv4, only IPv4 can
      be forwarded.  A dual IPv4/IPv6 IS MAY be installed inside this
      "subnetwork", but, it MUST NOT forward any IPv6 packets.  No IPv6
      hosts (including hosts internal to an IPv4/IPv6 IS) may be
      present in the "subnetwork".

   2. Outside of the "subnetwork", i.e. on the other side of an
      automatic encapsulation capable IS, if both IPv4 and IPv6 packets
      are present in a native form, then all ISs must be capable of
      forwarding both IPv4 and IPv6.

                                 IPv6-only
                                ..........
   IPv4 host-+------+  +------+ .+------+. +------+  +------+-IPv4 host
             | IS G |--| IS H |--| IS I |--| IS J |--| IS K |
   IPv6 host-+------+  +---+--+ .+--+---+. +--+---+  +------+-IPv6 host
                           |    ....X.....    |
                           |        X         |
                    .......|........X.........|.......
                    .  +---+--+  +--+---+  +--+---+  .
                    .  | IS A |--| IS B |--| IS C |  .
                    .  +--+---+  +------+  +---+--+  .
                    .     |                    |     .IPv4-only
                    .  +--+---+  +------+  +---+--+  .
                    .  | IS D |--| IS E |--| IS F |  .
                    .  +---+--+  +------+  +--+---+  .
                    .......|..................|.......
                           |                  |
             +------+  +---+--+            +--+---+  +------+
   IPv6 host-+ IS L |--| IS M |            | IS N |--| IS O +-IPv6 host
             +------+  +------+            +------+  +------+

   ISs A, B, C, D, E and F are an IPv4-only "subnetwork"; therefore ISs
   H, J, M and N must be capable of automatically encapsulating IPv6
   over IPv4.

   IS I is an IPv6-only "subnetwork", therefore ISs H and J must be
   capable of automatically encapsulating IPv4 over IPv6.

   ISs I and B support no network layer protocol in common and must
   therefore not form an adjacency.

   ISs G and K must forward IPv4 and IPv6 traffic and must therefore
   both be dual.

   ISs L and O need to forward only IPv6 and therefore may be either
   IPv6 only or dual.

Christian                 Expires March 2003                         12

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

5.LAN interfaces

   As stated in section 4, ISs must not have adjacencies if they are
   able to forward packets that the neighbour does not support, unless
   they can automatically encapsulate.

   Consequently an IPv4-only and an IPv6-only IS may exist in the same
   area and on the same LAN, but will have no adjacency with each
   other.

   If there is a dual IS on the LAN that does support automatic
   encapsulation, then both the IPv4 and the IPv6 IS will have an
   adjacency with it.

5.1. PseudoNode election process

   ISs can choose a Designated IS (DIS) only from valid adjacencies,
   therefore an IPv4-only IS cannot elect an IPv6-only IS as DIS, and
   vice versa.

   In this case there are effectively two separate "sub-LANs" on the
   physical LAN.  The IPv4-only ISs form one "sub-LAN" and elect a DIS,
   whilst the IPv6-only ISs form a second "sub-LAN" and a second DIS.

   Clearly a dual automatically encapsulating IS needs to be capable of
   connecting to both "sub-LANs", and so MUST participate in both
   pseudonode election processes.

   In this case a dual IS that does not support automatic
   encapsulation MUST NOT have adjacencies both with IPv4-only and with
   IPv6-only ISs, as this would form a leak between the two
   "subnetworks" and may cause packet loss.  Therefore such a dual IS
   simply cannot appear on such a LAN, and a modified pseudonode
   election process does not apply to it.  The following scenarios must
   be considered:-

   1.The dual automatic encapsulating IS might win neither election
     process, in which case it is not DIS.

   2.The dual automatic encapsulating IS might be elected DIS by the
     IPv4 ISs on the LAN, but not the IPv6 ISs; in this case it MUST
     create a pseudonode, and the pseudonode MUST declare adjacencies
     with all IPv4-capable ISs on the LAN (the IPv4-only ISs and the
     dual IPv4/IPv6 ISs on the LAN), but MUST NOT declare adjacencies
     with any IPv6-only ISs.

   3.The dual automatic encapsulating IS might be elected DIS by the
     IPv6 ISs on the LAN, but not the IPv4 ISs; in this case it MUST
     create a pseudonode, and the pseudonode MUST declare adjacencies
     with all IPv6-capable ISs on the LAN (the IPv6-only ISs and the
     dual IPv4/IPv6 ISs on the LAN), but MUST NOT declare adjacencies
     with any IPv4-only ISs.

Christian                 Expires March 2003                         13

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

   4.The dual automatic encapsulating IS might be elected DIS both by
     the IPv4 ISs and by the IPv6 ISs; in this case it MUST create one
     pseudonode which MUST declare adjacencies with all IPv4-capable
     ISs on the LAN, with all-IPv6 capable ISs on the LAN, and with
     the dual automatic encapsulating IS.

   The first three scenarios will always forward traffic correctly in
   on a LAN and will result in packets being encapsulated before being
   forwarded across incompatible ISs.

   The fourth scenario relies on other ISs on the LAN conforming to
   ISO/IEC 10589 section C.2.5 item "h" or RFC 1195 [1] section
   C.1.4 step 0 clause 8.  ISs that do not will drop packets
   rather than send traffic to a dual IS for automatic encapsulation,
   if the dual IS is the DIS, and if non-compatible ISs on the same LAN
   are on the shortest path.  This is because the psuedonode declares
   itself to be between two ISs that are actually incompatible and
   therefore should not share an adjacency.  The SPF algorithm in one
   IS on the LAN may find other ISs on the LAN to be the shortest path
   to certain destinations, through the pseudonode, but then cannot
   actually forward traffic to them as there is no adjacency.  This
   can result in packets being dropped rather than being encapsulated
   in order to traverse incompatible ISs on the LAN.

   ISO/IEC 10589 section C.2.5 item "h" or RFC 1195 [1] section
   C.1.4 step 0 clause 8 causes an IS to forward traffic to the DIS in
   this scenario, which in this case is an automatic encapsulation IS.
   Thus if all ISs on the LAN that have a lower priority than the
   automatic encapsulation IS are conformant with this clause then
   packets are forwarded and encapsulated properly.

   Network administrators need to ensure that ISs that do not conform
   with ISO/IEC 10589 section C.2.5 item "h" or RFC 1195 [1] section
   C.1.4 step 0 clause 8 have a higher priority than any automatic
   encapsulation ISs on the same LAN if it is a mixed protocol LAN.


5.2. LSP update process

   ISO/IEC 10589 [2] states in section 7.3.15.1 that an LSP received
   that does not come from a valid adjacency must be discarded.  A
   strict single protocol implementation will therefore reject LSPs
   that are transmitted onto a LAN interface by an IS that it has
   rejected an adjacency with due to no network-layer protocol in
   common (or by manual configuration or no subnet in common).

   Thus if an IPv4-only IS transmits an LSP onto a LAN then an IPv6-
   only IS can receive such an LSP only from a dual automatic
   encapsulating IS.  Normally a dual IS will only forward such an LSP
   during periodic LSP database synchronisation.



Christian                 Expires March 2003                         14

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

   Dual automatic encapsulating ISs are therefore required to have
   modified LSP flooding behaviour so that OSI-only, IPv4-only or IPv6-
   only ISs do not need to wait for the next LSP database
   synchronisation event.

   Dual automatic encapsulating ISs MUST check incoming LSPs that
   arrive on LAN interfaces to see if they come from a neighbour that
   supports all of the network layer protocols that the dual automatic
   encapsulating IS does.  This MUST be achieved by inspection of the
   "protocols supported" TLV in Hello packets received from that
   neighbour.

   If the LSP is received from a neighbour that does support all of the
   network layer protocols that the dual or multilingual IS supports,
   then the dual automatic encapsulating IS SHALL behave as per ISO/IEC
   10589 and unset the SRM flag for that LSP on that LAN interface if
   it already has the LSP, or shall flood it out of all other
   interfaces if it does not already have the LSP.

   If the LSP is received from a neighbour that does not support all of
   the network layer protocols that the dual automatic encapsulating IS
   supports, and, if it does not already have the LSP then the dual
   automatic encapsulating IS SHALL set the SRM flag for that LSP on
   the LAN interface over which the LSP was received, in addition to
   all other interfaces, resulting in the dual automatic encapsulating
   IS re-transmitting the LSP onto the LAN.

   In this way if an LSP is transmitted onto the LAN by an IPv4-only
   IS, then one of the dual automatic encapsulating ISs will re-
   transmit the LSP, so that it may be received on a valid adjacency by
   IPv6-only ISs on the LAN and vice versa.


5.3. Redirects

   If a dual automatic encapsulating IS originates an ICMP redirect
   request, the request MUST not redirect IPv4 packets from an IPv4
   capable IS to a non-IPv4 capable IS, or redirect IPv6 packets from
   an IPv6 capable IS to a non-IPv6 capable IS.  Likewise if a dual
   automatic encapsulating router originates ISO/IEC 9542[5] Redirect
   PDUs, the redirect MUST not redirect CLNS packets from an OSI
   capable IS to a non-OSI capable IS.


6.Level-1, level-2 ISs

   Although this mechanism allows "subnetworks" to exist in a level-1
   area or level-2 subdomain that do not support all of the network
   layer protocols present in the area or subdomain, packets must still
   be able to get in and out of an area and onto the level-2 subdomain.



Christian                 Expires March 2003                         15

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

   It is therefore recommended that all ISs that support both level-1
   and level-2 can forward all network layer protocols that exist in
   the area.

   However this may not be possible, if for example an existing network
   is using this mechanism to upgrade parts of an area to support a new
   network layer protocol, but a level-1, level-2 IS cannot be
   upgraded.

   In this case another IS that does support the new network layer
   protocol must become the gateway for that protocol. This can be
   achieved by configuration either of a default route, or a collection
   of static routes that cover all possible "out of area" destinations.

   Note that RFC 1195 [1] forbids default routes in level-1 LSPs
   (however this does not reduce its usefulness as a solution).

   This gateway IS must then tunnel all "out of area" packets of the
   new network layer protocol across the incompatible level-1,level-2
   IS to another IS somewhere in the level-2 subdomain or other routing
   protocol.

   Multiple gateways may be configured for redundancy, in this case a
   gateway SHOULD gate advertisement of a default route on the validity
   of the tunnel that it is using to send "out of area" packets across.
   i.e. the IS SHOULD somehow detect that the other end of the tunnel
   is alive and contactable, and if it is not, it SHOULD stop
   advertising a default route into the area. This can be achieved by
   running some other routing protocol such as RIP or OSPF across the
   tunnel, or another instance of IS-IS, for example.

7.Security Considerations

   7.1 Injection of IP and CLNP packets into the network

      An IS that employs automatic encapsulation is required to
      unencapsulate any incoming packet that is of a an advertised
      encapsulation mode, and forward the contents.

      Consequently packets may potentially be injected at such an IS
      in an encapsulated form that maybe would normally be filtered
      at the edge of a routing domain, but which are now an
      encapsulation packet.

      Such a risk is not unique to automatic encapsulation, but is
      present in manually configured tunnels too, such as RFC 2784 [4]
      GRE tunnels.

      Encapsulated packets should never arrive from any source other
      than another IS in the same level-1 area or level-2 subdomain,
      and this MAY then be used as the basis of a security filter.


Christian                 Expires March 2003                         16

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

      In any case such a mechanism will allow an attacker only to
      inject packets into a network; it does not supply a return path.

   7.2 Injection of other packets into the network

      Section 3.4 states that incoming packets SHOULD be discarded if
      they are not of an inner-protocol type that the IS advertised as
      being able to unencapsulate.

      This clause is an important security feature as it prevents
      false routing packets and consequent false routes from being
      injected into the network.


8.References

   [1]   RFC 1195
         Use of OSI IS-IS for Routing in TCP/IP and Dual Environments.

   [2]   RFC 1701  Generic Routing Encapsulation (GRE).

   [3]   RFC 1702  Generic Routing Encapsulation over IPv4 networks.

   [4]   RFC 2784  Generic Routing Encapsulation (GRE).

   [5]   RFC 3147  Generic Routing Encapsulation over CLNS Networks.

   [6]   RFC 2893  Transition Mechanisms for IPv6 Hosts and Routers.

   [7]   RFC 2003  IP Encapsulation within IP.

   [8]   ISO 9577 and ITU-T X.263  Information Technology - Protocol
         Identification In The Network Layer.

   [9]   http://www.iana.org/assignments/ethernet-numbers.

   [10]  ITU-T Recommendation G.7712 v1.2  Architecture and
         Specification of Data Communication Network.

   [11]  RFC 1191  Path MTU discovery.

   [12]  draft-ietf-isis-ipv6-02.txt  Routing IPv6 with IS-IS


9.Acknowledgements

   Jonathan Sadler, Mike Shand and Les Ginsberg have made various
   suggestions that have improved the automatic encapsulation scheme
   way beyond what was originally presented.




Christian                 Expires March 2003                         17

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

10.Author's Address

   Philip Christian,
   Christian Tena LTD,
   Essex,
   UK
   Email: philip.christian@christiantena.co.uk

11.Copyright Notice

   Copyright (C) The Internet Society 2001.  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 organisations, 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.


















Christian                 Expires March 2003                         18

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

                                  Annex A
                      Updates to Dijkstra's Algorithm

   The following Annex contains the full Dijkstra's algorithm including
   extensions to support automatic tunnelling. It is based on the
   algorithm as specified in RFC 1195 [1]. The algorithm describes the
   behaviour of a dual protocol IS capable of supporting network-layer
   protocols A and B.  A and B represent any pair of network-layer
   protocols such as CLNP, IPv4 or IPv6.

   A1.  Changes to the Database

   The PATHS and TENTS database should be updated to contain an
   extension to the {Adj(N)}, element of the triple. The adjacency N
   element will contain two corresponding Dual Protocol Support
   (ABDP(N)-BADP(N)) entries which will represent the System ID of the
   first Dual router on the path from S to N capable of de-
   encapsulating A over B tunnelled packets (ABDP(N)) and the System ID
   of the first dual router on that path from S to N capable of de-
   encapsulating B over A tunnelled packets (BADP(N). If no *DP(N)
   router exists on the PATH then this value will be set to zero. If
   multiple Adj(N) entries exist in either the TENTS or the PATHS
   database then each adjacency will have corresponding *DP(N) entries.
   Thus each triple will take the format
   <N,d(N),{Adj(N)-ABDP(N)-BADP(N)}>
   If the value of ABDP(N) is set to 0 then this means that no dual
   router exists on the path to the destination capable of de-
   encapsulating and encapsulating A over B packets.
   If the value of BADP(N) is set to 0 then this means that no dual
   router exists on the path to the destination capable of de-
   encapsulating and encapsulating B over A packets.

   A2.  Changes to the Algorithm

   The SPF algorithm specified in section C.2.3 of [1] is amended to
   appear as follows:

   Step 0: Initialize TENT and PATHS to empty. Initialize tentlength to
   [internalmetric=0, externalmetric=0].

   (tentlength is the pathlength of elements in TENT that we are
   examining.)

   1) Add <SELF,0,W-0-0> to PATHS, where W is a special value
      indicating traffic to SELF is passed up to internal processes
      (rather than forwarded).

   2) Now pre-load TENT with the local adjacency database (Each entry
      made to TENT must be marked as being either an End System or a
      router to enable the check at the end of Step 2 to be made
      correctly - Note that each local IP reachability entry is
      included as an adjacency, and is marked as being an End System).

Christian                 Expires March 2003                         19

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

      For each adjacency Adj(N) (including level 1 OSI Manual
      Adjacencies, or level 2 OSI enabled reachable addresses, and IP
      reachability entries) on enabled circuits, to system N of SELF in
      state "Up" compute:

         d(N) = cost of the parent circuit of the adjacency (N),
         obtained from metric.k , where k = one of {default metric,
         delay metric, monetary metric, error metric}

         Adj(N)-ABDP(N)-BADP(N) = the adjacency number of the
         adjacency to N ,the SID of the next-hop router along the path
         to the  neighbour capable of de-encapsulating A over B packets
         and the SID of the next-hop router along the path to the
         neighbour capable of de-encapsulating B over A packets . In
         this case i.e. during initialisation both DP values will be
         set to 0

   3) If a triple <N,x,{Adj(M)-ABDP(N)-BADP(N)}> is in TENT, then:

         If x = d(N), then {Adj(M)-ABDP(N)-BADP(N)} <--- {Adj(M)-
         ABDP(M)-BADP(M)} U {Adj(N)-ABDP(N)-BADP(N)}.

   4) If N is a router or an OSI End System entry, and there are now
      more adjacencies in {Adj(M)} than maximumPathSplits, then remove
      excess adjacencies as described in Clause 7.2.7 of [1]. If N is
      an IP Reachability Entry, then excess adjacencies may be removed
      as desired. This will not effect the correctness of routing, but
      may eliminate the determinism for IP routes (i.e., IP packets
      still follow optimal routes within an area, but where multiple
      equally good routes exist, will not necessarily follow precisely
      the route that any one particular router would have anticipated).

   5) If x < d(N), do nothing.

   6) If x > d(N), remove <N,x,{Adj(M)-ABDP(M)-BADP(M)}> from TENT and
      add the triple <N,d(N),{Adj(N) -ABDP(N)-BADP(N)}>.

   7) If no triple <N,x,{Adj(M) -ABDP(M)-BADP(M) }> is in TENT, then
      add <N,d(N),{Adj(N) -ABDP(N)-BADP(N)}> to TENT.

   8) Now add systems to which the local router does not have
      adjacencies, but which are mentioned in neighbouring pseudonode
      LSPs. The adjacency for such systems is set to that of the
      designated router.
      Note that this does not include IP reachability entries from
      neighbouring pseudonode LSPs. In particular, the pseudonode LSPs
      do not include IP reachability entries.

   9) For all broadcast circuits in state "On", find the pseudonode LSP
      for that circuit (specifically, the LSP with number zero and with
      the first 7 octets of LSPID equal to LnCircuitID for that
      circuit, where n is 1 (for level 1 routing) or 2 (level 2

Christian                 Expires March 2003                         20

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

      routing)). If it is present, for all the neighbours N reported in
      all the LSPs of this pseudonode which do not exist in TENT add an
      entry <N,d(N),{Adj(N)-ABDP(N)-BADP(N)}> to TENT, where:

         d(N) = metric.k  of the circuit.
         Adj(N) = the adjacency number of the adjacency to the DR.

   10) Go to Step 2.

   Step 1: Examine the zeroeth link state PDU of P, the system just
   placed on PATHS (i.e., the LSP with the same first 7 octets of LSPID
   as P, and LSP number zero).

   1) If this LSP is present and the "Infinite Hippity Cost" bit is
      clear, then for each Adj(*)-ABDP(*)-BADP(*) pair in the PATHS
      database for P:-

         If this is not a pseudonode LSP and if ABDP(*) is equal to
         zero then check the unencapsulation capability field of the
         LSP, if it supports A over B then set the ABDP(P) value for
         this adjacency to be the system ID of P.

         If this is not a pseudonode LSP and if BADP(*) is equal to
         zero then check the unencapsulation capability field of the
         LSP, if it supports B over A then set the BADP(P)value for
         this adjacency to be the system ID of P.

   2) If this LSP is present, and the "Infinite Hippity Cost" bit is
      clear, then for each LSP of P (i.e., all LSPs with the same first
      7 octets of LSPID and P, irrespective of the value of LSP number)
      compute:

         dist(P,N) = d(P) + metric.k(P,N)

      for each neighbour N (both End System and router) of the system
      P. If the "Infinite Hippity Cost" bit is set, only consider the
      End System neighbours of the system P.
      Note that the End Systems neighbours of the system P includes IP
      reachable address entries included in the LSPs from system P.
      Here, d(P) is the second element of the triple

         <P,d(P),{Adj(P)-ABDP(P)-BADP(P)}>

      and metric.k(P,N) is the cost of the link from P to N as reported
      in P's link state PDU.

   3) If dist(P,N) > MaxPathMetric, then do nothing.

   4) If <N,d(N),{Adj(N) - ABDP(N)-BADP(N)}> is in PATHS, then do
      nothing.

         Note: d(N) must be less than dist(P,N), or else N would not

Christian                 Expires March 2003                         21

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

         have been put into PATHS. An additional sanity check may be
         done here to ensure that d(N) is in fact less than dist(P,N)

   6) If a triple <N,x,{Adj(N) -ABDP(N)-BADP(N)}> is in TENT, then:

     a) If x = dist(P,N), then {Adj(N), ABDP(N)-BADP(N)} <-- {Adj(N) -
        ABDP(N)-BADP(N)} U {Adj(P) -ABDP(P)-BADP(N)}.

          Note that even if the value of Adj(N) is equal to the value
          Adj(P) but the corresponding values of either ABDP(P) or
          BADP(P) and ABDP(N) or BADP(N) are different then this should
          be treated as a different adjacency and will represent a
          different path to the destination.


     b) If N is a router or an OSI end system, and there are now more
        adjacencies in {Adj(N)} than maximumPath Splits, then remove
        excess adjacencies, as described in clause 7.2.7 of [1]. For IP
        Reachability Entries, excess adjacencies may be removed as
        desired. This will not effect the correctness of routing, but
        may eliminate the determinism for IP routes (i.e., IP packets
        will still follow optimal routes within an area, but where
        multiple equally good routes exist, will not necessarily follow
        precisely the route that any one particular router would have
        anticipated).

     c) if x < dist(P,N), do nothing.

     d) if x > dist(P,N), remove <N,x,{Adj(N)- ABDP(N)-BADP(N)}> from
        TENT, and add
        <N,dist(P,N),{Adj(P)- ABDP(P)-BADP(P)}>

   7) if no triple <N,x,{Adj(N)}> is in TENT, then add
      <N,dist(P,N),{Adj(P)}> to TENT.

   Step 2: If TENT is empty, stop. Else:

   1) Find the element <P,x,{Adj(P)-ABDP(P)-BADP(P)}>, with minimal x
      as follows:

     a) If an element <*,tentlength,*> remains in TENT in the list for
        tentlength, choose that element. If there are more than one
        elements in the list for tentlength, choose one of the elements
        (if any) for a system which is a pseudonode in preference to
        one for a non-pseudonode. If there are no more elements in the
        list for tentlength, increment tentlength and repeat Step 2.

     b) Remove <P,tentlength,{Adj(P)-ABDP(P)-BADP(P)}> from TENT.

     c) Add <P,d(P),{Adj(P)-ABDP(P)-BADP(P)}> to PATHS.



Christian                 Expires March 2003                         22

Internet Draft                                           September 2002
                    IS-IS Automatic Encapsulation

     d) If this is the Level 2 Decision Process running, and the system
        just added to PATHS listed itself as Partition Designated Level
        2 Intermediate system, then additionally add
        <AREA.P,d(P),{Adj(P)}> to PATHS, where AREA.P is the Network
        Entity Title of the other end of the Virtual Link, obtained by
        taking the first AREA listed in P's LSP and appending P's ID.

     e) If the system just added to PATHS was an end system, go to step
        2. Else go to Step 1.

   NOTE - In the level 2 context, the "End Systems" are the set of
   Reachable Address Prefixes (for OSI), the set of Area Addresses with
   zero cost (again, for OSI), plus the set of IP reachability entries
   (including both internal and external).







































Christian                 Expires March 2003                         23