5.3 Merge window, part 1

Posted Jul 15, 2019 14:47 UTC (Mon) by imMute (guest, #96323)
In reply to: 5.3 Merge window, part 1 by ianmcc
Parent article: 5.3 Merge window, part 1

That's how route aggregation works today. Route lookups are already fast using hardware TCAM. Variable length addresses would make the TCAM implementation harder. Or, more likely, they'd just make the TCAM addresses the max size allowed by the variable length spec. And you'd end up with smaller tables that wasted space.

5.3 Merge window, part 1

Posted Jul 15, 2019 15:10 UTC (Mon) by farnz (subscriber, #17727) [Link]

Note, too, that a variable length address space limited to N bits of address can be mapped into a fixed size address space of size N+1 bits. You add a prefix bit which is 1 if the next N bits are the full address, or 0 otherwise, and do this recursively. You can then unmap by counting leading 0s to retrieve the address size, strip the next 1 bit, and the remainder is the address.

In other words, unless your variable length address is greater than 127 bits in maximum size, it can be entirely mapped into IPv6.

5.3 Merge window, part 1

Posted Jul 16, 2019 23:56 UTC (Tue) by mtaht (subscriber, #11087) [Link]

I've kind of wondered how much of the internet, particularly the IPv6 portion, is actually routed by TCAM based hardware. Software routing in SDR and Linux/BSD based implementations seems to be on the rise.