[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03
INTERNET-DRAFT Christian Tena LTD,
Category: Informational April 2003
Expires: October 2003
IS-IS Automatic Encapsulation
<draft-ietf-isis-auto-encap-03.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 October 2003 1
Internet Draft April 2003
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 [10].
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
As of March 2003 version 1.5 successfully passed through last call
and will therefore be published as version 2 of G.7712. There are
no differences in the automatic encapsulation mechanism between
version 1.2 and version 1.5.
The automatic encapsulation mechanism was also 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.
Christian Expires October 2003 2
Internet Draft April 2003
IS-IS Automatic Encapsulation
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.
draft-ietf-isis-proprietary-tlv-01.txt therefore reverted the
pseudonode election process back to that used in G.7712.
draft-ietf-isis-proprietary-tlv-02.txt converged further towards
G.7712 as it only documented 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).
draft-ietf-isis-proprietary-tlv-03.txt version explains how to
populate the LAN ID field, and some interoperability requirements on
how LAN ID is handled. This aspect had previously been overlooked.
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 [10].
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.
Christian Expires October 2003 3
Internet Draft April 2003
IS-IS Automatic Encapsulation
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.
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.
Christian Expires October 2003 4
Internet Draft April 2003
IS-IS Automatic Encapsulation
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.
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.
Christian Expires October 2003 5
Internet Draft April 2003
IS-IS Automatic Encapsulation
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
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[7].
47 is chosen simply as it is the IP protocol number for GRE
encapsulation.
Note that ITU-T G.7712 [8] mandates that GRE shall be used for all
combinations of CLNS, IPv4 and IPv6 over CLNS, IPv4 or IPv6.
Christian Expires October 2003 6
Internet Draft April 2003
IS-IS Automatic Encapsulation
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.
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 October 2003 7
Internet Draft April 2003
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 3.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 [9].
Christian Expires October 2003 8
Internet Draft April 2003
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 October 2003 9
Internet Draft April 2003
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
advertised 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 [9].
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 October 2003 10
Internet Draft April 2003
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[8]
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 October 2003 11
Internet Draft April 2003
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 October 2003 12
Internet Draft April 2003
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 October 2003 13
Internet Draft April 2003
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. LAN ID
ISO/IEC 10589 [6] states than an IS shall take the LAN ID from the
neighbour that it considers to be the DIS and use it as the LAN ID
in its own Hello PDUs. If there are two or more DISs on a LAN then
an automatically encapsulating IS will be able to use only one of
these LAN IDs in its own Hellos.
Clearly if an automatically encapsulating IS is elected DIS by
either OSI, IPv4 or IPv6 ISs then it MUST use its own LAN ID in
Hello PDUs as per ISO/IEC 10589.
ISO/IEC 10589 does not specify what ISs should do with the LAN ID
from other ISs that they do not consider DIS. If an automatically
encapsulating IS looses one of the pseudonode election processes
Christian Expires October 2003 14
Internet Draft April 2003
IS-IS Automatic Encapsulation
then it may be forced to incorrectly report the ID of the DIS as far
as some of its neighbours are concerned. Provided that these
neighbours ignore the LAN ID in its Hello PDUs this should not cause
a problem.
All ISs that are intended to interwork with automatic encapsulation
SHOULD ignore the LAN ID that is present in Hello PDUs from ISs that
they do not consider to be DIS, or at least SHOULD NOT behave in an
unexpected manner if they receive an inconsistent LAN ID from
another IS on the LAN that they do not consider DIS.
If the automatically encapsulating IS is DIS for neither IPv4, IPv6
nor OSI ISs, and, if there is more than one DIS present on the LAN,
then the automatically encapsulating IS will need to choose the LAN
ID from one of the DISs and put that into its own Hello PDUs, or it
needs to use some other value. Given that other ISs SHOULD be
ignoring the LAN ID in its Hello PDUs it probably does not matter
which is chosen. The choice of LAN ID in this scenario is for
further study. One possibility might be to use a special value to
indicate that mutiple pseudonodes are present on the LAN. Other
possibilities are to simply take the DIS for one particular
protocol and and use that, or to stick to the first one that was
considered DIS.
5.3. LSP update process
ISO/IEC 10589 [6] 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.
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.
Christian Expires October 2003 15
Internet Draft April 2003
IS-IS Automatic Encapsulation
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.4. 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.
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.
Christian Expires October 2003 16
Internet Draft April 2003
IS-IS Automatic Encapsulation
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.
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.
Christian Expires October 2003 17
Internet Draft April 2003
IS-IS Automatic Encapsulation
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] ISO/IEC 10589 Intermediate system to Intermediate system
intra-domain routeing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473).
[7] ISO 9577 and ITU-T X.263 Information Technology - Protocol
Identification In The Network Layer.
[8] ITU-T Recommendation G.7712 Architecture and
Specification of Data Communication Network.
[9] RFC 1191 Path MTU discovery.
[10] draft-ietf-isis-ipv6-05.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.
10.Author's Address
Philip Christian,
Christian Tena LTD,
Essex,
UK
Email: philip.christian@christiantena.co.uk
Christian Expires October 2003 18
Internet Draft April 2003
IS-IS Automatic Encapsulation
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 October 2003 19
Internet Draft April 2003
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 October 2003 20
Internet Draft April 2003
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 October 2003 21
Internet Draft April 2003
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 October 2003 22
Internet Draft April 2003
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 October 2003 23
Internet Draft April 2003
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 October 2003 24
Html markup produced by rfcmarkup 1.122, available from
https://tools.ietf.org/tools/rfcmarkup/