(such as delivering the packet via level 1 routing to the correct
destination, or a more specific level 2 route) will automatically
take precedence according to the forwarding rules specified above.
Less desireable routes (such as using a level 2 external route to the
"default route" entry) are not possible because other level 2 routers
will believe the summary addresses advertised by this router.
C.2.2 Reduction of IP Forwarding Databases
The multiple forwarding databases used in the basic forwarding method
in section C.2.1 can be reduced, by combining the multiple databases
into one database for each supported TOS.
For reduction of IP forwarding databases, it is assumed that for any
two overlapping address entries, either the entries are identical, or
one range contains the other. In other words, for any two [IP
address, subnet mask] entries A and B, if there is at least one IP
address which matches both entries, then either: (i) the two entries
are identical; or (ii) entry A contains entry B (i.e., any IP address
which matches entry B also matches entry A); or (iii) entry B
contains entry A (any IP address which matches entry A also matches
entry B).
Non-contiguous subnet masks can be configured to violate this
assumption. For example, consider the two entries:
- A=[address="01010101 00000101 00000000 00000000",
mask="11111111 00001111 00000000 00000000"]
- B=[address="01010101 01010000 00000000 00000000",
mask="11111111 11110000 00000000 00000000"]
In this case neither entry contains the other. Specifically;
- there are IP addresses which match both A and B (e.g.,
"01010101 01010101 xxxxxxxx xxxxxxxx"),
- there are IP addresses which match A but not B (e.g.,
"01010101 11110101 xxxxxxxx xxxxxxxx")
- there are IP addresses which match B but not A (e.g.,
"01010101 01011111 xxxxxxxx xxxxxxxx").
The reduction of the multiple forwarding databases for each TOS to a
single database for each TOS is based on the use of "best match"
routing, combined with reduction of the entries placed in the
forwarding database in order to eliminate entries which are not to be
selected (based on the order of preference of routes specified in
section 3.10). The specific algorithm for creation of the IP
forwarding database can be described as follows:
1) Make use of the the Dijkstra algorithm described in section C.1 to
create separate forwarding databases for each supported TOS for
level 1 routes, level 2 internal routes, and level 2 external
routes. (Note that each entry in the forwarding database will
specify an [IP address, subnet mask] combination, as well as the
next hop router for IP packets which match that entry).
2) For each level 1 route entry which has been placed in the level 1
IP forwarding database for a specific TOS, copy that entry into
the overall IP forwarding database for that TOS.
3) For each route entry X which has been placed in the level 2 internal
IP forwarding database for a specific TOS, search for overlapping
entries in the level 1 IP forwarding database for the specific TOS,
and also for the default TOS:
a) If there is any overlapping entry Y in the level 1 forwarding
database (for the specfic TOS, or for the default TOS) such
that either (i) Y contains X; or (ii) Y is identically specific
to X; then ignore entry X.
b) Otherwise, copy entry X into the overall IP forwarding database
for the specific TOS.
4) For each route entry X which has been placed in the level 2
external IP forwarding database for a specific TOS, search for
overlapping entries in the level 1 IP forwarding database for
the specific TOS, and for the default TOS, and the level 2
internal IP forwarding database for the specific TOS, and for
the default TOS.
a) If there is an overlapping entry Y such that either (i) Y
contains X; or (ii) Y is identically specific to X; then
ignore entry X.
b) Otherwise, copy entry X into the overall IP forwarding database
for the specific TOS.
This method will result in one forwarding database for each supported
TOS. The forwarding of packets can then be simplified to be as follows:
1) For IP packets which map to the default TOS metric (or to an
unsupported TOS metric), search the default TOS forwarding
database and select the entry which has the most specific match.
Forward the packet accordingly.
2) For packets which map to a specific (non-default) TOS metric,
search the specific TOS forwarding database and select the entry
j which has the most specific match. Also search the default TOS
forwarding database and select the entry k which has the most
specific match. Forward the packet as follows:
a) If k is more specific than j, forward according to entry k
b) If j and k are equally specific, forward according to entry j
c) If j is more specific than k, forward according to entry j
Annex D
Use of the Authentication Field
The use of the Authentication field is outside of the scope of this
specification. However, there is a urgent need for simple error
detection/authentication mechanisms (such as a simple password) to
protect against certain types of errors. This annex therefore
proposes a possible use of this field.
This annex is included for informational purposes.
D.1 Authentication Field in IS-IS packets
All IS-IS packets may optionally include the authentication field, as
described in sections 3.9 and 5 of this specification. As described
in section 5, the authentication field is encoded as a (Code, Length,
Value) triplet. This annex proposes that the contents of the Value
field consist of a one octet "Authentication Type" field, plus a
variable length "Authentication Information" field. A specific value
of the "Authentication Type" is assigned to passwords, transmitted in
the clear without encryption. The authentication field is encoded as
follows:
7 Authentication Information -- Information used to authenticate
the PDU
x CODE - 133
x LENGTH - total length of the value field
x VALUE -
No. of Octets
+--------------------------------+
| Authentication Type | 1
+--------------------------------+
| Authentication Information | VARIABLE
+--------------------------------+
The Authentication Type is assigned as follows:
Type = 0 reserved
Type = 1 simple password
Type > 1 reserved
D.2 Authentication Type 1 - Simple Password
Using this authentication type, a variable length password is passed
in the clear (i.e., not encrypted) in the Authentication Information
field.
WARNING: The use of a simple password does not provide useful
protection against intentional misbehavior. In particular, since the
password is transmitted in the clear without encryption, it is easy
for a hostile system to intercept the passwords, and to transmit
authenticated packets. The use of simple passwords should be
considered only as a weak protection against accidental errors such
as accidental misconfiguration.
The password shall be configured on a per-link, per-area, and per-
domain basis. Specifically, when this form of authentication is used:
- IS-IS Hello and 9542 IS Hello packets shall contain the
per-link password
- Level 1 Link State Packets shall contain the per-area password
- Level 2 Link State Packets shall contain the per-domain password
- Level 1 Sequence Number Packets shall contain the per-area password
- Level 2 Sequence Number Packets shall contain the per-domain
password
Also, each of these three passwords shall be configured with: (i)
"Transmit Password", whose value is a single password, and (ii)
"Receive Passwords", whose value is a set of passwords. The transmit
password value is always transmitted. However, any password contained
in the receive password set will be accepted on receipt. This method
allows the graceful changing of passwords without temporary loss of
connectivity.
For example, consider the case that an area has the configured area
password "OLDAREAPASSWORD". In this case, the per-area transmit
password value is set to OLDAREAPASSWORD, and the per-area receive
password value is set to {OLDAREAPASSWORD}. Suppose that it is
desired to change the per-area password to "NEWERPASSWORD". The
first step would be to manually configure all of the routers in the
area to set the per-area receive password value to {OLDAREAPASSWORD,
NEWERPASSWORD}. When this step is complete, then all routers in the
area will still be using the old password OLDAREAPASSWORD in their
level 1 LSPs and SNPs. However, they will also accept the alternate
password NEWERPASSWORD. The second step would be to configure the
routers in the area to set the per-area transmit password to
NEWERPASSWORD. When the second step is complete, then all routers
will be using the new value of the per-area password, but will accept
the old value as well. Finally, the third step is to change all
routers in the area to have the per-area receive password set to
{NEWERPASSWORD}.
By configuring transmit and receive values for the passwords in this
manner, it is possible to maintain continuous correct operation. For
example, in the middle of the second step in the above example, some
of the routers in the area will be transmitting level 1 LSPs and SNPs
using the old password OLDAREAPASSWORD, and some will be transmitting
level 1 LSPs and SNPs using the new password NEWERPASSWORD. However,
during the second step of the transition all routers in the area will
accept level 1 LSPs and SNPs using either password.
Annex E
Interaction of the Integrated IS-IS with Brouters
A "brouter" is a device which operates an both a bridge and a router.
One possible type of brouter acts as a router for IP traffic, and
acts as a bridge for all other types of traffic.
Depending upon the manner in which a brouter is implemented, and
depending upon the network topology, there is an obscure bug which
can result from the interaction of the Integrated IS-IS protocol, and
brouters. This appendix gives an example of the bug, and proposes a
simple correction to the operation of brouters to correct the
problem.
This annex is included for informational purposes.
E.1 The Problem
Suppose that we have a brouter which treats IP packets as if it were
a normal IP router, and which treats all other packets as if it is a
bridge.
Suppose that two routers "X" and "Y" (which implement the integrated
IS-IS protocol), two Ethernets, and a brouter B are all connected as
follows:
| |
+----+---+ +----+---+
| Router | | Router |
| X | | Y |
+----+---+ +----+---+
| |
-----+------------+- -+------------+----
| |
+-+-----+-+
| Brouter |
| B |
+---------+
Here suppose that X and Y are running the Integrated IS-IS protocol,
and are both level 1 routers in the same area. Thus X and Y send IS-
IS Hello packets on the LAN. These Hello packets are received and
forwarded by the brouter (using normal bridge functions). Similarly,
X and Y receive each other's IS-IS LSP packets. In this way, it
appears to the Brouter that X and Y are exchanging OSI packets, and
so they are forwarded using normal bridge functions. It appears to X
and Y as if they are on the same LAN, and so they learn each others
48-bit Ethernet addresses and exchange routing information.
Now, suppose that X receives an IP packet, which it needs to forward
via Y. Since X thinks that it and Y are on the same Ethernet, it just
forwards the IP packet directly, using normal Ethernet encapsulation
and using the 48-bit Ethernet address of Y as the destination address
in the Ethernet header. Brouter B, when thinking as a bridge says:
"this is an IP packet, I don't forward this as a bridge". Brouter B,
when thinking like an IP router says: "this is an IP packet, I know
how to forward IP packets. However, this is sent to an Ethernet
address which is not me, thus I will ignore it". The result is that
the IP packet does not get forwarded.
This problem relates directly to the fact that X and Y are exchanging
OSI packets to determine the connectivity of the path between them,
but then are trying to send IP packets over the path. Also, there is
a device between X and Y on the path which treats OSI and IP packets
differently.
Also note that this problem can also occur in more complex
topologies, whenever a brouter is treating OSI and IP packets in a
fundamentally different manner.
E.2 Possible Solutions
E.2.1 More Sophisticated Brouter
One solution is that brouter B needs to be a little more
sophisticated. In particular, it needs to use the following rules:
- For packets which are not IP packets, act as a bridge (this is the
same as before).
- For IP packets sent to an Ethernet broadcast or multicast address,
act as an IP router (this is also the same as before).
- For IP packets sent to my own Ethernet 48-bit address(es), act as
an IP router (this is also the same as before).
- For IP packets sent to a single station 48-bit address which is not
one of my addresses, act at a bridge (THIS IS NEW).
With this change, the IP packet transmitted from X to Y is forwarded
by the brouter, acting as a bridge. This allows the Brouter and the
multiprotocol routers to interoperate properly.
E.2.2 Dual Router / Brouter
An alternate solution would be for the Brouter to route both OSI and
IP equally. If the Brouter used the integrated IS-IS for this
purpose, then it could be part of the same routing domain and
interoperate like any other dual router (except for the ability to
bridge other protocol suites). If it used other protocols for
routing OSI and IP, then it would need to be part of another routing
domain, and could interoperate with integrated IS-IS routers like any
other external router.