IS-IS over IPv6

The original specification of IS-IS defines that PDUs are transmitted directly on the link-layer. With this design comes the problem that specification work is required each time a new link-layer should be supported by IS-IS. By transmitting IS-IS PDUs as IPv6 packets, this specification work can be avoided and any link-layer supporting IPv6 can be used. Among other things, this allows to route IPv6 with IS-IS on any link supporting IPv6. This specification does not make changes to the general operation of IS-IS and any existing mechanisms should be kept as-is. The only change made by this draft is the format of IS-IS PDUs on the wire.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Link-local IPv6 addresses are used to transmit and receive IS-IS PDUs. Routers SHALL set the source address of transmitted PDUs to the link-local address of the outgoing interface. IPv6 link-local multicast is used as destination for the packets. The PDUs that would be sent to ALL-L1-IS when sending them directly on top of the link-layer MUST be sent to the IPv6 multicast group <TBD1> instead. Respectively, PDUs that would be sent to ALL-L2-IS MUST be sent to the multicast group <TBD2>.

The packets SHOULD be transmitted with type of service set to Internetwork control.

To transmit IS-IS PDUs over IPv6, they are encapsulated as IPv6 payload without any transport layer protocol. For that purpose, protocol number 124 is used. That number was assigned by IANA for IS-IS over IPv4. The PDUs are transmitted as IPv6 payload starting at the NLPI.

Using the ethernet MAC address as SNPA on LAN links is not practical for this application since the goal of this extension is to become independent from specific link-layer properties. Therefore, treat the whole 16 byte of the IPv6 address as SNPA. Since the SNPA is only used internally to each router and not put into any IS-IS PDUs, no protocol datastructures need to be modified for this, but implemenations need to deal with this new SNPA length internally.

Hello PDUs that are subject to padding SHALL be padded so that the total IPv6 packet size matches the MTU of the link they are transmitted over. Fragmentation SHALL NOT be used on hellos, and a system receiving an IPv6 encapsulated SHALL verify that the hello has not been subject to fragmentation. Other transmitted PDUs MAY be fragmented to allow the transport of LSPs that result in larger packets than the IPv6 MTU.

IS-IS implementations supporting IS-IS over IPv6 SHOULD provide a method that allows to choose between and IS-IS over IPv6 encapsulation for each interface. Implementations MUST NOT transmit or process ISO 10589:2002 PDUs on interfaces running in IS-IS over IPv6 mode and they MUST NOT transmit or process IS-IS over IPv6 PDUs on interfaces running in ISO 10589:2002 mode.

There has been previous work to specify operation of IS-IS over IPv4 which has been used as a reference for this work.

For this protocol, IANA should assign two IPv6 multicast group IDs <TBD1> and <TBD2> in the IPv6 Multicast Address Space Registry. Also, IANA should change the name of protocol 124 in the Internet Protocol Number registry from "ISIS over IPv4" to "ISIS".

Routers implementing this encapsulation of IS-IS over IPv6 can be susceptible to receiving and processing IS-IS over IPv6 packets that have not been originated by a router that is on-link. For example, someone with malicious intent could send IS-IS over IPv6 packets to a global unicast address of a router via multiple hops. For this reason, routers implementing IS-IS over IPv6 need to verify that the origin of each received IS-IS over IPv6 packet is indeed on-link. To do this, routers implementing IS-IS over IPv6 SHALL implement generalized TTL security as described in . Since ttl security is mandatory for IS-IS over IPv6, any packet received with a TTL differing from 255 can be classified as "Dangerous" and SHALL be dropped.