TLA/NLA structure for IPv6 addresses
The TLA/NLA allocation structure has been deprecated in RFC 3587, August 2003:
2. TLA/NLA Made Historic
The TLA/NLA scheme has been replaced by a coordinated allocation policy
defined by the Regional Internet Registries (RIRs) [IPV6RIR].
Part of the motivation for obsoleting the TLA/NLA structure is
technical; for instance, there is concern that TLA/NLA is not the
technically best approach at this stage of the deployment of IPv6.
Moreover, the allocation of IPv6 addresses is related to policy and
to the stewardship of the IP address space and routing table size,
which the RIRs have been managing for IPv4. It is likely that the
RIRs' policy will evolve as IPv6 deployment proceeds.
The IETF has provided technical input to the RIRs (for example,
[RFC3177]), which the RIRs have taken into account when defining
their address allocation policy.
RFC 2374 was the definition of addresses for Format Prefix 001
(2000::/3) which is formally made historic by this document. Even
though currently only 2000::/3 is being delegated by the IANA,
implementations should not make any assumptions about 2000::/3 being
special. In the future, the IANA might be directed to delegate
currently unassigned portions of the IPv6 address space for the
purpose of Global Unicast as well.
The Subnet Local Aggregator (SLA) field in RFC 2374 remains in
function but with a different name in [ARCH]. Its new name is
"subnet ID".
As can be seen in the last paragraph, the SLA has survived from the three, now being called subnet ID.
I think they should have obsoleted RFC 2450 together with RFC 2374 in RFC 3587. It does not make sense anymore, but it was only informational anyway.
Global Unicast prefixes
Your book is certainly wrong on the prefix. A bit prefix of 010 would mean the address space of 4000::/3, which is indeed Global Unicast as to RFC 4291, but does not identify the whole Global Unicast range, and is not even the one currently assigned by IANA, which is only 2000::/3 (i.e. address bits starting with 001).
In fact, almost all addresses before fc00::/128 (which starts the Unique Local Unicast address range) are Global Unicast, with the exceptions of the unspecified address :: and the loopback address ::1. There are some special ranges starting with the bits 000, like ::ffff:0:0/96 (IPv4-mapped IPv6 addresses) or 64:ff9b::/96 (for IPv4/IPv6 address translation, see RFC 6052). They allow Interface Identifiers with less than 64 bits. But all addresses starting with 001 have a 64 bit Interface Identifier (see RFC 4291, section 2.5.4, right from where you cited).
As I can see, the definition of the address structure from RFC 4291 is the most current one. There are three RFCs updating 4291 (RFC 5952, RFC 6052, RFC 7136), but none of them changes this structure.
Please note that the [IPV6RIR] reference points to the IPv6 registry policies, currently being ripe-589 which is "developed through joint discussions among the APNIC, ARIN and RIPE communities."
The document to which you link claims a specific IOS version. It may be incorrect; that would not be unusual in Cisco documentation.
In reality, having tested this on several IOS 15.X versions, you do not specify a prefix length on a link-local address since it is implicit for the link local address, as you saw in your CLI help (ipv6 address ? shows X:X:X:X::X IPv6 link-local address, the address without a prefix length). You do specify the prefix length on a non-link-local IPv6 address since there is no implicit prefix length.
Personally, I think specifying specific link-local addresses on your interfaces is going to be a giant pain, with little to no gain. Just enabling IPv6 on an interface will assign a unique link-local address, and that is all you really need. There is really no security risk about having the Interface ID being derived from the MAC address, since the address will never be seen off-link, and it won't be tracked across the Internet as a Global Scope address could be.
Best Answer
Because that would leave the option open for using other, non link-local networks that start with
fe80as the first word. For examplefe80:1:2:3::/64would not be infe80::/64, so theoretically could be used for something else, and that would be an undesired result.It also leaves the possibility that the current 54
0bits could be used for some enhancement of link-local addresses in the future. Basically, they are reserved bits. Often, protocols with reserved bits start using those bits to add functionality, later. For example, IPv6 multicast has scopes and flags, and there were originally two reserved flags, but one of those was used to add functionality to IPv6 multicast. Then, with only one reserved flag bit left, a later RFC expanded the number of flag bits to eight, even though only three flag bits are used.