Hank left a lovely comment on my Rearchitecting L3-Only Networks blog post:

What you describe is literally intra-area routing in CLNS.

He’s absolutely right (and I admitted as much during my IPv6 Microsegmentation presentations @ Troopers 15).

You might want to read this first

This is the fifth blog post in this series. You might want to read the first three before starting this one.

• Why is IPv6 layer-2 security so complex?
• What is layer-2 and why do we need it?
• Rearchitecting L3-Only Networks
• ARP processing in L3-Only Networks

Back to CLNS

Hank continued his analysis with comparison of routing protocols:

You need a protocol between routers. Some people seem to prefer BGP as the solution to any problem. But the most natural solution here, for IGP routing, would be to use an actual IGP. IS-IS would do a fine job. Not much worse than BGP. And less prone to configuration/network-design problems than BGP. You could advertise /32s. Or you could introduce a new TLV to make a proper destination.

IS-IS would probably be able to do the job in reasonably small environment. However, in a dense VLAN-based virtualization environment, a single L3 switch might need to insert several thousand routes into the physical routing domain, probably stretching IS-IS capabilities (and potentially killing OSPF with all those Type-5 LSAs).

It would be *minimal* work to actually implement this functionality into a proper IS-IS implementation. Just a small matter of programming.

The IS-IS implementation might not be an issue – carrying IPv4 host routes is a non-brainer; carrying host routes for multiple routing domains (VRFs) would require new TLVs. Anyone aware of an RFC/draft specifying such functionality (maybe Avaya documented what they’re doing with IS-IS in SPB deployments?)

You need a protocol for the routers to find out which EndStations are directly connected. In CLNS, that would be ESIS. In IPv4 you could indeed use ARP. In IPv6 you could use NDP. Or you could build a new proper host-router protocol (and use ARP until it catches on).

A proper host-to-router protocol, integrated with virtualization awareness (so that a VM re-advertises itself when it’s moved) would be ideal. In the meantime, implementations like Cisco DFA or Microsoft HNV (or VMware NSX for firewalling purposes) have to rely on all sorts of guesswork (listening to ARP/ND requests, DHCPv6 replies, or even gleaning source IP/IPv6 addresses).

Hank concluded his analysis with…

Of course all this will be impossible, because it reeks of CLNS. And therefore it must never ever be implemented in TCP/IP. Too bad, CLNS did it right.

Even worse, when IETF started designing next-generation IP protocol, a group of engineers actually suggested using TCP/UDP over CLNS (TUBA), but of course that idea never moved forward because the underlying protocol (and its “weird” concepts) had been designed in the wrong standardization body.

Regardless of its rejection in IETF, TUBA lives on – it’s been implemented in Cisco IOS and the last time I checked you were still able to telnet to a CLNS address.

To learn more about TUBA, read these RFCs:

• TCP and UDP with Bigger Addresses (TUBA – RFC 1347)
• Use of ISO CLNP in TUBA Environments (RFC 1561)
• DNS NSAP Resource Records (RFC 1706)
• Comparison of Proposals for Next Version of IP (RFC 1454)